Re: [PATCH v4 1/1] printf: add support for printing symbolic error names

[Uwe Kleine-König]

On Fri, Oct 11, 2019 at 03:36:17PM +0200, Rasmus Villemoes wrote:
> It has been suggested several times to extend vsnprintf() to be able
> to convert the numeric value of ENOSPC to print "ENOSPC". This
> implements that as a %p extension: With %pe, one can do
> 
>   if (IS_ERR(foo)) {
> pr_err("Sorry, can't do that: %pe\n", foo);
> return PTR_ERR(foo);
>   }
> 
> instead of what is seen in quite a few places in the kernel:
> 
>   if (IS_ERR(foo)) {
> pr_err("Sorry, can't do that: %ld\n", PTR_ERR(foo));
> return PTR_ERR(foo);
>   }
> 
> If the value passed to %pe is an ERR_PTR, but the library function
> errname() added here doesn't know about the value, the value is simply
> printed in decimal. If the value passed to %pe is not an ERR_PTR, we
> treat it as an ordinary %p and thus print the hashed value (passing
> non-ERR_PTR values to %pe indicates a bug in the caller, but we can't
> do much about that).
> 
> With my embedded hat on, and because it's not very invasive to do,
> I've made it possible to remove this. The errname() function and
> associated lookup tables take up about 3K. For most, that's probably
> quite acceptable and a price worth paying for more readable
> dmesg (once this starts getting used), while for those that disable
> printk() it's of very little use - I don't see a
> procfs/sysfs/seq_printf() file reasonably making use of this - and
> they clearly want to squeeze vmlinux as much as possible. Hence the
> default y if PRINTK.
> 
> The symbols to include have been found by massaging the output of
> 
>   find arch include -iname 'errno*.h' | xargs grep -E 'define\s*E'
> 
> In the cases where some common aliasing exists
> (e.g. EAGAIN=EWOULDBLOCK on all platforms, EDEADLOCK=EDEADLK on most),
> I've moved the more popular one (in terms of 'git grep -w Efoo | wc)
> to the bottom so that one takes precedence.
> 
> Signed-off-by: Rasmus Villemoes 

I like having an explicit code even better than relying on a plain %p to
emit the code. So please readd my

Acked-by: Uwe Kleine-König 

Best regards
Uwe


signature.asc
Description: PGP signature

RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.

[Jianyong Wu (Arm Technology China)]

Hi Paolo,

> -Original Message-
> From: Paolo Bonzini 
> Sent: Wednesday, October 9, 2019 5:13 PM
> To: Jianyong Wu (Arm Technology China) ; Marc
> Zyngier ; net...@vger.kernel.org; yangbo...@nxp.com;
> john.stu...@linaro.org; t...@linutronix.de; sean.j.christopher...@intel.com;
> richardcoch...@gmail.com; Mark Rutland ; Will
> Deacon ; Suzuki Poulose
> 
> Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; Steve Capper
> ; Kaly Xin (Arm Technology China)
> ; Justin He (Arm Technology China)
> ; nd ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
> 
> On 09/10/19 10:18, Jianyong Wu (Arm Technology China) wrote:
> > Hi Paolo,
> >
> >> -Original Message-
> >> From: Paolo Bonzini 
> >> Sent: Wednesday, October 9, 2019 2:36 PM
> >> To: Jianyong Wu (Arm Technology China) ; Marc
> >> Zyngier ; net...@vger.kernel.org;
> yangbo...@nxp.com;
> >> john.stu...@linaro.org; t...@linutronix.de;
> >> sean.j.christopher...@intel.com; richardcoch...@gmail.com; Mark
> >> Rutland ; Will Deacon
> ;
> >> Suzuki Poulose 
> >> Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; Steve Capper
> >> ; Kaly Xin (Arm Technology China)
> >> ; Justin He (Arm Technology China)
> >> ; nd ; linux-arm-
> >> ker...@lists.infradead.org
> >> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
> >>
> >> On 09/10/19 07:21, Jianyong Wu (Arm Technology China) wrote:
> >>> As ptp_kvm clock has fixed to arm arch system counter in patch set
> >>> v4, we need check if the current clocksource is system counter when
> >>> return clock cycle in host, so a helper needed to return the current
> >>> clocksource. Could I add this helper in next patch set?
> >>
> >> You don't need a helper.  You need to return the ARM arch counter
> >> clocksource in the struct system_counterval_t that you return.
> >> get_device_system_crosststamp will then check that the clocksource
> >> matches the active one.
> >
> > We must ensure both of the host and guest using the same clocksource.
> > get_device_system_crosststamp will check the clocksource of guest and
> > we also need check the clocksource in host, and struct type can't be
> transferred from host to guest using arm hypercall.
> > now we lack of a mechanism to check the current clocksource. I think this
> will be useful if we add one.
> 
> Got it---yes, I think adding a struct clocksource to struct
> system_time_snapshot would make sense.  Then the hypercall can just use
> ktime_get_snapshot and fail if the clocksource is not the ARM arch counter.
> 
> John (Stultz), does that sound good to you?  The context is that Jianyong
> would like to add a hypercall that returns a (cycles,
> nanoseconds) pair to the guest.  On x86 we're relying on the vclock_mode
> field that is already there for the vDSO, but being able to just use
> ktime_get_snapshot would be much nicer.
> 

Could I add struct clocksource to system_time_snapshot struct in next version 
of my patch set?

Jianyong Wu
Thanks

> Paolo

Re: [PATCH] arm64: dts: lx2160a: Correct CPU core idle state name

[Shawn Guo]

On Tue, Sep 17, 2019 at 03:33:56PM +0800, Ran Wang wrote:
> lx2160a support PW15 but not PW20, correct name to avoid confusing.
> 
> Signed-off-by: Ran Wang 

Applied, thanks.

Re: INFO: task hung in addrconf_verify_work (2)

[Eric Dumazet]

On 10/13/19 9:42 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    c208bdb9 tcp: improve recv_skip_hint for tcp_zerocopy_rece..
> git tree:   net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b6133b60
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d9be300620399522
> dashboard link: https://syzkaller.appspot.com/bug?extid=cf0adbb9c28c8866c788
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1548666f60
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11957d3b60
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cf0adbb9c28c8866c...@syzkaller.appspotmail.com
> 
> INFO: task kworker/0:2:2913 blocked for more than 143 seconds.
>   Not tainted 5.4.0-rc1+ #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/0:2 D27000  2913  2 0x80004000
> Workqueue: ipv6_addrconf addrconf_verify_work
> Call Trace:
>  context_switch kernel/sched/core.c:3384 [inline]
>  __schedule+0x94f/0x1e70 kernel/sched/core.c:4069
>  schedule+0xd9/0x260 kernel/sched/core.c:4136
>  schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4195
>  __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
>  __mutex_lock+0x7b0/0x13c0 kernel/locking/mutex.c:1103
>  mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118
>  rtnl_lock+0x17/0x20 net/core/rtnetlink.c:72
>  addrconf_verify_work+0xe/0x20 net/ipv6/addrconf.c:4520
>  process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
>  worker_thread+0x98/0xe40 kernel/workqueue.c:2415
>  kthread+0x361/0x430 kernel/kthread.c:255
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> 
> Showing all locks held in the system:
> 1 lock held by khungtaskd/1054:
>  #0: 88faae40 (rcu_read_lock){}, at: 
> debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:5337
> 3 locks held by kworker/0:2/2913:
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: 
> __write_once_size include/linux/compiler.h:226 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: 
> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: atomic64_set 
> include/asm-generic/atomic-instrumented.h:855 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: 
> atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: set_work_data 
> kernel/workqueue.c:620 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: 
> set_work_pool_and_clear_pending kernel/workqueue.c:647 [inline]
>  #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at: 
> process_one_work+0x88b/0x1740 kernel/workqueue.c:2240
>  #1: 8880a05b7dc0 ((addr_chk_work).work){+.+.}, at: 
> process_one_work+0x8c1/0x1740 kernel/workqueue.c:2244
>  #2: 89993b20 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20 
> net/core/rtnetlink.c:72
> 1 lock held by rsyslogd/8744:
>  #0: 8880899fa120 (>f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110 
> fs/file.c:801
> 2 locks held by getty/8833:
>  #0: 888090baedd0 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f292e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8834:
>  #0: 88808d0f6dd0 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f392e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8835:
>  #0: 888090148e10 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f252e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8836:
>  #0: 8880a7ab3750 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f412e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8837:
>  #0: 8880a7accf10 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f3d2e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8838:
>  #0: 88808d0f7650 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f352e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 2 locks held by getty/8839:
>  #0: 88808d162bd0 (>ldisc_sem){}, at: ldsem_down_read+0x33/0x40 
> drivers/tty/tty_ldsem.c:340
>  #1: c90005f112e0 (>atomic_read_lock){+.+.}, at: 
> n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156
> 1 lock held by syz-executor910/8859:
> 
> 

Re: [PATCH 3/3] soc: mediatek: pwrap: add support for MT6359 PMIC

[Argus Lin]

On Fri, 2019-10-04 at 01:27 +0200, Matthias Brugger wrote:
> 
> On 03/10/2019 09:48, Argus Lin wrote:
> > MT6359 is a new power management IC and it is used for
> > MT6779 SoCs. To define mt6359_regs for pmic register mapping
> > and pmic_mt6359 for accessing register.
> > 
> > Signed-off-by: Argus Lin 
> > ---
> >  drivers/soc/mediatek/mtk-pmic-wrap.c | 72 
> > 
> >  1 file changed, 72 insertions(+)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index fa8daf2..dd04318 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -111,6 +111,29 @@ enum dew_regs {
> > PWRAP_RG_SPI_CON13,
> > PWRAP_SPISLV_KEY,
> > 
> > +   /* MT6359 only regs */
> > +   PWRAP_DEW_CRC_SWRST,
> > +   PWRAP_DEW_RG_EN_RECORD,
> > +   PWRAP_DEW_RECORD_CMD0,
> > +   PWRAP_DEW_RECORD_CMD1,
> > +   PWRAP_DEW_RECORD_CMD2,
> > +   PWRAP_DEW_RECORD_CMD3,
> > +   PWRAP_DEW_RECORD_CMD4,
> > +   PWRAP_DEW_RECORD_CMD5,
> > +   PWRAP_DEW_RECORD_WDATA0,
> > +   PWRAP_DEW_RECORD_WDATA1,
> > +   PWRAP_DEW_RECORD_WDATA2,
> > +   PWRAP_DEW_RECORD_WDATA3,
> > +   PWRAP_DEW_RECORD_WDATA4,
> > +   PWRAP_DEW_RECORD_WDATA5,
> > +   PWRAP_DEW_RG_ADDR_TARGET,
> > +   PWRAP_DEW_RG_ADDR_MASK,
> > +   PWRAP_DEW_RG_WDATA_TARGET,
> > +   PWRAP_DEW_RG_WDATA_MASK,
> > +   PWRAP_DEW_RG_SPI_RECORD_CLR,
> > +   PWRAP_DEW_RG_CMD_ALERT_CLR,
> > +   PWRAP_DEW_SPISLV_KEY,
> 
> That looks like PWRAP_SPISLV_KEY from MT6358.
> 
> Regards,
> Matthias
> 
Yes, I think I can reuse the PWRAP_SPISLV_KEY of MT6358.

B.R.
Argus
> > +
> > /* MT6397 only regs */
> > PWRAP_DEW_EVENT_OUT_EN,
> > PWRAP_DEW_EVENT_SRC_EN,
> > @@ -197,6 +220,42 @@ enum dew_regs {
> > [PWRAP_SPISLV_KEY] =0x044a,
> >  };
> > 
> > +static const u32 mt6359_regs[] = {
> > +   [PWRAP_DEW_RG_EN_RECORD] =  0x040a,
> > +   [PWRAP_DEW_DIO_EN] =0x040c,
> > +   [PWRAP_DEW_READ_TEST] = 0x040e,
> > +   [PWRAP_DEW_WRITE_TEST] =0x0410,
> > +   [PWRAP_DEW_CRC_SWRST] = 0x0412,
> > +   [PWRAP_DEW_CRC_EN] =0x0414,
> > +   [PWRAP_DEW_CRC_VAL] =   0x0416,
> > +   [PWRAP_DEW_CIPHER_KEY_SEL] =0x0418,
> > +   [PWRAP_DEW_CIPHER_IV_SEL] = 0x041a,
> > +   [PWRAP_DEW_CIPHER_EN] = 0x041c,
> > +   [PWRAP_DEW_CIPHER_RDY] =0x041e,
> > +   [PWRAP_DEW_CIPHER_MODE] =   0x0420,
> > +   [PWRAP_DEW_CIPHER_SWRST] =  0x0422,
> > +   [PWRAP_DEW_RDDMY_NO] =  0x0424,
> > +   [PWRAP_DEW_RECORD_CMD0] =   0x0428,
> > +   [PWRAP_DEW_RECORD_CMD1] =   0x042a,
> > +   [PWRAP_DEW_RECORD_CMD2] =   0x042c,
> > +   [PWRAP_DEW_RECORD_CMD3] =   0x042e,
> > +   [PWRAP_DEW_RECORD_CMD4] =   0x0430,
> > +   [PWRAP_DEW_RECORD_CMD5] =   0x0432,
> > +   [PWRAP_DEW_RECORD_WDATA0] = 0x0434,
> > +   [PWRAP_DEW_RECORD_WDATA1] = 0x0436,
> > +   [PWRAP_DEW_RECORD_WDATA2] = 0x0438,
> > +   [PWRAP_DEW_RECORD_WDATA3] = 0x043a,
> > +   [PWRAP_DEW_RECORD_WDATA4] = 0x043c,
> > +   [PWRAP_DEW_RECORD_WDATA5] = 0x043e,
> > +   [PWRAP_DEW_RG_ADDR_TARGET] =0x0440,
> > +   [PWRAP_DEW_RG_ADDR_MASK] =  0x0442,
> > +   [PWRAP_DEW_RG_WDATA_TARGET] =   0x0444,
> > +   [PWRAP_DEW_RG_WDATA_MASK] = 0x0446,
> > +   [PWRAP_DEW_RG_SPI_RECORD_CLR] = 0x0448,
> > +   [PWRAP_DEW_RG_CMD_ALERT_CLR] =  0x0448,
> > +   [PWRAP_DEW_SPISLV_KEY] =0x044a,
> > +};
> > +
> >  static const u32 mt6397_regs[] = {
> > [PWRAP_DEW_BASE] =  0xbc00,
> > [PWRAP_DEW_EVENT_OUT_EN] =  0xbc00,
> > @@ -977,6 +1036,7 @@ enum pmic_type {
> > PMIC_MT6351,
> > PMIC_MT6357,
> > PMIC_MT6358,
> > +   PMIC_MT6359,
> > PMIC_MT6380,
> > PMIC_MT6397,
> >  };
> > @@ -1757,6 +1817,15 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
> > *dev_id)
> > .pwrap_write = pwrap_write16,
> >  };
> > 
> > +static const struct pwrap_slv_type pmic_mt6359 = {
> > +   .dew_regs = mt6359_regs,
> > +   .type = PMIC_MT6359,
> > +   .regmap = _regmap_config16,
> > +   .caps = PWRAP_SLV_CAP_DUALIO,
> > +   .pwrap_read = pwrap_read16,
> > +   .pwrap_write = pwrap_write16,
> > +};
> > +
> >  static const struct pwrap_slv_type pmic_mt6380 = {
> > .dew_regs = NULL,
> > .type = PMIC_MT6380,
> > @@ -1790,6 +1859,9 @@ static irqreturn_t pwrap_interrupt(int irqno, void 
> > *dev_id)
> > .compatible = "mediatek,mt6358",
> > .data = _mt6358,
> > }, {
> > +   .compatible = "mediatek,mt6359",
> > +   .data = _mt6359,
> > +   }, {
> > /* The MT6380 PMIC only implements a regulator, so we bind it
> >  * directly instead of using a MFD.
> >  */
> > --
> > 1.8.1.1.dirty
> > 

Re: [PATCH] dmaengine: sprd: Fix the link-list pointer register configuration issue

[Vinod Koul]

On 12-09-19, 13:47, Baolin Wang wrote:
> From: Zhenfang Wang 
> 
> We will set the link-list pointer register point to next link-list
> configuration's physical address, which can load DMA configuration
> from the link-list node automatically.
> 
> But the link-list node's physical address can be larger than 32bits,
> and now Spreadtrum DMA driver only supports 32bits physical address,
> which may cause loading a incorrect DMA configuration when starting
> the link-list transfer mode. According to the DMA datasheet, we can
> use SRC_BLK_STEP register (bit28 - bit31) to save the high bits of the
> link-list node's physical address to fix this issue.

Applied, thanks

-- 
~Vinod

Re: [PATCH v2 3/3] phy: qcom-qmp: Add SM8150 QMP UFS PHY support

[Vinod Koul]

On 08-10-19, 00:46, Jack Pham wrote:
> Hi Vinod,
> 
> On Fri, Sep 06, 2019 at 10:40:17AM +0530, Vinod Koul wrote:
> > SM8150 UFS PHY is v4 of QMP phy. Add support for V4 QMP phy register
> > defines and support for SM8150 QMP UFS PHY.
> > 
> > Signed-off-by: Vinod Koul 
> > Reviewed-by: Bjorn Andersson 
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qmp.c | 125 
> >  drivers/phy/qualcomm/phy-qcom-qmp.h |  96 +
> >  2 files changed, 221 insertions(+)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> > b/drivers/phy/qualcomm/phy-qcom-qmp.c
> > index 34ff6434da8f..92d3048f2b36 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> > @@ -164,6 +164,11 @@ static const unsigned int sdm845_ufsphy_regs_layout[] 
> > = {
> > [QPHY_PCS_READY_STATUS] = 0x160,
> >  };
> >  
> > +static const unsigned int sm8150_ufsphy_regs_layout[] = {
> > +   [QPHY_START_CTRL]   = 0x00,
> > +   [QPHY_PCS_READY_STATUS] = 0x180,
> > +};
> > +
> >  static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
> > QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
> > QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
> > @@ -878,6 +883,93 @@ static const struct qmp_phy_init_tbl 
> > msm8998_usb3_pcs_tbl[] = {
> > QMP_PHY_INIT_CFG(QPHY_V3_PCS_RXEQTRAINING_RUN_TIME, 0x13),
> >  };
> >  
> > +static const struct qmp_phy_init_tbl sm8150_ufsphy_serdes_tbl[] = {
> > +   QMP_PHY_INIT_CFG(QPHY_POWER_DOWN_CONTROL, 0x01),
> > +   QMP_PHY_INIT_CFG(QSERDES_COM_V4_SYSCLK_EN_SEL, 0xd9),
> 
> QSERDES_V4_COM? See below.
> 
> 
> 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h 
> > b/drivers/phy/qualcomm/phy-qcom-qmp.h
> > index 335ea5d7ef40..0eefd8621669 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp.h
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
> > @@ -313,4 +313,100 @@
> >  #define QPHY_V3_PCS_MISC_OSC_DTCT_MODE2_CONFIG40x5c
> >  #define QPHY_V3_PCS_MISC_OSC_DTCT_MODE2_CONFIG50x60
> >  
> > +/* Only for QMP V4 PHY - QSERDES COM registers */
> > +#define QSERDES_COM_V4_SYSCLK_EN_SEL   0x094
> 
> Should these rather be prefixed as QSERDES_V4_COM? There are already
> QSERDES_V3_COM_* in this header so the convention appears to be
> Q{SERDES,PHY}_VX_{COM,TX,RX,PCS}.

Yup, I seem to have missed that (Marc also pointed out)

> > +#define QSERDES_COM_V4_HSCLK_SEL   0x158
> > +#define QSERDES_COM_V4_HSCLK_HS_SWITCH_SEL 0x15C
> > +#define QSERDES_COM_V4_LOCK_CMP_EN 0x0A4
> > +#define QSERDES_COM_V4_VCO_TUNE_MAP0x10C
> 
> Nit: sort in ascending offset order, and make the hex values lowercase?

Sure will do

> 
> 
> 
> > +/* Only for QMP V4 PHY - PCS registers */
> > +#define QPHY_V4_PHY_START  0x000
> > +#define QPHY_V4_POWER_DOWN_CONTROL 0x004
> > +#define QPHY_V4_SW_RESET   0x008
> > +#define QPHY_V4_PCS_READY_STATUS   0x180
> > +#define QPHY_V4_LINECFG_DISABLE0x148
> > +#define QPHY_V4_MULTI_LANE_CTRL1   0x1E0
> > +#define QPHY_V4_RX_SIGDET_CTRL20x158
> > +#define QPHY_V4_TX_LARGE_AMP_DRV_LVL   0x030
> > +#define QPHY_V4_TX_SMALL_AMP_DRV_LVL   0x038
> > +#define QPHY_V4_TX_MID_TERM_CTRL1  0x1D8
> > +#define QPHY_V4_DEBUG_BUS_CLKSEL   0x124
> > +#define QPHY_V4_PLL_CNTL   0x02C
> > +#define QPHY_V4_TIMER_20US_CORECLK_STEPS_MSB   0x00C
> > +#define QPHY_V4_TIMER_20US_CORECLK_STEPS_LSB   0x010
> > +#define QPHY_V4_TX_PWM_GEAR_BAND   0x160
> > +#define QPHY_V4_TX_HS_GEAR_BAND0x168
> > +#define QPHY_V4_TX_HSGEAR_CAPABILITY   0x074
> > +#define QPHY_V4_RX_HSGEAR_CAPABILITY   0x0B4
> > +#define QPHY_V4_RX_MIN_HIBERN8_TIME0x150
> > +#define QPHY_V4_BIST_FIXED_PAT_CTRL0x060
> 
> Interesting. These offsets appear to be valid only for the UFS instance
> of the QMP PHY. For PCIe and USB the PCS layout is completely different.
> Wonder if we need to add _UFS_ to  the prefix to differentiate them? Or
> can this be deferred to when PCIe/USB PHY driver support for SM8150 gets
> added?

I didnt look at that yet. Are we sure that it is using V4 of the
instance?

-- 
~Vinod

Re: [PATCH 3/3] ARM: at91: add Overkiz KIZBOX3 board

[kbuild test robot]

Hi Kamel,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Kamel-Bouhara/Add-new-Overkiz-Kizbox3-support/20191014-054232
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm 

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

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/at91-kizbox3_common.dtsi:155.1-5 Label or path rtc 
>> not found
   FATAL ERROR: Syntax error parsing input tree

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


.config.gz
Description: application/gzip

INFO: task hung in addrconf_verify_work (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:c208bdb9 tcp: improve recv_skip_hint for tcp_zerocopy_rece..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15b6133b60
kernel config:  https://syzkaller.appspot.com/x/.config?x=d9be300620399522
dashboard link: https://syzkaller.appspot.com/bug?extid=cf0adbb9c28c8866c788
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1548666f60
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11957d3b60

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cf0adbb9c28c8866c...@syzkaller.appspotmail.com

INFO: task kworker/0:2:2913 blocked for more than 143 seconds.
  Not tainted 5.4.0-rc1+ #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:2 D27000  2913  2 0x80004000
Workqueue: ipv6_addrconf addrconf_verify_work
Call Trace:
 context_switch kernel/sched/core.c:3384 [inline]
 __schedule+0x94f/0x1e70 kernel/sched/core.c:4069
 schedule+0xd9/0x260 kernel/sched/core.c:4136
 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4195
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x7b0/0x13c0 kernel/locking/mutex.c:1103
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:72
 addrconf_verify_work+0xe/0x20 net/ipv6/addrconf.c:4520
 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269
 worker_thread+0x98/0xe40 kernel/workqueue.c:2415
 kthread+0x361/0x430 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

Showing all locks held in the system:
1 lock held by khungtaskd/1054:
 #0: 88faae40 (rcu_read_lock){}, at:  
debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:5337

3 locks held by kworker/0:2/2913:
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
__write_once_size include/linux/compiler.h:226 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
atomic64_set include/asm-generic/atomic-instrumented.h:855 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
atomic_long_set include/asm-generic/atomic-long.h:40 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
set_work_data kernel/workqueue.c:620 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
set_work_pool_and_clear_pending kernel/workqueue.c:647 [inline]
 #0: 888216019428 ((wq_completion)ipv6_addrconf){+.+.}, at:  
process_one_work+0x88b/0x1740 kernel/workqueue.c:2240
 #1: 8880a05b7dc0 ((addr_chk_work).work){+.+.}, at:  
process_one_work+0x8c1/0x1740 kernel/workqueue.c:2244
 #2: 89993b20 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20  
net/core/rtnetlink.c:72

1 lock held by rsyslogd/8744:
 #0: 8880899fa120 (>f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110  
fs/file.c:801

2 locks held by getty/8833:
 #0: 888090baedd0 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f292e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8834:
 #0: 88808d0f6dd0 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f392e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8835:
 #0: 888090148e10 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f252e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8836:
 #0: 8880a7ab3750 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f412e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8837:
 #0: 8880a7accf10 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f3d2e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8838:
 #0: 88808d0f7650 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f352e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

2 locks held by getty/8839:
 #0: 88808d162bd0 (>ldisc_sem){}, at:  
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:340
 #1: c90005f112e0 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x232/0x1c10 drivers/tty/n_tty.c:2156

1 lock held by syz-executor910/8859:

=

NMI backtrace for cpu 0
CPU: 0 PID: 1054 Comm: khungtaskd Not tainted 5.4.0-rc1+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 

Re: [PATCH v5 1/2] HID: logitech: Add MX Master over Bluetooth

[kbuild test robot]

Hi Mazin,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Mazin-Rezk/HID-logitech-Add-MX-Master-over-Bluetooth/20191014-071534
config: i386-randconfig-g004-201941 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/ioport.h:13:0,
from include/linux/device.h:15,
from drivers//hid/hid-logitech-hidpp.c:13:
   drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
   ^~~~
>> drivers//hid/hid-logitech-hidpp.c:347:2: note: in expansion of macro 'if'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^~
   drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers//hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
^~~~
>> drivers//hid/hid-logitech-hidpp.c:347:2: note: in expansion of macro 'if'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^~
   drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers//hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^
   drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
   ^~~~
   drivers//hid/hid-logitech-hidpp.c:3496:2: note: in expansion of macro 'if'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^~
   drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers//hid/hid-logitech-hidpp.c:3496:22: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : 
__trace_if_value(cond))
^~~~
   drivers//hid/hid-logitech-hidpp.c:3496:2: note: in expansion of macro 'if'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^~
   drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers//hid/hid-logitech-hidpp.c:3496:22: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^
   In file included from include/linux/ioport.h:15:0,
from 

Re: [PATCH v5 1/2] HID: logitech: Add MX Master over Bluetooth

[Mazin Rezk]

On Sunday, October 13, 2019 9:28 PM, kbuild test robot  wrote:

> Hi Mazin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [cannot apply to v5.4-rc2 next-20191010]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see 
> https://stackoverflow.com/a/37406982]
>
> url: 
> https://github.com/0day-ci/linux/commits/Mazin-Rezk/HID-logitech-Add-MX-Master-over-Bluetooth/20191014-071534
> config: mips-allmodconfig (attached as .config)
> compiler: mips-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross 
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot l...@intel.com
>
> All warnings (new ones prefixed by >>):
>
> In file included from include/linux/ioport.h:15:0,
> from include/linux/device.h:15,
> from drivers/hid/hid-logitech-hidpp.c:13:
> drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
>
> > > include/linux/bits.h:8:26: warning: left shift count >= width of type 
> > > [-Wshift-count-overflow]
>
> #define BIT(nr)   (UL(1) << (nr))
>  ^
>
>
> > > drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
>
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
>   ^~~
>
>
> > > drivers/hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro 
> > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
>
>  if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
>
>  ^
>
>
> drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device':
>
> > > include/linux/bits.h:8:26: warning: left shift count >= width of type 
> > > [-Wshift-count-overflow]
>
> #define BIT(nr)   (UL(1) << (nr))
>  ^
>
>
> > > drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
>
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
>   ^~~
>
>
> drivers/hid/hid-logitech-hidpp.c:3496:22: note: in expansion of macro 
> 'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
> if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
>
>  ^
>
>
> drivers/hid/hid-logitech-hidpp.c: At top level:
>
> > > include/linux/bits.h:8:26: warning: left shift count >= width of type 
> > > [-Wshift-count-overflow]
>
> #define BIT(nr)   (UL(1) << (nr))
>  ^
>
>
> > > drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
>
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
>   ^~~
>
>
> drivers/hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro 
> 'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
> #define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> ^
>
> > > drivers/hid/hid-logitech-hidpp.c:3794:5: note: in expansion of macro 
> > > 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE'
>
> HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> ^~
>
>
> > > include/linux/bits.h:8:26: warning: left shift count >= width of type 
> > > [-Wshift-count-overflow]
>
> #define BIT(nr)   (UL(1) << (nr))
>  ^
>
>
> > > drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
>
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
>   ^~~
>
>
> drivers/hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro 
> 'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
> #define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> ^
> drivers/hid/hid-logitech-hidpp.c:3797:5: note: in expansion of macro 
> 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE'
> HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> ^~
>
> --
>
> In file included from include/linux/ioport.h:15:0,
> from include/linux/device.h:15,
> from drivers//hid/hid-logitech-hidpp.c:13:
> drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
>
> > > include/linux/bits.h:8:26: warning: left shift count >= width of type 
> > > [-Wshift-count-overflow]
>
> #define BIT(nr)   (UL(1) << (nr))
>  ^
>
>
> 

Re: [PATCH 1/7] Add a new flags-accepting interface for anonymous inodes

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Daniel-Colascione/Harden-userfaultfd/20191014-102741
reproduce: make htmldocs

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

All warnings (new ones prefixed by >>):

   Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure 
you have the theme installed to produce pretty HTML output. Falling back to the 
default theme.
   WARNING: dot(1) not found, for better output quality install graphviz from 
http://www.graphviz.org
   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file drivers/dma-buf/reservation.c
   Error: Cannot open file include/linux/reservation.h
   Error: Cannot open file include/linux/reservation.h
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'quotactl' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'quota_on' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_free_mnt_opts' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_eat_lsm_opts' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_kern_mount' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_show_options' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'sb_add_mnt_opt' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'd_instantiate' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'getprocattr' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'setprocattr' not described in 'security_list_options'
   include/linux/lsm_hooks.h:1822: warning: Function parameter or member 
'locked_down' not described in 'security_list_options'
   include/linux/regulator/machine.h:196: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:223: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   fs/fs-writeback.c:918: warning: Excess function parameter 'nr_pages' 
description in 'cgroup_writeback_by_id'
>> fs/anon_inodes.c:139: warning: Function parameter or member 
>> 'anon_inode_flags' not described in 'anon_inode_getfd2'
   fs/direct-io.c:258: warning: Excess function parameter 'offset' description 
in 'dio_complete'
   fs/libfs.c:501: warning: Excess function parameter 'available' description 
in 'simple_write_end'
   fs/posix_acl.c:647: warning: Function parameter or member 'inode' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not 
described in 'posix_acl_update_mode'
   fs/posix_acl.c:647: warning: Function parameter or member 'acl' not 
described in 'posix_acl_update_mode'
   include/linux/spi/spi.h:190: warning: Function parameter or member 
'driver_override' not described in 'spi_device'
   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not 
found
   drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not 
found
   drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' 
not found
   include/linux/w1.h:277: warning: Function parameter or member 
'of_match_table' not described in 'w1_family'
   drivers/gpio/gpiolib-of.c:92: warning: Excess function parameter 'dev' 
description in 'of_gpio_need_valid_mask'
   include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' 
not described in 'i2c_client'
   kernel/dma/coherent.c:1: warning: no structured comments found
   include/linux/input/sparse-keymap.h:43: warning: Function parameter or 
member 'sw' not described in 'key_entry'
   include/linux/skbuff.h:888: warning: Function parameter or member 
'dev_scratch' not described in 'sk_buff'
   include/linux/skbuff.h:888: warning: Function parameter or member 'list' not 
described in 'sk_buff'
   include/linux/skbuff.h:888: 

Re: Regression in 4.14.147, 4.19.76, 5.2.18 leading to kernel panic on btrfs root fs mount

[Sasha Levin]

On Sun, Oct 13, 2019 at 07:04:12PM +0300, Andrew Macks wrote:

Was not sure the correct way to escalate this quickly enough.  I
unfortunately discovered this issue while upgrading a server (remotely) to
4.19.78 (longterm).

*Bug 205181*  - kernel
panic when accessing btrfs root device with f2fs in kernel
https://bugzilla.kernel.org/show_bug.cgi?id=205181


Okay, I've backported 38fb6d0ea3429 ("f2fs: use EINVAL for superblock
with invalid magic") to 4.19 and 4.14. It'll be great if someone could
ack that backport.

Sorry for the breakage.

--
Thanks,
Sasha

RE: [EXT] Re: [v2,2/2] dt-bindings: i2c-mux-pca954x: Add optional property i2c-mux-never-disable

[Biwen Li]

> 
> >
> > On Mon, Sep 30, 2019 at 11:25:03AM +0800, Biwen Li wrote:
> > > The patch adds an optional property i2c-mux-never-disable
> > >
> > > Signed-off-by: Biwen Li 
> > > ---
> > > Change in v2:
> > >   - update documentation
> > >
> > >  Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > > b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > > index 30ac6a60f041..71b73d0fdb62 100644
> > > --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > > +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > > @@ -34,6 +34,7 @@ Optional Properties:
> > >  - first cell is the pin number
> > >  - second cell is used to specify flags.
> > >  See also
> > > Documentation/devicetree/bindings/interrupt-controller/interrupts.tx
> > > t
> > > +  - i2c-mux-never-disable: always forces mux to be enabled.
> >
> > Either needs to have a vendor prefix or be documented as a common
> > property.
I choose to be documented as a common property.
> >
> > IIRC, we already have a property for mux default state which seems
> > like that would cover this unless you need to leave it in different states.
> Okay, you are right, thank you so much. I will try it in v3.
Do you mean that the property is i2c-mux-idle-disconnect in 
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt?
If so, the property i2c-mux-idle-disconnect is not good for me.
Because condition of the property i2c-mux-idle-disconnect is in idle 
state(sometimes).
But I need always enable i2c multiplexer in whatever state(anytime), so I add a 
common property i2c-mux-never-disable.
> >
> > Rob

Re: [PATCHv7 15/33] posix-timers: Make clock_nanosleep() time namespace aware

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: x86_64-randconfig-s1-201941 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   kernel//time/posix-stubs.c: In function '__do_sys_clock_nanosleep':
>> kernel//time/posix-stubs.c:153:31: error: 'clockid' undeclared (first use in 
>> this function)
  texp = timens_ktime_to_host(clockid, texp);
  ^
   kernel//time/posix-stubs.c:153:31: note: each undeclared identifier is 
reported only once for each function it appears in
   kernel//time/posix-stubs.c: In function '__do_sys_clock_nanosleep_time32':
>> kernel//time/posix-stubs.c:222:2: error: unknown type name 'ktime'
 ktime texp;
 ^
   kernel//time/posix-stubs.c:243:31: error: 'clockid' undeclared (first use in 
this function)
  texp = timens_ktime_to_host(clockid, texp);
  ^

vim +/clockid +153 kernel//time/posix-stubs.c

   126  
   127  SYSCALL_DEFINE4(clock_nanosleep, const clockid_t, which_clock, int, 
flags,
   128  const struct __kernel_timespec __user *, rqtp,
   129  struct __kernel_timespec __user *, rmtp)
   130  {
   131  struct timespec64 t;
   132  ktime_t texp;
   133  
   134  switch (which_clock) {
   135  case CLOCK_REALTIME:
   136  case CLOCK_MONOTONIC:
   137  case CLOCK_BOOTTIME:
   138  break;
   139  default:
   140  return -EINVAL;
   141  }
   142  
   143  if (get_timespec64(, rqtp))
   144  return -EFAULT;
   145  if (!timespec64_valid())
   146  return -EINVAL;
   147  if (flags & TIMER_ABSTIME)
   148  rmtp = NULL;
   149  current->restart_block.nanosleep.type = rmtp ? TT_NATIVE : 
TT_NONE;
   150  current->restart_block.nanosleep.rmtp = rmtp;
   151  texp = timespec64_to_ktime(t);
   152  if (flags & TIMER_ABSTIME)
 > 153  texp = timens_ktime_to_host(clockid, texp);
   154  return hrtimer_nanosleep(texp, flags & TIMER_ABSTIME ?
   155   HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
   156   which_clock);
   157  }
   158  
   159  #ifdef CONFIG_COMPAT
   160  COMPAT_SYS_NI(timer_create);
   161  COMPAT_SYS_NI(getitimer);
   162  COMPAT_SYS_NI(setitimer);
   163  #endif
   164  
   165  #ifdef CONFIG_COMPAT_32BIT_TIME
   166  SYS_NI(timer_settime32);
   167  SYS_NI(timer_gettime32);
   168  
   169  SYSCALL_DEFINE2(clock_settime32, const clockid_t, which_clock,
   170  struct old_timespec32 __user *, tp)
   171  {
   172  struct timespec64 new_tp;
   173  
   174  if (which_clock != CLOCK_REALTIME)
   175  return -EINVAL;
   176  if (get_old_timespec32(_tp, tp))
   177  return -EFAULT;
   178  
   179  return do_sys_settimeofday64(_tp, NULL);
   180  }
   181  
   182  SYSCALL_DEFINE2(clock_gettime32, clockid_t, which_clock,
   183  struct old_timespec32 __user *, tp)
   184  {
   185  int ret;
   186  struct timespec64 kernel_tp;
   187  
   188  ret = do_clock_gettime(which_clock, _tp);
   189  if (ret)
   190  return ret;
   191  
   192  if (put_old_timespec32(_tp, tp))
   193  return -EFAULT;
   194  return 0;
   195  }
   196  
   197  SYSCALL_DEFINE2(clock_getres_time32, clockid_t, which_clock,
   198  struct old_timespec32 __user *, tp)
   199  {
   200  struct timespec64 rtn_tp = {
   201  .tv_sec = 0,
   202  .tv_nsec = hrtimer_resolution,
   203  };
   204  
   205  switch (which_clock) {
   206  case CLOCK_REALTIME:
   207  case CLOCK_MONOTONIC:
   208  case CLOCK_BOOTTIME:
   209  if (put_old_timespec32(_tp, tp))
   210  return -EFAULT;
   211  return 0;
   212  default:
   213  return -EINVAL;
   214  }
   215  }
   216  
   217  SYSCALL_DEFINE4(clock_nanosleep_time32, clockid_t, which_clock, int, 
flags,
   218  struct old_timespec32 

Re: [PATCH] hrtimer: annotate lockless access to timer->base

[Eric Dumazet]

On Tue, Oct 8, 2019 at 10:32 AM Eric Dumazet  wrote:
>
> Followup to commit dd2261ed45aa ("hrtimer: Protect lockless access
> to timer->base")
>
> lock_hrtimer_base() fetches timer->base without lock exclusion.
>
> Compiler is allowed to read timer->base twice (even if considered dumb)
> and we could end up trying to lock migration_base and
> return _base.
>
>   base = timer->base;
>   if (likely(base != _base)) {
>
>/* compiler reads timer->base again, and now (base == _base)
>
>raw_spin_lock_irqsave(>cpu_base->lock, *flags);
>if (likely(base == timer->base))
> return base; /* == _base ! */
>
> Similarly the write sides should use WRITE_ONCE() to avoid
> store tearing.
>
> Signed-off-by: Eric Dumazet 
> Cc: Julien Grall 
> Cc: Thomas Gleixner 
> ---
>  kernel/time/hrtimer.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 
> 0d4dc241c0fb498036c91a571e65cb00f5d19ba6..65605530ee349c9682690c4fccb43aa9284d4287
>  100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -164,7 +164,7 @@ struct hrtimer_clock_base *lock_hrtimer_base(const struct 
> hrtimer *timer,
> struct hrtimer_clock_base *base;
>
> for (;;) {
> -   base = timer->base;
> +   base = READ_ONCE(timer->base);
> if (likely(base != _base)) {
> raw_spin_lock_irqsave(>cpu_base->lock, *flags);
> if (likely(base == timer->base))
> @@ -244,7 +244,7 @@ switch_hrtimer_base(struct hrtimer *timer, struct 
> hrtimer_clock_base *base,
> return base;
>
> /* See the comment in lock_hrtimer_base() */
> -   timer->base = _base;
> +   WRITE_ONCE(timer->base, _base);
> raw_spin_unlock(>cpu_base->lock);
> raw_spin_lock(_base->cpu_base->lock);
>
> @@ -253,10 +253,10 @@ switch_hrtimer_base(struct hrtimer *timer, struct 
> hrtimer_clock_base *base,
> raw_spin_unlock(_base->cpu_base->lock);
> raw_spin_lock(>cpu_base->lock);
> new_cpu_base = this_cpu_base;
> -   timer->base = base;
> +   WRITE_ONCE(timer->base, base);
> goto again;
> }
> -   timer->base = new_base;
> +   WRITE_ONCE(timer->base, new_base);
> } else {
> if (new_cpu_base != this_cpu_base &&
> hrtimer_check_target(timer, new_base)) {
> --
> 2.23.0.581.g78d2f28ef7-goog
>

Any news on this patch ?

If more information is needed, let me know.

Maybe I need to point to :

commit b831275a3553c32091222ac619cfddd73a5553fb timers: Plug locking
race vs. timer migration

Thanks

Re: Potential uninitialized variables in power: supply: rt5033_battery:

[Yizhuo Zhai]

Hi Sebastian:

Thanks for your explanation and I will send the patch accordingly.

On Sun, Oct 13, 2019 at 8:12 PM Sebastian Reichel  wrote:
>
> Hi,
>
> On Thu, Oct 03, 2019 at 09:21:44PM -0700, Yizhuo Zhai wrote:
> > drivers/power/supply/rt5033_battery.c:
> >
> > In function rt5033_battery_get_present(), variable "val" could be
> > uninitialized if regmap_read() returns -EINVAL. However, "val" is
> > used to decide the return value, which is potentially unsafe.
> >
> > Also, we cannot simply return -EINVAL in rt5033_battery_get_present()
> > because it's not an acceptable return value.
> >
> > Thanks for your time to check this case.
>
> Should be fine to just return false when regmap_read() fails.
> Will you prepare a patch for that?
>
> Thanks,
>
> -- Sebastian



-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

Re: [PATCH v5 2/2] HID: logitech: Support WirelessDeviceStatus connect events

[kbuild test robot]

Hi Mazin,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Mazin-Rezk/HID-logitech-Add-MX-Master-over-Bluetooth/20191014-071534
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/ioport.h:15:0,
from include/linux/device.h:15,
from drivers/hid/hid-logitech-hidpp.c:13:
   drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:351:26: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^
   drivers/hid/hid-logitech-hidpp.c: In function 
'hidpp_report_is_connect_event':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:75:44: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS BIT(33)
   ^~~
>> drivers/hid/hid-logitech-hidpp.c:412:27: note: in expansion of macro 
>> 'HIDPP_QUIRK_WIRELESS_DEVICE_STATUS'
 return ((hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS) &&
  ^
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:415:20: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
  (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)) &&
   ^
   drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:3522:22: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^
   drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_probe':
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:75:44: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS BIT(33)
   ^~~
   drivers/hid/hid-logitech-hidpp.c:3653:36: note: in expansion of macro 
'HIDPP_QUIRK_WIRELESS_DEVICE_STATUS'
 if (connected && (hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS)) {
   ^
   drivers/hid/hid-logitech-hidpp.c: At top level:
   include/linux/bits.h:8:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:86:41: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE (HIDPP_QUIRK_MISSING_SHORT_REPORTS | 
\
^
   drivers/hid/hid-logitech-hidpp.c:3826:5: note: in expansion of macro 

Re: [PATCH v4 0/5] Powerpc/Watchpoint: Few important fixes

[Ravi Bangoria]

On 10/12/19 2:21 PM, Christophe Leroy wrote:



Le 10/10/2019 à 06:44, Ravi Bangoria a écrit :



@Christophe, Is patch5 works for you on 8xx?



Getting the following :

root@vgoip:~# ./ptrace-hwbreak
test: ptrace-hwbreak
tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty
PTRACE_SET_DEBUGREG, WO, len: 1: Ok
PTRACE_SET_DEBUGREG, WO, len: 2: Ok
PTRACE_SET_DEBUGREG, WO, len: 4: Ok
PTRACE_SET_DEBUGREG, WO, len: 8: Ok
PTRACE_SET_DEBUGREG, RO, len: 1: Ok
PTRACE_SET_DEBUGREG, RO, len: 2: Ok
PTRACE_SET_DEBUGREG, RO, len: 4: Ok
PTRACE_SET_DEBUGREG, RO, len: 8: Ok
PTRACE_SET_DEBUGREG, RW, len: 1: Ok
PTRACE_SET_DEBUGREG, RW, len: 2: Ok
PTRACE_SET_DEBUGREG, RW, len: 4: Ok
PTRACE_SET_DEBUGREG, RW, len: 8: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Fail
failure: ptrace-hwbreak





I also tried on a 83xx (book3s/32). This one has a regular DABR :

root@vgoippro:~# ./ptrace-hwbreak
test: ptrace-hwbreak
tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty
PTRACE_SET_DEBUGREG, WO, len: 1: Ok
PTRACE_SET_DEBUGREG, WO, len: 2: Ok
PTRACE_SET_DEBUGREG, WO, len: 4: Ok
PTRACE_SET_DEBUGREG, WO, len: 8: Ok
PTRACE_SET_DEBUGREG, RO, len: 1: Ok
PTRACE_SET_DEBUGREG, RO, len: 2: Ok
PTRACE_SET_DEBUGREG, RO, len: 4: Ok
PTRACE_SET_DEBUGREG, RO, len: 8: Ok
PTRACE_SET_DEBUGREG, RW, len: 1: Ok
PTRACE_SET_DEBUGREG, RW, len: 2: Ok
PTRACE_SET_DEBUGREG, RW, len: 4: Ok
PTRACE_SET_DEBUGREG, RW, len: 8: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RW, len: 6: Ok
PPC_PTRACE_SETHWDEBUG failed: Invalid argument


Ok. If it has the DABR _only_, creation of MODE RANGE UNALINGED breakpoint
will failed because DABR supports only 8 bytes wide breakpoint and it must
be doubleword aligned.

So this means I've to add all unaligned tests inside if (dawr) condition.

Ravi

Re: [PATCH v4 0/5] Powerpc/Watchpoint: Few important fixes

[Ravi Bangoria]

On 10/12/19 1:01 PM, Christophe Leroy wrote:



Le 10/10/2019 à 08:25, Ravi Bangoria a écrit :



On 10/10/19 10:14 AM, Ravi Bangoria wrote:



@Christophe, Is patch5 works for you on 8xx?



Getting the following :

root@vgoip:~# ./ptrace-hwbreak
test: ptrace-hwbreak
tags: git_version:v5.4-rc2-710-gf0082e173fe4-dirty
PTRACE_SET_DEBUGREG, WO, len: 1: Ok
PTRACE_SET_DEBUGREG, WO, len: 2: Ok
PTRACE_SET_DEBUGREG, WO, len: 4: Ok
PTRACE_SET_DEBUGREG, WO, len: 8: Ok
PTRACE_SET_DEBUGREG, RO, len: 1: Ok
PTRACE_SET_DEBUGREG, RO, len: 2: Ok
PTRACE_SET_DEBUGREG, RO, len: 4: Ok
PTRACE_SET_DEBUGREG, RO, len: 8: Ok
PTRACE_SET_DEBUGREG, RW, len: 1: Ok
PTRACE_SET_DEBUGREG, RW, len: 2: Ok
PTRACE_SET_DEBUGREG, RW, len: 4: Ok
PTRACE_SET_DEBUGREG, RW, len: 8: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO, len: 6: Ok
PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, RO, len: 6: Fail
failure: ptrace-hwbreak



Thanks Christophe. I don't have any 8xx box. I checked qemu and it seems
qemu emulation for 8xx is not yet supported. So I can't debug this. Can
you please check why it's failing?


PPC_PTRACE_SETHWDEBUG internally uses DAWR register and probably 8xx does
not emulate DAWR logic, it only uses DABR to emulate double-word watchpoint.
In that case, all testcases that uses PPC_PTRACE_SETHWDEBUG should be
disabled for 8xx. I'll change [PATCH 5] accordingly and resend.


I think the MODE_EXACT ones are OK with the 8xx at the time being.


Ok. I'll disable other tests for 8xx.

Also, I was bit wrong in above point. Actually, PPC_PTRACE_SETHWDEBUG with RANGE
breakpoint also support DABR but the length will be 8 only. So I've to change my
patch 1 also a bit (ptrace stuff). I'll resend the series with these changes.





Also, do you think I should fix hw_breakpoint_validate_len() from [PARCH 1]
for 8xx? I re-checked you recent patch* to allow any address range size for
8xx. With that patch, hw_breakpoint_validate_len() won't get called at all
for 8xx.


At the time being, the 8xx emulates DABR so it has the same limitations as 
BOOK3S.
My patch needs to be rebased on top of your series and I think it needs some 
modifications, as it seems it doesn't properly handle size 1 and size 2 
breakpoints at least.
So I think that you should leave your Patch1 as is, and I'll modify the 
validate_len() logic while rebasing my patch.


Sure. Thanks for helping!

Ravi

Re: [PATCH] power: supply: max17042_battery: fix the potential uninitialized use in max17042_write_verify_reg()

[Sebastian Reichel]

Hi,

On Wed, Oct 02, 2019 at 08:44:06AM -0700, Yizhuo wrote:
> In function max17042_write_verify_reg(), variable "read_value"
> could be uninitialized if regmap_read() fails. However,
> "read_value" is used to decide the control flow later in the if
> statement, which is potentially unsafe.
> 
> Signed-off-by: Yizhuo 
> ---

Instead of directly failing, integrate this into
the retry loop. Also the Signed-off-by and patch
author name looks incomplete.

Thanks,

-- Sebastian

>  drivers/power/supply/max17042_battery.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/supply/max17042_battery.c 
> b/drivers/power/supply/max17042_battery.c
> index 0dfad2cf13fe..e6a2dacaa730 100644
> --- a/drivers/power/supply/max17042_battery.c
> +++ b/drivers/power/supply/max17042_battery.c
> @@ -486,12 +486,15 @@ static void max17042_external_power_changed(struct 
> power_supply *psy)
>  static int max17042_write_verify_reg(struct regmap *map, u8 reg, u32 value)
>  {
>   int retries = 8;
> - int ret;
> + int ret, err;
>   u32 read_value;
>  
>   do {
>   ret = regmap_write(map, reg, value);
> - regmap_read(map, reg, _value);
> + err = regmap_read(map, reg, _value);
> + if (err)
> + return err;
> +
>   if (read_value != value) {
>   ret = -EIO;
>   retries--;
> -- 
> 2.17.1
> 


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] Serial: Ingenic: Add support for the X1000.

[Zhou Yanjie]

Hi Greg,

I'm sorry, maybe it was a problem when I git send-email,
causing the wrong patch to be sent to you. Just ignore
the email about the serial patch please.

Best regards!

On 2019年10月12日 15:35, Greg KH wrote:

On Sat, Oct 12, 2019 at 01:13:23PM +0800, Zhou Yanjie wrote:

Add support for probing the 8250_ingenic driver on the
X1000 Soc from Ingenic.

Signed-off-by: Zhou Yanjie 
---
  drivers/tty/serial/8250/8250_ingenic.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)



you seem to have two patches merged into one here, please fix up and
resend.

thanks,

greg k-h

Re: [PATCH] power: supply: max17042_battery: fix some usage of uninitialized variables

[Sebastian Reichel]

Hi,

On Thu, Oct 03, 2019 at 10:29:48AM -0700, Yizhuo wrote:
> Several functions in this file are trying to use regmap_read() to
> initialize the specific variable, however, if regmap_read() fails,
> the variable could be uninitialized but used directly, which is
> potentially unsafe. The return value of regmap_read() should be
> checked and handled. The same case also happens in function
> max17042_thread_handler() but it needs more effort to patch.
> 
> Signed-off-by: Yizhuo 
> ---

This does not improve the situation much. You should change the
functions from 'void' to 'int' return code and propagate the error
code, otherwise the following code assumes everything to be correct.
Also the Signed-off-by name and the patch author's name seems to be
incomplete.

Thanks,

-- Sebastian

>  drivers/power/supply/max17042_battery.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/power/supply/max17042_battery.c 
> b/drivers/power/supply/max17042_battery.c
> index e6a2dacaa730..b897776a2749 100644
> --- a/drivers/power/supply/max17042_battery.c
> +++ b/drivers/power/supply/max17042_battery.c
> @@ -675,8 +675,12 @@ static void max17042_reset_vfsoc0_reg(struct 
> max17042_chip *chip)
>  {
>   unsigned int vfSoc;
>   struct regmap *map = chip->regmap;
> + int ret;
> +
> + ret = regmap_read(map, MAX17042_VFSOC, );
> + if (ret)
> + return;
>  
> - regmap_read(map, MAX17042_VFSOC, );
>   regmap_write(map, MAX17042_VFSOC0Enable, VFSOC0_UNLOCK);
>   max17042_write_verify_reg(map, MAX17042_VFSOC0, vfSoc);
>   regmap_write(map, MAX17042_VFSOC0Enable, VFSOC0_LOCK);
> @@ -686,12 +690,18 @@ static void max17042_load_new_capacity_params(struct 
> max17042_chip *chip)
>  {
>   u32 full_cap0, rep_cap, dq_acc, vfSoc;
>   u32 rem_cap;
> + int ret;
>  
>   struct max17042_config_data *config = chip->pdata->config_data;
>   struct regmap *map = chip->regmap;
>  
> - regmap_read(map, MAX17042_FullCAP0, _cap0);
> - regmap_read(map, MAX17042_VFSOC, );
> + ret = regmap_read(map, MAX17042_FullCAP0, _cap0);
> + if (ret)
> + return;
> +
> + ret = regmap_read(map, MAX17042_VFSOC, );
> + if (ret)
> + return;
>  
>   /* fg_vfSoc needs to shifted by 8 bits to get the
>* perc in 1% accuracy, to get the right rem_cap multiply
> @@ -1108,7 +1118,12 @@ static int max17042_probe(struct i2c_client *client,
>   if (!client->irq)
>   regmap_write(chip->regmap, MAX17042_SALRT_Th, 0xff00);
>  
> - regmap_read(chip->regmap, MAX17042_STATUS, );
> + ret = regmap_read(chip->regmap, MAX17042_STATUS, );
> + if (ret) {
> + dev_err(>dev, "Failed to get MAX17042_STATUS.\n");
> + return ret;
> + }
> +
>   if (val & STATUS_POR_BIT) {
>   INIT_WORK(>work, max17042_init_worker);
>   ret = devm_add_action(>dev, max17042_stop_work, chip);
> -- 
> 2.17.1
> 


signature.asc
Description: PGP signature

Re: [PATCH] fs/namespace.c: fix use-after-free of mount in mnt_warn_timestamp_expiry()

[Eric Biggers]

On Sun, Oct 13, 2019 at 07:04:10PM -0700, Deepa Dinamani wrote:
> Thanks for the fix.
> 
> Would it be better to move the check and warning to a place where the
> access is still safe?
> 
> -Deepa

True, we could just do

diff --git a/fs/namespace.c b/fs/namespace.c
index fe0e9e1410fe..9f2ceb542f05 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2764,14 +2764,14 @@ static int do_new_mount_fc(struct fs_context *fc, 
struct path *mountpoint,
if (IS_ERR(mnt))
return PTR_ERR(mnt);
 
+   mnt_warn_timestamp_expiry(mountpoint, mnt);
+
error = do_add_mount(real_mount(mnt), mountpoint, mnt_flags);
if (error < 0) {
mntput(mnt);
return error;
}
 
-   mnt_warn_timestamp_expiry(mountpoint, mnt);
-
return error;
 }

But then the warning ("Mounted %s file system ...") is printed even if
do_add_mount() fails so nothing was actually mounted.

Though, it's just a warning message and I think failures here are rare, so maybe
we don't care.  Al, what do you think?

- Eric

RE: [EXT] Re: [v2,2/2] dt-bindings: i2c-mux-pca954x: Add optional property i2c-mux-never-disable

[Biwen Li]

> 
> On Mon, Sep 30, 2019 at 11:25:03AM +0800, Biwen Li wrote:
> > The patch adds an optional property i2c-mux-never-disable
> >
> > Signed-off-by: Biwen Li 
> > ---
> > Change in v2:
> >   - update documentation
> >
> >  Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > index 30ac6a60f041..71b73d0fdb62 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
> > @@ -34,6 +34,7 @@ Optional Properties:
> >  - first cell is the pin number
> >  - second cell is used to specify flags.
> >  See also
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> > +  - i2c-mux-never-disable: always forces mux to be enabled.
> 
> Either needs to have a vendor prefix or be documented as a common
> property.
> 
> IIRC, we already have a property for mux default state which seems like that
> would cover this unless you need to leave it in different states.
Okay, you are right, thank you so much. I will try it in v3.
> 
> Rob

Re: [PATCH] firmware: vpd: Add an interface to read VPD value

[Cheng-yi Chiang]

On Wed, Oct 9, 2019 at 10:05 PM Srinivas Kandagatla
 wrote:
>
>
>
> On 08/10/2019 16:14, Stephen Boyd wrote:
> >> 3) As my use case does not use device tree, it is hard for ASoC
> >> machine to access nvmem device. I am wondering if I can use
> >> nvm_cell_lookup so machine driver can find the nvmem device using a
> >> con_id. But currently the cell lookup API requires a matched device,
> >> which does not fit my usage because there will be different machine
> >> drivers requesting the value.
> >> I think I can still workaround this by adding the lookup table in
> >> machine driver. This would seem to be a bit weird because I found that
> >> most lookup table is added in provider side, not consumer side. Not
> >> sure if this is logically correct.
> > Maybe Srini has some input here. It looks like your main concern is
> > consumer to provider mapping?
> >
>
> In non-DT setup, there are various ways to lookup nvmem provider.
>
> 1> nvmem_device_get()/put() using provider devid/name. I think you
> should be able to use this in your case.
> 2> nvmem_register_notifier() which notifies when nvmem provider is added
> to system.
> 3> nvmem_device_find() with own match function this will be merged in
> next window (https://lkml.org/lkml/2019/10/3/215)
>
>
> If none of these are of any help, could explain what exactly are you
> looking for w.r.t nvmem to be able to move to what Stephen Boyd suggested?
>
> --srini
>

Hi Stephen, Mark and Srinivas,
Thank you all for the suggestions.
In my non-DT setup, I have been working on coreboot changes to prepare
data in _DSD following suggestion in
https://patchwork.kernel.org/patch/11179237
The basic idea is that codec driver should just get data it needs from
device property.
The coreboot approach works in my local setup, but I have not sent the
change to coreboot upstream yet.
If that path work, then the change needed in kernel will be much simpler.

In the future, there might be DT setup use case, and I think it should
be doable for VPD to register a nvmem device, and let codec driver
gets the property.
But I would drop this path for now.
Thanks!

Re: Potential uninitialized variables in power: supply: rt5033_battery:

[Sebastian Reichel]

Hi,

On Thu, Oct 03, 2019 at 09:21:44PM -0700, Yizhuo Zhai wrote:
> drivers/power/supply/rt5033_battery.c:
> 
> In function rt5033_battery_get_present(), variable "val" could be
> uninitialized if regmap_read() returns -EINVAL. However, "val" is
> used to decide the return value, which is potentially unsafe.
> 
> Also, we cannot simply return -EINVAL in rt5033_battery_get_present()
> because it's not an acceptable return value.
> 
> Thanks for your time to check this case.

Should be fine to just return false when regmap_read() fails.
Will you prepare a patch for that?

Thanks,

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCHv7 25/33] x86/vdso: Zap vvar pages on switch a time namspace

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: riscv-defconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=riscv 

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

All errors (new ones prefixed by >>):

   kernel/time/namespace.o: In function `.L0 ':
   namespace.c:(.text+0xfc): undefined reference to `arch_get_vdso_data'
   kernel/time/namespace.o: In function `timens_install':
>> namespace.c:(.text+0x41c): undefined reference to `vdso_join_timens'
   namespace.c:(.text+0x4ce): undefined reference to `vdso_join_timens'

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


.config.gz
Description: application/gzip

kernel BUG at include/linux/rmap.h:LINE!

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:442630f6 Add linux-next specific files for 20191008
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11450d9360
kernel config:  https://syzkaller.appspot.com/x/.config?x=af1bfeef713eefdd
dashboard link: https://syzkaller.appspot.com/bug?extid=3370fc9fb190f98c5c72
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13132d5760

The bug was bisected to:

commit 480706f51e2c3a450d2f7fc10f5af215c9d249df
Author: Wei Yang 
Date:   Mon Oct 7 20:25:37 2019 +

mm/rmap.c: reuse mergeable anon_vma as parent when forking

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=107ea520e0
final crash:https://syzkaller.appspot.com/x/report.txt?x=127ea520e0
console output: https://syzkaller.appspot.com/x/log.txt?x=147ea520e0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3370fc9fb190f98c5...@syzkaller.appspotmail.com
Fixes: 480706f51e2c ("mm/rmap.c: reuse mergeable anon_vma as parent when  
forking")


prot 25 anon_vma 88809a9c4b40 vm_ops 
pgoff 2 file  private_data 
flags: 0x8100077(read|write|exec|mayread|maywrite|mayexec|account|softdirty)
[ cut here ]
kernel BUG at include/linux/rmap.h:159!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8601 Comm: syz-executor.0 Not tainted 5.4.0-rc2-next-20191008 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:anon_vma_merge include/linux/rmap.h:159 [inline]
RIP: 0010:__vma_adjust+0x151c/0x1cc0 mm/mmap.c:921
Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee 0f 82 1b fe ff ff 45 31 ed  
e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8 e8 76 62 fc ff <0f> 0b e8 6d 00  
d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f 85 20 07 00

RSP: 0018:8880a0e9f9c0 EFLAGS: 00010286
RAX: 0147 RBX: dc00 RCX: 
RDX:  RSI: 815cb676 RDI: ed10141d3f12
RBP: 8880a0e9fa88 R08: 0147 R09: ed1015d06161
R10: ed1015d06160 R11: 8880ae830b07 R12: 888095f28e10
R13: 88808c0f7f18 R14:  R15: 0001
FS:  00c57940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20d06000 CR3: 90f89000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 vma_merge+0xb8a/0xe60 mm/mmap.c:1169
 mmap_region+0x3e0/0x1760 mm/mmap.c:1741
 do_mmap+0x853/0x1190 mm/mmap.c:1552
 do_mmap_pgoff include/linux/mm.h:2361 [inline]
 vm_mmap_pgoff+0x1c5/0x230 mm/util.c:510
 ksys_mmap_pgoff+0xf7/0x630 mm/mmap.c:1604
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
 __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459a59
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ffcc91b5068 EFLAGS: 0246 ORIG_RAX: 0009
RAX: ffda RBX: 0006 RCX: 00459a59
RDX: efff RSI: 4000 RDI: 20196000
RBP: 0075bf20 R08:  R09: 
R10: 8032 R11: 0246 R12: 00c57914
R13: 004c6176 R14: 004db118 R15: 
Modules linked in:
---[ end trace aa2e499bc1c6fb5e ]---
RIP: 0010:anon_vma_merge include/linux/rmap.h:159 [inline]
RIP: 0010:__vma_adjust+0x151c/0x1cc0 mm/mmap.c:921
Code: 4c 89 ee 4c 89 f7 e8 b3 01 d2 ff 4d 39 ee 0f 82 1b fe ff ff 45 31 ed  
e9 1b fe ff ff e8 7d 00 d2 ff 48 8b 7d c8 e8 76 62 fc ff <0f> 0b e8 6d 00  
d2 ff 48 8b 85 68 ff ff ff 80 38 00 0f 85 20 07 00

RSP: 0018:8880a0e9f9c0 EFLAGS: 00010286
RAX: 0147 RBX: dc00 RCX: 
RDX:  RSI: 815cb676 RDI: ed10141d3f12
RBP: 8880a0e9fa88 R08: 0147 R09: ed1015d06161
R10: ed1015d06160 R11: 8880ae830b07 R12: 888095f28e10
R13: 88808c0f7f18 R14:  R15: 0001
FS:  00c57940() GS:8880ae80() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20d06000 CR3: 90f89000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.

Re: [PATCH 3/3] perf tools: Make 'struct map_shared' truly shared

[Andi Kleen]

On Sun, Oct 13, 2019 at 05:14:27PM +0200, Jiri Olsa wrote:
> Andi reported that maps cloning is eating lot of memory and
> it's probably unnecessary, because they keep the same data.
> 
> Changing 'struct map_shared' to be a pointer inside 'struct map',
> so it can be shared on fork. Changing the map__clone function to
> actually share 'struct map_shared' for cloned maps.
> 
> The 'struct map_shared' carries its own refcnt counter, which is
> incremented when it's assigned to new 'struct map' and decremented
> when 'struct map' gets deleted in map__delete (its refcnt is 0).
> 
> This 'maps sharing' seems to save lot of heap for reports with
> many forks/cloned mmaps (over 60% in example below).

The one case I wasn't sure about is with JIT support. So if
a map gets modified with fixup/start from /tmp/perf-%d 
in one process, would it impact the other too?

We may need a COW operation for this (hopefully rare) case.

-Andi

[PATCH v2 2/2] pinctrl: rockchip: add rk3308 SoC support

[Jianqun Xu]

This patch do support pinctrl for RK3308 SoCs.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
changes since v1:
- Add type case for pull get/set
- Add Reviewed-by: Heiko Stuebner 

 drivers/pinctrl/pinctrl-rockchip.c | 379 +
 1 file changed, 379 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index dc0bbf198cbc..15eff9676ad0 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -58,6 +58,7 @@ enum rockchip_pinctrl_type {
RK3128,
RK3188,
RK3288,
+   RK3308,
RK3368,
RK3399,
 };
@@ -70,6 +71,7 @@ enum rockchip_pinctrl_type {
 #define IOMUX_SOURCE_PMU   BIT(2)
 #define IOMUX_UNROUTED BIT(3)
 #define IOMUX_WIDTH_3BIT   BIT(4)
+#define IOMUX_WIDTH_2BIT   BIT(5)
 
 /**
  * @type: iomux variant using IOMUX_* constants
@@ -656,6 +658,100 @@ static  struct rockchip_mux_recalced_data 
rk3128_mux_recalced_data[] = {
},
 };
 
+static struct rockchip_mux_recalced_data rk3308_mux_recalced_data[] = {
+   {
+   .num = 1,
+   .pin = 14,
+   .reg = 0x28,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 15,
+   .reg = 0x2c,
+   .bit = 0,
+   .mask = 0x3
+   }, {
+   .num = 1,
+   .pin = 18,
+   .reg = 0x30,
+   .bit = 4,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 19,
+   .reg = 0x30,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 20,
+   .reg = 0x30,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 21,
+   .reg = 0x34,
+   .bit = 0,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 22,
+   .reg = 0x34,
+   .bit = 4,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 23,
+   .reg = 0x34,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 3,
+   .pin = 12,
+   .reg = 0x68,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 3,
+   .pin = 13,
+   .reg = 0x68,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 2,
+   .pin = 2,
+   .reg = 0x608,
+   .bit = 0,
+   .mask = 0x7
+   }, {
+   .num = 2,
+   .pin = 3,
+   .reg = 0x608,
+   .bit = 4,
+   .mask = 0x7
+   }, {
+   .num = 2,
+   .pin = 16,
+   .reg = 0x610,
+   .bit = 8,
+   .mask = 0x7
+   }, {
+   .num = 3,
+   .pin = 10,
+   .reg = 0x610,
+   .bit = 0,
+   .mask = 0x7
+   }, {
+   .num = 3,
+   .pin = 11,
+   .reg = 0x610,
+   .bit = 4,
+   .mask = 0x7
+   },
+};
+
 static struct rockchip_mux_recalced_data rk3328_mux_recalced_data[] = {
{
.num = 2,
@@ -982,6 +1078,192 @@ static struct rockchip_mux_route_data 
rk3288_mux_route_data[] = {
},
 };
 
+static struct rockchip_mux_route_data rk3308_mux_route_data[] = {
+   {
+   /* rtc_clk */
+   .bank_num = 0,
+   .pin = 19,
+   .func = 1,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 0) | BIT(0),
+   }, {
+   /* uart2_rxm0 */
+   .bank_num = 1,
+   .pin = 22,
+   .func = 2,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 2) | BIT(16 + 3),
+   }, {
+   /* uart2_rxm1 */
+   .bank_num = 4,
+   .pin = 26,
+   .func = 2,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 2) | BIT(16 + 3) | BIT(2),
+   }, {
+   /* i2c3_sdam0 */
+   .bank_num = 0,
+   .pin = 15,
+   .func = 2,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 9),
+   }, {
+   /* i2c3_sdam1 */
+   .bank_num = 3,
+   .pin = 12,
+   .func = 2,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 9) | BIT(8),
+   }, {
+   /* i2c3_sdam2 */
+   .bank_num = 2,
+   .pin = 0,
+   .func = 3,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 

[PATCH v2 1/2] dt-bindings: pinctrl: rockchip: add rk3308 SoC support

[Jianqun Xu]

Add rk3308 SoC support to rockchip pinctrl.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
changes since v1:
- Add Reviewed-by: Heiko Stuebner 

 Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index 0919db294c17..2113cfaa26e6 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -29,6 +29,7 @@ Required properties for iomux controller:
"rockchip,rk3188-pinctrl":  for Rockchip RK3188
"rockchip,rk3228-pinctrl":  for Rockchip RK3228
"rockchip,rk3288-pinctrl":  for Rockchip RK3288
+   "rockchip,rk3308-pinctrl":  for Rockchip RK3308
"rockchip,rk3328-pinctrl":  for Rockchip RK3328
"rockchip,rk3368-pinctrl":  for Rockchip RK3368
"rockchip,rk3399-pinctrl":  for Rockchip RK3399
-- 
2.17.1

[PATCH v2 0/2] pinctrl: rockchip: support rk3308 SoC

[Jianqun Xu]

Add support for rk3308 SoC from rockchip.

Jianqun Xu (2):
  dt-bindings: pinctrl: rockchip: add rk3308 SoC support
  pinctrl: rockchip: add rk3308 SoC support

 .../bindings/pinctrl/rockchip,pinctrl.txt |   1 +
 drivers/pinctrl/pinctrl-rockchip.c| 379 ++
 2 files changed, 380 insertions(+)

-- 
changes since v1:
- Add type case for pull get/set
- Add Reviewed-by: Heiko Stuebner 


2.17.1

Re: [PATCH 2/7] Add a concept of a "secure" anonymous file

[kbuild test robot]

Hi Daniel,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Daniel-Colascione/Harden-userfaultfd/20191014-102741
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All errors (new ones prefixed by >>):

   fs/anon_inodes.c: In function 'anon_inode_make_secure_inode':
>> fs/anon_inodes.c:67:10: error: implicit declaration of function 
>> 'security_inode_init_security_anon'; did you mean 
>> 'security_inode_init_security'? [-Werror=implicit-function-declaration]
 error = security_inode_init_security_anon(inode, name, fops);
 ^
 security_inode_init_security
   cc1: some warnings being treated as errors

vim +67 fs/anon_inodes.c

57  
58  struct inode *anon_inode_make_secure_inode(const char *name,
59 const struct file_operations 
*fops)
60  {
61  struct inode *inode;
62  int error;
63  inode = alloc_anon_inode(anon_inode_mnt->mnt_sb);
64  if (IS_ERR(inode))
65  return ERR_PTR(PTR_ERR(inode));
66  inode->i_flags &= ~S_PRIVATE;
  > 67  error = security_inode_init_security_anon(inode, name, fops);
68  if (error) {
69  iput(inode);
70  return ERR_PTR(error);
71  }
72  return inode;
73  }
74  

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


.config.gz
Description: application/gzip

[PATCH v4 1/3] powerpc: Don't add -mabi= flags when building with Clang

[Nathan Chancellor]

When building pseries_defconfig, building vdso32 errors out:

  error: unknown target ABI 'elfv1'

This happens because -m32 in clang changes the target to 32-bit,
which does not allow the ABI to be changed, as the setABI virtual
function is not overridden:

https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0/clang/include/clang/Basic/TargetInfo.h#L1073-L1078

https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0/clang/lib/Basic/Targets/PPC.h#L327-L365

Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
powerpc64le toolchain") added these flags to fix building big endian
kernels with a little endian GCC.

Clang doesn't need -mabi because the target triple controls the default
value. -mlittle-endian and -mbig-endian manipulate the triple into
either powerpc64-* or powerpc64le-*, which properly sets the default
ABI:

https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0/clang/lib/Driver/Driver.cpp#L450-L463

https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0/llvm/lib/Support/Triple.cpp#L1432-L1516

https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0/clang/lib/Basic/Targets/PPC.h#L377-L383

Adding a debug print out in the PPC64TargetInfo constructor after line
383 above shows this:

$ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null -
Default ABI: elfv1

$ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null -
Default ABI: elfv2

$ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null -
Default ABI: elfv1

$ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null -
Default ABI: elfv2

Don't specify -mabi when building with clang to avoid the build error
with -m32 and not change any code generation.

-mcall-aixdesc is not an implemented flag in clang so it can be
safely excluded as well, see commit 238abecde8ad ("powerpc: Don't
use gcc specific options on clang").

pseries_defconfig successfully builds after this patch and
powernv_defconfig and ppc44x_defconfig don't regress.

Link: https://github.com/ClangBuiltLinux/linux/issues/240
Reviewed-by: Daniel Axtens 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Improve commit message

v2 -> v3:

* Rebase and merge into a single series.

v3 -> v4:

* Rebase on v5.4-rc3.

* Update links to point to llvmorg-9.0.0 instead of llvmorg-9.0.0-rc2.

 arch/powerpc/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 83522c9fc7b6..37ac731a556b 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -91,11 +91,13 @@ MULTIPLEWORD:= -mmultiple
 endif
 
 ifdef CONFIG_PPC64
+ifndef CONFIG_CC_IS_CLANG
 cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call cc-option,-mabi=elfv1)
 cflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call 
cc-option,-mcall-aixdesc)
 aflags-$(CONFIG_CPU_BIG_ENDIAN)+= $(call cc-option,-mabi=elfv1)
 aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
 endif
+endif
 
 ifndef CONFIG_CC_IS_CLANG
   cflags-$(CONFIG_CPU_LITTLE_ENDIAN)   += -mno-strict-align
@@ -141,6 +143,7 @@ endif
 endif
 
 CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
+ifndef CONFIG_CC_IS_CLANG
 ifdef CONFIG_CPU_LITTLE_ENDIAN
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call 
cc-option,-mcall-aixdesc))
 AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
@@ -149,6 +152,7 @@ CFLAGS-$(CONFIG_PPC64)  += $(call cc-option,-mabi=elfv1)
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
 AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
 endif
+endif
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call 
cc-option,-mminimal-toc))
 CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
 
-- 
2.23.0

[PATCH v4 2/3] powerpc: Avoid clang warnings around setjmp and longjmp

[Nathan Chancellor]

Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
setjmp is used") disabled -Wbuiltin-requires-header because of a warning
about the setjmp and longjmp declarations.

r367387 in clang added another diagnostic around this, complaining that
there is no jmp_buf declaration.

In file included from ../arch/powerpc/xmon/xmon.c:47:
../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of
built-in function 'setjmp' requires the declaration of the 'jmp_buf'
type, commonly provided in the header .
[-Werror,-Wincomplete-setjmp-declaration]
extern long setjmp(long *);
^
../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of
built-in function 'longjmp' requires the declaration of the 'jmp_buf'
type, commonly provided in the header .
[-Werror,-Wincomplete-setjmp-declaration]
extern void longjmp(long *, long);
^
2 errors generated.

We are not using the standard library's longjmp/setjmp implementations
for obvious reasons; make this clear to clang by using -ffreestanding
on these files.

Cc: sta...@vger.kernel.org # 4.14+
Link: https://github.com/ClangBuiltLinux/linux/issues/625
Link: 
https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07
Link: https://godbolt.org/z/B2oQnl
Suggested-by: Segher Boessenkool 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---

v1 -> v3 (I skipped v2 because the first patch in the series already
  had a v2):

* Use -ffreestanding instead of outright disabling the warning because
  it is legitimate.

v3 -> v4:

* Rebase on v5.4-rc3

* Add Nick's reviewed-by and Compiler Explorer link.

 arch/powerpc/kernel/Makefile | 4 ++--
 arch/powerpc/xmon/Makefile   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a7ca8fe62368..f1f362146135 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -5,8 +5,8 @@
 
 CFLAGS_ptrace.o+= -DUTS_MACHINE='"$(UTS_MACHINE)"'
 
-# Disable clang warning for using setjmp without setjmp.h header
-CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header)
+# Avoid clang warnings around longjmp/setjmp declarations
+CFLAGS_crash.o += -ffreestanding
 
 ifdef CONFIG_PPC64
 CFLAGS_prom_init.o += $(NO_MINIMAL_TOC)
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index f142570ad860..c3842dbeb1b7 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 # Makefile for xmon
 
-# Disable clang warning for using setjmp without setjmp.h header
-subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)
+# Avoid clang warnings around longjmp/setjmp declarations
+subdir-ccflags-y := -ffreestanding
 
 GCOV_PROFILE := n
 KCOV_INSTRUMENT := n
-- 
2.23.0

[PATCH v4 0/3] LLVM/Clang fixes for pseries_defconfig

[Nathan Chancellor]

Hi all,

This series includes a set of fixes for LLVM/Clang when building
pseries_defconfig. These have been floating around as standalone
patches so I decided to gather them up as a series so it was easier
to review/apply them.

This has been broken for a bit now, it would be nice to get these
reviewed and applied. Please let me know if I need to do anything
to move these along.

Previous versions:

https://lore.kernel.org/lkml/20190911182049.77853-1-natechancel...@gmail.com/

Cheers,
Nathan

[PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

[Nathan Chancellor]

r374662 gives LLVM the ability to convert certain loops into a reference
to bcmp as an optimization; this breaks prom_init_check.sh:

  CALLarch/powerpc/kernel/prom_init_check.sh
Error: External symbol 'bcmp' referenced from prom_init.c
make[2]: *** [arch/powerpc/kernel/Makefile:196: prom_init_check] Error 1

bcmp is defined in lib/string.c as a wrapper for memcmp so this could be
added to the whitelist. However, commit 450e7dd4001f ("powerpc/prom_init:
don't use string functions from lib/") copied memcmp as prom_memcmp to
avoid KASAN instrumentation so having bcmp be resolved to regular memcmp
would break that assumption. Furthermore, because the compiler is the
one that inserted bcmp, we cannot provide something like prom_bcmp.

To prevent LLVM from being clever with optimizations like this, use
-ffreestanding to tell LLVM we are not hosted so it is not free to make
transformations like this.

Link: https://github.com/ClangBuiltLinux/linux/issues/647
Link: 
https://github.com/llvm/llvm-project/commit/76cdcf25b883751d83402baea6316772aa73865c
Reviewed-by: Nick Desaulneris 
Signed-off-by: Nathan Chancellor 
---

v1 -> v3:

* New patch in the series

v3 -> v4:

* Rebase on v5.4-rc3.

* Add Nick's reviewed-by tag.

* Update the LLVM commit reference to the latest applied version (r374662)
  as it was originally committed as r370454, reverted in r370788, and
  reapplied as r374662.

 arch/powerpc/kernel/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index f1f362146135..7f0ee465dfb6 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -21,7 +21,7 @@ CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 
-CFLAGS_prom_init.o += $(call cc-option, -fno-stack-protector)
+CFLAGS_prom_init.o += $(call cc-option, -fno-stack-protector) -ffreestanding
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-- 
2.23.0

KASAN: use-after-free Read in bpf_prog_kallsyms_find (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:b212921b elf: don't use MAP_FIXED_NOREPLACE for elf execut..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148abb3f60
kernel config:  https://syzkaller.appspot.com/x/.config?x=1ec3be9936e004f6
dashboard link: https://syzkaller.appspot.com/bug?extid=0bd67ad376a3f4a8606e
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15f4f6c360
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10a1b85760

The bug was bisected to:

commit 6c4fc209fcf9d27efbaa48368773e4d2bfbd59aa
Author: Daniel Borkmann 
Date:   Sat Dec 15 23:49:47 2018 +

bpf: remove useless version check for prog load

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16894e6360
final crash:https://syzkaller.appspot.com/x/report.txt?x=15894e6360
console output: https://syzkaller.appspot.com/x/log.txt?x=11894e6360

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0bd67ad376a3f4a86...@syzkaller.appspotmail.com
Fixes: 6c4fc209fcf9 ("bpf: remove useless version check for prog load")

==
BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:199  
[inline]
BUG: KASAN: use-after-free in __lt_find include/linux/rbtree_latch.h:118  
[inline]
BUG: KASAN: use-after-free in latch_tree_find  
include/linux/rbtree_latch.h:208 [inline]
BUG: KASAN: use-after-free in bpf_prog_kallsyms_find kernel/bpf/core.c:674  
[inline]
BUG: KASAN: use-after-free in bpf_prog_kallsyms_find+0x2a9/0x2c0  
kernel/bpf/core.c:667

Read of size 8 at addr 8880948217c8 by task syz-executor436/18258

CPU: 0 PID: 18258 Comm: syz-executor436 Not tainted 5.4.0-rc1+ #0
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+0x172/0x1f0 lib/dump_stack.c:113
 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
 kasan_report+0x12/0x20 mm/kasan/common.c:634
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
 __read_once_size include/linux/compiler.h:199 [inline]
 __lt_find include/linux/rbtree_latch.h:118 [inline]
 latch_tree_find include/linux/rbtree_latch.h:208 [inline]
 bpf_prog_kallsyms_find kernel/bpf/core.c:674 [inline]
 bpf_prog_kallsyms_find+0x2a9/0x2c0 kernel/bpf/core.c:667
 is_bpf_text_address+0x78/0x170 kernel/bpf/core.c:709
 kernel_text_address+0x73/0xf0 kernel/extable.c:147
 __kernel_text_address+0xd/0x40 kernel/extable.c:102
 unwind_get_return_address arch/x86/kernel/unwind_frame.c:19 [inline]
 unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:14
 arch_stack_walk+0x97/0xf0 arch/x86/kernel/stacktrace.c:26
 stack_trace_save+0xac/0xe0 kernel/stacktrace.c:123
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:510 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:483
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:524
 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:686 [inline]
 bpf_check+0xd8/0x99c0 kernel/bpf/verifier.c:9227
 bpf_prog_load+0xe68/0x1660 kernel/bpf/syscall.c:1709
 __do_sys_bpf+0xa44/0x3350 kernel/bpf/syscall.c:2866
 __se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
 __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2825
 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446949
Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f134f31edb8 EFLAGS: 0246 ORIG_RAX: 0141
RAX: ffda RBX: 006dbc28 RCX: 00446949
RDX: 0070 RSI: 2440 RDI: 0005
RBP: 006dbc20 R08:  R09: 
R10:  R11: 0246 R12: 006dbc2c
R13: 7ffd29fc3fff R14: 7f134f31f9c0 R15: 002d

Allocated by task 18255:
 save_stack+0x23/0x90 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:510 [inline]
 __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:483
 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:524
 kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3550
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:686 [inline]
 bpf_prog_alloc_no_stats+0xe6/0x2b0 kernel/bpf/core.c:88
 jit_subprogs kernel/bpf/verifier.c:8716 [inline]
 fixup_call_args kernel/bpf/verifier.c:8845 [inline]
 bpf_check+0x6b3d/0x99c0 kernel/bpf/verifier.c:9349
 bpf_prog_load+0xe68/0x1660 

WARNING: refcount bug in sock_wfree (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:442630f6 Add linux-next specific files for 20191008
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=158fa6bf60
kernel config:  https://syzkaller.appspot.com/x/.config?x=af1bfeef713eefdd
dashboard link: https://syzkaller.appspot.com/bug?extid=c0ba5b9e742f049a2edf
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15a861b360
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1769f48b60

The bug was bisected to:

commit 6c080ff07363389cb4092193eb333639f0392b8c
Author: Jens Axboe 
Date:   Thu Oct 3 14:11:03 2019 +

io_uring: allow sparse fixed file sets

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1344b99360
final crash:https://syzkaller.appspot.com/x/report.txt?x=10c4b99360
console output: https://syzkaller.appspot.com/x/log.txt?x=1744b99360

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c0ba5b9e742f049a2...@syzkaller.appspotmail.com
Fixes: 6c080ff07363 ("io_uring: allow sparse fixed file sets")

[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 8691 at lib/refcount.c:190  
refcount_sub_and_test_checked lib/refcount.c:190 [inline]
WARNING: CPU: 0 PID: 8691 at lib/refcount.c:190  
refcount_sub_and_test_checked+0x1d0/0x200 lib/refcount.c:180

Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 8691 Comm: syz-executor322 Not tainted 5.4.0-rc2-next-20191008  
#0
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+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2e3/0x75c kernel/panic.c:221
 __warn.cold+0x2f/0x35 kernel/panic.c:582
 report_bug+0x289/0x300 lib/bug.c:195
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 fixup_bug arch/x86/kernel/traps.c:169 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:refcount_sub_and_test_checked lib/refcount.c:190 [inline]
RIP: 0010:refcount_sub_and_test_checked+0x1d0/0x200 lib/refcount.c:180
Code: 1d b0 f0 7f 06 31 ff 89 de e8 6c d7 30 fe 84 db 75 94 e8 23 d6 30 fe  
48 c7 c7 20 81 e6 87 c6 05 90 f0 7f 06 01 e8 e8 15 02 fe <0f> 0b e9 75 ff  
ff ff e8 04 d6 30 fe e9 6e ff ff ff 48 89 df e8 e7

RSP: 0018:8880a8267a28 EFLAGS: 00010282
RAX:  RBX:  RCX: 
RDX:  RSI: 815cb676 RDI: ed101504cf37
RBP: 8880a8267ac0 R08: 888090e363c0 R09: fbfff14eeb42
R10: fbfff14eeb41 R11: 8a775a0f R12: fd02
R13: 0001 R14: 8880a8267a98 R15: 0001
 sock_wfree+0x10c/0x190 net/core/sock.c:1958
 unix_destruct_scm+0x115/0x170 net/unix/scm.c:149
 io_destruct_skb+0x62/0x80 fs/io_uring.c:2995
 skb_release_head_state+0xeb/0x260 net/core/skbuff.c:652
 skb_release_all+0x16/0x60 net/core/skbuff.c:663
 __kfree_skb net/core/skbuff.c:679 [inline]
 kfree_skb net/core/skbuff.c:697 [inline]
 kfree_skb+0x101/0x3c0 net/core/skbuff.c:691
 __io_sqe_files_scm+0x429/0x640 fs/io_uring.c:3049
 io_sqe_files_scm fs/io_uring.c:3071 [inline]
 io_sqe_files_register fs/io_uring.c:3154 [inline]
 __io_uring_register+0x1f69/0x2d70 fs/io_uring.c:4152
 __do_sys_io_uring_register fs/io_uring.c:4204 [inline]
 __se_sys_io_uring_register fs/io_uring.c:4186 [inline]
 __x64_sys_io_uring_register+0x193/0x1f0 fs/io_uring.c:4186
 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440279
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ffeeedc31e8 EFLAGS: 0246 ORIG_RAX: 01ab
RAX: ffda RBX: 004002c8 RCX: 00440279
RDX: 2280 RSI: 0002 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10: 0001 R11: 0246 R12: 00401b00
R13: 00401b90 R14:  R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

memory leak in sctp_get_port_local (3)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:da940012 Merge tag 'char-misc-5.4-rc3' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11c87fc760
kernel config:  https://syzkaller.appspot.com/x/.config?x=e76c708f07645488
dashboard link: https://syzkaller.appspot.com/bug?extid=d44f7bbebdea49dbc84a
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=128d3f8b60
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17ead04b60

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d44f7bbebdea49dbc...@syzkaller.appspotmail.com

executing program
executing program
BUG: memory leak
unreferenced object 0x888120b3d380 (size 64):
  comm "syz-executor517", pid 6949, jiffies 4294941316 (age 13.400s)
  hex dump (first 32 bytes):
23 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 00  #N..
88 16 ef 24 81 88 ff ff 00 00 00 00 00 00 00 00  ...$
  backtrace:
[<6e6207b2>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:43 [inline]

[<6e6207b2>] slab_post_alloc_hook mm/slab.h:586 [inline]
[<6e6207b2>] slab_alloc mm/slab.c:3319 [inline]
[<6e6207b2>] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
[] sctp_bucket_create net/sctp/socket.c:8523 [inline]
[] sctp_get_port_local+0x189/0x5a0  
net/sctp/socket.c:8270

[<82735c7f>] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402
[<80c8d55e>] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497
[] sctp_setsockopt_bindx+0x156/0x1b0  
net/sctp/socket.c:1022

[<4e959dd5>] sctp_setsockopt net/sctp/socket.c:4641 [inline]
[<4e959dd5>] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611
[<0e9e767a>] sock_common_setsockopt+0x38/0x50  
net/core/sock.c:3147

[] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
[<3c15b96c>] __do_sys_setsockopt net/socket.c:2100 [inline]
[<3c15b96c>] __se_sys_setsockopt net/socket.c:2097 [inline]
[<3c15b96c>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
[] do_syscall_64+0x73/0x1f0  
arch/x86/entry/common.c:290

[<6bf005e9>] entry_SYSCALL_64_after_hwframe+0x44/0xa9



---
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. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

WARNING in vkms_gem_free_object

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:8ada228a Add linux-next specific files for 20191011
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14c30b1b60
kernel config:  https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a
dashboard link: https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1087d31b60
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15e27c5360

The bug was bisected to:

commit 94e2ec3f7fef86506293a448273b2b4ee21e6195
Author: Oleg Vasilev 
Date:   Mon Sep 30 15:59:24 2019 +

drm/vkms: prime import support

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15ef2d5760
final crash:https://syzkaller.appspot.com/x/report.txt?x=17ef2d5760
console output: https://syzkaller.appspot.com/x/log.txt?x=13ef2d5760

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e7ad70d406e74d8fc...@syzkaller.appspotmail.com
Fixes: 94e2ec3f7fef ("drm/vkms: prime import support")

[ cut here ]
WARNING: CPU: 1 PID: 9040 at drivers/gpu/drm/vkms/vkms_gem.c:37  
vkms_gem_free_object+0x92/0xb0 drivers/gpu/drm/vkms/vkms_gem.c:37

Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9040 Comm: syz-executor028 Not tainted 5.4.0-rc2-next-20191011  
#0
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+0x172/0x1f0 lib/dump_stack.c:113
 panic+0x2e3/0x75c kernel/panic.c:221
 __warn.cold+0x2f/0x35 kernel/panic.c:582
 report_bug+0x289/0x300 lib/bug.c:195
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 fixup_bug arch/x86/kernel/traps.c:169 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:vkms_gem_free_object+0x92/0xb0 drivers/gpu/drm/vkms/vkms_gem.c:37
Code: 44 68 7f fd 49 8d bc 24 f8 01 00 00 e8 c7 8d 64 fd 4c 89 e7 e8 3f 39  
ae ff 4c 89 e7 e8 f7 9a ba fd 41 5c 5d c3 e8 1e 68 7f fd <0f> 0b eb a2 e8  
15 68 7f fd 0f 0b eb c8 e8 2c e7 ba fd eb b6 e8 25

RSP: 0018:8880971df9e8 EFLAGS: 00010293
RAX: 8880989c2200 RBX: 894e5000 RCX: 83a1eda6
RDX:  RSI: 83f3ab02 RDI: 8880a8c4fa78
RBP: 8880971df9f0 R08: 8880989c2200 R09: ed1012e3bf36
R10: ed1012e3bf35 R11: 0003 R12: 8880a8c4f800
R13: 8880a3ab8000 R14: 83f3aa70 R15: 8880a3ab8020
 drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983
 kref_put include/linux/kref.h:65 [inline]
 drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline]
 drm_gem_object_put_unlocked+0x127/0x170 drivers/gpu/drm/drm_gem.c:1002
 drm_gem_object_handle_put_unlocked+0x1ad/0x2d0  
drivers/gpu/drm/drm_gem.c:239

 drm_gem_object_release_handle+0x102/0x1c0 drivers/gpu/drm/drm_gem.c:261
 idr_for_each+0x138/0x250 lib/idr.c:208
 drm_gem_release+0x27/0x40 drivers/gpu/drm/drm_gem.c:939
 drm_file_free.part.0+0x7f4/0xc00 drivers/gpu/drm/drm_file.c:244
 drm_file_free drivers/gpu/drm/drm_file.c:213 [inline]
 drm_close_helper drivers/gpu/drm/drm_file.c:271 [inline]
 drm_release+0x286/0x3f0 drivers/gpu/drm/drm_file.c:443
 __fput+0x2ff/0x890 fs/file_table.c:280
 fput+0x16/0x20 fs/file_table.c:313
 task_work_run+0x145/0x1c0 kernel/task_work.c:113
 exit_task_work include/linux/task_work.h:22 [inline]
 do_exit+0x904/0x2e60 kernel/exit.c:817
 do_group_exit+0x135/0x360 kernel/exit.c:921
 __do_sys_exit_group kernel/exit.c:932 [inline]
 __se_sys_exit_group kernel/exit.c:930 [inline]
 __x64_sys_exit_group+0x44/0x50 kernel/exit.c:930
 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442bb8
Code: Bad RIP value.
RSP: 002b:7ffd8fdc0b98 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 00442bb8
RDX:  RSI: 003c RDI: 
RBP: 004c24c8 R08: 00e7 R09: ffd0
R10: 004002e0 R11: 0246 R12: 0001
R13: 006d41a0 R14:  R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCHv7 25/33] x86/vdso: Zap vvar pages on switch a time namspace

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: parisc-b180_defconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=parisc 

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

All errors (new ones prefixed by >>):

   kernel/time/namespace.o: In function `timens_set_vvar_page.isra.8.part.9':
   (.text+0x130): undefined reference to `arch_get_vdso_data'
   kernel/time/namespace.o: In function `timens_install':
>> (.text+0x6e0): undefined reference to `vdso_join_timens'
   kernel/time/namespace.o: In function `timens_on_fork':
   (.text+0x804): undefined reference to `vdso_join_timens'

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


.config.gz
Description: application/gzip

Re: [PATCHv7 22/33] time: Allocate per-timens vvar page

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: riscv-defconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=riscv 

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

All errors (new ones prefixed by >>):

   kernel/time/namespace.o: In function `.L0 ':
>> namespace.c:(.text+0xfc): undefined reference to `arch_get_vdso_data'

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


.config.gz
Description: application/gzip

[REGRESSION] kmemleak: commit c566586818 causes failure to boot

[Theodore Y. Ts'o]

Commit c566586818 ("mm: kmemleak: use the memory pool for early
allocations") causes my test kernels to fail to boot on using both kvm
and using Google Compute Engine.  A git bisect localized it to
c566586818, and I confirmed by test building v5.4-rc3, which failed as
above using KVM.  When I reverted c566586818 the kernel booted
successfully.

The symptoms are that the boot hangs after:

[2.844808] hctosys: unable to open rtc device (rtc0)

and then about 25 seconds later, we get the following warning:

[   28.237938] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:1:7]
[   28.239345] irq event stamp: 198897938
[   28.240017] hardirqs last  enabled at (198897937): [] 
_raw_write_unlock_irqrestore+
0x43/0x47
[   28.241979] hardirqs last disabled at (198897938): [] 
trace_hardirqs_off_thunk+0x1a
/0x20
[   28.243930] softirqs last  enabled at (198876302): [] 
__do_softirq+0x32a/0x42a
[   28.247350] softirqs last disabled at (198876295): [] 
irq_exit+0xb3/0xc0
[   28.250080] CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 
5.4.0-rc3-xfstests-00403-g4f5cafb5cb84 #1225
[   28.253081] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   28.254885] Workqueue: events kmemleak_do_cleanup
[   28.255570] RIP: 0010:_raw_write_unlock_irqrestore+0x45/0x47
[   28.256401] Code: e8 b0 4d 60 ff 48 89 ef e8 d8 a6 60 ff f6 c7 02 75 11 53 
9d e8 dc b1 68 ff 65 ff 0d
 cd 73 10 5f 5b 5d c3 e8 ed b0 68 ff 53 9d  ed 90 90 90 90 90 90 90 90 90 
90 90 90 90 90 90 90 90 90
 90 90
[   28.260440] RSP: :98984006fdf8 EFLAGS: 0246 ORIG_RAX: 
ff13
[   28.262258] RAX: 94d7fd23a1c0 RBX: 0246 RCX: 0006
[   28.264238] RDX: 0007 RSI: 94d7fd23a9c0 RDI: 94d7fd23a1c0
[   28.267333] RBP: a1c94bc0 R08: 0006931c1cf2 R09: 
[   28.269871] R10:  R11:  R12: 
[   28.272175] R13:  R14:  R15: a1c94aa8
[   28.274649] FS:  () GS:94d7fd80() 
knlGS:
[   28.277758] CS:  0010 DS:  ES:  CR0: 80050033
[   28.279638] CR2:  CR3: 5fc12001 CR4: 00360ef0
[   28.282367] Call Trace:
[   28.283075]  find_and_remove_object+0x7f/0x90
[   28.284335]  delete_object_full+0xc/0x20
[   28.285488]  __kmemleak_do_cleanup+0x63/0x100
[   28.286913]  process_one_work+0x246/0x570
[   28.288801]  worker_thread+0x50/0x3b0
[   28.290406]  ? process_one_work+0x570/0x570
[   28.291497]  kthread+0x126/0x140
[   28.292316]  ? kthread_delayed_work_timer_fn+0xa0/0xa0
[   28.294262]  ret_from_fork+0x3a/0x50
[   28.837921] rcu: INFO: rcu_sched self-detected stall on CPU
...

I've attached the log from the KVM session and the config.gz used to
build the kernels.

- Ted


config.gz
Description: application/gzip


log.201910132216.gz
Description: application/gzip

Re: [PATCH xfstests] generic/192: Move 'cd /' to the place where the program exits

[Zhihao Cheng]

I agree with your proposal. Indeed, '$here' is referenced in other places where 
executable files under src are used, including '$here/src/feature', 
'$here/src/seek_sanity_test', etc.
I have a question about why many test cases execute 'cd /' before the end. For 
example, generic/124, generic/122, generic/003. I wonder the intention of 
operation 'cd /'.

在 2019/10/13 20:46, Eryu Guan 写道:
> On Wed, Oct 09, 2019 at 04:27:57PM +0800, Zhihao Cheng wrote:
>> Running generic/192 with overlayfs(Let ubifs as base fs) yields the
>> following output:
>>
>>   generic/192 - output mismatch
>>  QA output created by 192
>>  sleep for 5 seconds
>>  test
>> +./common/rc: line 316: src/t_dir_type: No such file or directory
>>  delta1 is in range
>>  delta2 is in range
>> ...
>>
>> When the use case fails, the call stack in generic/192 is:
>>
>>   local unknowns=$(src/t_dir_type $dir u | wc -l)common/rc:316
>>   _supports_filetype common/rc:299
>>   _overlay_mount common/overlay:52
>>   _overlay_test_mount
>> common/overlay:93
>>   _test_mountcommon/rc:407
>>   _test_cycle_mount  generic/192:50
>>
>> Before _test_cycle_mount() being invoked, generic/192 executed 'cd /'
>> to change work dir from 'xfstests-dev' to '/', so src/t_dir_type was not
>> found.
>>
>> Signed-off-by: Zhihao Cheng 
> 
> Thanks for the debug! But I think the right fix is to call t_dir_type
> via "$here", i.e.
> 
>   local unknowns=$($here/src/t_dir_type $dir u | wc -l)
> 
> 'here', which points to the top level dir of xfstests source code, is
> defined in every test in test setup, and is guaranteed not to be empty.
> 
> Thanks,
> Eryu
> 
>> ---
>>  tests/generic/192 | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/generic/192 b/tests/generic/192
>> index 50b3d6fd..5550f39e 100755
>> --- a/tests/generic/192
>> +++ b/tests/generic/192
>> @@ -15,7 +15,12 @@ echo "QA output created by $seq"
>>  here=`pwd`
>>  tmp=/tmp/$$
>>  status=1# failure is the default!
>> -trap "exit \$status" 0 1 2 3 15
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +_cleanup()
>> +{
>> +cd /
>> +}
>>  
>>  _access_time()
>>  {
>> @@ -46,7 +51,6 @@ sleep $delay # sleep to allow time to move on for access
>>  cat $testfile
>>  time2=`_access_time $testfile | tee -a $seqres.full`
>>  
>> -cd /
>>  _test_cycle_mount
>>  time3=`_access_time $testfile | tee -a $seqres.full`
>>  
>> -- 
>> 2.13.6
>>
> 
> .
> 

Re: [PATCH] kernel: dma: Make CMA boot parameters __ro_after_init

[Nathan Chancellor]

On Sat, Oct 12, 2019 at 05:59:18PM +0530, Shyam Saini wrote:
> This parameters are not changed after early boot.
> By making them __ro_after_init will reduce any attack surface in the
> kernel.
> 
> Link: https://lwn.net/Articles/676145/
> Cc: Christoph Hellwig 
> Cc: Marek Szyprowski 
> Cc: Robin Murphy 
> Cc: Matthew Wilcox 
> Cc: Christopher Lameter 
> Cc: Kees Cook 
> Signed-off-by: Shyam Saini 
> ---
>  kernel/dma/contiguous.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 69cfb4345388..1b689b1303cd 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -42,10 +42,10 @@ struct cma *dma_contiguous_default_area;
>   * Users, who want to set the size of global CMA area for their system
>   * should use cma= kernel parameter.
>   */
> -static const phys_addr_t size_bytes = (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
> -static phys_addr_t size_cmdline = -1;
> -static phys_addr_t base_cmdline;
> -static phys_addr_t limit_cmdline;
> +static const phys_addr_t __ro_after_init size_bytes = 
> (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;

The 0day bot reported an issue with this change with clang:

https://groups.google.com/d/msgid/clang-built-linux/201910140334.nhultlt8%25lkp%40intel.com

kernel/dma/contiguous.c:46:36: error: 'size_cmdline' causes a section type 
conflict with 'size_bytes'
static phys_addr_t __ro_after_init size_cmdline = -1;
   ^
kernel/dma/contiguous.c:45:42: note: declared here
static const phys_addr_t __ro_after_init size_bytes = 
(phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
 ^
kernel/dma/contiguous.c:47:36: error: 'base_cmdline' causes a section type 
conflict with 'size_bytes'
static phys_addr_t __ro_after_init base_cmdline;
   ^
kernel/dma/contiguous.c:45:42: note: declared here
static const phys_addr_t __ro_after_init size_bytes = 
(phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
 ^
kernel/dma/contiguous.c:48:36: error: 'limit_cmdline' causes a section type 
conflict with 'size_bytes'
static phys_addr_t __ro_after_init limit_cmdline;
   ^
kernel/dma/contiguous.c:45:42: note: declared here
static const phys_addr_t __ro_after_init size_bytes = 
(phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
 ^
3 errors generated.

The errors seem kind of cryptic at first but something that is const
should automatically be in the read only section, this part of the
commit seems unnecessary. Removing that part of the change fixes the error.

Cheers,
Nathan

Re: [PATCHv7 22/33] time: Allocate per-timens vvar page

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: parisc-b180_defconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=parisc 

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

All errors (new ones prefixed by >>):

   kernel/time/namespace.o: In function `timens_set_vvar_page.isra.8.part.9':
>> (.text+0x130): undefined reference to `arch_get_vdso_data'

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


.config.gz
Description: application/gzip

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Walter Wu]

On Tue, 2019-10-08 at 14:11 +0200, Dmitry Vyukov wrote:
> On Tue, Oct 8, 2019 at 1:42 PM Qian Cai  wrote:
> > > On Oct 8, 2019, at 7:02 AM, Walter Wu  wrote:
> > > I don't know very well in UBSAN, but I try to build ubsan kernel and
> > > test a negative number in memset and kmalloc_memmove_invalid_size(), it
> > > look like no check.
> >
> > It sounds like more important to figure out why the UBSAN is not working in 
> > this case rather than duplicating functionality elsewhere.
> 
> Detecting out-of-bounds accesses is the direct KASAN responsibility.
> Even more direct than for KUBSAN. We are not even adding
> functionality, it's just a plain bug in KASAN code, it tricks itself
> into thinking that access size is 0.
> Maybe it's already detected by KUBSAN too?

Thanks for your response.
I survey the KUBSAN, it don't check size is negative in
memset/memcpy/memmove, we try to verify our uni testing too, it don't
report the bug in KUBSAN, so it needs to report this bug by KASAN. The
reason is like what you said. so we still send the patch.

[PATCH] media: imx7-mipi-csis: Add a check for devm_regulator_get

[Chuhong Yuan]

devm_regulator_get may return an error but mipi_csis_phy_init misses
a check for it.
This may lead to problems when regulator_set_voltage uses the unchecked
pointer.
This patch adds a check for devm_regulator_get to avoid potential risk.

Signed-off-by: Chuhong Yuan 
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c 
b/drivers/staging/media/imx/imx7-mipi-csis.c
index 73d8354e618c..9a07b54c4ab1 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -350,6 +350,8 @@ static void mipi_csis_sw_reset(struct csi_state *state)
 static int mipi_csis_phy_init(struct csi_state *state)
 {
state->mipi_phy_regulator = devm_regulator_get(state->dev, "phy");
+   if (IS_ERR(state->mipi_phy_regulator))
+   return PTR_ERR(state->mipi_phy_regulator);
 
return regulator_set_voltage(state->mipi_phy_regulator, 100,
 100);
-- 
2.20.1

[PATCH] media: cxusb: detect cxusb_ctrl_msg error in query

[Vito Caputo]

Don't use uninitialized ircode[] in cxusb_rc_query() when
cxusb_ctrl_msg() fails to populate its contents.

syzbot reported:

dvb-usb: bulk message failed: -22 (1/-30591)
=
BUG: KMSAN: uninit-value in ir_lookup_by_scancode 
drivers/media/rc/rc-main.c:494 [inline]
BUG: KMSAN: uninit-value in rc_g_keycode_from_table 
drivers/media/rc/rc-main.c:582 [inline]
BUG: KMSAN: uninit-value in rc_keydown+0x1a6/0x6f0 
drivers/media/rc/rc-main.c:816
CPU: 1 PID: 11436 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: events dvb_usb_read_remote_control
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x191/0x1f0 lib/dump_stack.c:113
 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
 bsearch+0x1dd/0x250 lib/bsearch.c:41
 ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline]
 rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline]
 rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816
 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548
 dvb_usb_read_remote_control+0xf9/0x290 
drivers/media/usb/dvb-usb/dvb-usb-remote.c:261
 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269
 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
 kthread+0x4b5/0x4f0 kernel/kthread.c:256
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline]
 kmsan_internal_chain_origin+0xd2/0x170 mm/kmsan/kmsan.c:314
 __msan_chain_origin+0x6b/0xe0 mm/kmsan/kmsan_instr.c:184
 rc_g_keycode_from_table drivers/media/rc/rc-main.c:583 [inline]
 rc_keydown+0x2c4/0x6f0 drivers/media/rc/rc-main.c:816
 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548
 dvb_usb_read_remote_control+0xf9/0x290 
drivers/media/usb/dvb-usb/dvb-usb-remote.c:261
 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269
 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415
 kthread+0x4b5/0x4f0 kernel/kthread.c:256
 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355

Local variable description: ircode@cxusb_rc_query
Variable was created at:
 cxusb_rc_query+0x4d/0x360 drivers/media/usb/dvb-usb/cxusb.c:543
 dvb_usb_read_remote_control+0xf9/0x290 
drivers/media/usb/dvb-usb/dvb-usb-remote.c:261

Signed-off-by: Vito Caputo 
Reported-by: syzbot 
---
 drivers/media/usb/dvb-usb/cxusb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index f02fa0a67aa4..fac19ec46089 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -521,7 +521,8 @@ static int cxusb_rc_query(struct dvb_usb_device *d)
 {
u8 ircode[4];
 
-   cxusb_ctrl_msg(d, CMD_GET_IR_CODE, NULL, 0, ircode, 4);
+   if (cxusb_ctrl_msg(d, CMD_GET_IR_CODE, NULL, 0, ircode, 4) < 0)
+   return 0;
 
if (ircode[2] || ircode[3])
rc_keydown(d->rc_dev, RC_PROTO_NEC,
-- 
2.11.0

Re: [PATCH] fs/namespace.c: fix use-after-free of mount in mnt_warn_timestamp_expiry()

[Deepa Dinamani]

Thanks for the fix.

Would it be better to move the check and warning to a place where the
access is still safe?

-Deepa

> On Oct 9, 2019, at 12:19 AM, Eric Biggers  wrote:
>
> From: Eric Biggers 


On Wed, Oct 9, 2019 at 12:19 AM Eric Biggers  wrote:
>
> From: Eric Biggers 
>
> After do_add_mount() returns success, the caller doesn't hold a
> reference to the 'struct mount' anymore.  So it's invalid to access it
> in mnt_warn_timestamp_expiry().
>
> Fix it by instead passing the super_block and the mnt_flags.  It's safe
> to access the super_block because it's pinned by fs_context::root.
>
> Reported-by: syzbot+da4f525235510683d...@syzkaller.appspotmail.com
> Fixes: f8b92ba67c5d ("mount: Add mount warning for impending timestamp 
> expiry")
> Signed-off-by: Eric Biggers 
> ---
>  fs/namespace.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index fe0e9e1410fe..7ef8edaaed69 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2466,12 +2466,11 @@ static void set_mount_attributes(struct mount *mnt, 
> unsigned int mnt_flags)
> unlock_mount_hash();
>  }
>
> -static void mnt_warn_timestamp_expiry(struct path *mountpoint, struct 
> vfsmount *mnt)
> +static void mnt_warn_timestamp_expiry(struct path *mountpoint,
> + struct super_block *sb, int mnt_flags)
>  {
> -   struct super_block *sb = mnt->mnt_sb;
> -
> -   if (!__mnt_is_readonly(mnt) &&
> -  (ktime_get_real_seconds() + TIME_UPTIME_SEC_MAX > sb->s_time_max)) 
> {
> +   if (!(mnt_flags & MNT_READONLY) && !sb_rdonly(sb) &&
> +   (ktime_get_real_seconds() + TIME_UPTIME_SEC_MAX > 
> sb->s_time_max)) {
> char *buf = (char *)__get_free_page(GFP_KERNEL);
> char *mntpath = buf ? d_path(mountpoint, buf, PAGE_SIZE) : 
> ERR_PTR(-ENOMEM);
> struct tm tm;
> @@ -2512,7 +2511,7 @@ static int do_reconfigure_mnt(struct path *path, 
> unsigned int mnt_flags)
> set_mount_attributes(mnt, mnt_flags);
> up_write(>s_umount);
>
> -   mnt_warn_timestamp_expiry(path, >mnt);
> +   mnt_warn_timestamp_expiry(path, sb, mnt_flags);
>
> return ret;
>  }
> @@ -2555,7 +2554,7 @@ static int do_remount(struct path *path, int ms_flags, 
> int sb_flags,
> up_write(>s_umount);
> }
>
> -   mnt_warn_timestamp_expiry(path, >mnt);
> +   mnt_warn_timestamp_expiry(path, sb, mnt_flags);
>
> put_fs_context(fc);
> return err;
> @@ -2770,7 +2769,7 @@ static int do_new_mount_fc(struct fs_context *fc, 
> struct path *mountpoint,
> return error;
> }
>
> -   mnt_warn_timestamp_expiry(mountpoint, mnt);
> +   mnt_warn_timestamp_expiry(mountpoint, sb, mnt_flags);
>
> return error;
>  }
> --
> 2.23.0
>

Re: [PATCH v5 3/5] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks

[Zhenzhong Duan]

On 2019/10/13 17:02, Vitaly Kuznetsov wrote:

Zhenzhong Duan  writes:

...snip

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index ef836d6..6e14bd4 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -825,18 +825,31 @@ __visible bool __kvm_vcpu_is_preempted(long cpu)
   */
  void __init kvm_spinlock_init(void)
  {
-   /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
-   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
+   /*
+* Disable PV qspinlocks if host kernel doesn't support
+* KVM_FEATURE_PV_UNHALT feature or there is only 1 vCPU.
+* virt_spin_lock_key is enabled to avoid lock holder
+* preemption issue.
+*/
+   if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT) ||
+   num_possible_cpus() == 1) {
+   pr_info("PV spinlocks disabled\n");
Why don't we need static_branch_disable(_spin_lock_key) here?


Thanks for review.

I have a brief explanation in above comment area.

Boris also raised the same question in v4 and see my detailed explanation

in https://lkml.org/lkml/2019/10/6/39



Also, as you're printing the exact reason for PV spinlocks disablement
in other cases, I'd suggest separating "no host support" and "single
CPU" cases.


Will do after reaching a consensus on your first question.




return;
+   }
  
  	if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {

+   pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME 
hints.\n");
static_branch_disable(_spin_lock_key);
return;
}
  
-	/* Don't use the pvqspinlock code if there is only 1 vCPU. */

-   if (num_possible_cpus() == 1)
+   if (nopvspin) {
+   pr_info("PV spinlocks disabled forced by \"nopvspin\" 
parameter.\n");

Nit: to make it sound better a comma is missing between 'disabled' and
'forced', or

"PV spinlocks forcefully disabled by ..." if you prefer.


Will do.

Zhenzhong

Re: [PATCH RFC v1 2/2] vhost: batching fetches

[Jason Wang]

On 2019/10/13 上午4:36, Michael S. Tsirkin wrote:

On Sat, Oct 12, 2019 at 03:30:52PM +0800, Jason Wang wrote:

On 2019/10/11 下午9:46, Michael S. Tsirkin wrote:

With this patch applied, new and old code perform identically.

Lots of extra optimizations are now possible, e.g.
we can fetch multiple heads with copy_from/to_user now.
We can get rid of maintaining the log array.  Etc etc.

Signed-off-by: Michael S. Tsirkin 
---
   drivers/vhost/test.c  |  2 +-
   drivers/vhost/vhost.c | 50 ---
   drivers/vhost/vhost.h |  4 +++-
   3 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 39a018a7af2d..e3a8e9db22cd 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -128,7 +128,7 @@ static int vhost_test_open(struct inode *inode, struct file 
*f)
dev = >dev;
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
-   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
+   vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
   VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT);
f->private_data = n;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 36661d6cb51f..aa383e847865 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -302,6 +302,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
   {
vq->num = 1;
vq->ndescs = 0;
+   vq->first_desc = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -390,6 +391,7 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
vq->max_descs = dev->iov_limit;
+   vq->batch_descs = dev->iov_limit - UIO_MAXIOV;
vq->descs = kmalloc_array(vq->max_descs,
  sizeof(*vq->descs),
  GFP_KERNEL);
@@ -2366,6 +2368,8 @@ static void pop_split_desc(struct vhost_virtqueue *vq)
--vq->ndescs;
   }
+#define VHOST_DESC_FLAGS (VRING_DESC_F_INDIRECT | VRING_DESC_F_WRITE | \
+ VRING_DESC_F_NEXT)
   static int push_split_desc(struct vhost_virtqueue *vq, struct vring_desc 
*desc, u16 id)
   {
struct vhost_desc *h;
@@ -2375,7 +2379,7 @@ static int push_split_desc(struct vhost_virtqueue *vq, 
struct vring_desc *desc,
h = >descs[vq->ndescs++];
h->addr = vhost64_to_cpu(vq, desc->addr);
h->len = vhost32_to_cpu(vq, desc->len);
-   h->flags = vhost16_to_cpu(vq, desc->flags);
+   h->flags = vhost16_to_cpu(vq, desc->flags) & VHOST_DESC_FLAGS;
h->id = id;
return 0;
@@ -2450,7 +2454,7 @@ static int fetch_indirect_descs(struct vhost_virtqueue 
*vq,
return 0;
   }
-static int fetch_descs(struct vhost_virtqueue *vq)
+static int fetch_buf(struct vhost_virtqueue *vq)
   {
struct vring_desc desc;
unsigned int i, head, found = 0;
@@ -2462,7 +2466,11 @@ static int fetch_descs(struct vhost_virtqueue *vq)
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
-   if (vq->avail_idx == vq->last_avail_idx) {
+   if (unlikely(vq->avail_idx == vq->last_avail_idx)) {
+   /* If we already have work to do, don't bother re-checking. */
+   if (likely(vq->ndescs))
+   return vq->num;
+
if (unlikely(vhost_get_avail_idx(vq, _idx))) {
vq_err(vq, "Failed to access avail idx at %p\n",
>avail->idx);
@@ -2541,6 +2549,24 @@ static int fetch_descs(struct vhost_virtqueue *vq)
return 0;
   }
+static int fetch_descs(struct vhost_virtqueue *vq)
+{
+   int ret = 0;
+
+   if (unlikely(vq->first_desc >= vq->ndescs)) {
+   vq->first_desc = 0;
+   vq->ndescs = 0;
+   }
+
+   if (vq->ndescs)
+   return 0;
+
+   while (!ret && vq->ndescs <= vq->batch_descs)
+   ret = fetch_buf(vq);


It looks to me descriptor chaining might be broken here.

It should work because fetch_buf fetches a whole buf, following
the chain. Seems to work in a small test ... what issues do you see?



Consider the case when fetch_buf return -EINVAL when push_split_desc() 
fail. This means we only have partial descriptors.


Do we need decreasing last_avail_idx and vq->ndescs here? Or having a 
head,tail instead of first_desc?


Thanks





+
+   return vq->ndescs ? 0 : ret;
+}
+
   /* This looks in the virtqueue and for the first available buffer, and 
converts
* it to an iovec for convenient access.  Since descriptors consist of some
* number of output then some number of input descriptors, it's actually two
@@ -2562,6 +2588,8 @@ int vhost_get_vq_desc_batch(struct vhost_virtqueue *vq,
if (ret)
   

Re: [PATCH RFC v1 1/2] vhost: option to fetch descriptors through an independent struct

[Jason Wang]

On 2019/10/13 上午4:27, Michael S. Tsirkin wrote:

On Sat, Oct 12, 2019 at 03:28:49PM +0800, Jason Wang wrote:

On 2019/10/11 下午9:45, Michael S. Tsirkin wrote:

The idea is to support multiple ring formats by converting
to a format-independent array of descriptors.

This costs extra cycles, but we gain in ability
to fetch a batch of descriptors in one go, which
is good for code cache locality.

To simplify benchmarking, I kept the old code
around so one can switch back and forth by
writing into a module parameter.
This will go away in the final submission.

This patch causes a minor performance degradation,
it's been kept as simple as possible for ease of review.
Next patch gets us back the performance by adding batching.

Signed-off-by: Michael S. Tsirkin 
---
   drivers/vhost/test.c  |  17 ++-
   drivers/vhost/vhost.c | 299 +-
   drivers/vhost/vhost.h |  16 +++
   3 files changed, 327 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 056308008288..39a018a7af2d 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -18,6 +18,9 @@
   #include "test.h"
   #include "vhost.h"
+static int newcode = 0;
+module_param(newcode, int, 0644);
+
   /* Max number of bytes transferred before requeueing the job.
* Using this limit prevents one virtqueue from starving others. */
   #define VHOST_TEST_WEIGHT 0x8
@@ -58,10 +61,16 @@ static void handle_vq(struct vhost_test *n)
vhost_disable_notify(>dev, vq);
for (;;) {
-   head = vhost_get_vq_desc(vq, vq->iov,
-ARRAY_SIZE(vq->iov),
-, ,
-NULL, NULL);
+   if (newcode)
+   head = vhost_get_vq_desc_batch(vq, vq->iov,
+  ARRAY_SIZE(vq->iov),
+  , ,
+  NULL, NULL);
+   else
+   head = vhost_get_vq_desc(vq, vq->iov,
+ARRAY_SIZE(vq->iov),
+, ,
+NULL, NULL);
/* On error, stop handling until the next kick. */
if (unlikely(head < 0))
break;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 36ca2cf419bf..36661d6cb51f 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -301,6 +301,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
   struct vhost_virtqueue *vq)
   {
vq->num = 1;
+   vq->ndescs = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -369,6 +370,9 @@ static int vhost_worker(void *data)
   static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
   {
+   kfree(vq->descs);
+   vq->descs = NULL;
+   vq->max_descs = 0;
kfree(vq->indirect);
vq->indirect = NULL;
kfree(vq->log);
@@ -385,6 +389,10 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
+   vq->max_descs = dev->iov_limit;
+   vq->descs = kmalloc_array(vq->max_descs,
+ sizeof(*vq->descs),
+ GFP_KERNEL);


Is iov_limit too much here? It can obviously increase the footprint. I guess
the batching can only be done for descriptor without indirect or next set.
Then we may batch 16 or 64.

Thanks

Yes, next patch only batches up to 64.  But we do need iov_limit because
guest can pass a long chain of scatter/gather.
We already have iovecs in a huge array so this does not look like
a big deal. If we ever teach the code to avoid the huge
iov arrays by handling huge s/g lists piece by piece,
we can make the desc array smaller at the same point.



Another possible issue, if we try to batch descriptor chain when we've 
already batched some descriptors, we may reach the limit then some of 
the descriptors might need re-read.


Or we may need circular index (head, tail) in this case?

Thanks

Re: [PATCH v5 2/5] x86/kvm: Change print code to use pr_*() format

[Zhenzhong Duan]

On 2019/10/13 17:06, Vitaly Kuznetsov wrote:

Zhenzhong Duan  writes:


pr_*() is preferred than printk(KERN_* ...), after change all the print
in arch/x86/kernel/kvm.c will have "kvm_guest: xxx" style.

No functional change.

Signed-off-by: Zhenzhong Duan 
Cc: Paolo Bonzini 
Cc: Radim Krcmar 
Cc: Sean Christopherson 
Cc: Vitaly Kuznetsov 
Cc: Wanpeng Li 
Cc: Jim Mattson 
Cc: Joerg Roedel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
---
  arch/x86/kernel/kvm.c | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 3bc6a266..ef836d6 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -7,6 +7,8 @@
   *   Authors: Anthony Liguori 
   */
  
+#define pr_fmt(fmt) "kvm_guest: " fmt

+
  #include 
  #include 
  #include 
@@ -286,8 +288,8 @@ static void kvm_register_steal_time(void)
return;
  
  	wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));

-   pr_info("kvm-stealtime: cpu %d, msr %llx\n",
-   cpu, (unsigned long long) slow_virt_to_phys(st));
+   pr_info("stealtime: cpu %d, msr %llx\n", cpu,
+   (unsigned long long) slow_virt_to_phys(st));
  }
  
  static DEFINE_PER_CPU_DECRYPTED(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;

@@ -321,8 +323,7 @@ static void kvm_guest_cpu_init(void)
  
  		wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);

__this_cpu_write(apf_reason.enabled, 1);
-   printk(KERN_INFO"KVM setup async PF for cpu %d\n",
-  smp_processor_id());
+   pr_info("setup async PF for cpu %d\n", smp_processor_id());
}
  
  	if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) {

@@ -347,8 +348,7 @@ static void kvm_pv_disable_apf(void)
wrmsrl(MSR_KVM_ASYNC_PF_EN, 0);
__this_cpu_write(apf_reason.enabled, 0);
  
-	printk(KERN_INFO"Unregister pv shared memory for cpu %d\n",

-  smp_processor_id());
+   pr_info("Unregister pv shared memory for cpu %d\n", smp_processor_id());
  }
  
  static void kvm_pv_guest_cpu_reboot(void *unused)

@@ -469,7 +469,8 @@ static void __send_ipi_mask(const struct cpumask *mask, int 
vector)
} else {
ret = kvm_hypercall4(KVM_HC_SEND_IPI, (unsigned 
long)ipi_bitmap,
(unsigned long)(ipi_bitmap >> BITS_PER_LONG), 
min, icr);
-   WARN_ONCE(ret < 0, "KVM: failed to send PV IPI: %ld", 
ret);
+   WARN_ONCE(ret < 0, "kvm_guest: failed to send PV IPI: 
%ld",
+ ret);
min = max = apic_id;
ipi_bitmap = 0;
}
@@ -479,7 +480,8 @@ static void __send_ipi_mask(const struct cpumask *mask, int 
vector)
if (ipi_bitmap) {
ret = kvm_hypercall4(KVM_HC_SEND_IPI, (unsigned long)ipi_bitmap,
(unsigned long)(ipi_bitmap >> BITS_PER_LONG), min, icr);
-   WARN_ONCE(ret < 0, "KVM: failed to send PV IPI: %ld", ret);
+   WARN_ONCE(ret < 0, "kvm_guest: failed to send PV IPI: %ld",
+ ret);
}
  
  	local_irq_restore(flags);

@@ -509,7 +511,7 @@ static void kvm_setup_pv_ipi(void)
  {
apic->send_IPI_mask = kvm_send_ipi_mask;
apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
-   pr_info("KVM setup pv IPIs\n");
+   pr_info("setup pv IPIs\n");

Not your fault but in WARN_ONCE() above we use 'PV' capitalized so I'd
suggest we converge on something: either capitalize them all or make
them all lowercase.


Thanks for catching, will do with 'PV' for all print.

Zhenzhong

Re: [PATCH 1/3] perf tools: Allow to build with -ltcmalloc

[Andi Kleen]

> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index a099a8a89447..8f1ba986d3bf 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -114,6 +114,8 @@ include ../scripts/utilities.mak
>  # Define NO_LIBZSTD if you do not want support of Zstandard based runtime
>  # trace compression in record mode.
>  #
> +# Define TCMALLOC to enable tcmalloc heap profiling.

It might be useful for more than just profiling. I found that gcc runs a
few percent faster with tcmalloc for some workloads. Maybe the same is
true for perf too, as sometimes it does a lot of mallocs.

-Andi

Re: [PATCH v5 1/2] HID: logitech: Add MX Master over Bluetooth

[kbuild test robot]

Hi Mazin,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Mazin-Rezk/HID-logitech-Add-MX-Master-over-Bluetooth/20191014-071534
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/ioport.h:15:0,
from include/linux/device.h:15,
from drivers/hid/hid-logitech-hidpp.c:13:
   drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
>> include/linux/bits.h:8:26: warning: left shift count >= width of type 
>> [-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
>> drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
>> drivers/hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro 
>> 'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^
   drivers/hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device':
>> include/linux/bits.h:8:26: warning: left shift count >= width of type 
>> [-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
>> drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:3496:22: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
 ^
   drivers/hid/hid-logitech-hidpp.c: At top level:
>> include/linux/bits.h:8:26: warning: left shift count >= width of type 
>> [-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
>> drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
   ^
>> drivers/hid/hid-logitech-hidpp.c:3794:5: note: in expansion of macro 
>> 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE'
HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
^~
>> include/linux/bits.h:8:26: warning: left shift count >= width of type 
>> [-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
>> drivers/hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers/hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
   ^
   drivers/hid/hid-logitech-hidpp.c:3797:5: note: in expansion of macro 
'HIDPP_QUIRK_CLASS_BLUETOOTH_LE'
HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
^~
--
   In file included from include/linux/ioport.h:15:0,
from include/linux/device.h:15,
from drivers//hid/hid-logitech-hidpp.c:13:
   drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_send_rap_command_sync':
>> include/linux/bits.h:8:26: warning: left shift count >= width of type 
>> [-Wshift-count-overflow]
#define BIT(nr)   (UL(1) << (nr))
 ^
   drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT'
#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32)
  ^~~
   drivers//hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro 
'HIDPP_QUIRK_MISSING_SHORT_REPORTS'
 if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
 ^
   drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device':
>> include/linux/bits.h:8:26: warning: left shift 

Re: [PATCH] ipmi: Convert ipmi_debug_msg to pr_debug and use %*ph

[kbuild test robot]

Hi Joe,

I love your patch! Perhaps something to improve:

[auto build test WARNING on char-misc/char-misc-testing]
[cannot apply to v5.4-rc2 next-20191011]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/ipmi-Convert-ipmi_debug_msg-to-pr_debug-and-use-ph/20191014-051352
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

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

All warnings (new ones prefixed by >>):

   drivers/char/ipmi/ipmi_msghandler.c: In function 'i_ipmi_request':
>> drivers/char/ipmi/ipmi_msghandler.c:14:21: warning: field width specifier 
>> '*' expects argument of type 'int', but argument 5 has type 'unsigned char 
>> *' [-Wformat=]
#define pr_fmt(fmt) "%s" fmt, "IPMI message handler: "
^
   include/linux/dynamic_debug.h:125:15: note: in expansion of macro 'pr_fmt'
  func(, ##__VA_ARGS__);  \
  ^~~
   include/linux/dynamic_debug.h:143:2: note: in expansion of macro 
'__dynamic_func_call'
 __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
 ^~~
   include/linux/dynamic_debug.h:153:2: note: in expansion of macro 
'_dynamic_func_call'
 _dynamic_func_call(fmt, __dynamic_pr_debug,  \
 ^~
   include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
>> drivers/char/ipmi/ipmi_msghandler.c:2251:3: note: in expansion of macro 
>> 'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:2251:18: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~^~
>> drivers/char/ipmi/ipmi_msghandler.c:14:21: warning: format '%p' expects 
>> argument of type 'void *', but argument 6 has type 'int' [-Wformat=]
#define pr_fmt(fmt) "%s" fmt, "IPMI message handler: "
^
   include/linux/dynamic_debug.h:125:15: note: in expansion of macro 'pr_fmt'
  func(, ##__VA_ARGS__);  \
  ^~~
   include/linux/dynamic_debug.h:143:2: note: in expansion of macro 
'__dynamic_func_call'
 __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
 ^~~
   include/linux/dynamic_debug.h:153:2: note: in expansion of macro 
'_dynamic_func_call'
 _dynamic_func_call(fmt, __dynamic_pr_debug,  \
 ^~
   include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
>> drivers/char/ipmi/ipmi_msghandler.c:2251:3: note: in expansion of macro 
>> 'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:2251:19: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~~^
%*d
   drivers/char/ipmi/ipmi_msghandler.c: In function 'handle_ipmb_get_msg_cmd':
>> drivers/char/ipmi/ipmi_msghandler.c:14:21: warning: field width specifier 
>> '*' expects argument of type 'int', but argument 5 has type 'unsigned char 
>> *' [-Wformat=]
#define pr_fmt(fmt) "%s" fmt, "IPMI message handler: "
^
   include/linux/dynamic_debug.h:125:15: note: in expansion of macro 'pr_fmt'
  func(, ##__VA_ARGS__);  \
  ^~~
   include/linux/dynamic_debug.h:143:2: note: in expansion of macro 
'__dynamic_func_call'
 __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
 ^~~
   include/linux/dynamic_debug.h:153:2: note: in expansion of macro 
'_dynamic_func_call'
 _dynamic_func_call(fmt, __dynamic_pr_debug,  \
 ^~
   include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:3715:3: note: in expansion of macro 
'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:3715:18: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~^~
>> drivers/char/ipmi/ipmi_msghandler.c:14:21: warning: format '%p' expects 
>> argument of type 'void *', but argument 6 has type 'int' [-Wformat=]
#define pr_fmt(fmt) "%s" fmt, "IPMI message handler: "
^
   include/linux/dynamic_debug.h:125:15: note: in expansion of macro 'pr_fmt'
  func(, ##__VA_ARGS__);  \
 

[PATCH v2 2/4] perf/core: Provide a kernel-internal interface to pause perf_event

[Like Xu]

Exporting perf_event_pause() as an external accessor for kernel users (such
as KVM) who may do both disable perf_event and read count with just one
time to hold perf_event_ctx_lock. Also the value could be reset optionally.

Suggested-by: Peter Zijlstra 
Signed-off-by: Like Xu 
---
 include/linux/perf_event.h |  5 +
 kernel/events/core.c   | 16 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index d601df36e671..e9768bfc76f6 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1337,6 +1337,7 @@ extern void perf_event_disable_inatomic(struct perf_event 
*event);
 extern void perf_event_task_tick(void);
 extern int perf_event_account_interrupt(struct perf_event *event);
 extern int perf_event_period(struct perf_event *event, u64 value);
+extern u64 perf_event_pause(struct perf_event *event, bool reset);
 #else /* !CONFIG_PERF_EVENTS: */
 static inline void *
 perf_aux_output_begin(struct perf_output_handle *handle,
@@ -1420,6 +1421,10 @@ static inline int perf_event_period(struct perf_event 
*event, u64 value)
 {
return -EINVAL;
 }
+static inline u64 perf_event_pause(struct perf_event *event, bool reset)
+{
+   return 0;
+}
 #endif
 
 #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index e1b83d2731da..e29038984cf4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5029,6 +5029,22 @@ static void _perf_event_reset(struct perf_event *event)
perf_event_update_userpage(event);
 }
 
+u64 perf_event_pause(struct perf_event *event, bool reset)
+{
+   struct perf_event_context *ctx;
+   u64 count, enabled, running;
+
+   ctx = perf_event_ctx_lock(event);
+   _perf_event_disable(event);
+   count = __perf_event_read_value(event, , );
+   if (reset)
+   local64_set(>count, 0);
+   perf_event_ctx_unlock(event, ctx);
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(perf_event_pause);
+
 /*
  * Holding the top-level event's child_mutex means that any
  * descendant process that has inherited this event will block
-- 
2.21.0

[PATCH v2 3/4] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter

[Like Xu]

The perf_event_create_kernel_counter() in the pmc_reprogram_counter() is
a heavyweight and high-frequency operation, especially when host disables
the watchdog (maximum 2100 ns) which leads to an unacceptable latency
of the guest NMI handler. It limits the use of vPMUs in the guest.

When a vPMC is fully enabled, the legacy reprogram_*_counter() would stop
and release its existing perf_event (if any) every time EVEN in most cases
almost the same requested perf_event will be created and configured again.

For each vPMC, if the reuqested config ('u64 eventsel' for gp and 'u8 ctrl'
for fixed) is the same as its last programed config AND a new sample period
based on pmc->counter is accepted by host perf interface, the current event
could be reused safely as a new created one does. Otherwise, do release the
undesirable perf_event and reprogram a new one as usual.

It's light-weight to call pmc_pause_counter (disable, read and reset event)
and pmc_resume_counter (recalibrate period and re-enable event) as guest
expects instead of release-and-create again on any condition. Compared to
use the filterable event->attr or hw.config, a new 'u64 programed_config'
field is added to save the last original programed config for each vPMC.

Based on this implementation, the number of calls to pmc_reprogram_counter
is reduced by ~94% for a gp sampling event and ~99.9% for a fixed event.
In the usage of multiplexing perf sampling mode, the average latency of the
guest NMI handler is reduced from 99450 ns to 56195 ns (1.76x speed up).
If host disables watchdog, the minimum latecy of guest NMI handler could be
speed up at 2994x (from 18134692 to 6057 ns) and at 685x in the average.

Suggested-by: Kan Liang 
Signed-off-by: Like Xu 
---
 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/pmu.c  | 45 +++--
 arch/x86/kvm/pmu.h  | 12 +++--
 arch/x86/kvm/pmu_amd.c  |  1 +
 arch/x86/kvm/vmx/pmu_intel.c|  2 ++
 5 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 50eb430b0ad8..1aae4953 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -451,6 +451,8 @@ struct kvm_pmc {
u64 eventsel;
struct perf_event *perf_event;
struct kvm_vcpu *vcpu;
+   /* the exact requested config to create perf_event */
+   u64 programed_config;
 };
 
 struct kvm_pmu {
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 46875bbd0419..09d1a03c057c 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -140,6 +140,35 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 
type,
clear_bit(pmc->idx, (unsigned long*)_to_pmu(pmc)->reprogram_pmi);
 }
 
+static void pmc_pause_counter(struct kvm_pmc *pmc)
+{
+   u64 counter = pmc->counter;
+
+   if (!pmc->perf_event)
+   return;
+
+   /* update counter, reset event value to avoid redundant accumulation */
+   counter += perf_event_pause(pmc->perf_event, true);
+   pmc->counter = counter & pmc_bitmask(pmc);
+}
+
+static bool pmc_resume_counter(struct kvm_pmc *pmc)
+{
+   if (!pmc->perf_event)
+   return false;
+
+   /* recalibrate sample period and check if it's accepted by perf core */
+   if (perf_event_period(pmc->perf_event,
+   (-pmc->counter) & pmc_bitmask(pmc)))
+   return false;
+
+   /* reuse perf_event to serve as pmc_reprogram_counter() does*/
+   perf_event_enable(pmc->perf_event);
+
+   clear_bit(pmc->idx, (unsigned long *)_to_pmu(pmc)->reprogram_pmi);
+   return true;
+}
+
 void reprogram_gp_counter(struct kvm_pmc *pmc, u64 eventsel)
 {
unsigned config, type = PERF_TYPE_RAW;
@@ -154,7 +183,7 @@ void reprogram_gp_counter(struct kvm_pmc *pmc, u64 eventsel)
 
pmc->eventsel = eventsel;
 
-   pmc_stop_counter(pmc);
+   pmc_pause_counter(pmc);
 
if (!(eventsel & ARCH_PERFMON_EVENTSEL_ENABLE) || !pmc_is_enabled(pmc))
return;
@@ -193,6 +222,12 @@ void reprogram_gp_counter(struct kvm_pmc *pmc, u64 
eventsel)
if (type == PERF_TYPE_RAW)
config = eventsel & X86_RAW_EVENT_MASK;
 
+   if (pmc->programed_config == eventsel && pmc_resume_counter(pmc))
+   return;
+
+   pmc_release_perf_event(pmc);
+
+   pmc->programed_config = eventsel;
pmc_reprogram_counter(pmc, type, config,
  !(eventsel & ARCH_PERFMON_EVENTSEL_USR),
  !(eventsel & ARCH_PERFMON_EVENTSEL_OS),
@@ -209,7 +244,7 @@ void reprogram_fixed_counter(struct kvm_pmc *pmc, u8 ctrl, 
int idx)
struct kvm_pmu_event_filter *filter;
struct kvm *kvm = pmc->vcpu->kvm;
 
-   pmc_stop_counter(pmc);
+   pmc_pause_counter(pmc);
 
if (!en_field || !pmc_is_enabled(pmc))
return;
@@ -224,6 +259,12 @@ void 

[PATCH v2 1/4] perf/core: Provide a kernel-internal interface to recalibrate event period

[Like Xu]

Currently, perf_event_period() is used by user tools via ioctl. Based on
naming convention, exporting perf_event_period() for kernel users (such
as KVM) who may recalibrate the event period for their assigned counter
according to their requirements.

The perf_event_period() is an external accessor, just like the
perf_event_{en,dis}able() and should thus use perf_event_ctx_lock().

Suggested-by: Kan Liang 
Signed-off-by: Like Xu 
---
 include/linux/perf_event.h |  5 +
 kernel/events/core.c   | 28 +---
 2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 61448c19a132..d601df36e671 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1336,6 +1336,7 @@ extern void perf_event_disable_local(struct perf_event 
*event);
 extern void perf_event_disable_inatomic(struct perf_event *event);
 extern void perf_event_task_tick(void);
 extern int perf_event_account_interrupt(struct perf_event *event);
+extern int perf_event_period(struct perf_event *event, u64 value);
 #else /* !CONFIG_PERF_EVENTS: */
 static inline void *
 perf_aux_output_begin(struct perf_output_handle *handle,
@@ -1415,6 +1416,10 @@ static inline void perf_event_disable(struct perf_event 
*event)  { }
 static inline int __perf_event_disable(void *info) { 
return -1; }
 static inline void perf_event_task_tick(void)  { }
 static inline int perf_event_release_kernel(struct perf_event *event)  { 
return 0; }
+static inline int perf_event_period(struct perf_event *event, u64 value)
+{
+   return -EINVAL;
+}
 #endif
 
 #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_CPU_SUP_INTEL)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9ec0b0bfddbd..e1b83d2731da 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5106,16 +5106,11 @@ static int perf_event_check_period(struct perf_event 
*event, u64 value)
return event->pmu->check_period(event, value);
 }
 
-static int perf_event_period(struct perf_event *event, u64 __user *arg)
+static int _perf_event_period(struct perf_event *event, u64 value)
 {
-   u64 value;
-
if (!is_sampling_event(event))
return -EINVAL;
 
-   if (copy_from_user(, arg, sizeof(value)))
-   return -EFAULT;
-
if (!value)
return -EINVAL;
 
@@ -5133,6 +5128,19 @@ static int perf_event_period(struct perf_event *event, 
u64 __user *arg)
return 0;
 }
 
+int perf_event_period(struct perf_event *event, u64 value)
+{
+   struct perf_event_context *ctx;
+   int ret;
+
+   ctx = perf_event_ctx_lock(event);
+   ret = _perf_event_period(event, value);
+   perf_event_ctx_unlock(event, ctx);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(perf_event_period);
+
 static const struct file_operations perf_fops;
 
 static inline int perf_fget_light(int fd, struct fd *p)
@@ -5176,8 +5184,14 @@ static long _perf_ioctl(struct perf_event *event, 
unsigned int cmd, unsigned lon
return _perf_event_refresh(event, arg);
 
case PERF_EVENT_IOC_PERIOD:
-   return perf_event_period(event, (u64 __user *)arg);
+   {
+   u64 value;
+
+   if (copy_from_user(, (u64 __user *)arg, sizeof(value)))
+   return -EFAULT;
 
+   return _perf_event_period(event, value);
+   }
case PERF_EVENT_IOC_ID:
{
u64 id = primary_event_id(event);
-- 
2.21.0

[PATCH v2 0/4] KVM: x86/vPMU: Efficiency optimization by reusing last created perf_event

[Like Xu]

Performance Monitoring Unit is designed to monitor micro architectural
events which helps in analyzing how applications or operating systems
are performing on the processors. In KVM/X86, version 2 Architectural
PMU on Intel and AMD hosts have been enabled.

This patch series is going to improve vPMU Efficiency for guest perf users
which is mainly measured by guest NMI handler latency for basic perf usages
[1][2][3][4] with hardware PMU. It's not a passthrough solution but based
on the legacy vPMU implementation (since 2011) with backport-friendliness.

The general idea (defined in patch 2/3) is to reuse last created perf_event
for the same vPMC when the new requested config is the exactly same as the
last programed config (used by pmc_reprogram_counter()) AND the new event
period is appropriate and accepted (via perf_event_period() in patch 1/3).
Before reusing the perf_event, it will be disabled until it's suitable for
reuse and a hardware counter will be reassigned again to serve vPMC.

If the disabled perf_event is no longer reused, we do a lazy release
mechanism (defined in patch 3/3) which in a short is to release the
disabled perf_events on the first call of vcpu_enter_guest since the
vcpu gets next scheduled in if its MSRs is not accessed in the last
sched time slice. The bitmap pmu->lazy_release_ctrl is added to track.
The kvm_pmu_cleanup() is called at the first time to run vcpu_enter_guest
after the vcpu shced_in and the overhead for check is very limited.

With this optimization, the average latency of the guest NMI handler is
reduced from 99450 ns to 56195 ns (1.76x speed up on CLX-AP with v5.3).
If host disables the watchdog (echo 0 > /proc/sys/kernel/watchdog), the
minimum latency of guest NMI handler could be speed up at 2994x and in
the average at 685x. The run time of workload with perf attached inside
the guest could be reduced significantly with this optimization.

Please check each commit for more details and share your comments with us.

Thanks,
Like Xu

---
[1] multiplexing sampling usage: time perf record  -e \
`perf list | grep Hardware | grep event |\
awk '{print $1}' | head -n 10 |tr '\n' ',' | sed 's/,$//' ` ./ftest
[2] one gp counter sampling usage: perf record -e branch-misses ./ftest
[3] one fixed counter sampling usage: perf record -e instructions ./ftest
[4] event count usage: perf stat -e branch-misses ./ftest

---
Changes in v2:
- use perf_event_pause() to disable, read, reset by only one lock;
- use __perf_event_read_value() after _perf_event_disable();
- replace bitfields with 'u8 event_count; bool need_cleanup;';
- refine comments and commit messages;
- fix two issues reported by kbuild test robot for ARCH=[nds32|sh]

v1:
https://lore.kernel.org/kvm/20190930072257.43352-1-like...@linux.intel.com/

Like Xu (4):
  perf/core: Provide a kernel-internal interface to recalibrate event
period
  perf/core: Provide a kernel-internal interface to pause perf_event
  KVM: x86/vPMU: Reuse perf_event to avoid unnecessary
pmc_reprogram_counter
  KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC

 arch/x86/include/asm/kvm_host.h | 17 +++
 arch/x86/kvm/pmu.c  | 88 -
 arch/x86/kvm/pmu.h  | 15 +-
 arch/x86/kvm/pmu_amd.c  | 14 ++
 arch/x86/kvm/vmx/pmu_intel.c| 27 ++
 arch/x86/kvm/x86.c  | 12 +
 include/linux/perf_event.h  | 10 
 kernel/events/core.c| 44 ++---
 8 files changed, 216 insertions(+), 11 deletions(-)

-- 
2.21.0

[PATCH v2 4/4] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC

[Like Xu]

Currently, a host perf_event is created for a vPMC functionality emulation.
It’s unpredictable to determine if a disabled perf_event will be reused.
If they are disabled and are not reused for a considerable period of time,
those obsolete perf_events would increase host context switch overhead that
could have been avoided.

If the guest doesn't access (set_msr/get_msr/rdpmc) any of the vPMC's MSRs
during an entire vcpu sched time slice, and its independent enable bit of
the vPMC isn't set, we can predict that the guest has finished the use of
this vPMC, and then it's time to release non-reused perf_events in the
first call of vcpu_enter_guest() after the vcpu gets next scheduled in.

This lazy mechanism delays the event release time to the beginning of the
next scheduled time slice if vPMC's MSRs aren't accessed during this time
slice. If guest comes back to use this vPMC in next time slice, a new perf
event would be re-created via perf_event_create_kernel_counter() as usual.

Suggested-by: Wei W Wang 
Signed-off-by: Like Xu 
---
 arch/x86/include/asm/kvm_host.h | 15 
 arch/x86/kvm/pmu.c  | 43 +
 arch/x86/kvm/pmu.h  |  3 +++
 arch/x86/kvm/pmu_amd.c  | 13 ++
 arch/x86/kvm/vmx/pmu_intel.c| 25 +++
 arch/x86/kvm/x86.c  | 12 +
 6 files changed, 111 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1aae4953..45f9cdae150b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -472,6 +472,21 @@ struct kvm_pmu {
struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED];
struct irq_work irq_work;
u64 reprogram_pmi;
+
+   /* for vPMC being set, do not released its perf_event (if any) */
+   u64 lazy_release_ctrl;
+
+   /*
+* The gate to release perf_events not marked in
+* lazy_release_ctrl only once in a vcpu time slice.
+*/
+   bool need_cleanup;
+
+   /*
+* The total number of programmed perf_events and it helps to avoid
+* redundant check before cleanup if guest don't use vPMU at all.
+*/
+   u8 event_count;
 };
 
 struct kvm_pmu_ops;
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 09d1a03c057c..7ab262f009f6 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -137,6 +137,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 
type,
}
 
pmc->perf_event = event;
+   pmc_to_pmu(pmc)->event_count++;
clear_bit(pmc->idx, (unsigned long*)_to_pmu(pmc)->reprogram_pmi);
 }
 
@@ -368,6 +369,7 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64 
*data)
if (!pmc)
return 1;
 
+   __set_bit(pmc->idx, (unsigned long *)>lazy_release_ctrl);
*data = pmc_read_counter(pmc) & mask;
return 0;
 }
@@ -385,11 +387,13 @@ bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
 
 int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)
 {
+   kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr);
return kvm_x86_ops->pmu_ops->get_msr(vcpu, msr, data);
 }
 
 int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
 {
+   kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr_info->index);
return kvm_x86_ops->pmu_ops->set_msr(vcpu, msr_info);
 }
 
@@ -417,9 +421,48 @@ void kvm_pmu_init(struct kvm_vcpu *vcpu)
memset(pmu, 0, sizeof(*pmu));
kvm_x86_ops->pmu_ops->init(vcpu);
init_irq_work(>irq_work, kvm_pmi_trigger_fn);
+   pmu->lazy_release_ctrl = 0;
+   pmu->event_count = 0;
+   pmu->need_cleanup = false;
kvm_pmu_refresh(vcpu);
 }
 
+static inline bool pmc_speculative_in_use(struct kvm_pmc *pmc)
+{
+   struct kvm_pmu *pmu = pmc_to_pmu(pmc);
+
+   if (pmc_is_fixed(pmc))
+   return fixed_ctrl_field(pmu->fixed_ctr_ctrl,
+   pmc->idx - INTEL_PMC_IDX_FIXED) & 0x3;
+
+   return pmc->eventsel & ARCH_PERFMON_EVENTSEL_ENABLE;
+}
+
+void kvm_pmu_cleanup(struct kvm_vcpu *vcpu)
+{
+   struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
+   struct kvm_pmc *pmc = NULL;
+   u64 bitmask = ~pmu->lazy_release_ctrl;
+   int i;
+
+   if (!unlikely(pmu->need_cleanup))
+   return;
+
+   /* do cleanup before the first time of running vcpu after sched_in */
+   pmu->need_cleanup = false;
+
+   /* release events for unmarked vPMCs in the last sched time slice */
+   for_each_set_bit(i, (unsigned long *), X86_PMC_IDX_MAX) {
+   pmc = kvm_x86_ops->pmu_ops->pmc_idx_to_pmc(pmu, i);
+
+   if (pmc && pmc->perf_event && !pmc_speculative_in_use(pmc))
+   pmc_stop_counter(pmc);
+   }
+
+   /* reset vPMC lazy-release bitmap for this sched time slice */
+   pmu->lazy_release_ctrl = 0;
+}
+
 void kvm_pmu_destroy(struct kvm_vcpu *vcpu)
 {

RE: [EXT] Re: [PATCH v3] thermal: qoriq: add thermal monitor unit version 2 support

[Andy Tang]

Thanks Daniel for your help..

BR,
Andy

> -Original Message-
> From: Daniel Lezcano 
> Sent: 2019年10月11日 22:32
> To: Andy Tang ; edubez...@gmail.com;
> rui.zh...@intel.com; Anson Huang 
> Cc: Leo Li ; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [EXT] Re: [PATCH v3] thermal: qoriq: add thermal monitor unit
> version 2 support
> 
> Caution: EXT Email
> 
> On 11/10/2019 04:05, Yuantian Tang wrote:
> > Thermal Monitor Unit v2 is introduced on new Layscape SoC.
> > Compared to v1, TMUv2 has a little different register layout and
> > digital output is fairly linear.
> >
> > Signed-off-by: Yuantian Tang 
> > Reviewed-by: Anson Huang 
> 
> Hi Yuantian,
> 
> I've applied the patch to the 'testing' branch [1]. If everything is fine, it 
> should
> be applied to thermal/next branch by Eduardo/Rui.
> 
> Thanks
> 
>   -- Daniel
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fthermal%2Flinux.git%2Fl
> og%2F%3Fh%3Dtestingdata=02%7C01%7Candy.tang%40nxp.com%7C
> 15745a8a41334cfdee1108d74e57d25b%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C0%7C637064011402158027sdata=4Pm7DCVf9pSzUL%
> 2BkQg05TMrwF3WiohIduOei2Siq3BM%3Dreserved=0
> 
> 
> --
> 
>  linaro.org%2Fdata=02%7C01%7Candy.tang%40nxp.com%7C15745a8a
> 41334cfdee1108d74e57d25b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637064011402168025sdata=5PVEzeRIm%2FwHppVoUOvjK9
> KI977FBJrXOjOHMSVmIbQ%3Dreserved=0> Linaro.org │ Open source
> software for ARM SoCs
> 
> Follow Linaro:
>  facebook.com%2Fpages%2FLinarodata=02%7C01%7Candy.tang%40nx
> p.com%7C15745a8a41334cfdee1108d74e57d25b%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C637064011402168025sdata=x%2B29Kv
> hFHCnFz%2BHgUXl5GkqUJSG6Kr8bcXaxZ%2BmRUns%3Dreserved=0>
> Facebook |
>  r.com%2F%23!%2Flinaroorgdata=02%7C01%7Candy.tang%40nxp.com
> %7C15745a8a41334cfdee1108d74e57d25b%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C0%7C637064011402168025sdata=pNceHPcgd3r7nl
> dAGyoKlX0B5QsZqATn0iHZDMKJ%2FvY%3Dreserved=0> Twitter |
>  linaro.org%2Flinaro-blog%2Fdata=02%7C01%7Candy.tang%40nxp.co
> m%7C15745a8a41334cfdee1108d74e57d25b%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637064011402168025sdata=AVdkzJ7tEAeH
> 1olG6VKfVv9fngCwVxn5S76LrSUDwrg%3Dreserved=0> Blog

Re: [PATCH] net: core: datagram: tidy up copy functions a bit

[Eric Dumazet]

On 10/13/19 3:41 PM, Vito Caputo wrote:

> I read it, thank you for your responses.
> 
> Do you have any guidance to offer someone wanting to contribute with 1-2
> hours available per day?  I don't want to cause a nuisance, but would
> like to help where I can.  My flawed assumption was that small, isolated
> hygienic contributions without functionally changing anything would be
> appropriate.

I suggest you look at the syzkaller huge queue of bugs.

You will learn more interesting stuff, and you will help the community
in a more quantifiable way.

https://syzkaller.appspot.com/upstream

[Patch v3 4/7] sched/fair: Enable CFS periodic tick to update thermal pressure

[Thara Gopinath]

Introduce support in CFS periodic tick to trigger the process of
computing average thermal pressure for a cpu.

Signed-off-by: Thara Gopinath 
---
 kernel/sched/fair.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 83ab35e..fe7c165 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -21,6 +21,7 @@
  *  Copyright (C) 2007 Red Hat, Inc., Peter Zijlstra
  */
 #include "sched.h"
+#include "thermal.h"
 
 #include 
 
@@ -7566,6 +7567,8 @@ static void update_blocked_averages(int cpu)
done = false;
 
update_blocked_load_status(rq, !done);
+
+   update_periodic_maxcap(rq);
rq_unlock_irqrestore(rq, );
 }
 
@@ -9925,6 +9928,8 @@ static void task_tick_fair(struct rq *rq, struct 
task_struct *curr, int queued)
 
update_misfit_status(curr, rq);
update_overutilized_status(task_rq(curr));
+
+   update_periodic_maxcap(rq);
 }
 
 /*
-- 
2.1.4

[PATCH V2] clk: imx7ulp: Correct system clock source option #7

[Anson Huang]

In the latest reference manual Rev.0,06/2019, the SCS's option #7
is no longer from upll, it is reserved, update clock driver accordingly.

Fixes: b1260067ac3d ("clk: imx: add imx7ulp clk driver")
Signed-off-by: Anson Huang 
Reviewed-by: Fabio Estevam 
---
Changes since V1:
- no code change, just improve commit log using SCS instead of SCG1.
---
 drivers/clk/imx/clk-imx7ulp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 2022d9b..b2c5866 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -24,7 +24,7 @@ static const char * const spll_pfd_sels[] = { 
"spll_pfd0", "spll_pfd1", "spll_pf
 static const char * const spll_sels[]  = { "spll", "spll_pfd_sel", };
 static const char * const apll_pfd_sels[]  = { "apll_pfd0", "apll_pfd1", 
"apll_pfd2", "apll_pfd3", };
 static const char * const apll_sels[]  = { "apll", "apll_pfd_sel", };
-static const char * const scs_sels[]   = { "dummy", "sosc", "sirc", 
"firc", "dummy", "apll_sel", "spll_sel", "upll", };
+static const char * const scs_sels[]   = { "dummy", "sosc", "sirc", 
"firc", "dummy", "apll_sel", "spll_sel", "dummy", };
 static const char * const ddr_sels[]   = { "apll_pfd_sel", "upll", };
 static const char * const nic_sels[]   = { "firc", "ddr_clk", };
 static const char * const periph_plat_sels[]   = { "dummy", "nic1_bus_clk", 
"nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
-- 
2.7.4

[Patch v3 2/7] sched: Add infrastructure to store and update instantaneous thermal pressure

[Thara Gopinath]

Add thermal.c and thermal.h files that provides interface
APIs to initialize, update/average, track, accumulate and decay
thermal pressure per cpu basis. A per cpu structure max_capacity_info is
introduced to keep track of instantaneous per cpu thermal pressure.
Thermal pressure is the delta between max_capacity and cap_capacity.
API update_periodic_maxcap is called for periodic accumulate and decay
of the thermal pressure. It is to to be called from a periodic tick
function. This API calculates the delta between max_capacity and
cap_capacity and passes on the delta to update_thermal_avg to do the
necessary accumulate, decay and average. API update_maxcap_capacity is for
the system to update the thermal pressure by updating cap_capacity.
Considering, update_periodic_maxcap reads cap_capacity and
update_maxcap_capacity writes into cap_capacity, one can argue for
some sort of locking mechanism to avoid a stale value.
But considering update_periodic_maxcap can be called from a system
critical path like scheduler tick function, a locking mechanism is not
ideal. This means that it is possible the value used to
calculate average thermal pressure for a cpu can be stale for upto 1
tick period.

Signed-off-by: Thara Gopinath 
---
 include/linux/sched.h  | 14 +++
 kernel/sched/Makefile  |  2 +-
 kernel/sched/thermal.c | 66 ++
 kernel/sched/thermal.h | 13 ++
 4 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 kernel/sched/thermal.c
 create mode 100644 kernel/sched/thermal.h

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 2c2e56b..875ce2b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1983,6 +1983,20 @@ static inline void rseq_syscall(struct pt_regs *regs)
 
 #endif
 
+#ifdef CONFIG_SMP
+void update_maxcap_capacity(int cpu, u64 capacity);
+
+void populate_max_capacity_info(void);
+#else
+static inline void update_maxcap_capacity(int cpu, u64 capacity)
+{
+}
+
+static inline void populate_max_capacity_info(void)
+{
+}
+#endif
+
 const struct sched_avg *sched_trace_cfs_rq_avg(struct cfs_rq *cfs_rq);
 char *sched_trace_cfs_rq_path(struct cfs_rq *cfs_rq, char *str, int len);
 int sched_trace_cfs_rq_cpu(struct cfs_rq *cfs_rq);
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 21fb5a5..4d3b820 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -20,7 +20,7 @@ obj-y += core.o loadavg.o clock.o cputime.o
 obj-y += idle.o fair.o rt.o deadline.o
 obj-y += wait.o wait_bit.o swait.o completion.o
 
-obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o pelt.o
+obj-$(CONFIG_SMP) += cpupri.o cpudeadline.o topology.o stop_task.o pelt.o 
thermal.o
 obj-$(CONFIG_SCHED_AUTOGROUP) += autogroup.o
 obj-$(CONFIG_SCHEDSTATS) += stats.o
 obj-$(CONFIG_SCHED_DEBUG) += debug.o
diff --git a/kernel/sched/thermal.c b/kernel/sched/thermal.c
new file mode 100644
index 000..5f0b2d4
--- /dev/null
+++ b/kernel/sched/thermal.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sceduler Thermal Interactions
+ *
+ *  Copyright (C) 2018 Linaro, Inc., Thara Gopinath 
+ */
+
+#include 
+#include "sched.h"
+#include "pelt.h"
+#include "thermal.h"
+
+struct max_capacity_info {
+   unsigned long max_capacity;
+   unsigned long cap_capacity;
+};
+
+static DEFINE_PER_CPU(struct max_capacity_info, max_cap);
+
+void update_maxcap_capacity(int cpu, u64 capacity)
+{
+   struct max_capacity_info *__max_cap;
+   unsigned long __capacity;
+
+   __max_cap = (_cpu(max_cap, cpu));
+   if (!__max_cap) {
+   pr_err("no max_capacity_info structure for cpu %d\n", cpu);
+   return;
+   }
+
+   /* Normalize the capacity */
+   __capacity = (capacity * arch_scale_cpu_capacity(cpu)) >>
+   SCHED_CAPACITY_SHIFT;
+   pr_debug("updating cpu%d capped capacity from %lu to %lu\n", cpu, 
__max_cap->cap_capacity, __capacity);
+
+   __max_cap->cap_capacity = __capacity;
+}
+
+void populate_max_capacity_info(void)
+{
+   struct max_capacity_info *__max_cap;
+   u64 capacity;
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   __max_cap = (_cpu(max_cap, cpu));
+   if (!__max_cap)
+   continue;
+   capacity = arch_scale_cpu_capacity(cpu);
+   __max_cap->max_capacity = capacity;
+   __max_cap->cap_capacity = capacity;
+   pr_debug("cpu %d max capacity set to %ld\n", cpu, 
__max_cap->max_capacity);
+   }
+}
+
+void update_periodic_maxcap(struct rq *rq)
+{
+   struct max_capacity_info *__max_cap = (_cpu(max_cap, cpu_of(rq)));
+   unsigned long delta;
+
+   if (!__max_cap)
+   return;
+
+   delta = __max_cap->max_capacity - __max_cap->cap_capacity;
+   update_thermal_avg(rq_clock_task(rq), rq, delta);
+}
diff --git a/kernel/sched/thermal.h b/kernel/sched/thermal.h

[Patch v3 0/7] Introduce Thermal Pressure

[Thara Gopinath]

Thermal governors can respond to an overheat event of a cpu by
capping the cpu's maximum possible frequency. This in turn
means that the maximum available compute capacity of the
cpu is restricted. But today in the kernel, task scheduler is 
not notified of capping of maximum frequency of a cpu.
In other words, scheduler is unware of maximum capacity
restrictions placed on a cpu due to thermal activity.
This patch series attempts to address this issue.
The benefits identified are better task placement among available
cpus in event of overheating which in turn leads to better
performance numbers.

The reduction in the maximum possible capacity of a cpu due to a 
thermal event can be considered as thermal pressure. Instantaneous
thermal pressure is hard to record and can sometime be erroneous
as there can be mismatch between the actual capping of capacity
and scheduler recording it. Thus solution is to have a weighted
average per cpu value for thermal pressure over time.
The weight reflects the amount of time the cpu has spent at a
capped maximum frequency. Since thermal pressure is recorded as
an average, it must be decayed periodically. Exisiting algorithm
in the kernel scheduler pelt framework is re-used to calculate
the weighted average. This patch series also defines a sysctl
inerface to allow for a configurable decay period.

Regarding testing, basic build, boot and sanity testing have been
performed on db845c platform with debian file system.
Further, dhrystone and hackbench tests have been
run with the thermal pressure algorithm. During testing, due to
constraints of step wise governor in dealing with big little systems,
trip point 0 temperature was made assymetric between cpus in little
cluster and big cluster; the idea being that
big core will heat up and cpu cooling device will throttle the
frequency of the big cores faster, there by limiting the maximum available
capacity and the scheduler will spread out tasks to little cores as well.

Test Results

Hackbench: 1 group , 3 loops, 10 runs   
   Result SD 
   (Secs) (% of mean) 
 No Thermal Pressure14.03   2.69%   
 Thermal Pressure PELT Algo. Decay : 32 ms  13.29   0.56% 
 Thermal Pressure PELT Algo. Decay : 64 ms  12.57   1.56%   
 Thermal Pressure PELT Algo. Decay : 128 ms 12.71   1.04% 
 Thermal Pressure PELT Algo. Decay : 256 ms 12.29   1.42%   
 Thermal Pressure PELT Algo. Decay : 512 ms 12.42   1.15%  


Dhrystone Run Time  : 20 threads, 3000 MLOOPS
 Result  SD 
 (Secs)(% of mean) 
 No Thermal Pressure  9.452  4.49%
 Thermal Pressure PELT Algo. Decay : 32 ms8.793  5.30%
 Thermal Pressure PELT Algo. Decay : 64 ms8.981  5.29%
 Thermal Pressure PELT Algo. Decay : 128 ms   8.647  6.62%
 Thermal Pressure PELT Algo. Decay : 256 ms   8.774  6.45%
 Thermal Pressure PELT Algo. Decay : 512 ms   8.603  5.41%  

A Brief History

The first version of this patch-series was posted with resuing
PELT algorithm to decay thermal pressure signal. The discussions
that followed were around whether intanteneous thermal pressure
solution is better and whether a stand-alone algortihm to accumulate
and decay thermal pressure is more appropriate than re-using the
PELT framework. 
Tests on Hikey960 showed the stand-alone algorithm performing slightly
better than resuing PELT algorithm and V2 was posted with the stand
alone algorithm. Test results were shared as part of this series.
Discussions were around re-using PELT algorithm and running
further tests with more granular decay period.

For some time after this development was impeded due to hardware
unavailability, some other unforseen and possibly unfortunate events.
For this version, h/w was switched from hikey960 to db845c.
Also Instantaneous thermal pressure was never tested as part of this
cycle as it is clear that weighted average is a better implementation.
The non-PELT algorithm never gave any conclusive results to prove that it
is better than reusing PELT algorithm, in this round of testing.
Also reusing PELT algorithm means thermal pressure tracks the
other utilization signals in the scheduler.

Thara Gopinath (7):
  sched/pelt.c: Add support to track thermal pressure
  sched: Add infrastructure to store and update instantaneous thermal
pressure
  sched: Initialize per cpu thermal pressure structure
  sched/fair: Enable CFS periodic tick to update thermal pressure
  sched/fair: update cpu_capcity to reflect thermal pressure
  thermal/cpu-cooling: Update thermal pressure in case of a maximum
frequency capping
  sched: thermal: Enable tuning of decay period

 

[Patch v3 1/7] sched/pelt.c: Add support to track thermal pressure

[Thara Gopinath]

Extrapolating on the exisitng framework to track rt/dl utilization using
pelt signals, add a similar mechanism to track thermal pressue. The
difference here from rt/dl utilization tracking is that, instead of
tracking time spent by a cpu running a rt/dl task through util_avg,
the average thermal pressure is tracked through load_avg.
In order to track average thermal pressure, a new sched_avg variable
avg_thermal is introduced. Function update_thermal_avg can be called
to do the periodic bookeeping (accumulate, decay and average)
of the thermal pressure.

Signed-off-by: Thara Gopinath 
---
 kernel/sched/pelt.c  | 13 +
 kernel/sched/pelt.h  |  7 +++
 kernel/sched/sched.h |  1 +
 3 files changed, 21 insertions(+)

diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c
index a96db50..f06aae3 100644
--- a/kernel/sched/pelt.c
+++ b/kernel/sched/pelt.c
@@ -353,6 +353,19 @@ int update_dl_rq_load_avg(u64 now, struct rq *rq, int 
running)
return 0;
 }
 
+int update_thermal_avg(u64 now, struct rq *rq, u64 capacity)
+{
+   if (___update_load_sum(now, >avg_thermal,
+  capacity,
+  capacity,
+  capacity)) {
+   ___update_load_avg(>avg_thermal, 1, 1);
+   return 1;
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
 /*
  * irq:
diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
index afff644..01c5436 100644
--- a/kernel/sched/pelt.h
+++ b/kernel/sched/pelt.h
@@ -6,6 +6,7 @@ int __update_load_avg_se(u64 now, struct cfs_rq *cfs_rq, struct 
sched_entity *se
 int __update_load_avg_cfs_rq(u64 now, struct cfs_rq *cfs_rq);
 int update_rt_rq_load_avg(u64 now, struct rq *rq, int running);
 int update_dl_rq_load_avg(u64 now, struct rq *rq, int running);
+int update_thermal_avg(u64 now, struct rq *rq, u64 capacity);
 
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
 int update_irq_load_avg(struct rq *rq, u64 running);
@@ -175,6 +176,12 @@ update_rq_clock_pelt(struct rq *rq, s64 delta) { }
 static inline void
 update_idle_rq_clock_pelt(struct rq *rq) { }
 
+static inline int
+update_thermal_avg(u64 now, struct rq *rq, u64 capacity)
+{
+   return 0;
+}
+
 #endif
 
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 0db2c1b..d5d82c8 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -944,6 +944,7 @@ struct rq {
 #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
struct sched_avgavg_irq;
 #endif
+   struct sched_avgavg_thermal;
u64 idle_stamp;
u64 avg_idle;
 
-- 
2.1.4

[Patch v3 3/7] sched: Initialize per cpu thermal pressure structure

[Thara Gopinath]

Initialize per cpu max_capacity_info during scheduler init.

Signed-off-by: Thara Gopinath 
---
 drivers/base/arch_topology.c | 1 +
 kernel/sched/core.c  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 1eb81f11..7ac9f2f 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -123,6 +123,7 @@ void topology_normalize_cpu_scale(void)
pr_debug("cpu_capacity: CPU%d cpu_capacity=%lu\n",
cpu, topology_get_cpu_scale(cpu));
}
+   populate_max_capacity_info();
 }
 
 bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7880f4f..744f026 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6534,6 +6534,8 @@ void __init sched_init_smp(void)
init_sched_rt_class();
init_sched_dl_class();
 
+   populate_max_capacity_info();
+
sched_smp_initialized = true;
 }
 
-- 
2.1.4

[Patch v3 5/7] sched/fair: update cpu_capcity to reflect thermal pressure

[Thara Gopinath]

cpu_capacity relflects the maximum available capacity of a cpu. Thermal
pressure on a cpu means this maximum available capacity is reduced. This
patch reduces the average thermal pressure for a cpu from its maximum
available capacity so that cpu_capacity reflects the actual
available capacity.

Signed-off-by: Thara Gopinath 
---
 kernel/sched/fair.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fe7c165..cbc2208 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7719,6 +7719,7 @@ static unsigned long scale_rt_capacity(struct 
sched_domain *sd, int cpu)
 
used = READ_ONCE(rq->avg_rt.util_avg);
used += READ_ONCE(rq->avg_dl.util_avg);
+   used += READ_ONCE(rq->avg_thermal.load_avg);
 
if (unlikely(used >= max))
return 1;
-- 
2.1.4

[Patch v3 7/7] sched: thermal: Enable tuning of decay period

[Thara Gopinath]

Thermal pressure follows pelt signas which means the
decay period for thermal pressure is the default pelt
decay period. Depending on soc charecteristics and thermal
activity, it might be beneficial to decay thermal pressure
slower, but still in-tune with the pelt signals.
One way to achieve this slow decay is to right shift the now
run time.

Signed-off-by: Thara Gopinath 
---
 include/linux/sched/sysctl.h |  1 +
 kernel/sched/thermal.c   | 16 +++-
 kernel/sysctl.c  |  7 +++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index d4f6215..f4c4afd 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -41,6 +41,7 @@ extern unsigned int sysctl_numa_balancing_scan_size;
 #ifdef CONFIG_SCHED_DEBUG
 extern __read_mostly unsigned int sysctl_sched_migration_cost;
 extern __read_mostly unsigned int sysctl_sched_nr_migrate;
+extern __read_mostly unsigned int sysctl_sched_thermal_decay_coeff;
 
 int sched_proc_update_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length,
diff --git a/kernel/sched/thermal.c b/kernel/sched/thermal.c
index 5f0b2d4..2a00488 100644
--- a/kernel/sched/thermal.c
+++ b/kernel/sched/thermal.c
@@ -10,6 +10,19 @@
 #include "pelt.h"
 #include "thermal.h"
 
+/**
+ * By default the decay is the default pelt decay period.
+ * The decay coefficient can change is decay period in
+ * multiples of 32.
+ *   Decay coefficientDecay period(ms)
+ * 0   32
+ * 1   64
+ * 2   128
+ * 3   256
+ * 4   512
+ */
+unsigned int sysctl_sched_thermal_decay_coeff __read_mostly;
+
 struct max_capacity_info {
unsigned long max_capacity;
unsigned long cap_capacity;
@@ -62,5 +75,6 @@ void update_periodic_maxcap(struct rq *rq)
return;
 
delta = __max_cap->max_capacity - __max_cap->cap_capacity;
-   update_thermal_avg(rq_clock_task(rq), rq, delta);
+   update_thermal_avg((rq_clock_task(rq) >>
+  sysctl_sched_thermal_decay_coeff), rq, delta);
 }
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 00fcea2..5056c08 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -376,6 +376,13 @@ static struct ctl_table kern_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec,
},
+   {
+   .procname   = "sched_thermal_decay_coeff",
+   .data   = _sched_thermal_decay_coeff,
+   .maxlen = sizeof(unsigned int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
 #ifdef CONFIG_SCHEDSTATS
{
.procname   = "sched_schedstats",
-- 
2.1.4

[Patch v3 6/7] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping

[Thara Gopinath]

Thermal governors can request for a cpu's maximum supported frequency
to be capped in case of an overheat event. This in turn means that the
maximum capacity available for tasks to run on the particular cpu is
reduced. Delta between the original maximum capacity and capped
maximum capacity is known as thermal pressure. Enable cpufreq cooling
device to update the thermal pressure in event of a capped
maximum frequency.

Signed-off-by: Thara Gopinath 
---
 drivers/thermal/cpu_cooling.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 391f397..9e2764a 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -218,6 +218,23 @@ static u32 cpu_power_to_freq(struct cpufreq_cooling_device 
*cpufreq_cdev,
 }
 
 /**
+ * update_sched_max_capacity - update scheduler about change in cpu
+ * max frequency.
+ * @policy - cpufreq policy whose max frequency is capped.
+ */
+static void update_sched_max_capacity(struct cpumask *cpus,
+ unsigned int cur_max_freq,
+ unsigned int max_freq)
+{
+   int cpu;
+   unsigned long capacity = (cur_max_freq << SCHED_CAPACITY_SHIFT) /
+ max_freq;
+
+   for_each_cpu(cpu, cpus)
+   update_maxcap_capacity(cpu, capacity);
+}
+
+/**
  * get_load() - get load for a cpu since last updated
  * @cpufreq_cdev:   cpufreq_cooling_device for this cpu
  * @cpu:   cpu number
@@ -320,6 +337,7 @@ static int cpufreq_set_cur_state(struct 
thermal_cooling_device *cdev,
 unsigned long state)
 {
struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata;
+   int ret;
 
/* Request state should be less than max_level */
if (WARN_ON(state > cpufreq_cdev->max_level))
@@ -331,8 +349,17 @@ static int cpufreq_set_cur_state(struct 
thermal_cooling_device *cdev,
 
cpufreq_cdev->cpufreq_state = state;
 
-   return dev_pm_qos_update_request(_cdev->qos_req,
-   cpufreq_cdev->freq_table[state].frequency);
+   ret = dev_pm_qos_update_request
+   (_cdev->qos_req,
+cpufreq_cdev->freq_table[state].frequency);
+
+   if (ret > 0)
+   update_sched_max_capacity
+   (cpufreq_cdev->policy->cpus,
+cpufreq_cdev->freq_table[state].frequency,
+cpufreq_cdev->policy->cpuinfo.max_freq);
+
+   return ret;
 }
 
 /**
-- 
2.1.4

Re: [PATCH] ipmi: Convert ipmi_debug_msg to pr_debug and use %*ph

[kbuild test robot]

Hi Joe,

I love your patch! Perhaps something to improve:

[auto build test WARNING on char-misc/char-misc-testing]
[cannot apply to v5.4-rc2 next-20191011]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/ipmi-Convert-ipmi_debug_msg-to-pr_debug-and-use-ph/20191014-051352
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/char/ipmi/ipmi_msghandler.c:17:
   drivers/char/ipmi/ipmi_msghandler.c: In function 'i_ipmi_request':
>> include/linux/kern_levels.h:5:18: warning: field width specifier '*' expects 
>> argument of type 'int', but argument 4 has type 'unsigned char *' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
  printk(fmt, ##__VA_ARGS__);  \
 ^~~
   include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
   ^~~~
   include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
   ^~
   drivers/char/ipmi/ipmi_msghandler.c:2251:3: note: in expansion of macro 
'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:2251:18: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~^~
   In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/char/ipmi/ipmi_msghandler.c:17:
>> include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of 
>> type 'void *', but argument 5 has type 'int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
  printk(fmt, ##__VA_ARGS__);  \
 ^~~
   include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
   ^~~~
   include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
   ^~
   drivers/char/ipmi/ipmi_msghandler.c:2251:3: note: in expansion of macro 
'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:2251:19: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~~^
%*d
   In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/char/ipmi/ipmi_msghandler.c:17:
   drivers/char/ipmi/ipmi_msghandler.c: In function 'handle_ipmb_get_msg_cmd':
>> include/linux/kern_levels.h:5:18: warning: field width specifier '*' expects 
>> argument of type 'int', but argument 4 has type 'unsigned char *' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
  printk(fmt, ##__VA_ARGS__);  \
 ^~~
   include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
   ^~~~
   include/linux/printk.h:342:12: note: in expansion of macro 'KERN_DEBUG'
 no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
   ^~
   drivers/char/ipmi/ipmi_msghandler.c:3715:3: note: in expansion of macro 
'pr_debug'
  pr_debug("%s: %*ph\n",
  ^~~~
   drivers/char/ipmi/ipmi_msghandler.c:3715:18: note: format string is defined 
here
  pr_debug("%s: %*ph\n",
~^~
   In file included from include/linux/kernel.h:15:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/char/ipmi/ipmi_msghandler.c:17:
>> include/linux/kern_levels.h:5:18: warning: format '%p' expects argument of 
>> type 'void *', but argument 5 has type 'int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   

[no subject]

[linux-kernel]

Здравствуйте! Вас интересуют клиентские базы данных?

Re: [PATCHv7 15/33] posix-timers: Make clock_nanosleep() time namespace aware

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All errors (new ones prefixed by >>):

   kernel/time/posix-stubs.c: In function '__do_sys_clock_nanosleep':
>> kernel/time/posix-stubs.c:153:31: error: 'clockid' undeclared (first use in 
>> this function); did you mean 'clock_t'?
  texp = timens_ktime_to_host(clockid, texp);
  ^~~
  clock_t
   kernel/time/posix-stubs.c:153:31: note: each undeclared identifier is 
reported only once for each function it appears in
   kernel/time/posix-stubs.c: In function '__do_sys_clock_nanosleep_time32':
>> kernel/time/posix-stubs.c:222:2: error: unknown type name 'ktime'; did you 
>> mean 'ktime_t'?
 ktime texp;
 ^
 ktime_t
   kernel/time/posix-stubs.c:243:31: error: 'clockid' undeclared (first use in 
this function); did you mean 'clock_t'?
  texp = timens_ktime_to_host(clockid, texp);
  ^~~
  clock_t

vim +153 kernel/time/posix-stubs.c

   126  
   127  SYSCALL_DEFINE4(clock_nanosleep, const clockid_t, which_clock, int, 
flags,
   128  const struct __kernel_timespec __user *, rqtp,
   129  struct __kernel_timespec __user *, rmtp)
   130  {
   131  struct timespec64 t;
   132  ktime_t texp;
   133  
   134  switch (which_clock) {
   135  case CLOCK_REALTIME:
   136  case CLOCK_MONOTONIC:
   137  case CLOCK_BOOTTIME:
   138  break;
   139  default:
   140  return -EINVAL;
   141  }
   142  
   143  if (get_timespec64(, rqtp))
   144  return -EFAULT;
   145  if (!timespec64_valid())
   146  return -EINVAL;
   147  if (flags & TIMER_ABSTIME)
   148  rmtp = NULL;
   149  current->restart_block.nanosleep.type = rmtp ? TT_NATIVE : 
TT_NONE;
   150  current->restart_block.nanosleep.rmtp = rmtp;
   151  texp = timespec64_to_ktime(t);
   152  if (flags & TIMER_ABSTIME)
 > 153  texp = timens_ktime_to_host(clockid, texp);
   154  return hrtimer_nanosleep(texp, flags & TIMER_ABSTIME ?
   155   HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
   156   which_clock);
   157  }
   158  
   159  #ifdef CONFIG_COMPAT
   160  COMPAT_SYS_NI(timer_create);
   161  COMPAT_SYS_NI(getitimer);
   162  COMPAT_SYS_NI(setitimer);
   163  #endif
   164  
   165  #ifdef CONFIG_COMPAT_32BIT_TIME
   166  SYS_NI(timer_settime32);
   167  SYS_NI(timer_gettime32);
   168  
   169  SYSCALL_DEFINE2(clock_settime32, const clockid_t, which_clock,
   170  struct old_timespec32 __user *, tp)
   171  {
   172  struct timespec64 new_tp;
   173  
   174  if (which_clock != CLOCK_REALTIME)
   175  return -EINVAL;
   176  if (get_old_timespec32(_tp, tp))
   177  return -EFAULT;
   178  
   179  return do_sys_settimeofday64(_tp, NULL);
   180  }
   181  
   182  SYSCALL_DEFINE2(clock_gettime32, clockid_t, which_clock,
   183  struct old_timespec32 __user *, tp)
   184  {
   185  int ret;
   186  struct timespec64 kernel_tp;
   187  
   188  ret = do_clock_gettime(which_clock, _tp);
   189  if (ret)
   190  return ret;
   191  
   192  if (put_old_timespec32(_tp, tp))
   193  return -EFAULT;
   194  return 0;
   195  }
   196  
   197  SYSCALL_DEFINE2(clock_getres_time32, clockid_t, which_clock,
   198  struct old_timespec32 __user *, tp)
   199  {
   200  struct timespec64 rtn_tp = {
   201  .tv_sec = 0,
   202  .tv_nsec = hrtimer_resolution,
   203  };
   204  
   205  switch (which_clock) {
   206  case CLOCK_REALTIME:
   207  case CLOCK_MONOTONIC:
   208  case CLOCK_BOOTTIME:
   209  if (put_old_timespec32(_tp, tp))
   210  return -EFAULT;
   211  return 0;
   212  default:
   213  return -EINVAL;
   214  }
 

Re: [PATCH] KVM: LAPIC: micro-optimize fixed mode ipi delivery

[Wanpeng Li]

ping,
On Fri, 20 Sep 2019 at 18:07, Wanpeng Li  wrote:
>
> From: Wanpeng Li 
>
> After disabling mwait/halt/pause vmexits, RESCHEDULE_VECTOR and
> CALL_FUNCTION_SINGLE_VECTOR etc IPI is one of the main remaining
> cause of vmexits observed in product environment which can't be
> optimized by PV IPIs. This patch is the follow-up on commit
> 0e6d242eccdb (KVM: LAPIC: Micro optimize IPI latency), to optimize
> redundancy logic before fixed mode ipi is delivered in the fast
> path.
>
> - broadcast handling needs to go slow path, so the delivery mode repair
>   can be delayed to before slow path.
> - self-IPI will not be intervened by hypervisor any more after APICv is
>   introduced and the boxes support APICv are popular now. In addition,
>   kvm_apic_map_get_dest_lapic() can handle the self-IPI, so there is no
>   need a shortcut for the non-APICv case.
>
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/irq_comm.c | 6 +++---
>  arch/x86/kvm/lapic.c| 5 -
>  2 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> index 8ecd48d..aa88156 100644
> --- a/arch/x86/kvm/irq_comm.c
> +++ b/arch/x86/kvm/irq_comm.c
> @@ -52,15 +52,15 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct 
> kvm_lapic *src,
> unsigned long dest_vcpu_bitmap[BITS_TO_LONGS(KVM_MAX_VCPUS)];
> unsigned int dest_vcpus = 0;
>
> +   if (kvm_irq_delivery_to_apic_fast(kvm, src, irq, , dest_map))
> +   return r;
> +
> if (irq->dest_mode == 0 && irq->dest_id == 0xff &&
> kvm_lowest_prio_delivery(irq)) {
> printk(KERN_INFO "kvm: apic: phys broadcast and lowest 
> prio\n");
> irq->delivery_mode = APIC_DM_FIXED;
> }
>
> -   if (kvm_irq_delivery_to_apic_fast(kvm, src, irq, , dest_map))
> -   return r;
> -
> memset(dest_vcpu_bitmap, 0, sizeof(dest_vcpu_bitmap));
>
> kvm_for_each_vcpu(i, vcpu, kvm) {
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 323bdca..d77fe29 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -955,11 +955,6 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, 
> struct kvm_lapic *src,
>
> *r = -1;
>
> -   if (irq->shorthand == APIC_DEST_SELF) {
> -   *r = kvm_apic_set_irq(src->vcpu, irq, dest_map);
> -   return true;
> -   }
> -
> rcu_read_lock();
> map = rcu_dereference(kvm->arch.apic_map);
>
> --
> 2.7.4
>

[PATCH] cpuidle: not unset the driver if it already exist

[Zhenzhong Duan]

__cpuidle_set_driver() check if there is an already exist driver and
unset it before return with -EBUSY. The next call will succeed as it's
just unset. This is strange as we should either keep old driver and
return -EBUSY or unset and set new driver and return 0.

Signed-off-by: Zhenzhong Duan 
---
 drivers/cpuidle/driver.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 80c1a83..a200304 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -74,7 +74,6 @@ static inline int __cpuidle_set_driver(struct cpuidle_driver 
*drv)
for_each_cpu(cpu, drv->cpumask) {
 
if (__cpuidle_get_cpu_driver(cpu)) {
-   __cpuidle_unset_driver(drv);
return -EBUSY;
}
 
-- 
1.8.3.1

Re: [PATCHv7 06/33] alarmtimer: Provide get_timespec() callback

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kernel-Introduce-Time-Namespace/20191014-075119
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All errors (new ones prefixed by >>):

   ld: kernel/time/alarmtimer.o: in function `alarmtimer_init':
>> alarmtimer.c:(.init.text+0x26): undefined reference to 
>> `posix_get_realtime_timespec'
>> ld: alarmtimer.c:(.init.text+0x44): undefined reference to 
>> `posix_get_boottime_timespec'

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


.config.gz
Description: application/gzip

[PATCH v2 1/2] dt-bindings: pinctrl: rockchip: add rk3308 SoC support

[Jianqun Xu]

Add rk3308 SoC support to rockchip pinctrl.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
changes since v1:
- Add Reviewed-by: Heiko Stuebner 

 Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index 0919db294c17..2113cfaa26e6 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -29,6 +29,7 @@ Required properties for iomux controller:
"rockchip,rk3188-pinctrl":  for Rockchip RK3188
"rockchip,rk3228-pinctrl":  for Rockchip RK3228
"rockchip,rk3288-pinctrl":  for Rockchip RK3288
+   "rockchip,rk3308-pinctrl":  for Rockchip RK3308
"rockchip,rk3328-pinctrl":  for Rockchip RK3328
"rockchip,rk3368-pinctrl":  for Rockchip RK3368
"rockchip,rk3399-pinctrl":  for Rockchip RK3399
-- 
2.17.1

[PATCH v2 0/2] pinctrl: rockchip: support rk3308 SoC

[Jianqun Xu]

Add support for rk3308 SoC from rockchip.

Jianqun Xu (2):
  dt-bindings: pinctrl: rockchip: add rk3308 SoC support
  pinctrl: rockchip: add rk3308 SoC support

 .../bindings/pinctrl/rockchip,pinctrl.txt |   1 +
 drivers/pinctrl/pinctrl-rockchip.c| 377 ++
 2 files changed, 378 insertions(+)

--
changes since v1:
- add Reviewed-by: Heiko Stuebner , thanks Heiko

2.17.1

[PATCH v2 2/2] pinctrl: rockchip: add rk3308 SoC support

[Jianqun Xu]

This patch do support pinctrl for RK3308 SoCs.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Jianqun Xu 
---
changes since v1:
- Add Reviewed-by: Heiko Stuebner 

 drivers/pinctrl/pinctrl-rockchip.c | 377 +
 1 file changed, 377 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index dc0bbf198cbc..9e19db402ee5 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -58,6 +58,7 @@ enum rockchip_pinctrl_type {
RK3128,
RK3188,
RK3288,
+   RK3308,
RK3368,
RK3399,
 };
@@ -70,6 +71,7 @@ enum rockchip_pinctrl_type {
 #define IOMUX_SOURCE_PMU   BIT(2)
 #define IOMUX_UNROUTED BIT(3)
 #define IOMUX_WIDTH_3BIT   BIT(4)
+#define IOMUX_WIDTH_2BIT   BIT(5)
 
 /**
  * @type: iomux variant using IOMUX_* constants
@@ -656,6 +658,100 @@ static  struct rockchip_mux_recalced_data 
rk3128_mux_recalced_data[] = {
},
 };
 
+static struct rockchip_mux_recalced_data rk3308_mux_recalced_data[] = {
+   {
+   .num = 1,
+   .pin = 14,
+   .reg = 0x28,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 15,
+   .reg = 0x2c,
+   .bit = 0,
+   .mask = 0x3
+   }, {
+   .num = 1,
+   .pin = 18,
+   .reg = 0x30,
+   .bit = 4,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 19,
+   .reg = 0x30,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 20,
+   .reg = 0x30,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 21,
+   .reg = 0x34,
+   .bit = 0,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 22,
+   .reg = 0x34,
+   .bit = 4,
+   .mask = 0xf
+   }, {
+   .num = 1,
+   .pin = 23,
+   .reg = 0x34,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 3,
+   .pin = 12,
+   .reg = 0x68,
+   .bit = 8,
+   .mask = 0xf
+   }, {
+   .num = 3,
+   .pin = 13,
+   .reg = 0x68,
+   .bit = 12,
+   .mask = 0xf
+   }, {
+   .num = 2,
+   .pin = 2,
+   .reg = 0x608,
+   .bit = 0,
+   .mask = 0x7
+   }, {
+   .num = 2,
+   .pin = 3,
+   .reg = 0x608,
+   .bit = 4,
+   .mask = 0x7
+   }, {
+   .num = 2,
+   .pin = 16,
+   .reg = 0x610,
+   .bit = 8,
+   .mask = 0x7
+   }, {
+   .num = 3,
+   .pin = 10,
+   .reg = 0x610,
+   .bit = 0,
+   .mask = 0x7
+   }, {
+   .num = 3,
+   .pin = 11,
+   .reg = 0x610,
+   .bit = 4,
+   .mask = 0x7
+   },
+};
+
 static struct rockchip_mux_recalced_data rk3328_mux_recalced_data[] = {
{
.num = 2,
@@ -982,6 +1078,192 @@ static struct rockchip_mux_route_data 
rk3288_mux_route_data[] = {
},
 };
 
+static struct rockchip_mux_route_data rk3308_mux_route_data[] = {
+   {
+   /* rtc_clk */
+   .bank_num = 0,
+   .pin = 19,
+   .func = 1,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 0) | BIT(0),
+   }, {
+   /* uart2_rxm0 */
+   .bank_num = 1,
+   .pin = 22,
+   .func = 2,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 2) | BIT(16 + 3),
+   }, {
+   /* uart2_rxm1 */
+   .bank_num = 4,
+   .pin = 26,
+   .func = 2,
+   .route_offset = 0x314,
+   .route_val = BIT(16 + 2) | BIT(16 + 3) | BIT(2),
+   }, {
+   /* i2c3_sdam0 */
+   .bank_num = 0,
+   .pin = 15,
+   .func = 2,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 9),
+   }, {
+   /* i2c3_sdam1 */
+   .bank_num = 3,
+   .pin = 12,
+   .func = 2,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 9) | BIT(8),
+   }, {
+   /* i2c3_sdam2 */
+   .bank_num = 2,
+   .pin = 0,
+   .func = 3,
+   .route_offset = 0x608,
+   .route_val = BIT(16 + 8) | BIT(16 + 9) | BIT(9),
+   }, {
+  

Linux 5.4-rc3

[Linus Torvalds]

Things continue to look fairly normal, with rc3 being larger than rc2,
as people are starting to find more regressions, but 5.4 so far
remains on the smaller side of recent releases.

The diffstat looks fairly flat too, although we had a couple of
staging drivers being removed here that show up as spikes. Drivers in
general account for about two thirds of the diff, and it's not just
those staging drivers, it's other small noise all over the place: usb,
drm, iio, rdma..

Outside of drivers, filesystems pop up more than perhaps usual, but
it's again mostly low-grade noise all over: btrfs, cifs, nfs, ocfs,
xfs and some core vfs fixes.

The rest is arch updates (mainly arm64, x86, mips), tooling (mostly
perf tooling updates, but also some selftest fixlets), documentation,
and misc core kernel and mm stuff.

There really isn't anything huge that stands out. You can scan the
appended shortlog for a flavor of the details, it's not too long to
just scroll through.

  Linus

---
Adam Ford (2):
  serial: mctrl_gpio: Check for NULL pointer
  serial: 8250_omap: Fix gpio check for auto RTS/CTS

Adam Zerella (3):
  docs: arm64: Fix indentation and doc formatting
  docs: hwmon: Include 'inspur-ipsps1.rst' into docs
  hwmon: docs: Extend inspur-ipsps1 title underline

Adit Ranadive (1):
  RDMA/vmw_pvrdma: Free SRQ only once

Al Viro (3):
  Fix the locking in dcache_readdir() and friends
  shmem: fix LSM options parsing
  libfs: take cursors out of list when moving past the end of directory

Alan Stern (1):
  USB: yurex: Don't retry on unexpected errors

Alexander Shishkin (1):
  perf/core: Fix inheritance of aux_output groups

Alexander Usyskin (1):
  mei: avoid FW version request on Ibex Peak and earlier

Aliasgar Surti (1):
  xfs: removed unused error variable from xchk_refcountbt_rec

Andi Kleen (2):
  perf script brstackinsn: Fix recovery from LBR/binary mismatch
  perf jevents: Fix period for Intel fixed counters

Andreas Klinger (1):
  iio: adc: hx711: fix bug in sampling of data

Andrey Smirnov (1):
  tty: serial: fsl_lpuart: Fix lpuart_flush_buffer()

Anshuman Khandual (1):
  mm/memremap: drop unused SECTION_SIZE and SECTION_MASK

Anson Huang (1):
  tty: serial: imx: Use platform_get_irq_optional() for optional IRQs

Ard Biesheuvel (3):
  crypto: arm/aes-ce - build for v8 architecture explicitly
  crypto: arm/aes-ce - add dependency on AES library
  efivar/ssdt: Don't iterate over EFI vars if no SSDT override was specified

Arnaldo Carvalho de Melo (13):
  tools headers uapi: Sync drm/i915_drm.h with the kernel sources
  tools headers uapi: Sync asm-generic/mman-common.h with the kernel
  tools headers uapi: Sync linux/usbdevice_fs.h with the kernel sources
  tools headers uapi: Sync linux/fs.h with the kernel sources
  tools headers kvm: Sync kvm headers with the kernel sources
  perf tools: Propagate get_cpuid() error
  perf evsel: Fall back to global 'perf_env' in perf_evsel__env()
  perf annotate: Propagate perf_env__arch() error
  perf annotate: Fix the signedness of failure returns
  perf annotate: Propagate the symbol__annotate() error return
  perf annotate: Fix arch specific ->init() failure errors
  perf annotate: Return appropriate error code for allocation failures
  perf annotate: Don't return -1 for error when doing BPF disassembly

Arnd Bergmann (1):
  udc: lpc32xx: fix 64-bit compiler warning

Arvind Sankar (1):
  lib/string: Make memzero_explicit() inline instead of external

Austin Kim (2):
  fs: cifs: mute -Wunused-const-variable message
  btrfs: silence maybe-uninitialized warning in clone_range

Baoquan He (1):
  memcg: only record foreign writebacks with dirty pages when
memcg is not disabled

Bart Van Assche (1):
  RDMA/iwcm: Fix a lock inversion issue

Bartosz Golaszewski (1):
  gpiolib: don't clear FLAG_IS_OUT when emulating open-drain/open-source

Bastien Nocera (1):
  USB: rio500: Remove Rio 500 kernel driver

Ben Dooks (1):
  efi: Make unexported efi_rci2_sysfs_init() static

Beni Mahler (1):
  USB: serial: ftdi_sio: add device IDs for Sienna and Echelon PL-20

Benjamin Coddington (1):
  SUNRPC: fix race to sk_err after xs_error_report

Biju Das (1):
  dt-bindings: serial: sh-sci: Document r8a774b1 bindings

Bill Kuzeja (1):
  xhci: Prevent deadlock when xhci adapter breaks during init

Bill O'Donnell (1):
  xfs: assure zeroed memory buffers for certain kmem allocations

Boris Ostrovsky (1):
  x86/xen: Return from panic notifier

Brian Foster (3):
  xfs: log the inode on directory sf to block format change
  xfs: remove broken error handling on failed attr sf to leaf change
  xfs: move local to extent inode logging into bmap helper

Brian Norris (1):
  firmware: google: increment VPD key_len properly

Bruce Chen (1):
  gpio: eic: sprd: Fix the incorrect EIC 

Re: [PATCH 3/3] Input: mms114 - add support for mms345l

[Andi Shyti]

Hi Dmitry,

> > > > There was a related patch [2] that removes I2C_M_NOSTART for all models,
> > > > but it seems abandoned and I do not have any other model for testing.
> > > > Therefore, this patch implements the least instrusive solution
> > > > and only removes I2C_M_NOSTART for MMS345L.
> > > 
> > > Hmm,  at this point I am inclined to pick up Andi's patch since it seems
> > > to work for you and him and it looks like Android drivers are not using
> > > I2C_M_NOSTART. I wonder if this was some quirk/big on the platform where
> > > it was originally developed.
> > 
> > I completely forgot about that patch :)
> > 
> > I should refresh some old work on that device which was left
> > undone.
> > 
> > > Any objections?
> > 
> > It's OK for me. If you can just update my e-mail, please, when
> > applying the patch to "a...@etezian.org". Thanks!
> 
> Andi, any chance you could resend it with the new email? One thing that
> I try to avoid modifying whenever I can is S-O-B strings...

sure, I will resend the patches, but it might take some time (a
few days I hope) because I don't have the devices with me right
now for testing (and I added some small fixes, as well)

Thanks,
Andi

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

[Stephen Rothwell]

Hi all,

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

  tools/lib/bpf/Makefile

between commit:

  1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")

from the net tree and commits:

  5c26f9a78358 ("libbpf: Don't use cxx to test_libpf target")
  793a349cd819 ("libbpf: Add C/LDFLAGS to libbpf.so and test_libpf targets")

from the bpf-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/lib/bpf/Makefile
index 56ce6292071b,75b538577c17..
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET := $(addprefix $(OUTPUT),$(L
  LIB_FILE  := $(addprefix $(OUTPUT),$(LIB_FILE))
  PC_FILE   := $(addprefix $(OUTPUT),$(PC_FILE))
  
+ TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
+ 
 -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
 +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
   sort -u | wc -l)
@@@ -165,7 -149,7 +159,7 @@@ all: fixde
  
  all_cmd: $(CMD_TARGETS) check
  
- $(BPF_IN_SHARED): force elfdep bpfdep
 -$(BPF_IN): force elfdep bpfdep bpf_helper_defs.h
++$(BPF_IN_SHARED): force elfdep bpfdep bpf_helper_defs.h
@(test -f ../../include/uapi/linux/bpf.h -a -f 
../../../include/uapi/linux/bpf.h && ( \
(diff -B ../../include/uapi/linux/bpf.h 
../../../include/uapi/linux/bpf.h >/dev/null) || \
echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' 
differs from latest version at 'include/uapi/linux/bpf.h'" >&2 )) || true
@@@ -181,24 -165,26 +175,29 @@@
@(test -f ../../include/uapi/linux/if_xdp.h -a -f 
../../../include/uapi/linux/if_xdp.h && ( \
(diff -B ../../include/uapi/linux/if_xdp.h 
../../../include/uapi/linux/if_xdp.h >/dev/null) || \
echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' 
differs from latest version at 'include/uapi/linux/if_xdp.h'" >&2 )) || true
 -  $(Q)$(MAKE) $(build)=libbpf
 +  $(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) 
$(SHLIB_FLAGS)"
 +
 +$(BPF_IN_STATIC): force elfdep bpfdep
 +  $(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
  
+ bpf_helper_defs.h: $(srctree)/include/uapi/linux/bpf.h
+   $(Q)$(srctree)/scripts/bpf_helpers_doc.py --header  \
+   --file $(srctree)/include/uapi/linux/bpf.h > bpf_helper_defs.h
+ 
  $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
  
 -$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
 +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN_SHARED)
-   $(QUIET_LINK)$(CC) --shared 
-Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
-   -Wl,--version-script=$(VERSION_SCRIPT) $^ 
-lelf -o $@
+   $(QUIET_LINK)$(CC) $(LDFLAGS) \
+   --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
+   -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
@ln -sf $(@F) $(OUTPUT)libbpf.so
@ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION)
  
 -$(OUTPUT)libbpf.a: $(BPF_IN)
 +$(OUTPUT)libbpf.a: $(BPF_IN_STATIC)
$(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
  
- $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
-   $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@
+ $(OUTPUT)test_libbpf: test_libbpf.c $(OUTPUT)libbpf.a
+   $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@
  
  $(OUTPUT)libbpf.pc:
$(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \
@@@ -268,9 -259,9 +272,10 @@@ config-clean
$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
  
  clean:
-   $(call QUIET_CLEAN, libbpf) $(RM) -rf $(TARGETS) $(CXX_TEST_TARGET) \
 -  $(call QUIET_CLEAN, libbpf) $(RM) $(CMD_TARGETS) \
++  $(call QUIET_CLEAN, libbpf) $(RM) -rf $(CMD_TARGETS) \
*.o *~ *.a *.so *.so.$(LIBBPF_MAJOR_VERSION) .*.d .*.cmd \
-   *.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR)
 -  *.pc LIBBPF-CFLAGS bpf_helper_defs.h
++  *.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR) \
++  bpf_helper_defs.h
$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
  
  


pgpCtw_6OrnGR.pgp
Description: OpenPGP digital signature

Re: [PATCH v3][RESEND] adp5061: Add support for battery charging enable

[kbuild test robot]

Hi Alexandru,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Alexandru-Ardelean/adp5061-Add-support-for-battery-charging-enable/20191014-035456
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git 
for-next
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64 

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

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

   In file included from include/linux/kobject.h:20:0,
from include/linux/module.h:17,
from drivers/power/supply/adp5061.c:9:
>> drivers/power/supply/adp5061.c:738:44: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^
   include/linux/sysfs.h:104:10: note: in definition of macro '__ATTR'
 .show = _show,  \
 ^
>> drivers/power/supply/adp5061.c:738:8: note: in expansion of macro 
>> 'DEVICE_ATTR'
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^~~
   drivers/power/supply/adp5061.c:738:44: note: (near initialization for 
'dev_attr_charging_enabled.show')
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^
   include/linux/sysfs.h:104:10: note: in definition of macro '__ATTR'
 .show = _show,  \
 ^
>> drivers/power/supply/adp5061.c:738:8: note: in expansion of macro 
>> 'DEVICE_ATTR'
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^~~
   drivers/power/supply/adp5061.c:739:6: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 adp5061_set_charging_enabled);
 ^
   include/linux/sysfs.h:105:11: note: in definition of macro '__ATTR'
 .store = _store,  \
  ^~
>> drivers/power/supply/adp5061.c:738:8: note: in expansion of macro 
>> 'DEVICE_ATTR'
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^~~
   drivers/power/supply/adp5061.c:739:6: note: (near initialization for 
'dev_attr_charging_enabled.store')
 adp5061_set_charging_enabled);
 ^
   include/linux/sysfs.h:105:11: note: in definition of macro '__ATTR'
 .store = _store,  \
  ^~
>> drivers/power/supply/adp5061.c:738:8: note: in expansion of macro 
>> 'DEVICE_ATTR'
static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   ^~~
   cc1: some warnings being treated as errors

vim +738 drivers/power/supply/adp5061.c

   737  
 > 738  static DEVICE_ATTR(charging_enabled, 0644, adp5061_get_charging_enabled,
   739 adp5061_set_charging_enabled);
   740  

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


.config.gz
Description: application/gzip

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:

  drivers/net/netdevsim/fib.c

between commit:

  33902b4a4227 ("netdevsim: Fix error handling in nsim_fib_init and 
nsim_fib_exit")

from the net tree and commit:

  a5facc4cac4d ("netdevsim: change fib accounting and limitations to be 
per-device")

from the net-next tree.

I fixed it up (I just used the latter version) 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


pgp8FDPi8JL_K.pgp
Description: OpenPGP digital signature

Re: [PATCH] net: core: datagram: tidy up copy functions a bit

[Vito Caputo]

On Sun, Oct 13, 2019 at 01:17:18PM -0700, Eric Dumazet wrote:
> 
> 
> On 10/13/19 1:01 PM, Vito Caputo wrote:
> > On Sun, Oct 13, 2019 at 12:30:41PM -0700, Eric Dumazet wrote:
> >>
> >>
> >> On 10/12/19 4:55 AM, Vito Caputo wrote:
> >>> Eliminate some verbosity by using min() macro and consolidating some
> >>> things, also fix inconsistent zero tests (! vs. == 0).
> >>>
> >>> Signed-off-by: Vito Caputo 
> >>> ---
> >>>  net/core/datagram.c | 44 ++--
> >>>  1 file changed, 14 insertions(+), 30 deletions(-)
> >>>
> >>> diff --git a/net/core/datagram.c b/net/core/datagram.c
> >>> index 4cc8dc5db2b7..08d403f93952 100644
> >>> --- a/net/core/datagram.c
> >>> +++ b/net/core/datagram.c
> >>> @@ -413,13 +413,11 @@ static int __skb_datagram_iter(const struct sk_buff 
> >>> *skb, int offset,
> >>>   struct iov_iter *), void *data)
> >>>  {
> >>>   int start = skb_headlen(skb);
> >>> - int i, copy = start - offset, start_off = offset, n;
> >>> + int i, copy, start_off = offset, n;
> >>>   struct sk_buff *frag_iter;
> >>>  
> >>>   /* Copy header. */
> >>> - if (copy > 0) {
> >>> - if (copy > len)
> >>> - copy = len;
> >>> + if ((copy = min(start - offset, len)) > 0) {
> >>
> >> No, we prefer not having this kind of construct anymore.
> >>
> >> This refactoring looks unnecessary code churn, making our future backports 
> >> not
> >> clean cherry-picks.
> >>
> >> Simply making sure this patch does not bring a regression is very time 
> >> consuming.
> > 
> > Should I not bother submitting patches for such cleanups?
> > 
> > I submitted another, more trivial patch, is it also considered unnecessary 
> > churn:
> > 
> > ---
> > 
> > Author: Vito Caputo 
> > Date:   Sat Oct 12 17:10:41 2019 -0700
> > 
> > net: core: skbuff: skb_checksum_setup() drop err
> > 
> > Return directly from all switch cases, no point in storing in err.
> > 
> > Signed-off-by: Vito Caputo 
> > 
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index f5f904f46893..c59b68a413b5 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -4888,23 +4888,14 @@ static int skb_checksum_setup_ipv6(struct sk_buff 
> > *skb, bool recalculate)
> >   */
> >  int skb_checksum_setup(struct sk_buff *skb, bool recalculate)
> >  {
> > -   int err;
> > -
> > switch (skb->protocol) {
> > case htons(ETH_P_IP):
> > -   err = skb_checksum_setup_ipv4(skb, recalculate);
> > -   break;
> > -
> > +   return skb_checksum_setup_ipv4(skb, recalculate);
> > case htons(ETH_P_IPV6):
> > -   err = skb_checksum_setup_ipv6(skb, recalculate);
> > -   break;
> > -
> > +   return skb_checksum_setup_ipv6(skb, recalculate);
> > default:
> > -   err = -EPROTO;
> > -   break;
> > +   return -EPROTO;
> > }
> > -
> > -   return err;
> >  }
> >  EXPORT_SYMBOL(skb_checksum_setup);
> > 
> > ---
> > 
> > Asking to calibrate my thresholds to yours, since I was planning to 
> > volunteer
> > some time each evening to reading kernel code and submitting any obvious
> > cleanups.
> > 
> 
> This is not a cleanup.
> 
> You prefer seeing the code written the way you did, but that is really a 
> matter of taste.
> 

I respectfully disagree with your assertion.  When the diff --stat shows
more lines removed than added without harming readability, preferably
improving readability, it's both a cleanup and not a debatable matter of
taste.  Having the quantifiable metric of fewer lines of code matters.

> Think about backports of real bug fixes to stable kernels.
> 

That's fair, but when the change is an isolated mechanical one in a
single small function, as the one quoted above - is that really of any
significant burden on backports?

> Having these re-writes of code make things less easy for us really.
> So in general we tend to leave the existing code style.
> 
> I already replied to the other patch submission, please read
> 
> https://marc.info/?l=linux-netdev=157099669227635=2
> 

I read it, thank you for your responses.

Do you have any guidance to offer someone wanting to contribute with 1-2
hours available per day?  I don't want to cause a nuisance, but would
like to help where I can.  My flawed assumption was that small, isolated
hygienic contributions without functionally changing anything would be
appropriate.

Thanks,
Vito Caputo

Re: [PATCH] watchdog/hardlockup: reassign last_timestamp when enable nmi event

[kbuild test robot]

Hi Li,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Li-RongQing/watchdog-hardlockup-reassign-last_timestamp-when-enable-nmi-event/20191014-022936
config: i386-randconfig-g002-201941 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/percpu.h:7:0,
from arch/x86/include/asm/percpu.h:556,
from arch/x86/include/asm/current.h:6,
from include/linux/sched.h:12,
from include/linux/nmi.h:8,
from kernel/watchdog_hld.c:15:
   kernel/watchdog_hld.c: In function 'hardlockup_detector_perf_enable':
   kernel/watchdog_hld.c:201:17: error: 'last_timestamp' undeclared (first use 
in this function); did you mean 'statx_timestamp'?
 this_cpu_write(last_timestamp, now);
^
   include/linux/percpu-defs.h:220:47: note: in definition of macro 
'__verify_pcpu_ptr'
 const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ^~~
   include/linux/percpu-defs.h:509:34: note: in expansion of macro 
'__pcpu_size_call'
#define this_cpu_write(pcp, val) __pcpu_size_call(this_cpu_write_, pcp, val)
 ^~~~
   kernel/watchdog_hld.c:201:2: note: in expansion of macro 'this_cpu_write'
 this_cpu_write(last_timestamp, now);
 ^~
   kernel/watchdog_hld.c:201:17: note: each undeclared identifier is reported 
only once for each function it appears in
 this_cpu_write(last_timestamp, now);
^
   include/linux/percpu-defs.h:220:47: note: in definition of macro 
'__verify_pcpu_ptr'
 const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ^~~
   include/linux/percpu-defs.h:509:34: note: in expansion of macro 
'__pcpu_size_call'
#define this_cpu_write(pcp, val) __pcpu_size_call(this_cpu_write_, pcp, val)
 ^~~~
   kernel/watchdog_hld.c:201:2: note: in expansion of macro 'this_cpu_write'
 this_cpu_write(last_timestamp, now);
 ^~
   kernel/watchdog_hld.c: In function 'hardlockup_detector_perf_restart':
   kernel/watchdog_hld.c:283:12: error: 'last_timestamp' undeclared (first use 
in this function); did you mean 'statx_timestamp'?
   per_cpu(last_timestamp, cpu) = now;
   ^
   include/linux/percpu-defs.h:220:47: note: in definition of macro 
'__verify_pcpu_ptr'
 const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ^~~
>> include/linux/percpu-defs.h:264:47: note: in expansion of macro 
>> 'VERIFY_PERCPU_PTR'
#define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
  ^
   include/linux/percpu-defs.h:270:29: note: in expansion of macro 'per_cpu_ptr'
#define per_cpu(var, cpu) (*per_cpu_ptr(&(var), cpu))
^~~
   kernel/watchdog_hld.c:283:4: note: in expansion of macro 'per_cpu'
   per_cpu(last_timestamp, cpu) = now;
   ^~~

vim +/VERIFY_PERCPU_PTR +264 include/linux/percpu-defs.h

62fde54123fb64 Tejun Heo 2014-06-17  206  
9c28278a24c01c Tejun Heo 2014-06-17  207  /*
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  208   * __verify_pcpu_ptr() verifies @ptr 
is a percpu pointer without evaluating
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  209   * @ptr and is invoked once before a 
percpu area is accessed by all
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  210   * accessors and operations.  This is 
performed in the generic part of
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  211   * percpu and arch overrides don't 
need to worry about it; however, if an
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  212   * arch wants to implement an 
arch-specific percpu accessor or operation,
6fbc07bbe2b5a8 Tejun Heo 2014-06-17  213   * it may use __verify_pcpu_ptr() to 
verify the parameters.
9c28278a24c01c Tejun Heo 2014-06-17  214   *
9c28278a24c01c Tejun Heo 2014-06-17  215   * + 0 is required in order to 
convert the pointer type from a
9c28278a24c01c Tejun Heo 2014-06-17  216   * potential array type to a pointer 
to a single item of the array.
9c28278a24c01c Tejun Heo 2014-06-17  217   */
eba117889ac444 Tejun Heo 2014-06-17  218  #define __verify_pcpu_ptr(ptr)  

Re: [PATCH 3/3] Input: mms114 - add support for mms345l

[Andi Shyti]

Hi Stephan,

> > > There was a related patch [2] that removes I2C_M_NOSTART for all models,
> > > but it seems abandoned and I do not have any other model for testing.
> > > Therefore, this patch implements the least instrusive solution
> > > and only removes I2C_M_NOSTART for MMS345L.
> > 
> > Hmm,  at this point I am inclined to pick up Andi's patch since it seems
> > to work for you and him and it looks like Android drivers are not using
> > I2C_M_NOSTART. I wonder if this was some quirk/big on the platform where
> > it was originally developed.
> > 
> > Any objections?
> 
> I cannot really speak for any of the other models, but no objections for
> removing I2C_M_NOSTART from my side. I'm actually rather confused by it
> since it is used on the first partial message.
> 
> The documentation [1] says:
>   If you set the I2C_M_NOSTART variable for the first partial message,
>   we do not generate Addr, but we do generate the startbit S.
>   ** This will probably confuse all other clients on your bus,
>   so don't try this. **
> 
> Yet, someone felt like trying this here. ;)

still it should be specified in the i2c protocol of the device,
if it's not, then most probably it's not needed, I guess.

Andi

[PATCH 0/2] gup.c, gup_benchmark.c trivial fixes before the storm

[John Hubbard]

Hi,

These trivial fixes apply to today's linux.git (5.4-rc3, or maybe -rc4, by
the time I send this).

I found these while polishing up the Next And Final get_user_pages()+dma
tracking patchset (which is in final testing and passing nicely...so far).

Anyway, as these two patches apply cleanly both before and after the larger
gup/dma upcoming patchset, I thought it best to send this out separately,
in order to avoid muddying the waters more than usual.

Cc: Christoph Hellwig 
Cc: Aneesh Kumar K.V 
Cc: Kirill A. Shutemov 
Cc: Keith Busch 
Cc: Shuah Khan 
Cc: linux-kselft...@vger.kernel.org


John Hubbard (2):
  mm/gup_benchmark: add a missing "w" to getopt string
  mm/gup: fix a misnamed "write" argument: should be "flags"

 mm/gup.c   | 12 +++-
 tools/testing/selftests/vm/gup_benchmark.c |  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.23.0

[PATCH 1/2] mm/gup_benchmark: add a missing "w" to getopt string

[John Hubbard]

Even though gup_benchmark.c has code to handle the -w
command-line option, the "w" is not part of the getopt
string. It looks as if it has been missing the whole time.

On my machine, this leads naturally to the following
predictable result:

$ sudo ./gup_benchmark -w
./gup_benchmark: invalid option -- 'w'

...which is fixed, with this commit.

Cc: Kirill A. Shutemov 
Cc: Keith Busch 
Cc: Shuah Khan 
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: John Hubbard 
---
 tools/testing/selftests/vm/gup_benchmark.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vm/gup_benchmark.c 
b/tools/testing/selftests/vm/gup_benchmark.c
index c0534e298b51..cb3fc09645c4 100644
--- a/tools/testing/selftests/vm/gup_benchmark.c
+++ b/tools/testing/selftests/vm/gup_benchmark.c
@@ -37,7 +37,7 @@ int main(int argc, char **argv)
char *file = "/dev/zero";
char *p;
 
-   while ((opt = getopt(argc, argv, "m:r:n:f:tTLUSH")) != -1) {
+   while ((opt = getopt(argc, argv, "m:r:n:f:tTLUwSH")) != -1) {
switch (opt) {
case 'm':
size = atoi(optarg) * MB;
-- 
2.23.0

[PATCH 2/2] mm/gup: fix a misnamed "write" argument: should be "flags"

[John Hubbard]

In several routines, the "flags" argument is incorrectly
named "write". Change it to "flags".

You can see that this was a simple oversight, because the
calling code passes "flags" to the fifth argument:

gup_pgd_range():
...
if (!gup_huge_pd(__hugepd(pgd_val(pgd)), addr,
PGDIR_SHIFT, next, flags, pages, nr))

...which, until this patch, the callees referred to as "write".

Also, change two lines to avoid checkpatch line length
complaints, and another line to fix another oversight
that checkpatch called out: missing "int" on pdshift.

Cc: Christoph Hellwig 
Cc: Aneesh Kumar K.V 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 23a9f9c9d377..0438221d8c53 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1973,7 +1973,8 @@ static unsigned long hugepte_addr_end(unsigned long addr, 
unsigned long end,
 }
 
 static int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
-  unsigned long end, int write, struct page **pages, int 
*nr)
+  unsigned long end, int flags, struct page **pages,
+  int *nr)
 {
unsigned long pte_end;
struct page *head, *page;
@@ -2023,7 +2024,7 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, 
unsigned long addr,
 }
 
 static int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
-   unsigned int pdshift, unsigned long end, int write,
+   unsigned int pdshift, unsigned long end, int flags,
struct page **pages, int *nr)
 {
pte_t *ptep;
@@ -2033,7 +2034,7 @@ static int gup_huge_pd(hugepd_t hugepd, unsigned long 
addr,
ptep = hugepte_offset(hugepd, addr, pdshift);
do {
next = hugepte_addr_end(addr, end, sz);
-   if (!gup_hugepte(ptep, sz, addr, end, write, pages, nr))
+   if (!gup_hugepte(ptep, sz, addr, end, flags, pages, nr))
return 0;
} while (ptep++, addr = next, addr != end);
 
@@ -2041,7 +2042,7 @@ static int gup_huge_pd(hugepd_t hugepd, unsigned long 
addr,
 }
 #else
 static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
-   unsigned pdshift, unsigned long end, int write,
+   unsigned int pdshift, unsigned long end, int flags,
struct page **pages, int *nr)
 {
return 0;
@@ -2049,7 +2050,8 @@ static inline int gup_huge_pd(hugepd_t hugepd, unsigned 
long addr,
 #endif /* CONFIG_ARCH_HAS_HUGEPD */
 
 static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
-   unsigned long end, unsigned int flags, struct page **pages, int 
*nr)
+   unsigned long end, unsigned int flags,
+   struct page **pages, int *nr)
 {
struct page *head, *page;
int refs;
-- 
2.23.0

Re: [PATCH v2 for 5.4 2/4] media: hantro: Fix H264 max frmsize supported on RK3288

[Nicolas Dufresne]

Le jeudi 10 octobre 2019 à 16:23 +0900, Tomasz Figa a écrit :
> On Tue, Oct 8, 2019 at 11:12 PM Jonas Karlman  wrote:
> > On 2019-10-08 15:53, Tomasz Figa wrote:
> > > On Tue, Oct 8, 2019 at 10:35 PM Tomasz Figa  wrote:
> > > > On Tue, Oct 8, 2019 at 7:42 PM Tomasz Figa  wrote:
> > > > > On Tue, Oct 8, 2019 at 3:31 PM Jonas Karlman  wrote:
> > > > > > On 2019-10-08 07:27, Tomasz Figa wrote:
> > > > > > > Hi Ezequiel, Jonas,
> > > > > > > 
> > > > > > > On Tue, Oct 8, 2019 at 2:46 AM Ezequiel Garcia 
> > > > > > >  wrote:
> > > > > > > > From: Jonas Karlman 
> > > > > > > > 
> > > > > > > > TRM specify supported image size 48x48 to 4096x2304 at step 
> > > > > > > > size 16 pixels,
> > > > > > > > change frmsize max_width/max_height to match TRM.
> > > > > > > > 
> > > > > > > > Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on 
> > > > > > > > rk3288")
> > > > > > > > Signed-off-by: Jonas Karlman 
> > > > > > > > ---
> > > > > > > > v2:
> > > > > > > > * No changes.
> > > > > > > > 
> > > > > > > >  drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 ++--
> > > > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/staging/media/hantro/rk3288_vpu_hw.c 
> > > > > > > > b/drivers/staging/media/hantro/rk3288_vpu_hw.c
> > > > > > > > index 6bfcc47d1e58..ebb017b8a334 100644
> > > > > > > > --- a/drivers/staging/media/hantro/rk3288_vpu_hw.c
> > > > > > > > +++ b/drivers/staging/media/hantro/rk3288_vpu_hw.c
> > > > > > > > @@ -67,10 +67,10 @@ static const struct hantro_fmt 
> > > > > > > > rk3288_vpu_dec_fmts[] = {
> > > > > > > > .max_depth = 2,
> > > > > > > > .frmsize = {
> > > > > > > > .min_width = 48,
> > > > > > > > -   .max_width = 3840,
> > > > > > > > +   .max_width = 4096,
> > > > > > > > .step_width = H264_MB_DIM,
> > > > > > > > .min_height = 48,
> > > > > > > > -   .max_height = 2160,
> > > > > > > > +   .max_height = 2304,
> > > > > > > This doesn't match the datasheet I have, which is RK3288 
> > > > > > > Datasheet Rev
> > > > > > > 1.4 and which has the values as in current code. What's the one 
> > > > > > > you
> > > > > > > got the values from?
> > > > > > The RK3288 TRM vcodec chapter from [1], unknown revision and date, 
> > > > > > lists 48x48 to 4096x2304 step size 16 pixels under 25.5.1 H.264 
> > > > > > decoder.
> > > > > > 
> > > > > > I can also confirm that one of my test samples (PUPPIES BATH IN 4K) 
> > > > > > is 4096x2304 and can be decoded after this patch.
> > > > > > However the decoding speed is not optimal at 400Mhz, if I recall 
> > > > > > correctly you need to set the VPU1 clock to 600Mhz for 4K decoding 
> > > > > > on RK3288.
> > > > > > 
> > > > > > I am not sure if I should include a v2 of this patch in my v2 
> > > > > > series, as-is this patch do not apply on master (H264_MB_DIM has 
> > > > > > changed to MB_DIM in master).
> > > > > > 
> > > > > > [1] 
> > > > > > http://www.t-firefly.com/download/firefly-rk3288/docs/TRM/rk3288-chapter-25-video-encoder-decoder-unit-(vcodec).pdf
> > > > > I checked the RK3288 TRM V1.1 too and it refers to 3840x2160@24fps as
> > > > > the maximum.
> > > > > 
> > > > > As for performance, we've actually been getting around 33 fps at 400
> > > > > MHz with 3840x2160 on our devices (the old RK3288 Asus Chromebook
> > > > > Flip).
> > > > > 
> > > > > I guess we might want to check that with Hantro.
> > > > Could you check the value of bits 10:0 in register at 0x0c8? That
> > > > should be the maximum supported stream width in the units of 16
> > > > pixels.
> > > Correction: The unit is 1 pixel and there are additional 2 most
> > > significant bits at 0x0d8, 15:14.
> > 
> > I will check this later tonight when I have access to my devices.
> > The PUPPIES BATH IN 4K (4096x2304) sample decoded without issue using 
> > rockchip 4.4 BSP kernel and mpp last time I tested.
> > 
> > The vcodec driver in 4.4 BSP kernel use 300/400 Mhz as default clock rate 
> > and will change to 600 Mhz when width is over 2560, see [1]:
> >   raise frequency for resolution larger than 1440p avc
> > 
> > [1] 
> > https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/video/rockchip/vcodec/vcodec_service.c#L2551-L2570
> 
> How comes it works for us well at 400 MHz? Better DRAM? Differences in
> how Vcodec BSP handles the hardware that somehow make the decoding
> slower?

FWIW, here on the mainline driver, on RK3288, playing a 4K30 sample
(probably the max for this one) get stuck at 20fps with 400MHz. So
600MHz would in theory be perfect to reach 30fps. That being said,
different stream yield different performance with H264 and other
CODECs, so doing a completely objective evaluation is hard.

> 
> Best regards,
> Tomasz


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/2] gpio: Add xgs-iproc driver

[Chris Packham]

On Fri, 2019-10-11 at 09:43 +0200, Linus Walleij wrote:
> Hi Chris!
> 
> Thanks for your patch!
> 
> On Fri, Oct 4, 2019 at 3:25 AM Chris Packham
>  wrote:
> 
> > This driver supports the Chip Common A GPIO controller present on a
> > number of Broadcom switch ASICs with integrated SoCs. The controller is
> > similar to the pinctrl-nsp-gpio and pinctrl-iproc-gpio blocks but
> > different enough that a separate driver is required.
> > 
> > This has been ported from Broadcom's XLDK 5.0.3 retaining only the CCA
> > support (pinctrl-iproc-gpio covers CCB).
> > 
> > Signed-off-by: Chris Packham 
> 
> (...)
> 
> > +config GPIO_XGS_IPROC
> > +   tristate "BRCM XGS iProc GPIO support"
> > +   depends on OF_GPIO && (ARCH_BCM_IPROC || COMPILE_TEST)
> > +   select GPIO_GENERIC
> > +   select GPIOLIB_IRQCHIP
> 
> Nice reuse of abstractions.
> 
> > +static u32 iproc_gpio_readl(struct iproc_gpio_chip *chip, int reg)
> > +{
> > +   return readl(chip->base + reg);
> > +}
> > +
> > +static void iproc_gpio_writel(struct iproc_gpio_chip *chip, u32 val, int 
> > reg)
> > +{
> > +   writel(val, chip->base + reg);
> > +}
> 
> These wrappers don't really add anything do they? Just inline the
> direct readl()/writel() to base + reg everywhere instead.
> 

Will do.

> > +/* returns the corresponding gpio register bit */
> > +static int iproc_irq_to_gpio(struct iproc_gpio_chip *chip, u32 irq)
> > +{
> > +   struct irq_data *data = irq_domain_get_irq_data(chip->irq_domain, 
> > irq);
> > +
> > +   return data->hwirq;
> > +}
> 
> I would name it something clearer since "gpio" is pretty ambigous.
> 
> Like iproc_irq_to_gpio_offset()
> 
> Maybe this is also a bit of unnecessary wrapper?
> 

I'll look into it. We might already have the irq_data we need so the
callers could use "pin = d->hwirq;".

> > +static irqreturn_t iproc_gpio_irq_handler(int irq, void *data)
> > +{
> > +   struct iproc_gpio_chip *chip = (struct iproc_gpio_chip *)data;
> > +   struct gpio_chip gc = chip->gc;
> > +   int bit;
> > +   unsigned long int_bits = 0;
> > +   u32 int_status;
> > +
> > +   /* go through the entire GPIOs and handle all interrupts */
> > +   int_status = readl(chip->intr + CCA_INT_STS);
> > +   if (int_status & CCA_INT_F_GPIOINT) {
> > +   u32 event, level;
> > +
> > +   /* Get level and edge interrupts */
> > +   event = readl(chip->base + GPIO_CCA_INT_EVENT_MASK);
> > +   event &= readl(chip->base + GPIO_CCA_INT_EVENT);
> > +   level = readl(chip->base + GPIO_CCA_DIN);
> > +   level ^= readl(chip->base + GPIO_CCA_INT_LEVEL);
> > +   level &= readl(chip->base + GPIO_CCA_INT_LEVEL_MASK);
> > +   int_bits = level | event;
> > +
> > +   for_each_set_bit(bit, _bits, gc.ngpio)
> > +   generic_handle_irq(
> > +   irq_linear_revmap(chip->irq_domain, bit));
> > +   }
> > +
> > +   return  int_bits ? IRQ_HANDLED : IRQ_NONE;
> > +}
> 
> I think this should be a chained interrupt handler (see below how to
> register it).
> 
> See e.g. drivers/gpio/gpio-ftgpio010.c for an example:
> change function prototype, no return value, use
> chained_irq_enter/exit(irqchip, desc); etc.
> 

I don't think a chained interrupt handler can work. The problem is that
the parent irq on the SoC is shared between the gpio and uart0 (why
it's this way with two IP blocks in the same SoC I'll never know). When
a chained interrupt handler is registered I lose the serial interrupts.
Please correct me if there is some way to make the chained handlers
deal with sharing interrupts.

> > +static int iproc_gpiolib_input(struct gpio_chip *gc, u32 gpio)
> > +static int iproc_gpiolib_output(struct gpio_chip *gc, u32 gpio, int value)
> > +static void iproc_gpiolib_set(struct gpio_chip *gc, u32 gpio, int value)
> > +static int iproc_gpiolib_get(struct gpio_chip *gc, u32 gpio)
> 
> These callbacks seems to reimplement parts of GPIO_GENERIC
> that you should already be using.
> 
> Again look at drivers/gpio/gpio-ftgpio010.c() use bgpio_init()
> to set up the library callbacks, look in
> drivers/gpio/gpio-mmio.c for kerneldoc on the function.
> 

Will look into it.

> > +static int iproc_gpiolib_to_irq(struct gpio_chip *gc, u32 offset)
> > +{
> > +   struct iproc_gpio_chip *chip = gpiochip_get_data(gc);
> > +
> > +   return irq_linear_revmap(chip->irq_domain, offset);
> > +}
> 
> GPIOLIB_IRQCHIP provides a .to_irq() implementation
> so drop this and let the library handle this.
> 

Will that work if I've squirreled the irq_domain away in struct
iproc_gpio_chip? See above as to why I'm not using the embedded
gpio_irq_chip.

> > +static int iproc_gpio_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct device_node *dn = pdev->dev.of_node;
> > +   struct iproc_gpio_chip *chip;
> > +   u32 num_gpios;
> > +   

[PATCH] 8250-men-mcb: fix error checking when get_num_ports returns -ENODEV

[Colin King]

From: Colin Ian King 

The current checking for failure on the number of ports fails when
-ENODEV is returned from the call to get_num_ports. Fix this by making
num_ports and loop counter i signed rather than unsigned ints. Also
add check for num_ports being less than zero to check for -ve error
returns.

Addresses-Coverity: ("Unsigned compared against 0")
Fixes: e2fea54e4592 ("8250-men-mcb: add support for 16z025 and 16z057")
Signed-off-by: Colin Ian King 
---
 drivers/tty/serial/8250/8250_men_mcb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_men_mcb.c 
b/drivers/tty/serial/8250/8250_men_mcb.c
index 02c5aff58a74..8df89e9cd254 100644
--- a/drivers/tty/serial/8250/8250_men_mcb.c
+++ b/drivers/tty/serial/8250/8250_men_mcb.c
@@ -72,8 +72,8 @@ static int serial_8250_men_mcb_probe(struct mcb_device *mdev,
 {
struct serial_8250_men_mcb_data *data;
struct resource *mem;
-   unsigned int num_ports;
-   unsigned int i;
+   int num_ports;
+   int i;
void __iomem *membase;
 
mem = mcb_get_resource(mdev, IORESOURCE_MEM);
@@ -88,7 +88,7 @@ static int serial_8250_men_mcb_probe(struct mcb_device *mdev,
dev_dbg(>dev, "found a 16z%03u with %u ports\n",
mdev->id, num_ports);
 
-   if (num_ports == 0 || num_ports > 4) {
+   if (num_ports <= 0 || num_ports > 4) {
dev_err(>dev, "unexpected number of ports: %u\n",
num_ports);
return -ENODEV;
@@ -133,7 +133,7 @@ static int serial_8250_men_mcb_probe(struct mcb_device 
*mdev,
 
 static void serial_8250_men_mcb_remove(struct mcb_device *mdev)
 {
-   unsigned int num_ports, i;
+   int num_ports, i;
struct serial_8250_men_mcb_data *data = mcb_get_drvdata(mdev);
 
if (!data)
-- 
2.20.1

Re: [GIT PULL] tracing: Fixes for v5.4-rc2

[pr-tracker-bot]

The pull request you sent on Sun, 13 Oct 2019 15:07:02 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> trace-v5.4-rc2

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

Thank you!

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

Re: clk: rockchip: Checking a kmemdup() call in rockchip_clk_register_pll()

[Heiko Stuebner]

Am Sonntag, 13. Oktober 2019, 10:45:09 CEST schrieb Markus Elfring:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/rockchip/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n913
> >> https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/rockchip/clk-pll.c#L913
> >>
> >> * Do you find the usage of the format string “%s: could not allocate
> >>   rate table for %s\n” still appropriate at this place?
> >
> > If there is an internal "no-memory" output from inside kmemdup now,
> > I guess the one in the clock driver would be a duplicate and could go away.
> 
> How do you think about to recheck information sources around
> the Linux allocation failure report?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=da94001239cceb93c132a31928d6ddc4214862d5#n878
> 
> 
> >> * Is there a need to adjust the error handling here?
> >
> > There is no need for additional error handling.
> 
> If you would like to omit the macro call “WARN”, I would expect also
> to express a corresponding null pointer check.

So I guess we want something like the change at the bottom.


> > Like if the rate-table could not be duplicated,
> > the clock will still report the correct clockrate
> > you can just not set a new rate.
> 
> How much will a different system configuration matter finally?
> (Do you really want to treat this setting as “optional”?)
> 
> > And for a system it's always better to have the clock driver present
> > than for all device-drivers to fail probing. Especially as this start as
> > core clock driver, so there is no deferring possible.
> 
> I imagine that such a view can be clarified further.

The core soc clock driver gets initialized through CLK_OF_DECLARE(),
aka real early during boot. So if the kmemdup fails there can not be
any -EPROBE_DEFER, as there is no kernel-driver-model running yet.

All other components of the system of course depend on the clock-
controller being available, so that way the system can at least come
up further so that people might be able to debug their issue further.

The other option would be to panic, but the kernel should not
panic if other options are available - and continuing with a static
pll frequency is less invasive in the error case.

Heiko

-- 8< ---
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 198417d56300..17bfac611e79 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -909,14 +909,16 @@ struct clk *rockchip_clk_register_pll(struct 
rockchip_clk_provider *ctx,
for (len = 0; rate_table[len].rate != 0; )
len++;
 
-   pll->rate_count = len;
pll->rate_table = kmemdup(rate_table,
pll->rate_count *
sizeof(struct rockchip_pll_rate_table),
GFP_KERNEL);
-   WARN(!pll->rate_table,
-   "%s: could not allocate rate table for %s\n",
-   __func__, name);
+
+   /*
+* Set num rates to 0 if kmemdup fails. That way the clock
+* at least can report its rate and stays usable.
+*/
+   pll->rate_count = pll->rate_table ? len : 0;
}
 
switch (pll_type) {