Re: [PATCH 2/2] mmc: sdhci-iproc: Set NO_HISPD bit to fix HS50 data hold time problem

[Adrian Hunter]

On 8/05/19 1:46 AM, Scott Branden wrote:
> Hi Adrian,
> 
> On 2019-05-06 11:31 p.m., Adrian Hunter wrote:
>> On 6/05/19 8:01 PM, Scott Branden wrote:
>>> From: Trac Hoang 
>>>
>>> The iproc host eMMC/SD controller hold time does not meet the
>>> specification in the HS50 mode.  This problem can be mitigated
>>> by disabling the HISPD bit; thus forcing the controller output
>>> data to be driven on the falling clock edges rather than the
>>> rising clock edges.
>>>
>>> Fixes: f5f968f2371c ("mmc: sdhci-iproc: suppress spurious interrupt with
>>> Multiblock read")
>> Is this fixes tag correct, because it doesn't seem related.  Maybe explain
>> that in the commit message.
> 
> I chose this tag to assist stable kernel maintainers so that the change does
> not produce merge conflicts backporting to older kernel versions.
> 
> In reality, the timing bug existed since the driver was first introduced but
> there is no need for this driver to be supported in kernel versions that old.

You don't need to use the Fixes tag for that.  You can put it on the Cc line
e.g.

Cc: sta...@vger.kernel.org # v4.12+

> Do you want me to add such to the commit message?

Yes please.

> 
>>
>>> Signed-off-by: Trac Hoang 
>>> Signed-off-by: Scott Branden 
>>> ---
>>>   drivers/mmc/host/sdhci-iproc.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
>>> index 9d4071c41c94..2feb4ef32035 100644
>>> --- a/drivers/mmc/host/sdhci-iproc.c
>>> +++ b/drivers/mmc/host/sdhci-iproc.c
>>> @@ -220,7 +220,8 @@ static const struct sdhci_iproc_data
>>> iproc_cygnus_data = {
>>>     static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
>>>   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
>>> -  SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
>>> +  SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 |
>>> +  SDHCI_QUIRK_NO_HISPD_BIT,
>>>   .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
>>>   .ops = _iproc_ops,
>>>   };
>>>
> 

Re: [PATCH v5 09/12] soc: mediatek: cmdq: add polling function

[CK Hu]

Hi, Bibby:

On Tue, 2019-05-07 at 16:13 +0800, Bibby Hsieh wrote:
> add polling function in cmdq helper functions

Reviewed-by: CK Hu 

> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   | 29 
>  include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
>  include/linux/soc/mediatek/mtk-cmdq.h| 15 
>  3 files changed, 45 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 17ee8196fb3d..716f8c4f207b 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -220,6 +220,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_clear_event);
>  
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> +   u16 offset, u32 value, u32 mask)
> +{
> + struct cmdq_instruction *inst;
> +
> + if (mask != 0x) {
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_MASK;
> + inst->value = ~mask;
> + offset = offset | 0x1;
> + }
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_POLL;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_pkt_poll);
> +
>  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction *inst;
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index f21801d32a3a..1dfd5ed5c8c5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -46,6 +46,7 @@
>  enum cmdq_code {
>   CMDQ_CODE_MASK = 0x02,
>   CMDQ_CODE_WRITE = 0x04,
> + CMDQ_CODE_POLL = 0x08,
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 52f69c8db8de..0651a0bffa54 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
>   */
>  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>  
> +/**
> + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> + *execute an instruction that wait for a specified hardware
> + *register to check for the value. All GCE hardware
> + *threads will be blocked by this instruction.
> + * @pkt: the CMDQ packet
> + * @subsys:  the CMDQ sub system code
> + * @offset:  register offset from CMDQ sub system
> + * @value:   the specified target register value
> + * @mask:the specified target register mask
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> +   u16 offset, u32 value, u32 mask);
>  /**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet

Re: [PATCH v3 2/2] RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs

[Yash Shah]

On Tue, May 7, 2019 at 7:15 PM Andrew F. Davis  wrote:
>
> On 5/7/19 2:48 AM, Yash Shah wrote:
> > On Mon, May 6, 2019 at 5:48 PM Andrew F. Davis  wrote:
> >>
> >> On 5/6/19 6:48 AM, Yash Shah wrote:
> >>> The driver currently supports only SiFive FU540-C000 platform.
> >>>
> >>> The initial version of L2 cache controller driver includes:
> >>> - Initial configuration reporting at boot up.
> >>> - Support for ECC related functionality.
> >>>
> >>> Signed-off-by: Yash Shah 
> >>> ---
> >>>  arch/riscv/include/asm/sifive_l2_cache.h |  16 +++
> >>>  arch/riscv/mm/Makefile   |   1 +
> >>>  arch/riscv/mm/sifive_l2_cache.c  | 175 
> >>> +++
> >>>  3 files changed, 192 insertions(+)
> >>>  create mode 100644 arch/riscv/include/asm/sifive_l2_cache.h
> >>>  create mode 100644 arch/riscv/mm/sifive_l2_cache.c
> >>>
> >>> diff --git a/arch/riscv/include/asm/sifive_l2_cache.h 
> >>> b/arch/riscv/include/asm/sifive_l2_cache.h
> >>> new file mode 100644
> >>> index 000..04f6748
> >>> --- /dev/null
> >>> +++ b/arch/riscv/include/asm/sifive_l2_cache.h
> >>> @@ -0,0 +1,16 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/*
> >>> + * SiFive L2 Cache Controller header file
> >>> + *
> >>> + */
> >>> +
> >>> +#ifndef _ASM_RISCV_SIFIVE_L2_CACHE_H
> >>> +#define _ASM_RISCV_SIFIVE_L2_CACHE_H
> >>> +
> >>> +extern int register_sifive_l2_error_notifier(struct notifier_block *nb);
> >>> +extern int unregister_sifive_l2_error_notifier(struct notifier_block 
> >>> *nb);
> >>> +
> >>> +#define SIFIVE_L2_ERR_TYPE_CE 0
> >>> +#define SIFIVE_L2_ERR_TYPE_UE 1
> >>> +
> >>> +#endif /* _ASM_RISCV_SIFIVE_L2_CACHE_H */
> >>> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> >>> index eb22ab4..1523ee5 100644
> >>> --- a/arch/riscv/mm/Makefile
> >>> +++ b/arch/riscv/mm/Makefile
> >>> @@ -3,3 +3,4 @@ obj-y += fault.o
> >>>  obj-y += extable.o
> >>>  obj-y += ioremap.o
> >>>  obj-y += cacheflush.o
> >>> +obj-y += sifive_l2_cache.o
> >>> diff --git a/arch/riscv/mm/sifive_l2_cache.c 
> >>> b/arch/riscv/mm/sifive_l2_cache.c
> >>> new file mode 100644
> >>> index 000..4eb6461
> >>> --- /dev/null
> >>> +++ b/arch/riscv/mm/sifive_l2_cache.c
> >>> @@ -0,0 +1,175 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * SiFive L2 cache controller Driver
> >>> + *
> >>> + * Copyright (C) 2018-2019 SiFive, Inc.
> >>> + *
> >>> + */
> > [...]
> >>> +
> >>> +#ifdef CONFIG_DEBUG_FS
> >>> +static struct dentry *sifive_test;
> >>> +
> >>> +static ssize_t l2_write(struct file *file, const char __user *data,
> >>> + size_t count, loff_t *ppos)
> >>> +{
> >>> + unsigned int val;
> >>> +
> >>> + if (kstrtouint_from_user(data, count, 0, ))
> >>> + return -EINVAL;
> >>> + if ((val >= 0 && val < 0xFF) || (val >= 0x1 && val < 0x100FF))
> >>
> >> I'm guessing bit 16 is the enable and the lower 8 are some kind of
> >> region to enable the error? This is probably a bad interface, it looks
> >> useful for testing but doesn't provide any debugging info useful for
> >> running systems. Do you really want userspace to be able to do this?
> >
> > Bit 16 selects the type of ECC error (0=data or 1=directory error).
> > The lower 8 bits toggles (corrupt) that bit index.
> > Are you suggesting to remove this debug interface altogether or you
> > want me to improve the current interface?
> > Something like providing 2 separate debugfs files for data and
> > directory errors. And create a separate 8-bit debugfs variable to
> > select the bit index to toggle.
> >
>
> I was suggesting to remove the whole thing. I don't see it being all
> that useful, but it is up to you.

Thanks for the suggestion, but I will keep it as we do need it for our testing.

- Yash

Re: [GIT PULL] Devicetree for 5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 18:53:25 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
> tags/devicetree-for-5.2

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

Thank you!

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

Re: [PATCH v5 08/12] soc: mediatek: cmdq: define the instruction struct

[CK Hu]

Hi, Bibby:

On Tue, 2019-05-07 at 16:13 +0800, Bibby Hsieh wrote:
> Define a instruction structure for gce driver to append command.

I would like you to describe _WHY_ do this. I think you do this for
'code readability'.

> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   | 113 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |   2 +
>  include/linux/soc/mediatek/mtk-cmdq.h|  14 +--
>  3 files changed, 84 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index ff9fef5a032b..17ee8196fb3d 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -9,12 +9,24 @@
>  #include 
>  #include 
>  
> -#define CMDQ_ARG_A_WRITE_MASK0x
>  #define CMDQ_WRITE_ENABLE_MASK   BIT(0)
>  #define CMDQ_EOC_IRQ_EN  BIT(0)
>  #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
>   << 32 | CMDQ_EOC_IRQ_EN)
>  
> +struct cmdq_instruction {
> + union {
> + u32 value;
> + u32 mask;
> + };
> + union {
> + u16 offset;
> + u16 event;
> + };
> + u8 subsys;
> + u8 op;
> +};
> +
>  static void cmdq_client_timeout(struct timer_list *t)
>  {
>   struct cmdq_client *client = from_timer(client, t, timer);
> @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_destroy);
>  
> -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> -u32 arg_a, u32 arg_b)
> +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
>  {
> - u64 *cmd_ptr;
>  
>   if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
>   /*
> @@ -127,81 +137,108 @@ static int cmdq_pkt_append_command(struct cmdq_pkt 
> *pkt, enum cmdq_code code,
>   pkt->cmd_buf_size += CMDQ_INST_SIZE;
>   WARN_ONCE(1, "%s: buffer size %u is too small !\n",
>   __func__, (u32)pkt->buf_size);
> - return -ENOMEM;
> + return NULL;
>   }
> - cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> +
>   pkt->cmd_buf_size += CMDQ_INST_SIZE;
>  
> - return 0;
> + return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
>  }
>  
> -int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
> +int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
>  {
> - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> - (subsys << CMDQ_SUBSYS_SHIFT);
> + struct cmdq_instruction *inst;
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WRITE;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
>  
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> + return 0;
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write);
>  
> -int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
> - u32 subsys, u32 offset, u32 mask)
> +int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys, u16 offset,
> + u32 value, u32 mask)
>  {
> + struct cmdq_instruction *inst;
>   u32 offset_mask = offset;
> - int err = 0;
>  
>   if (mask != 0x) {
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_MASK;
> + inst->mask = ~mask;
>   offset_mask |= CMDQ_WRITE_ENABLE_MASK;
>   }
> - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
>  
> - return err;
> + return cmdq_pkt_write(pkt, subsys, offset_mask, value);
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>  
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>  {
> - u32 arg_b;
> + struct cmdq_instruction *inst;
>  
>   if (event >= CMDQ_MAX_EVENT)
>   return -EINVAL;
>  
> - /*
> -  * WFE arg_b
> -  * bit 0-11: wait value
> -  * bit 15: 1 - wait, 0 - no wait
> -  * bit 16-27: update value
> -  * bit 31: 1 - update, 0 - no update
> -  */
> - arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WFE;
> + inst->value = CMDQ_WFE_OPTION;
> + inst->event = event;
>  
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> + return 0;
>  }
>  EXPORT_SYMBOL(cmdq_pkt_wfe);
>  
> -int 

Re: [PATCH v5 04/12] dt-binding: gce: add binding for gce event property

[CK Hu]

Hi, Bibby:

On Tue, 2019-05-07 at 16:13 +0800, Bibby Hsieh wrote:
> Client hardware would send event to GCE hardware,
> mediatek,gce-event-names and mediatek,gce-events
> can be used to present the event.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt 
> b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> index 8fd9479bc9f6..76491f194c56 100644
> --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> @@ -35,6 +35,9 @@ Required properties for a client device:
>  Optional propertier for a client device:
>  - mediatek,gce-client-reg: u32, specify the sub-system id which is 
> corresponding
>to the register address.
> +- mediatek,gce-event-names: the event name can be defined by user.

gce-event is like an interrupt from client hardware to GCE hardware, we
do not give a name to an interrupt, so do we need to give a name for
gce-event?

Regards,
CK

> +- mediatek,gce-events: u32, the event number defined in
> +  'dt-bindings/gce/mt8173-gce.h' or 'dt-binding/gce/mt8183-gce.h'.
>  
>  Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
>  or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, 
> event ids.
> @@ -57,8 +60,10 @@ Example for a client device:
>   compatible = "mediatek,mt8173-mmsys";
>   mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>,
>< 1 CMDQ_THR_PRIO_LOWEST 1>;
> - mutex-event-eof =  - CMDQ_EVENT_MUTEX1_STREAM_EOF>;
> + mediatek,gce-event-names = "rdma0_sof",
> +"rsz0_sof";
> + mediatek,gce-events = ,
> +   ;
>   mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>,
> < SUBSYS_1401 0x2000 0x100>;
>   ...

Re: [PATCH 1/8] soundwire: intel: filter SoundWire controller device search

[Vinod Koul]

On 07-05-19, 09:43, Pierre-Louis Bossart wrote:
> 
> 
> On 5/7/19 7:26 AM, Vinod Koul wrote:
> > On 03-05-19, 19:29, Pierre-Louis Bossart wrote:
> > > The convention is that the SoundWire controller device is a child of
> > > the HDAudio controller. However there can be more than one child
> > > exposed in the DSDT table, and the current namespace walk returns the
> > > last device.
> > > 
> > > Add a filter and terminate early when a valid _ADR is provided,
> > > otherwise keep iterating to find the next child.
> > 
> > So what are the other devices in DSDT here..
> 
> this is what I see:
> 
> Scope (HDAS)
> {
> Device (IDA)
> {
> Name (_ADR, 0x00020001)  // _ADR: Address
> }
> }
> 
> I thought this was nonsense but your question triggered me to look into the
> Intel SST ACPI specs (not public I am afraid but shared with the OS who
> shall not be named).
> Using the same source of information as below, I *believe* this is HDaudio
> related, bits 31..16 mean HDaudio with codec SDI 2, and NodeId 1 for the
> function group. This would make sense as I believe there are two codecs on
> the board that can be pin-strapped to boot either in HDaudio or SoundWire
> mode- but this is a conjecture only.
> 
> At any rate, we need a hardware rework and mutual exclusion between HDaudio
> and SoundWire, so we have to ignore this one when SoundWire is enabled.

That is how I was expecting it to be...

> > > + /*
> > > +  * On some Intel platforms, multiple children of the HDAS
> > > +  * device can be found, but only one of them is the SoundWire
> > > +  * controller. The SNDW device is always exposed with
> > > +  * Name(_ADR, 0x4000) so filter accordingly
> > > +  */
> > > + if (adr != 0x4000)
> > 
> > I do not recall if 4 corresponds to the links you have or soundwire
> > device type, is this number documented somewhere is HDA specs?
> 
> I thought it was a magic number, but I did check and for once it's
> documented and the values match the spec :-)
> I see in the ACPI docs bits 31..28 set to 4 indicate a SoundWire Link Type
> and bits 3..0 indicate the SoundWire controller instance, the rest is
> reserved to zero.

So in that case we should mask with bits 31..28 and match, who knows you
may have multiple controller instances in future
I had a vague recollection that this was documented in the spec, glad
that in turned out to be the case.

Btw was the update to HDA spec made public?

> > Also it might good to create a define for this
> 
> I will respin this one to add the documentation above, and only filter on
> the 4 ms-bits. Thanks for forcing me to RTFM :-)

-- 
~Vinod

Re: linux-next: manual merge of the char-misc tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

On Tue, 30 Apr 2019 17:40:51 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the char-misc tree got conflicts in:
> 
>   drivers/misc/Kconfig
>   drivers/misc/Makefile
> 
> between commit:
> 
>   524feb799408 ("soc: add aspeed folder and misc drivers")
> 
> from the arm-soc tree and commit:
> 
>   01c60dcea9f7 ("drivers/misc: Add Aspeed P2A control driver")
> 
> from the char-misc tree.
> 
> I fixed it up (see below - though the additions probably want to be
> moved as in the arm-soc commit) 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 drivers/misc/Kconfig
> index b80cb6af0cb4,3209ee020b15..
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@@ -496,6 -496,30 +496,14 @@@ config VEXPRESS_SYSCF
> bus. System Configuration interface is one of the possible means
> of generating transactions on this bus.
>   
> + config ASPEED_P2A_CTRL
> + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> + tristate "Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC bridge control"
> + help
> +   Control Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC mappings through
> +   ioctl()s, the driver also provides an interface for userspace 
> mappings to
> +   a pre-defined region.
> + 
>  -config ASPEED_LPC_CTRL
>  -depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
>  -tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
>  ----help---
>  -  Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
>  -  ioctl()s, the driver also provides a read/write interface to a BMC ram
>  -  region where the host LPC read/write region can be buffered.
>  -
>  -config ASPEED_LPC_SNOOP
>  -tristate "Aspeed ast2500 HOST LPC snoop support"
>  -depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
>  -help
>  -  Provides a driver to control the LPC snoop interface which
>  -  allows the BMC to listen on and save the data written by
>  -  the host to an arbitrary LPC I/O port.
>  -
>   config PCI_ENDPOINT_TEST
>   depends on PCI
>   select CRC32
> diff --cc drivers/misc/Makefile
> index b9affcdaa3d6,c36239573a5c..
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@@ -54,6 -54,9 +54,7 @@@ obj-$(CONFIG_GENWQE)+= genwqe
>   obj-$(CONFIG_ECHO)  += echo/
>   obj-$(CONFIG_VEXPRESS_SYSCFG)   += vexpress-syscfg.o
>   obj-$(CONFIG_CXL_BASE)  += cxl/
>  -obj-$(CONFIG_ASPEED_LPC_CTRL)   += aspeed-lpc-ctrl.o
>  -obj-$(CONFIG_ASPEED_LPC_SNOOP)  += aspeed-lpc-snoop.o
> + obj-$(CONFIG_ASPEED_P2A_CTRL)   += aspeed-p2a-ctrl.o
>   obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
>   obj-$(CONFIG_OCXL)  += ocxl/
>   obj-y   += cardreader/

This is now a conflict between the arm-soc tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpfMyNIJ6qAY.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 0/3] tracing: probeevent: Fix probe argument parser and handler

[Masami Hiramatsu]

On Tue, 7 May 2019 22:10:06 -0400
Steven Rostedt  wrote:

> On Tue,  7 May 2019 22:55:22 +0900
> Masami Hiramatsu  wrote:
> 
> > Hi,
> > 
> > Here is the 3rd version of series to fix several bugs in probe event
> > argument parser and handler routines.
> > 
> > In this version I updated patch [1/3] according to Steve's comment.
> > 
> > 
> > I got 2 issues reported by Andreas, see
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1899098.html
> > 
> > One issue is already fixed by Andreas (Thanks!) but $comm handling
> > issue still exists on uprobe event. [1/3] fixes it.
> > And I found other issues around that, [2/3] is just a trivial cleanup,
> > [3/3] fixes $comm type issue which occurs not only uprobe events but
> > also on kprobe events. Anyway, after this series applied, $comm must
> > be "string" type and not be an array.
> >
> 
> Thanks Masami,
> 
> I applied these to my queue.

Thank you, Steve! I'll rebase other series on that.



-- 
Masami Hiramatsu 

Re: [git pull] vfs.git next bits of mount ABI stuff (syscalls, this time)

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 21:49:21 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.mount-syscalls

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

Thank you!

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

Re: [GIT PULL] fscrypt updates for 5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 19:30:42 -0400:

> git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt_for_linus

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

Thank you!

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

Re: [git pull] vfs.git misc pieces

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 21:53:19 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc

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

Thank you!

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

Re: [GIT PULL] ext4 changes for 5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 19:28:23 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
> tags/ext4_for_linus

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

Thank you!

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

Re: [GIT PULL] AFS fixes and development

[pr-tracker-bot]

The pull request you sent on Tue, 07 May 2019 21:11:17 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
> tags/afs-next-20190507

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

Thank you!

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

Re: [GIT PULL] random changes for 5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 19:32:08 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git 
> tags/random_for_linus

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

Thank you!

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

Re: [git pull] vfs.git several struct file-related pieces

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 21:52:09 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.file

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

Thank you!

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

Re: [git pull] vfs.git misc dcache-related stuff

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 21:33:55 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache

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

Thank you!

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

Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions

[Linus Torvalds]

On Tue, May 7, 2019 at 2:24 PM Steven Rostedt  wrote:
>
> And there's been several times I forget that regs->sp can not be read
> directly. Especially most of my bug reports are for x86_64 these days.
> But when I had that seldom x86_32 one, and go debugging, I would print
> out "regs->sp" and then the system would crash. And I spend some time
> wondering why?
>
> It's been a bane of mine for some time.

Guys, I have basically a one-liner patch for your hangups.

It's called "rename 'sp' to 'user_sp' on x86-32".

Then we make the 'sp' field on x86-64 be a union, so that you can call
it user_sp or sp as you wish.

Yeah, it's really more than one line, because obviously the users will
need chaning, but honestly, that would be a _real_ cleanup. Make the
register match what it actually is.

And it doesn't mess up the stack frame, and it doesn't change the
entry code. It just reminds people that the entry is the USER stack
pointer.

Problem solved.

   Linus

Re: [PATCH 1/2] x86/boot: move early_serial_base to .data section

[Pingfan Liu]

On Tue, May 7, 2019 at 4:28 PM Ingo Molnar  wrote:
>
>
> * Pingfan Liu  wrote:
>
> > arch/x86/boot/compressed/head_64.S clears BSS after relocated. If early
> > serial is set up before clearing BSS, the early_serial_base will be reset
> > to 0.
> >
> > Initializing early_serial_base as -1 to push it to .data section.
>
> I'm wondering whether it's wise to clear the BSS after relocation to
> begin with. It already gets cleared once, and an implicit zeroing of all
> fields on kernel relocation sounds dubious to me.
>
After reading the code more closely, I think that the BSS is not fully
initialized to 0, exception the stack and heap.

Furthermore the BSS is not copied to the target address. We just copy [0, _bss).
> Is there a strong reason for that? I.e. is there some uninitialized or
> otherwise important-to-clear data there?
>
I guess the reason may be stack or heap can contain some position
dependent data. (While in practice, there is no such kind of data in
the code now days)

Thanks,
Pingfan

Re: Fwd: linux-next: build failure after merge of the kbuild tree

[Masahiro Yamada]

Hi Paul,


On Mon, May 6, 2019 at 11:23 PM Paul Gortmaker
 wrote:
>
> [Re: Fwd: linux-next: build failure after merge of the kbuild tree] On 
> 06/05/2019 (Mon 21:07) Masahiro Yamada wrote:
>
> > Hi Paul,
> >
> >
> > On Mon, May 6, 2019 at 12:34 PM Paul Gortmaker
> >  wrote:
> > >
> > > [Fwd: linux-next: build failure after merge of the kbuild tree] On 
> > > 06/05/2019 (Mon 11:19) Masahiro Yamada wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > In today's linux-next build testing,
> > > > more "make ... explicitly non-modular"
> > > > candidates showed up.
> > > >
> > >
> > > Hi Masahiro,
> > >
> > > I am not 100% clear on what you are asking me.  There are lots and lots
> > > of these in the kernel many fixed, and many remain unfortunately.
> > >
> > > > arch/arm/plat-omap/dma.c
> > > > drivers/clocksource/timer-ti-dm.c
> > > > drivers/mfd/omap-usb-host.c
> > > > drivers/mfd/omap-usb-tll.c
> > >
> > > None of these are "new".  I just checked, and I have had patches for all
> > > these for a long time, in my personal queue, found by my audits.
> >
> >
> > OK, I saw many patches from you
> > addressing this issue,
> > so I just thought you might be motivated to
> > fix them.
> >
> > Anyway, I have a reason to fix them
> > because a patch in my tree is causing build errors.
>
> I understand now.  I missed the connection between these drivers and the
> Kbuild change when I read this last night.  Sorry about that.
>
> I can send the changes to those four files, but since I can't guarantee
> they will be merged quickly (or at all!) - that will leave the commit in
> the Kbuild tree causing build regressions for days or likely even weeks.
>
> > So, I will do something for them
> > if you do not have a plan to send patches soon.
>
> I will be happy to send them, but we just opened the two week merge
> window, and a lot of maintainers don't like getting sent new patches
> until the two week merge window has closed - so we should avoid that.
>
> I'm not sure how you would like to proceed - one way would be that we
> get the drivers above changed in 5.2 and you delay your kbuild change
> until we start v5.3 - to that end I'd be happy to add the Kbuild change
> to my internal build testing in the meantime, if you would like.
>
> Now that I understand the problem, let me know what you would like to
> do, and I'll do what I can to help out.


I decided to merge minimal changes to my kbuild tree
since I did not want to delay the kbuild patch.

I got some Ack tags, so I applied this patch:
https://patchwork.kernel.org/patch/10931673/

I appreciate if you could fix those files in a complete way,
but there is no more reason to rush.



> Thanks,
> Paul.




--
Best Regards
Masahiro Yamada

Re: [PATCH 0/3] x86_64/ftrace: Emulate calls from int3 when patching functions

[Masami Hiramatsu]

On Tue, 07 May 2019 21:55:59 -0400
Steven Rostedt  wrote:

> 
> [
>   This is the non-RFC version.
> 
>   It went through and passed all my tests. If there's no objections
>   I'm going to include this in my pull request. I still have patches
>   in my INBOX that may still be included, so I need to run those through
>   my tests as well, so a pull request wont be immediate.
> ]
> 
> Nicolai Stange discovered that Live Kernel Patching can have unforseen
> consequences if tracing is enabled when there are functions that are
> patched. The reason being, is that Live Kernel patching is built on top
> of ftrace, which will have the patched functions call the live kernel
> trampoline directly, and that trampoline will modify the regs->ip address
> to return to the patched function.
> 
> But in the transition between changing the call to the customized
> trampoline, the tracing code is needed to have its handler called
> an well, so the function fentry location must be changed from calling
> the live kernel patching trampoline, to the ftrace_reg_caller trampoline
> which will iterate through all the registered ftrace handlers for
> that function.
> 
> During this transition, a break point is added to do the live code
> modifications. But if that break point is hit, it just skips calling
> any handler, and makes the call site act as a nop. For tracing, the
> worse that can happen is that you miss a function being traced, but
> for live kernel patching the affects are more severe, as the old buggy
> function is now called.
> 
> To solve this, an int3_emulate_call() is created for x86_64 to allow
> ftrace on x86_64 to emulate the call to ftrace_regs_caller() which will
> make sure all the registered handlers to that function are still called.
> And this keeps live kernel patching happy!

Out of curiosity, would you have any idea to re-use these function for
other use-case? Maybe kprobes can reuse it, but very limited use-case.

> To mimimize the changes, and to avoid controversial patches, this
> only changes x86_64. Due to the way x86_32 implements the regs->sp
> the complexity of emulating calls on that platform is too much for
> stable patches, and live kernel patching does not support x86_32 anyway.

This series looks good to me.

Reviewed-by: Masami Hiramatsu 

Thanks!

-- 
Masami Hiramatsu 

Re: [PATCH] cgroup: Fix low cpu usage with high throttling by removing slice expiration

[Dave Chiluk]

I'd really appreciate some attention on this.  Should I have marked
the subject as sched: instead?

I heard through some back-channels that there may be concern with the
ability to use more cpu than allocated in a given period.  To that I
say,
#1 The current behavior of an application hitting cpu throttling while
simultaneously accounting for much less cpu time than was allocated is
a very poor user experience. i.e. granted .5 cpu, but only used .1 cpu
while simultaneously hitting throttling.
#2 This has been broken like this since at least 3.16-rc1 which is why
I ripped out most of the logic instead of trying to patch it again.  I
proved this experimentally by adding a counter in
expire_cfs_rq_runtime when runtime is expired.  I can share the
patches if that would help.  That means that user-interactive
applications have been able to over-use quota in a similar manner
since June 2014, and no one has noticed or complained.  Now that the
mechanism is "fixed" people are starting to notice and they are
complaining loudly.  See
https://github.com/kubernetes/kubernetes/issues/67577 and the many
linked tickets to that one.
#3 Even though it's true that you can use more cpu than allocated in a
period, that would require that you under-use quota in previous
periods equal to the overage.  In effect you are still enforcing the
quota requirements albeit over longer time-frames than cfs_period_us
*(I'm amenable to a documentation update to fix this nuance).
Additionally any single cpu run queue can only over-use by as much as
sched_cfs_bandwidth_slice_us which defaults to 5ms.  So other
applications on the same processor will at most be hindered by that
amount.
#4 cpu-bound applications will not be able to over-use in any period,
as the entirety of their quota will be consumed every period.

Your review would be much appreciated.
Thank you,
Dave


On Wed, Apr 10, 2019 at 5:21 PM Dave Chiluk  wrote:
>
> It has been observed, that highly-threaded, non-cpu-bound applications
> running under cpu.cfs_quota_us constraints can hit a high percentage of
> periods throttled while simultaneously not consuming the allocated
> amount of quota.  This use case is typical of user-interactive non-cpu
> bound web services, such as those running in kubernetes or mesos.
>
> This has been root caused to threads being allocated per cpu bandwidth
> slices, and then not fully using that slice within the period, and then
> having that quota expire.  This constant expiration of unused quota
> results applications not being able to utilize the quota for which they
> are allocated.
>
> The expiration of quota was recently fixed by commit 512ac999d275
> ("sched/fair: Fix bandwidth timer clock drift condition"). Prior to that
> it appears that this has been broken since a least commit 51f2176d74ac
> ("sched/fair: Fix unlocked reads of some cfs_b->quota/period") which was
> introduced in v3.16-rc1 in 2014.  That commit added the following
> testcase which resulted in runtime never being expired.
>
> if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
> /* extend local deadline, drift is bounded above by 2 ticks */
> cfs_rq->runtime_expires += TICK_NSEC;
>
> Because this was broken for nearly 5 years, and has recently been fixed
> and is now being noticed by many users running kubernetes
> (https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
> that the mechanisms around expiring runtime should be removed
> altogether.
>
> This allows quota runtime slices allocated to per-cpu runqueues to live
> longer than the period boundary.  This allows threads on runqueues that
> do not use much CPU to continue to use their remaining slice over a
> longer period of time than cpu.cfs_period_us. However, this helps
> prevents the above condition of hitting throttling while also not fully
> utilizing your cpu quota.
>
> This theoretically allows a machine to use slightly more than it's
> allotted quota in some periods.  This overflow would be equal to the
> amount of quota that was left un-used on cfs_rq's in the previous
> period.  For CPU bound tasks this will change nothing, as they should
> theoretically fully utilize all of their quota in each period. For
> user-interactive tasks as described above this provides a much better
> user/application experience as their cpu utilization will more closely
> match the amount they requested when they hit throttling.
>
> This greatly improves performance of high-thread-count, interactive
> applications with low cfs_quota_us allocation on high-core-count
> machines. In the case of an artificial testcase, this performance
> discrepancy has been observed to be almost 30x performance improvement,
> while still maintaining correct cpu quota restrictions albeit over
> longer time intervals than cpu.cfs_period_us.
>
> Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
> Signed-off-by: Dave Chiluk 
> ---
>  kernel/sched/fair.c  | 71 
> 

Re: [RFC PATCH v6 4/6] tracing/probe: Support user-space dereference

[Masami Hiramatsu]

On Mon, 6 May 2019 11:52:26 -0400
Steven Rostedt  wrote:

> On Mon, 18 Mar 2019 15:43:52 +0900
> Masami Hiramatsu  wrote:
> 
> > +.. _user_mem_access:
> > +User Memory Access
> > +--
> > +Kprobe events supports user-space memory access. For that purpose, you can 
> > use
> > +either user-space dereference syntax or 'ustring' type.
> > +
> > +The user-space dereference syntax allows you to access a field of a data
> > +structure in user-space. This is done by adding the "u" prefix to the
> > +dereference syntax. For example, +u4(%si) means it will read memory from 
> > the
> > +address in the register %si offset by 4, and the mory is expected to be in
> 
> 
>  "memory"

OK, thanks!

> 
> > +user-space. You can use this for strings too, e.g. +u0(%si):string will 
> > read
> > +a string from the address in the register %si that is expected to be in 
> > user-
> > +space. 'ustring' is a shortcut way of performing the same task. That is,
> > ++0(%si):ustring is equivalent to +u0(%si):string.
> > +
> > +Note that kprobe-event provides the user-memory access syntax but it 
> > doesn't
> > +use it transparently. This means if you use normal dereference or string 
> > type
> > +for user memory, it might fail, and always fails on some arch. So user has 
> > to
> 
>   "and may always fail on some archs. The user has to carefully check
>   if the target data is in kernel or user space."

OK. I'll update.

> > +check if the targe data is in kernel or in user space carefully.
> >  
> >  Per-Probe Event Filtering
> >  -
> > diff --git a/Documentation/trace/uprobetracer.rst 
> > b/Documentation/trace/uprobetracer.rst
> > index 4346e23e3ae7..de8812c932bc 100644
> > --- a/Documentation/trace/uprobetracer.rst
> > +++ b/Documentation/trace/uprobetracer.rst
> > @@ -42,16 +42,17 @@ Synopsis of uprobe_tracer
> > @+OFFSET: Fetch memory at OFFSET (OFFSET from same file as PATH)
> > $stackN : Fetch Nth entry of stack (N >= 0)
> > $stack  : Fetch stack address.
> > -   $retval : Fetch return value.(*)
> > +   $retval : Fetch return value.(\*1)
> > $comm   : Fetch current task comm.
> > -   +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
> > +   +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS 
> > address.(\*2)(\*3)
> > NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
> > FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic 
> > types
> >(u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types
> >(x8/x16/x32/x64), "string" and bitfield are supported.
> 
> Hmm, shouldn't uprobes default to userspace. Isn't the purpose mostly
> to find out what's going on in userspace. Perhaps we should add a 'k'
> annotation to uprobes to denote that it's for kernel space, as that
> should be the exception and not the norm.

No, uprobe can not access kernel space, because it doesn't have the
current kernel context. Note that all registers, stacks which
can be accessed from uprobe handler are user-space. We can not access
kernel context from that. See below

> > -  (*) only for return probe.
> > -  (**) this is useful for fetching a field of data structures.
> > +  (\*1) only for return probe.
> > +  (\*2) this is useful for fetching a field of data structures.
> > +  (\*3) Unlike kprobe event, "u" prefix will just be ignored.

Thus the 'u' is just ignored on uprobe event.

> >  
> >  Types
> >  -
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 7a6ed76ba104..b595d5ef099a 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> > @@ -4815,10 +4815,11 @@ static const char readme_msg[] =
> > "\t args: =fetcharg[:type]\n"
> > "\t fetcharg: %, @, @[+|-],\n"
> >  #ifdef CONFIG_HAVE_FUNCTION_ARG_ACCESS_API
> > -   "\t   $stack, $stack, $retval, $comm, $arg\n"
> > +   "\t   $stack, $stack, $retval, $comm, $arg,\n"
> >  #else
> > -   "\t   $stack, $stack, $retval, $comm\n"
> > +   "\t   $stack, $stack, $retval, $comm,\n"
> >  #endif
> > +   "\t   +|-[u]()\n"
> > "\t type: s8/16/32/64, u8/16/32/64, x8/16/32/64, string, symbol,\n"
> > "\t   b@/, ustring,\n"
> > "\t   \\[\\]\n"
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index e346229ddbba..9456f4ca3b8a 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -930,6 +930,12 @@ probe_mem_read(void *dest, void *src, size_t size)
> > return probe_kernel_read(dest, src, size);
> >  }
> >  
> > +static nokprobe_inline int
> > +probe_mem_read_user(void *dest, void *src, size_t size)
> > +{
> > +   return probe_user_read(dest, src, size);
> > +}
> > +
> >  /* Note that we don't verify it, since the code does not come from user 
> > space */
> >  static int
> >  process_fetch_insn(struct fetch_insn *code, 

Re: linux-next: Signed-off-by missing for commit in the cifs tree

[Steve French]

fixed

On Tue, May 7, 2019 at 4:32 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> Commit
>
>   b00c40f57bd5 ("cifs: fix strcat buffer overflow and reduce raciness in 
> smb21_set_oplock_level()")
>
> is missing a Signed-off-by from its author.
>
> Actually it looks like you were just tripped up by the mailing list's
> DMARC workaround.  :-(
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

Re: linux-next: manual merge of the staging tree with the imx-mxs tree

[Stephen Rothwell]

Hi all,

On Fri, 12 Apr 2019 14:49:21 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> between commit:
> 
>   189733b0a7e4 ("dt-bindings: Add vendor prefix for Rakuten Kobo, Inc.")
> 
> from the imx-mxs tree and commit:
> 
>   2e5cee6c7622 ("dt-bindings: Add vendor prefix for Kionix, Inc.")
> 
> from the staging 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 Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f2b185a04e6,93753f447c20..
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@@ -211,7 -210,7 +211,8 @@@ kiebackpeterKieback & Peter Gmb
>   kinetic Kinetic Technologies
>   kingdisplay King & Display Technology Co., Ltd.
>   kingnovel   Kingnovel Technology Co., Ltd.
> + kionix  Kionix, Inc.
>  +koboRakuten Kobo Inc.
>   koe Kaohsiung Opto-Electronics Inc.
>   kosagi  Sutajio Ko-Usagi PTE Ltd.
>   kyo Kyocera Corporation

This is now a conflict between the arm-soc tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpe481OxJ2wU.pgp
Description: OpenPGP digital signature

Re: [PATCH] fix use-after-free in perf_sched__lat

[liwei (GF)]

Hi Jiri，
Thanks for your reply.

On 2019/5/7 16:51, Jiri Olsa wrote:
> On Fri, May 03, 2019 at 10:35:55AM +0800, Wei Li wrote:
>> After thread is added to machine->threads[i].dead in
>> __machine__remove_thread, the machine->threads[i].dead is freed
>> when calling free(session) in perf_session__delete(). So it get a
>> Segmentation fault when accessing it in thread__put().
>>
>> In this patch, we delay the perf_session__delete until all threads
>> have been deleted.
>>
>> This can be reproduced by following steps:
>>  ulimit -c unlimited
>>  export MALLOC_MMAP_THRESHOLD_=0
> 
> what's this for?

When we set env "MALLOC_MMAP_THRESHOLD_=0"，the memory-allocation functions 
employ
mmap instead of increasing the program break using sbrk what may be maintained
with cache. Thus it can report "Segmentation fault" immediately when going into
this use-after-free code.

> 
>>  perf sched record sleep 10
>>  perf sched latency --sort max
>>  Segmentation fault (core dumped)
>>
>> Signed-off-by: Zhipeng Xie 
>> Signed-off-by: Wei Li 
>> ---
>>  tools/perf/builtin-sched.c | 44 --
>>  1 file changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
>> index cbf39dab19c1..17849ae2eb1e 100644
>> --- a/tools/perf/builtin-sched.c
>> +++ b/tools/perf/builtin-sched.c
>> @@ -3130,11 +3130,48 @@ static void perf_sched__merge_lat(struct perf_sched 
>> *sched)
>>  static int perf_sched__lat(struct perf_sched *sched)
>>  {
>>  struct rb_node *next;
>> +const struct perf_evsel_str_handler handlers[] = {
>> +{ "sched:sched_switch",   process_sched_switch_event, },
>> +{ "sched:sched_stat_runtime", process_sched_runtime_event, },
>> +{ "sched:sched_wakeup",   process_sched_wakeup_event, },
>> +{ "sched:sched_wakeup_new",   process_sched_wakeup_event, },
>> +{ "sched:sched_migrate_task", process_sched_migrate_task_event, 
>> },
>> +};
>> +struct perf_session *session;
>> +struct perf_data data = {
>> +.file  = {
>> +.path = input_name,
>> +},
> 
> I can't compile this:
> 
> builtin-sched.c: In function ‘perf_sched__lat’:
> builtin-sched.c:3144:12: error: initialization discards ‘const’ qualifier 
> from pointer target type [-Werror=discarded-qualifiers]
> .path = input_name,
> 
Sorry, this place has been changed recently in mainline code, i will update to
the latest code.

> 
>> +.mode  = PERF_DATA_MODE_READ,
>> +.force = sched->force,
>> +};
>> +int rc = -1;
>>  
>>  setup_pager();
>>  
>> -if (perf_sched__read_events(sched))
> 
> so it's basically perf_sched__read_events code in here now, right?
> 
> might be better to add __perf_sched__read_events function
> that would take session argument, something like:
> 
> session = perf_session__new(, false, >tool);
>   ...
>   __perf_sched__read_events(sched, session)
>   ...
>   perf_session__delete(session);
> 
> to avoid the code ducplication

Yes, what you suggest is reasonable, i will send a v2 with your suggestion soon.

Thanks，
Wei

Re: linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi all,

On Wed, 1 May 2019 17:05:28 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/erofs/data.c
>   drivers/staging/erofs/unzip_vle.c
> 
> between commit:
> 
>   2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")
> 
> from the block tree and commit:
> 
>   14a56ec65bab ("staging: erofs: support IO read error injection")
> 
> from the staging 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 drivers/staging/erofs/data.c
> index 9f04d7466c55,c64ec76643d4..
> --- a/drivers/staging/erofs/data.c
> +++ b/drivers/staging/erofs/data.c
> @@@ -17,11 -17,18 +17,17 @@@
>   
>   static inline void read_endio(struct bio *bio)
>   {
> + struct super_block *const sb = bio->bi_private;
>  -int i;
>   struct bio_vec *bvec;
> - const blk_status_t err = bio->bi_status;
> + blk_status_t err = bio->bi_status;
>   struct bvec_iter_all iter_all;
>   
> + if (time_to_inject(EROFS_SB(sb), FAULT_READ_IO)) {
> + erofs_show_injection_info(FAULT_READ_IO);
> + err = BLK_STS_IOERR;
> + }
> + 
>  -bio_for_each_segment_all(bvec, bio, i, iter_all) {
>  +bio_for_each_segment_all(bvec, bio, iter_all) {
>   struct page *page = bvec->bv_page;
>   
>   /* page is already locked */
> diff --cc drivers/staging/erofs/unzip_vle.c
> index 59b9f37d5c00,a2e03c932102..
> --- a/drivers/staging/erofs/unzip_vle.c
> +++ b/drivers/staging/erofs/unzip_vle.c
> @@@ -843,14 -844,13 +844,12 @@@ static void z_erofs_vle_unzip_kickoff(v
>   
>   static inline void z_erofs_vle_read_endio(struct bio *bio)
>   {
> - const blk_status_t err = bio->bi_status;
> + struct erofs_sb_info *sbi = NULL;
> + blk_status_t err = bio->bi_status;
>  -unsigned int i;
>   struct bio_vec *bvec;
> - #ifdef EROFS_FS_HAS_MANAGED_CACHE
> - struct address_space *mc = NULL;
> - #endif
>   struct bvec_iter_all iter_all;
>   
>  -bio_for_each_segment_all(bvec, bio, i, iter_all) {
>  +bio_for_each_segment_all(bvec, bio, iter_all) {
>   struct page *page = bvec->bv_page;
>   bool cachemngd = false;
>   

This conflict is now between the block tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgp0ac28V7kvJ.pgp
Description: OpenPGP digital signature

Re: [PATCH v5 03/12] dt-binding: gce: add binding for gce subsys property

[CK Hu]

Hi, Bibby:

On Tue, 2019-05-07 at 16:13 +0800, Bibby Hsieh wrote:
> tcmdq driver provide a function that get the relationship
> of sub system number from device node for client.
> add specification for #subsys-cells, mediatek,gce-subsys.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  .../devicetree/bindings/mailbox/mtk-gce.txt   | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt 
> b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> index 1f7f8f2a3f49..8fd9479bc9f6 100644
> --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> @@ -21,11 +21,19 @@ Required properties:
>   priority: Priority of GCE thread.
>   atomic_exec: GCE processing continuous packets of commands in atomic
>   way.
> +- #subsys-cells: Should be 3.
> + < subsys_number start_offset size>
> + phandle: Label name of a gce node.
> + subsys_number: specify the sub-system id which is corresponding
> +to the register address.
> + start_offset: the start offset of register address that GCE can access.
> + size: the total size of register address that GCE can access.
>  
>  Required properties for a client device:
>  - mboxes: Client use mailbox to communicate with GCE, it should have this
>property and list of phandle, mailbox specifiers.
> -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding
> +Optional propertier for a client device:

properties

Regards,
CK

> +- mediatek,gce-client-reg: u32, specify the sub-system id which is 
> corresponding
>to the register address.
>  
>  Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
> @@ -40,6 +48,7 @@ Example:
>   clocks = < CLK_INFRA_GCE>;
>   clock-names = "gce";
>   #mbox-cells = <3>;
> + #subsys-cells = <3>;
>   };
>  
>  Example for a client device:
> @@ -48,9 +57,9 @@ Example for a client device:
>   compatible = "mediatek,mt8173-mmsys";
>   mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>,
>< 1 CMDQ_THR_PRIO_LOWEST 1>;
> - mediatek,gce-subsys = ;
>   mutex-event-eof =CMDQ_EVENT_MUTEX1_STREAM_EOF>;
> -
> + mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>,
> +   < SUBSYS_1401 0x2000 0x100>;
>   ...
>   };

RE: [EXT] Re: [PATCHv2 1/2] ARM: dts: imx6sx: Use MX6SX_CLK_ENET for fec 'ahb' clock

[Andy Duan]

From: Fabio Estevam 
> Hi Andy,
> 
> On Sun, May 5, 2019 at 5:15 AM Andy Duan  wrote:
> 
> > Nack the patch !
> >
...
> > Secondly,  for your issue you caught, which was fixed by patch:
> > commit d7c3a206e6338e4ccdf030719dec028e26a521d5
> > Author: Andy Duan 
> > Date:   Tue Apr 9 03:40:56 2019 +
> >
> > net: fec: manage ahb clock in runtime pm
> 
> Would this also fix the case where power management support is disabled?
> 
> If I understand correctly the explanation from Kay-Liu he would still see a
> hang in the case when PM is disabled.
> 
> Thanks
From current design, it still work even if disable PM.
Please double check it.

Andy

[PATCH V2 4/4] arm64: dts: imx: add i.MX8QXP ocotp support

[Peng Fan]

Add i.MX8QXP ocotp node

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: Aisheng Dong 
Cc: Anson Huang 
Cc: Daniel Baluta 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Peng Fan 
---

V2:
 move address/size-cells below compatible, add "scu"

 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 0683ee2a48ae..725d341ee160 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -141,6 +141,12 @@
compatible = "fsl,imx8qxp-iomuxc";
};
 
+   ocotp: imx8qx-ocotp {
+   compatible = "fsl,imx8qxp-scu-ocotp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd";
#power-domain-cells = <1>;
-- 
2.16.4

[PATCH V2 3/4] defconfig: arm64: enable i.MX8 SCU octop driver

[Peng Fan]

Build in CONFIG_NVMEM_IMX_OCOTP_SCU.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Shawn Guo 
Cc: Andy Gross 
Cc: Maxime Ripard 
Cc: Olof Johansson 
Cc: Jagan Teki 
Cc: Bjorn Andersson 
Cc: Leonard Crestez 
Cc: Marc Gonzalez 
Cc: Enric Balletbo i Serra 
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Peng Fan 
---

V2:
 rename patch title, add review tag

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eb31c20e9914..9d8a512fc3d5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -748,6 +748,7 @@ CONFIG_HISI_PMU=y
 CONFIG_QCOM_L2_PMU=y
 CONFIG_QCOM_L3_PMU=y
 CONFIG_NVMEM_IMX_OCOTP=y
+CONFIG_NVMEM_IMX_OCOTP_SCU=y
 CONFIG_QCOM_QFPROM=y
 CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_UNIPHIER_EFUSE=y
-- 
2.16.4

[PATCH V2 1/4] dt-bindings: fsl: scu: add ocotp binding

[Peng Fan]

NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller(SCU), the ocotp controller is being controlled
by the SCU, so Linux need use RPC to SCU for ocotp handling. This
patch adds binding doc for i.MX8 SCU OCOTP driver.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Aisheng Dong 
Cc: Shawn Guo 
Cc: Ulf Hansson 
Cc: Stephen Boyd 
Cc: Anson Huang 
Cc: devicet...@vger.kernel.org
Signed-off-by: Peng Fan 
---

V2:
 Move OCOTP to end, add example, add "scu"

 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 5d7dbabbb784..f378922906f6 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -133,6 +133,18 @@ RTC bindings based on SCU Message Protocol
 Required properties:
 - compatible: should be "fsl,imx8qxp-sc-rtc";
 
+OCOTP bindings based on SCU Message Protocol
+
+Required properties:
+- compatible:  Should be "fsl,imx8qxp-scu-ocotp"
+- #address-cells:  Must be 1. Contains byte index
+- #size-cells: Must be 1. Contains byte length
+
+Optional Child nodes:
+
+- Data cells of ocotp:
+  Detailed bindings are described in bindings/nvmem/nvmem.txt
+
 Example (imx8qxp):
 -
 aliases {
@@ -177,6 +189,16 @@ firmware {
...
};
 
+   ocotp: imx8qx-ocotp {
+   compatible = "fsl,imx8qxp-scu-ocotp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   fec_mac0: mac@2c4 {
+   reg = <0x2c4 8>;
+   };
+   };
+
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
-- 
2.16.4

[PATCH V2 2/4] nvmem: imx: add i.MX8 nvmem driver

[Peng Fan]

This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.

Cc: Srinivas Kandagatla 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Peng Fan 
---

V2:
 Add "scu" or "SCU", Add imx_sc_misc_otp_fuse_read, minor fixes

 drivers/nvmem/Kconfig |   7 ++
 drivers/nvmem/Makefile|   2 +
 drivers/nvmem/imx-ocotp-scu.c | 170 ++
 3 files changed, 179 insertions(+)
 create mode 100644 drivers/nvmem/imx-ocotp-scu.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 530d570724c9..79afe44195a1 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,6 +36,13 @@ config NVMEM_IMX_OCOTP
  This driver can also be built as a module. If so, the module
  will be called nvmem-imx-ocotp.
 
+config NVMEM_IMX_OCOTP_SCU
+   tristate "i.MX8 SCU On-Chip OTP Controller support"
+   depends on IMX_SCU
+   help
+ This is a driver for the SCU On-Chip OTP Controller (OCOTP)
+ available on i.MX8 SoCs.
+
 config NVMEM_LPC18XX_EEPROM
tristate "NXP LPC18XX EEPROM Memory Support"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 2ece8dda..30d653d34e57 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM)   += nvmem-imx-iim.o
 nvmem-imx-iim-y:= imx-iim.o
 obj-$(CONFIG_NVMEM_IMX_OCOTP)  += nvmem-imx-ocotp.o
 nvmem-imx-ocotp-y  := imx-ocotp.o
+obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU)  += nvmem-imx-ocotp-scu.o
+nvmem-imx-ocotp-scu-y  := imx-ocotp-scu.o
 obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
 nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
 obj-$(CONFIG_NVMEM_LPC18XX_OTP)+= nvmem_lpc18xx_otp.o
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
new file mode 100644
index ..038e744c8588
--- /dev/null
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 OCOTP fusebox driver
+ *
+ * Copyright 2019 NXP
+ *
+ * Peng Fan 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum ocotp_devtype {
+   IMX8QXP,
+};
+
+struct ocotp_devtype_data {
+   int devtype;
+   int nregs;
+};
+
+struct ocotp_priv {
+   struct device *dev;
+   const struct ocotp_devtype_data *data;
+   struct imx_sc_ipc *nvmem_ipc;
+};
+
+struct imx_sc_msg_req_misc_fuse_read {
+   struct imx_sc_rpc_msg hdr;
+   u32 word;
+} __packed;
+
+struct imx_sc_msg_resp_misc_fuse_read {
+   struct imx_sc_rpc_msg hdr;
+   u32 val;
+} __packed;
+
+static struct ocotp_devtype_data imx8qxp_data = {
+   .devtype = IMX8QXP,
+   .nregs = 800,
+};
+
+static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
+u32 *val)
+{
+   struct imx_sc_msg_req_misc_fuse_read msg;
+   struct imx_sc_msg_resp_misc_fuse_read *resp;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = (uint8_t)IMX_SC_RPC_SVC_MISC;
+   hdr->func = (uint8_t)IMX_SC_MISC_FUNC_OTP_FUSE_READ;
+   hdr->size = 2;
+
+   msg.word = word;
+
+   ret = imx_scu_call_rpc(ipc, , true);
+   if (ret)
+   return ret;
+
+   resp = (struct imx_sc_msg_resp_misc_fuse_read *)
+   if (val != NULL)
+   *val = resp->val;
+
+   return 0;
+}
+
+static int imx_scu_ocotp_read(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+   struct ocotp_priv *priv = context;
+   u32 count, index, num_bytes;
+   u32 *buf;
+   void *p;
+   int i, ret;
+
+   index = offset >> 2;
+   num_bytes = round_up((offset % 4) + bytes, 4);
+   count = num_bytes >> 2;
+
+   if (count > (priv->data->nregs - index))
+   count = priv->data->nregs - index;
+
+   p = kzalloc(num_bytes, GFP_KERNEL);
+   if (!p)
+   return -ENOMEM;
+
+   buf = p;
+
+   for (i = index; i < (index + count); i++) {
+   if (priv->data->devtype == IMX8QXP) {
+   if ((i > 271) && (i < 544)) {
+   *(u32 *)buf = 0;
+   buf += 4;
+   continue;
+   }
+   }
+
+   ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
+   if (ret) {
+   kfree(p);
+   return ret;
+   }
+   buf++;
+   }
+
+   memcpy(val, p + offset % 4, bytes);
+
+   kfree(p);
+
+   return 0;
+}
+
+static struct nvmem_config imx_scu_ocotp_nvmem_config = {
+   .name = "imx-scu-ocotp",
+   .read_only = 

Re: [GIT PULL] LED updates for 5.2-rc1

[pr-tracker-bot]

The pull request you sent on Tue,  7 May 2019 20:42:25 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git 
> tags/leds-for-5.2-rc1

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

Thank you!

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

Re: [GIT PULL] parisc architecture updates for kernel v5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 20:38:18 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
> parisc-5.2-1

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

Thank you!

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

Re: [GIT PULL] Audit patches for v5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 13:23:05 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git 
> tags/audit-pr-20190507

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

Thank you!

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

Re: [GIT PULL] SELinux patches for v5.2

[pr-tracker-bot]

The pull request you sent on Tue, 7 May 2019 13:23:03 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git 
> tags/selinux-pr-20190507

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

Thank you!

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

Re: [RFC PATCH v2 00/17] Core scheduling v2

[Aaron Lu]

On Mon, May 06, 2019 at 03:39:37PM -0400, Julien Desfossez wrote:
> On 29-Apr-2019 11:53:21 AM, Aaron Lu wrote:
> > This is what I have used to make sure no two unmatched tasks being
> > scheduled on the same core: (on top of v1, I thinks it's easier to just
> > show the diff instead of commenting on various places of the patches :-)
> 
> We imported this fix in v2 and made some small changes and optimizations
> (with and without Peter’s fix from https://lkml.org/lkml/2019/4/26/658)
> and in both cases, the performance problem where the core can end up

By 'core', do you mean a logical CPU(hyperthread) or the entire core?

> idle with tasks in its runqueues came back.

Assume you meant a hyperthread, then the question is: when a hyperthread
is idle with tasks sitting in its runqueue, do these tasks match with the
other hyperthread's rq->curr? If so, then it is a problem that need to
be addressed; if not, then this is due to the constraint imposed by the
mitigation of L1TF.

Thanks.

Re: linux-next: manual merge of the driver-core tree with the block tree

[Stephen Rothwell]

Hi all,

On Mon, 29 Apr 2019 15:24:00 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   block/blk-sysfs.c
> 
> between commit:
> 
>   4d25339e32a1 ("block: don't show io_timeout if driver has no timeout 
> handler")
> 
> from the block tree and commit:
> 
>   800f5aa1e7e1 ("block: Replace all ktype default_attrs with groups")
> 
> from the driver-core tree.
> 
> I fixed it up (the former stopped using the default_attrs field, so I
> effectively reverted the latter changes to this file) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.

This is now a conflict between the block tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpn8_3vxGIVb.pgp
Description: OpenPGP digital signature

[PATCH v2 11/11] arm64: dts: sc9860: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel,
so can dismiss warning during initialisation.

Cc: Chunyan Zhang 
Cc: Orson Zhai 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
Acked-by: Chunyan Zhang 
---
 arch/arm64/boot/dts/sprd/sc9860.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
index b25d19977170..e27eb3ed1d47 100644
--- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -300,7 +300,7 @@
};
 
funnel@10001000 { /* SoC Funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0x10001000 0 0x1000>;
clocks = <_26m>;
clock-names = "apb_pclk";
@@ -367,7 +367,7 @@
};
 
funnel@11001000 { /* Cluster0 Funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0x11001000 0 0x1000>;
clocks = <_26m>;
clock-names = "apb_pclk";
@@ -415,7 +415,7 @@
};
 
funnel@11002000 { /* Cluster1 Funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0x11002000 0 0x1000>;
clocks = <_26m>;
clock-names = "apb_pclk";
@@ -513,7 +513,7 @@
};
 
funnel@11005000 { /* Main Funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0x11005000 0 0x1000>;
clocks = <_26m>;
clock-names = "apb_pclk";
-- 
2.17.1

[PATCH v2 10/11] arm64: dts: sc9836: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel,
so can dismiss warning during initialisation.

Cc: Chunyan Zhang 
Cc: Orson Zhai 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
Acked-by: Chunyan Zhang 
---
 arch/arm64/boot/dts/sprd/sc9836.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/sprd/sc9836.dtsi 
b/arch/arm64/boot/dts/sprd/sc9836.dtsi
index 286d7173f94f..231436be0e3f 100644
--- a/arch/arm64/boot/dts/sprd/sc9836.dtsi
+++ b/arch/arm64/boot/dts/sprd/sc9836.dtsi
@@ -60,7 +60,7 @@
};
 
funnel@10001000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x10001000 0 0x1000>;
clocks = <>;
clock-names = "apb_pclk";
-- 
2.17.1

[PATCH v2 07/11] arm64: dts: hi6220: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Haojian Zhuang 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
index 68c52f1149be..5a34217d823a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-coresight.dtsi
@@ -15,7 +15,7 @@
 / {
soc {
funnel@f6401000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0xf6401000 0 0x1000>;
clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
clock-names = "apb_pclk";
@@ -65,7 +65,7 @@
};
 
replicator {
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
clock-names = "apb_pclk";
 
@@ -133,7 +133,7 @@
};
 
funnel@f6501000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0 0xf6501000 0 0x1000>;
clocks = <_sctrl HI6220_ACPU_SFT_AT_S>;
clock-names = "apb_pclk";
-- 
2.17.1

RE: [PATCH v2] arm64: dts: ls1028a: Add USB dt nodes

[Ran Wang]

Hi Rob,

On Wednesday, May 08, 2019 00:40, Rob Herring wrote:
> 
> On Tue, May 7, 2019 at 3:48 AM Ran Wang  wrote:
> >
> > Hi Rob,
> >
> > On Thursday, May 02, 2019 07:54 Rob Herring wrote:
> > >
> > > On Fri, Apr 26, 2019 at 05:54:26AM +, Ran Wang wrote:
> > > > This patch adds USB dt nodes for LS1028A.
> > > >
> > > > Signed-off-by: Ran Wang 
> > > > ---
> > > > Changes in v2:
> > > >   - Rename node from usb3@... to usb@... to meet DTSpec
> > > >
> > > >  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi |   20
> > > 
> > > >  1 files changed, 20 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > index 8dd3501..188cfb8 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > > > @@ -144,6 +144,26 @@
> > > > clocks = <>;
> > > > };
> > > >
> > > > +   usb0:usb@310 {
> > >  ^ space needed
> >
> > Yes, will update this in next version.
> >
> > > > +   compatible= "snps,dwc3";
> > >
> > > Needs an SoC specific compatible.
> >
> > Do you mean change compatible to "snps,dwc3", "fsl,ls1028a-dwc3" ?
> 
> Well, that's the wrong order, but yes.

OK, will update this.
 
> > As I know, so far there is no SoC specific programming for this IP, so
> > do you think it's still necessary to add it?
> 
> Yes. All the bugs and quirks are discovered already?

Yes, so far I don't receive any SoC specific defect report, I think it's fine.
 Will work out next version patch, thanks for your time.

Regards,
Ran

[PATCH v2 09/11] arm64: dts: qcom-msm8916: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel,
so can dismiss warning during initialisation.

Cc: Andy Gross 
Cc: David Brown 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 423dda996b5d..de49ec110fc2 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1172,7 +1172,7 @@
};
 
funnel@821000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x821000 0x1000>;
 
clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
@@ -1285,7 +1285,7 @@
};
 
funnel@841000 { /* APSS funnel only 4 inputs are used */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x841000 0x1000>;
 
clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
-- 
2.17.1

[PATCH v2 08/11] arm64: dts: juno: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel,
so can dismiss warning during initialisation.

Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/arm/juno-base.dtsi| 6 +++---
 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi 
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 7446e0dc154d..26a039a028b8 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -150,7 +150,7 @@
 
/* main funnel on Juno r0, cssys0 funnel on Juno r1/r2 as per TRM*/
main_funnel: funnel@2004 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x2004 0 0x1000>;
 
clocks = <_smc50mhz>;
@@ -281,7 +281,7 @@
};
 
funnel@220c { /* cluster0 funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x220c 0 0x1000>;
 
clocks = <_smc50mhz>;
@@ -366,7 +366,7 @@
};
 
funnel@230c { /* cluster1 funnel */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x230c 0 0x1000>;
 
clocks = <_smc50mhz>;
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi 
b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index cf285152deab..eda3d9e18af6 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 / {
funnel@2013 { /* cssys1 */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x2013 0 0x1000>;
 
clocks = <_smc50mhz>;
@@ -47,7 +47,7 @@
};
 
funnel@2015 { /* cssys2 */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x2015 0 0x1000>;
 
clocks = <_smc50mhz>;
-- 
2.17.1

[PATCH v2 06/11] ARM: dts: qcom-msm8974: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel,
so can dismiss warning during initialisation.

Cc: Andy Gross 
Cc: David Brown 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 45b5c8ef0374..272ebea20a5f 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -897,7 +897,7 @@
};
 
funnel@fc31b000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0xfc31b000 0x1000>;
 
clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
@@ -931,7 +931,7 @@
};
 
funnel@fc31a000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0xfc31a000 0x1000>;
 
clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
@@ -969,7 +969,7 @@
};
 
funnel@fc345000 { /* KPSS funnel only 4 inputs are used */
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0xfc345000 0x1000>;
 
clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
-- 
2.17.1

[PATCH v2 04/11] ARM: dts: ste: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Linus Walleij 
Cc: Lee Jones 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/ste-dbx5x0.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi 
b/arch/arm/boot/dts/ste-dbx5x0.dtsi
index 81fabf031eff..4bdd247b9534 100644
--- a/arch/arm/boot/dts/ste-dbx5x0.dtsi
+++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi
@@ -98,7 +98,7 @@
};
 
funnel@801a6000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x801a6000 0x1000>;
 
clocks = <_clk PRCMU_APETRACECLK>, <_clk 
PRCMU_APEATCLK>;
@@ -133,7 +133,7 @@
};
 
replicator {
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
clocks = <_clk PRCMU_APEATCLK>;
clock-names = "atclk";
 
-- 
2.17.1

[PATCH v2 05/11] ARM: dts: vexpress-v2p-ca15_a7: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 00cd9f5bef2e..164c904c9992 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -440,7 +440,7 @@
/* non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell".
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -471,7 +471,7 @@
};
 
funnel@2004 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0x2004 0 0x1000>;
 
clocks = <>;
-- 
2.17.1

[PATCH v2 03/11] ARM: dts: qcom-apq8064: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Andy Gross 
Cc: David Brown 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 65975df6a8c3..8b79b4112ee1 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1603,7 +1603,7 @@
};
 
replicator {
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
clocks = < RPM_QDSS_CLK>;
clock-names = "apb_pclk";
@@ -1636,7 +1636,7 @@
};
 
funnel@1a04000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x1a04000 0x1000>;
 
clocks = < RPM_QDSS_CLK>;
-- 
2.17.1

[PATCH v2 01/11] ARM: dts: hip04: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Haojian Zhuang 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/hip04.dtsi | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
index 0f917b272ff3..f58313353519 100644
--- a/arch/arm/boot/dts/hip04.dtsi
+++ b/arch/arm/boot/dts/hip04.dtsi
@@ -350,7 +350,7 @@
/* non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell".
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -385,7 +385,7 @@
/* non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell".
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -420,7 +420,7 @@
/* non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell".
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -454,7 +454,7 @@
/* non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell".
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -485,7 +485,7 @@
};
 
funnel@0,e3c41000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0xe3c41000 0 0x1000>;
 
clocks = <_375m>;
@@ -534,7 +534,7 @@
};
 
funnel@0,e3c81000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0xe3c81000 0 0x1000>;
 
clocks = <_375m>;
@@ -583,7 +583,7 @@
};
 
funnel@0,e3cc1000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0xe3cc1000 0 0x1000>;
 
clocks = <_375m>;
@@ -632,7 +632,7 @@
};
 
funnel@0,e3d01000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0xe3d01000 0 0x1000>;
 
clocks = <_375m>;
@@ -681,7 +681,7 @@
};
 
funnel@0,e3c04000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0 0xe3c04000 0 0x1000>;
 
clocks = <_375m>;
-- 
2.17.1

[PATCH v2 02/11] ARM: dts: imx7s: Update coresight DT bindings

[Leo Yan]

CoreSight DT bindings have been updated, thus the old compatible strings
are obsolete and the drivers will report warning if DTS uses these
obsolete strings.

This patch switches to the new bindings for CoreSight dynamic funnel and
static replicator, so can dismiss warning during initialisation.

Cc: Shawn Guo 
Cc: Chris Healy 
Cc: Andrew Lunn 
Cc: Fabio Estevam 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Signed-off-by: Leo Yan 
---
 arch/arm/boot/dts/imx7s.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 106711d2c01b..d8b4eb67146d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -117,7 +117,7 @@
 * non-configurable replicators don't show up on the
 * AMBA bus.  As such no need to add "arm,primecell"
 */
-   compatible = "arm,coresight-replicator";
+   compatible = "arm,coresight-static-replicator";
 
out-ports {
#address-cells = <1>;
@@ -175,7 +175,7 @@
ranges;
 
funnel@30041000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x30041000 0x1000>;
clocks = < IMX7D_MAIN_AXI_ROOT_CLK>;
clock-names = "apb_pclk";
@@ -217,7 +217,7 @@
};
 
funnel@30083000 {
-   compatible = "arm,coresight-funnel", "arm,primecell";
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
reg = <0x30083000 0x1000>;
clocks = < IMX7D_MAIN_AXI_ROOT_CLK>;
clock-names = "apb_pclk";
-- 
2.17.1

[PATCH v2 00/11] dts: Update DT bindings for CoreSight replicator and funnel

[Leo Yan]

Since the DT bindings consolidatoins for CoreSight replicator and funnel
is ready for kernel v5.2 merge window [1], this patch set is to update
the related CoreSight DT bindings for platforms; IIUC, this patch set
will be safe for merging into kernel v5.2 because the dependency
patches in [1] will be landed into mainline kernel v5.2 cycle.

In this patch set, it tries to update below two compatible strings to
the latest strings:

  s/"arm,coresight-replicator"/"arm,coresight-static-replicator"
  s/"arm,coresight-funnel"/"arm,coresight-dynamic-funnel"

Please note, some platforms have two continuous patches, one is for
updating static replicator compatible string and another is for dynamic
funnel change; and other platforms have only one patch since it only
needs to change for dynamic funnel.

Avoid to introduce merging confliction, I rebased this patch set on
linux-next branch with last commit fcdb095ad001 ("Add linux-next
specific files for 20190506").

This patch set has been tested on Arm Juno and Hikey620 boards, other
platforms are only compilation passing.

P.s. when use scirpt/checkpatch.pl, it reports the warnings as below. I
think we can ignore this warnings for this patch set, please review if
this makes sense for you.

WARNING: line over 80 characters
#29: FILE: arch/arm/boot/dts/imx7s.dtsi:178:
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";

[1] 
https://archive.armlinux.org.uk/lurker/message/20190412.102734.2afbb29a.en.html

== Changes for v2 ==
* Add explanation for the change in the commit logs. (Fabio)
* Merge the separate patches for funnel and replicator per DTS into
  a single patch. (Suzuki)


Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Mathieu Poirier 
Cc: Suzuki K Poulose 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Haojian Zhuang 
Cc: Shawn Guo 
Cc: Chris Healy 
Cc: Andrew Lunn 
Cc: Fabio Estevam 
Cc: Sascha Hauer 
Cc: Andy Gross 
Cc: David Brown 
Cc: Linus Walleij 
Cc: Lee Jones 
Cc: Chunyan Zhang 
Cc: Orson Zhai 
Cc: Baolin Wang 


Leo Yan (11):
  ARM: dts: hip04: Update coresight DT bindings
  ARM: dts: imx7s: Update coresight DT bindings
  ARM: dts: qcom-apq8064: Update coresight DT bindings
  ARM: dts: ste: Update coresight DT bindings
  ARM: dts: vexpress-v2p-ca15_a7: Update coresight DT bindings
  ARM: dts: qcom-msm8974: Update coresight DT bindings
  arm64: dts: hi6220: Update coresight DT bindings
  arm64: dts: juno: Update coresight DT bindings
  arm64: dts: qcom-msm8916: Update coresight DT bindings
  arm64: dts: sc9836: Update coresight DT bindings
  arm64: dts: sc9860: Update coresight DT bindings

 arch/arm/boot/dts/hip04.dtsi   | 18 +-
 arch/arm/boot/dts/imx7s.dtsi   |  6 +++---
 arch/arm/boot/dts/qcom-apq8064.dtsi|  4 ++--
 arch/arm/boot/dts/qcom-msm8974.dtsi|  6 +++---
 arch/arm/boot/dts/ste-dbx5x0.dtsi  |  4 ++--
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts |  4 ++--
 arch/arm64/boot/dts/arm/juno-base.dtsi |  6 +++---
 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi  |  4 ++--
 .../boot/dts/hisilicon/hi6220-coresight.dtsi   |  6 +++---
 arch/arm64/boot/dts/qcom/msm8916.dtsi  |  4 ++--
 arch/arm64/boot/dts/sprd/sc9836.dtsi   |  2 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   |  8 
 12 files changed, 36 insertions(+), 36 deletions(-)

-- 
2.17.1

Re: [PATCH v3 0/3] tracing: probeevent: Fix probe argument parser and handler

[Steven Rostedt]

On Tue,  7 May 2019 22:55:22 +0900
Masami Hiramatsu  wrote:

> Hi,
> 
> Here is the 3rd version of series to fix several bugs in probe event
> argument parser and handler routines.
> 
> In this version I updated patch [1/3] according to Steve's comment.
> 
> 
> I got 2 issues reported by Andreas, see
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1899098.html
> 
> One issue is already fixed by Andreas (Thanks!) but $comm handling
> issue still exists on uprobe event. [1/3] fixes it.
> And I found other issues around that, [2/3] is just a trivial cleanup,
> [3/3] fixes $comm type issue which occurs not only uprobe events but
> also on kprobe events. Anyway, after this series applied, $comm must
> be "string" type and not be an array.
>

Thanks Masami,

I applied these to my queue.

-- Steve

[PATCH] x86/events/amd/iommu: Make symbol 'amd_iommu_attr_groups' static

[Wang Hai]

Fix the following sparse warning:

arch/x86/events/amd/iommu.c:396:30: warning:
 symbol 'amd_iommu_attr_groups' was not declared. Should it be static?

Fixes: 51686546304f (x86/events/amd/iommu: Fix sysfs perf attribute groups)
Signed-off-by: Wang Hai 
---
 arch/x86/events/amd/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/amd/iommu.c b/arch/x86/events/amd/iommu.c
index 7635c23f7d82..58a6993d7eb3 100644
--- a/arch/x86/events/amd/iommu.c
+++ b/arch/x86/events/amd/iommu.c
@@ -393,7 +393,7 @@ static __init int _init_events_attrs(void)
return 0;
 }
 
-const struct attribute_group *amd_iommu_attr_groups[] = {
+static const struct attribute_group *amd_iommu_attr_groups[] = {
_iommu_format_group,
_iommu_cpumask_group,
_iommu_events_group,
-- 
2.17.1

[PATCH 0/3] x86_64/ftrace: Emulate calls from int3 when patching functions

[Steven Rostedt]

[
  This is the non-RFC version.

  It went through and passed all my tests. If there's no objections
  I'm going to include this in my pull request. I still have patches
  in my INBOX that may still be included, so I need to run those through
  my tests as well, so a pull request wont be immediate.
]

Nicolai Stange discovered that Live Kernel Patching can have unforseen
consequences if tracing is enabled when there are functions that are
patched. The reason being, is that Live Kernel patching is built on top
of ftrace, which will have the patched functions call the live kernel
trampoline directly, and that trampoline will modify the regs->ip address
to return to the patched function.

But in the transition between changing the call to the customized
trampoline, the tracing code is needed to have its handler called
an well, so the function fentry location must be changed from calling
the live kernel patching trampoline, to the ftrace_reg_caller trampoline
which will iterate through all the registered ftrace handlers for
that function.

During this transition, a break point is added to do the live code
modifications. But if that break point is hit, it just skips calling
any handler, and makes the call site act as a nop. For tracing, the
worse that can happen is that you miss a function being traced, but
for live kernel patching the affects are more severe, as the old buggy
function is now called.

To solve this, an int3_emulate_call() is created for x86_64 to allow
ftrace on x86_64 to emulate the call to ftrace_regs_caller() which will
make sure all the registered handlers to that function are still called.
And this keeps live kernel patching happy!

To mimimize the changes, and to avoid controversial patches, this
only changes x86_64. Due to the way x86_32 implements the regs->sp
the complexity of emulating calls on that platform is too much for
stable patches, and live kernel patching does not support x86_32 anyway.


Josh Poimboeuf (1):
  x86_64: Add gap to int3 to allow for call emulation

Peter Zijlstra (2):
  x86_64: Allow breakpoints to emulate call instructions
  ftrace/x86_64: Emulate call function while updating in breakpoint handler


 arch/x86/entry/entry_64.S| 18 --
 arch/x86/include/asm/text-patching.h | 28 
 arch/x86/kernel/ftrace.c | 32 +++-
 3 files changed, 71 insertions(+), 7 deletions(-)

[PATCH 1/3] x86_64: Add gap to int3 to allow for call emulation

[Steven Rostedt]

From: Josh Poimboeuf 

To allow an int3 handler to emulate a call instruction, it must be able to
push a return address onto the stack. Add a gap to the stack to allow the
int3 handler to push the return address and change the return from int3 to
jump straight to the emulated called function target.

Link: http://lkml.kernel.org/r/20181130183917.hxmti5josgq4clti@treble
Link: 
http://lkml.kernel.org/r/20190502162133.gx2...@hirez.programming.kicks-ass.net

[
  Note, this is needed to allow Live Kernel Patching to not miss calling a
  patched function when tracing is enabled. -- Steven Rostedt
]

Cc: sta...@vger.kernel.org
Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching")
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/entry/entry_64.S | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1f0efdb7b629..27fcc6fbdd52 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -879,7 +879,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
  * @paranoid == 2 is special: the stub will never switch stacks.  This is for
  * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
  */
-.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
+.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 
create_gap=0
 ENTRY(\sym)
UNWIND_HINT_IRET_REGS offset=\has_error_code*8
 
@@ -899,6 +899,20 @@ ENTRY(\sym)
jnz .Lfrom_usermode_switch_stack_\@
.endif
 
+   .if \create_gap == 1
+   /*
+* If coming from kernel space, create a 6-word gap to allow the
+* int3 handler to emulate a call instruction.
+*/
+   testb   $3, CS-ORIG_RAX(%rsp)
+   jnz .Lfrom_usermode_no_gap_\@
+   .rept   6
+   pushq   5*8(%rsp)
+   .endr
+   UNWIND_HINT_IRET_REGS offset=8
+.Lfrom_usermode_no_gap_\@:
+   .endif
+
.if \paranoid
callparanoid_entry
.else
@@ -1130,7 +1144,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
 #endif /* CONFIG_HYPERV */
 
 idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3  do_int3 has_error_code=0
+idtentry int3  do_int3 has_error_code=0
create_gap=1
 idtentry stack_segment do_stack_segmenthas_error_code=1
 
 #ifdef CONFIG_XEN_PV
-- 
2.20.1

[PATCH 2/3] x86_64: Allow breakpoints to emulate call instructions

[Steven Rostedt]

From: Peter Zijlstra 

In order to allow breakpoints to emulate call instructions, they need to push
the return address onto the stack. The x86_64 int3 handler adds a small gap
to allow the stack to grow some. Use this gap to add the return address to
be able to emulate a call instruction at the breakpoint location.

These helper functions are added:

  int3_emulate_jmp(): changes the location of the regs->ip to return there.

 (The next two are only for x86_64)
  int3_emulate_push(): to push the address onto the gap in the stack
  int3_emulate_call(): push the return address and change regs->ip

Cc: Andy Lutomirski 
Cc: Nicolai Stange 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: the arch/x86 maintainers 
Cc: Josh Poimboeuf 
Cc: Jiri Kosina 
Cc: Miroslav Benes 
Cc: Petr Mladek 
Cc: Joe Lawrence 
Cc: Shuah Khan 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Chen 
Cc: Sebastian Andrzej Siewior 
Cc: Mimi Zohar 
Cc: Juergen Gross 
Cc: Nick Desaulniers 
Cc: Nayna Jain 
Cc: Masahiro Yamada 
Cc: Joerg Roedel 
Cc: "open list:KERNEL SELFTEST FRAMEWORK" 
Cc: sta...@vger.kernel.org
Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching")
Signed-off-by: Peter Zijlstra (Intel) 
[ Modified to only work for x86_64 and added comment to int3_emulate_push() ]
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/include/asm/text-patching.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/x86/include/asm/text-patching.h 
b/arch/x86/include/asm/text-patching.h
index e85ff65c43c3..05861cc08787 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -39,4 +39,32 @@ extern int poke_int3_handler(struct pt_regs *regs);
 extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void 
*handler);
 extern int after_bootmem;
 
+static inline void int3_emulate_jmp(struct pt_regs *regs, unsigned long ip)
+{
+   regs->ip = ip;
+}
+
+#define INT3_INSN_SIZE 1
+#define CALL_INSN_SIZE 5
+
+#ifdef CONFIG_X86_64
+static inline void int3_emulate_push(struct pt_regs *regs, unsigned long val)
+{
+   /*
+* The int3 handler in entry_64.S adds a gap between the
+* stack where the break point happened, and the saving of
+* pt_regs. We can extend the original stack because of
+* this gap. See the idtentry macro's create_gap option.
+*/
+   regs->sp -= sizeof(unsigned long);
+   *(unsigned long *)regs->sp = val;
+}
+
+static inline void int3_emulate_call(struct pt_regs *regs, unsigned long func)
+{
+   int3_emulate_push(regs, regs->ip - INT3_INSN_SIZE + CALL_INSN_SIZE);
+   int3_emulate_jmp(regs, func);
+}
+#endif
+
 #endif /* _ASM_X86_TEXT_PATCHING_H */
-- 
2.20.1

Re: [PATCH RFC] bpf: Add support for reading user pointers

[Joel Fernandes]

On Tue, May 07, 2019 at 10:52:42AM +0100, Will Deacon wrote:
> On Mon, May 06, 2019 at 10:57:37PM +0100, Qais Yousef wrote:
> > On 05/06/19 16:58, Joel Fernandes wrote:
> > > > If you're trying to dereference a pointer to userspace using
> > > > probe_kernel_read(), that clearly isn't going to work.
> > > 
> > > Ok. Thanks for confirming as well. The existing code has this bug and 
> > > these
> > > patches fix it.
> > 
> > 5.1-rc7 and 4.9.173 stable both managed to read the path in do_sys_open() 
> > on my
> > Juno-r2 board using the defconfig in the tree.
> 
> That's not surprising: Juno-r2 only features v8.0 CPUs, so doesn't have PAN
> or UAO capabilities. The SoC Joel is talking about is 8.2, so has both of
> those.
> 
> Here's some background which might help...
> 
> PAN (Privileged Access Never) prevents the kernel from inadvertently
> accessing userspace and will cause a page (permission) fault if such an
> access is made outside of the standard uaccess routines. This means that
> in those routines (e.g. get_user()) we have to toggle the PAN state in the
> same way that x86 toggles SMAP. This can be expensive and was part of the
> motivation for the adoption of things like unsafe_get_user() on x86.
> 
> On arm64, we have a set of so-called "translated" memory access instructions
> which can be used to perform unprivileged accesses to userspace from within
> the kernel even when PAN is enabled. Using these special instructions (e.g.
> LDTR) in our uaccess routines can therefore remove the need to toggle PAN.
> Sounds great, right? Well, that all falls apart when the uaccess routines
> are used on kernel addresses as in probe_kernel_read() because they will
> fault when trying to dereference a kernel pointer.
> 
> The answer is UAO (User Access Override). When UAO is set, the translated
> memory access instructions behave the same as non-translated accesses.
> Therefore we can toggle UAO in set_fs() so that it is set when we're using
> KERNEL_DS and cleared when we're using USER_DS.
> 
> The side-effect of this is that when KERNEL_DS is set on a system that
> implements both PAN and UAO, passing a user pointer to our uaccess routines
> will return -EFAULT. In other words, set_fs() can be thought of as a
> selector between the kernel and user address spaces, which are distinct.
> 
> Joel -- does disabling UAO in your .config "fix" the issue? If so, feel
> free to use some of the above text in a commit message if it helps to
> justify your change.

Disabling CONFIG_ARM64_UAO does "fix" it.

I will use the description above in the commit message as you suggested,
thanks a lot for the explantation of this!

 - Joel

[PATCH 3/3] ftrace/x86_64: Emulate call function while updating in breakpoint handler

[Steven Rostedt]

From: Peter Zijlstra 

Nicolai Stange discovered[1] that if live kernel patching is enabled, and the
function tracer started tracing the same function that was patched, the
conversion of the fentry call site during the translation of going from
calling the live kernel patch trampoline to the iterator trampoline, would
have as slight window where it didn't call anything.

As live kernel patching depends on ftrace to always call its code (to
prevent the function being traced from being called, as it will redirect
it). This small window would allow the old buggy function to be called, and
this can cause undesirable results.

Nicolai submitted new patches[2] but these were controversial. As this is
similar to the static call emulation issues that came up a while ago[3].
But after some debate[4][5] adding a gap in the stack when entering the
breakpoint handler allows for pushing the return address onto the stack to
easily emulate a call.

[1] http://lkml.kernel.org/r/20180726104029.7736-1-nsta...@suse.de
[2] http://lkml.kernel.org/r/20190427100639.15074-1-nsta...@suse.de
[3] 
http://lkml.kernel.org/r/3cf04e113d71c9f8e4be95fb84a510f085aa4afa.1541711457.git.jpoim...@redhat.com
[4] 
http://lkml.kernel.org/r/CAHk-=wh5OpheSU8Em_Q3Hg8qw_JtoijxOdPtHru6d+5K8TWM=a...@mail.gmail.com
[5] 
http://lkml.kernel.org/r/CAHk-=wjvQxY4DvPrJ6haPgAa6b906h=MwZXO6G8OtiTGe=n...@mail.gmail.com

[
  Live kernel patching is not implemented on x86_32, thus the emulate
  calls are only for x86_64.
]

Cc: Andy Lutomirski 
Cc: Nicolai Stange 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: the arch/x86 maintainers 
Cc: Josh Poimboeuf 
Cc: Jiri Kosina 
Cc: Miroslav Benes 
Cc: Petr Mladek 
Cc: Joe Lawrence 
Cc: Shuah Khan 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Chen 
Cc: Sebastian Andrzej Siewior 
Cc: Mimi Zohar 
Cc: Juergen Gross 
Cc: Nick Desaulniers 
Cc: Nayna Jain 
Cc: Masahiro Yamada 
Cc: Joerg Roedel 
Cc: "open list:KERNEL SELFTEST FRAMEWORK" 
Cc: sta...@vger.kernel.org
Fixes: b700e7f03df5 ("livepatch: kernel: add support for live patching")
Signed-off-by: Peter Zijlstra (Intel) 
[ Changed to only implement emulated calls for x86_64 ]
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/ftrace.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index ef49517f6bb2..bd553b3af22e 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 
@@ -231,6 +232,7 @@ int ftrace_modify_call(struct dyn_ftrace *rec, unsigned 
long old_addr,
 }
 
 static unsigned long ftrace_update_func;
+static unsigned long ftrace_update_func_call;
 
 static int update_ftrace_func(unsigned long ip, void *new)
 {
@@ -259,6 +261,8 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
unsigned char *new;
int ret;
 
+   ftrace_update_func_call = (unsigned long)func;
+
new = ftrace_call_replace(ip, (unsigned long)func);
ret = update_ftrace_func(ip, new);
 
@@ -294,13 +298,28 @@ int ftrace_int3_handler(struct pt_regs *regs)
if (WARN_ON_ONCE(!regs))
return 0;
 
-   ip = regs->ip - 1;
-   if (!ftrace_location(ip) && !is_ftrace_caller(ip))
-   return 0;
+   ip = regs->ip - INT3_INSN_SIZE;
 
-   regs->ip += MCOUNT_INSN_SIZE - 1;
+#ifdef CONFIG_X86_64
+   if (ftrace_location(ip)) {
+   int3_emulate_call(regs, (unsigned long)ftrace_regs_caller);
+   return 1;
+   } else if (is_ftrace_caller(ip)) {
+   if (!ftrace_update_func_call) {
+   int3_emulate_jmp(regs, ip + CALL_INSN_SIZE);
+   return 1;
+   }
+   int3_emulate_call(regs, ftrace_update_func_call);
+   return 1;
+   }
+#else
+   if (ftrace_location(ip) || is_ftrace_caller(ip)) {
+   int3_emulate_jmp(regs, ip + CALL_INSN_SIZE);
+   return 1;
+   }
+#endif
 
-   return 1;
+   return 0;
 }
 NOKPROBE_SYMBOL(ftrace_int3_handler);
 
@@ -859,6 +878,8 @@ void arch_ftrace_update_trampoline(struct ftrace_ops *ops)
 
func = ftrace_ops_get_func(ops);
 
+   ftrace_update_func_call = (unsigned long)func;
+
/* Do a safe modify in case the trampoline is executing */
new = ftrace_call_replace(ip, (unsigned long)func);
ret = update_ftrace_func(ip, new);
@@ -960,6 +981,7 @@ static int ftrace_mod_jmp(unsigned long ip, void *func)
 {
unsigned char *new;
 
+   ftrace_update_func_call = 0UL;
new = ftrace_jmp_replace(ip, (unsigned long)func);
 
return update_ftrace_func(ip, new);
-- 
2.20.1

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi all,

On Fri, 26 Apr 2019 16:06:58 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/media/zoran/Kconfig
>   drivers/staging/media/zoran/videocodec.c
>   drivers/staging/media/zoran/videocodec.h
>   drivers/staging/media/zoran/zoran.h
>   drivers/staging/media/zoran/zoran_card.c
>   drivers/staging/media/zoran/zoran_card.h
>   drivers/staging/media/zoran/zoran_device.c
>   drivers/staging/media/zoran/zoran_device.h
>   drivers/staging/media/zoran/zoran_driver.c
>   drivers/staging/media/zoran/zoran_procfs.c
>   drivers/staging/media/zoran/zoran_procfs.h
>   drivers/staging/media/zoran/zr36016.c
>   drivers/staging/media/zoran/zr36016.h
>   drivers/staging/media/zoran/zr36050.c
>   drivers/staging/media/zoran/zr36050.h
>   drivers/staging/media/zoran/zr36057.h
>   drivers/staging/media/zoran/zr36060.c
>   drivers/staging/media/zoran/zr36060.h
> 
> between commit:
> 
>   8dce4b265a53 ("media: zoran: remove deprecated driver")
> 
> from the v4l-dvb tree and various commits from the staging tree.
> 
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the v4l-dvb tree and Linus' tree.
-- 
Cheers,
Stephen Rothwell


pgpSs6suUbWER.pgp
Description: OpenPGP digital signature

[for-next][PATCH 3/3] tracing: kdb: Allow ftdump to skip all but the last few entries

[Steven Rostedt]

From: Douglas Anderson 

The 'ftdump' command in kdb is currently a bit of a last resort, at
least if you have lots of traces turned on.  It's going to print a
whole boatload of data out your serial port which is probably running
at 115200.  This could easily take many, many minutes.

Usually you're most interested in what's at the _end_ of the ftrace
buffer, AKA what happened most recently.  That means you've got to
wait the full time for the dump.  The 'ftdump' command does attempt to
help you a little bit by allowing you to skip a fixed number of
entries.  Unfortunately it provides no way for you to know how many
entries you should skip.

Let's do similar to python and allow you to use a negative number to
indicate that you want to skip all entries except the last few.  This
allows you to quickly see what you want.

Note that we also change the printout in ftdump to print the
(positive) number of entries actually skipped since that could be
helpful to know when you've specified a negative skip count.

Link: http://lkml.kernel.org/r/20190319171206.97107-3-diand...@chromium.org

Signed-off-by: Douglas Anderson 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/trace_kdb.c | 45 +++-
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c
index 4b43d69f..6c1ae6b752d1 100644
--- a/kernel/trace/trace_kdb.c
+++ b/kernel/trace/trace_kdb.c
@@ -17,29 +17,25 @@
 #include "trace.h"
 #include "trace_output.h"
 
+static struct trace_iterator iter;
+static struct ring_buffer_iter *buffer_iter[CONFIG_NR_CPUS];
+
 static void ftrace_dump_buf(int skip_entries, long cpu_file)
 {
-   /* use static because iter can be a bit big for the stack */
-   static struct trace_iterator iter;
-   static struct ring_buffer_iter *buffer_iter[CONFIG_NR_CPUS];
struct trace_array *tr;
unsigned int old_userobj;
int cnt = 0, cpu;
 
-   trace_init_global_iter();
-   iter.buffer_iter = buffer_iter;
tr = iter.tr;
 
-   for_each_tracing_cpu(cpu) {
-   atomic_inc(_cpu_ptr(iter.trace_buffer->data, 
cpu)->disabled);
-   }
-
old_userobj = tr->trace_flags;
 
/* don't look at user memory in panic mode */
tr->trace_flags &= ~TRACE_ITER_SYM_USEROBJ;
 
kdb_printf("Dumping ftrace buffer:\n");
+   if (skip_entries)
+   kdb_printf("(skipping %d entries)\n", skip_entries);
 
/* reset all but tr, trace, and overruns */
memset(, 0,
@@ -89,10 +85,6 @@ static void ftrace_dump_buf(int skip_entries, long cpu_file)
 out:
tr->trace_flags = old_userobj;
 
-   for_each_tracing_cpu(cpu) {
-   atomic_dec(_cpu_ptr(iter.trace_buffer->data, 
cpu)->disabled);
-   }
-
for_each_tracing_cpu(cpu) {
if (iter.buffer_iter[cpu]) {
ring_buffer_read_finish(iter.buffer_iter[cpu]);
@@ -109,6 +101,8 @@ static int kdb_ftdump(int argc, const char **argv)
int skip_entries = 0;
long cpu_file;
char *cp;
+   int cnt;
+   int cpu;
 
if (argc > 2)
return KDB_ARGCOUNT;
@@ -129,7 +123,29 @@ static int kdb_ftdump(int argc, const char **argv)
}
 
kdb_trap_printk++;
+
+   trace_init_global_iter();
+   iter.buffer_iter = buffer_iter;
+
+   for_each_tracing_cpu(cpu) {
+   atomic_inc(_cpu_ptr(iter.trace_buffer->data, 
cpu)->disabled);
+   }
+
+   /* A negative skip_entries means skip all but the last entries */
+   if (skip_entries < 0) {
+   if (cpu_file == RING_BUFFER_ALL_CPUS)
+   cnt = trace_total_entries(NULL);
+   else
+   cnt = trace_total_entries_cpu(NULL, cpu_file);
+   skip_entries = max(cnt + skip_entries, 0);
+   }
+
ftrace_dump_buf(skip_entries, cpu_file);
+
+   for_each_tracing_cpu(cpu) {
+   atomic_dec(_cpu_ptr(iter.trace_buffer->data, 
cpu)->disabled);
+   }
+
kdb_trap_printk--;
 
return 0;
@@ -138,7 +154,8 @@ static int kdb_ftdump(int argc, const char **argv)
 static __init int kdb_ftrace_register(void)
 {
kdb_register_flags("ftdump", kdb_ftdump, "[skip_#entries] [cpu]",
-   "Dump ftrace log", 0, KDB_ENABLE_ALWAYS_SAFE);
+   "Dump ftrace log; -skip dumps last #entries", 0,
+   KDB_ENABLE_ALWAYS_SAFE);
return 0;
 }
 
-- 
2.20.1

[for-next][PATCH 1/3] tracing: kdb: The skip_lines parameter should have been skip_entries

[Steven Rostedt]

From: Douglas Anderson 

The things skipped by kdb's "ftdump" command when you pass it a
parameter has always been entries, not lines.  The difference usually
doesn't matter but when the trace buffer has multi-line entries (like
a stack dump) it can matter.

Let's fix this both in the help text for ftdump and also in the local
variable names.

Link: http://lkml.kernel.org/r/20190319171206.97107-1-diand...@chromium.org

Acked-by: Daniel Thompson 
Signed-off-by: Douglas Anderson 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/trace_kdb.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c
index 810d78a8d14c..4b43d69f 100644
--- a/kernel/trace/trace_kdb.c
+++ b/kernel/trace/trace_kdb.c
@@ -17,7 +17,7 @@
 #include "trace.h"
 #include "trace_output.h"
 
-static void ftrace_dump_buf(int skip_lines, long cpu_file)
+static void ftrace_dump_buf(int skip_entries, long cpu_file)
 {
/* use static because iter can be a bit big for the stack */
static struct trace_iterator iter;
@@ -70,11 +70,11 @@ static void ftrace_dump_buf(int skip_lines, long cpu_file)
kdb_printf("-\n");
cnt++;
 
-   if (!skip_lines) {
+   if (!skip_entries) {
print_trace_line();
trace_printk_seq();
} else {
-   skip_lines--;
+   skip_entries--;
}
 
if (KDB_FLAG(CMD_INTERRUPT))
@@ -106,7 +106,7 @@ static void ftrace_dump_buf(int skip_lines, long cpu_file)
  */
 static int kdb_ftdump(int argc, const char **argv)
 {
-   int skip_lines = 0;
+   int skip_entries = 0;
long cpu_file;
char *cp;
 
@@ -114,9 +114,9 @@ static int kdb_ftdump(int argc, const char **argv)
return KDB_ARGCOUNT;
 
if (argc) {
-   skip_lines = simple_strtol(argv[1], , 0);
+   skip_entries = simple_strtol(argv[1], , 0);
if (*cp)
-   skip_lines = 0;
+   skip_entries = 0;
}
 
if (argc == 2) {
@@ -129,7 +129,7 @@ static int kdb_ftdump(int argc, const char **argv)
}
 
kdb_trap_printk++;
-   ftrace_dump_buf(skip_lines, cpu_file);
+   ftrace_dump_buf(skip_entries, cpu_file);
kdb_trap_printk--;
 
return 0;
@@ -137,7 +137,7 @@ static int kdb_ftdump(int argc, const char **argv)
 
 static __init int kdb_ftrace_register(void)
 {
-   kdb_register_flags("ftdump", kdb_ftdump, "[skip_#lines] [cpu]",
+   kdb_register_flags("ftdump", kdb_ftdump, "[skip_#entries] [cpu]",
"Dump ftrace log", 0, KDB_ENABLE_ALWAYS_SAFE);
return 0;
 }
-- 
2.20.1

[for-next][PATCH 0/3] tracing: Some updates before the pull request

[Steven Rostedt]

I had this in my queue for some time, but never posted it to next.

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 03197fc02b356606355d7ede343b18e3e3737771


Douglas Anderson (3):
  tracing: kdb: The skip_lines parameter should have been skip_entries
  tracing: Add trace_total_entries() / trace_total_entries_cpu()
  tracing: kdb: Allow ftdump to skip all but the last few entries


 kernel/trace/trace.c | 65 +---
 kernel/trace/trace.h |  3 +++
 kernel/trace/trace_kdb.c | 61 +
 3 files changed, 92 insertions(+), 37 deletions(-)

[for-next][PATCH 2/3] tracing: Add trace_total_entries() / trace_total_entries_cpu()

[Steven Rostedt]

From: Douglas Anderson 

These two new exported functions will be used in a future patch by
kdb_ftdump() to quickly skip all but the last few trace entries.

Link: http://lkml.kernel.org/r/20190319171206.97107-2-diand...@chromium.org

Acked-by: Daniel Thompson 
Suggested-by: Steven Rostedt 
Signed-off-by: Douglas Anderson 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/trace/trace.c | 65 ++--
 kernel/trace/trace.h |  3 ++
 2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2bc18de7f0dc..dcb9adb44be9 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3492,34 +3492,69 @@ static void s_stop(struct seq_file *m, void *p)
trace_event_read_unlock();
 }
 
+static void
+get_total_entries_cpu(struct trace_buffer *buf, unsigned long *total,
+ unsigned long *entries, int cpu)
+{
+   unsigned long count;
+
+   count = ring_buffer_entries_cpu(buf->buffer, cpu);
+   /*
+* If this buffer has skipped entries, then we hold all
+* entries for the trace and we need to ignore the
+* ones before the time stamp.
+*/
+   if (per_cpu_ptr(buf->data, cpu)->skipped_entries) {
+   count -= per_cpu_ptr(buf->data, cpu)->skipped_entries;
+   /* total is the same as the entries */
+   *total = count;
+   } else
+   *total = count +
+   ring_buffer_overrun_cpu(buf->buffer, cpu);
+   *entries = count;
+}
+
 static void
 get_total_entries(struct trace_buffer *buf,
  unsigned long *total, unsigned long *entries)
 {
-   unsigned long count;
+   unsigned long t, e;
int cpu;
 
*total = 0;
*entries = 0;
 
for_each_tracing_cpu(cpu) {
-   count = ring_buffer_entries_cpu(buf->buffer, cpu);
-   /*
-* If this buffer has skipped entries, then we hold all
-* entries for the trace and we need to ignore the
-* ones before the time stamp.
-*/
-   if (per_cpu_ptr(buf->data, cpu)->skipped_entries) {
-   count -= per_cpu_ptr(buf->data, cpu)->skipped_entries;
-   /* total is the same as the entries */
-   *total += count;
-   } else
-   *total += count +
-   ring_buffer_overrun_cpu(buf->buffer, cpu);
-   *entries += count;
+   get_total_entries_cpu(buf, , , cpu);
+   *total += t;
+   *entries += e;
}
 }
 
+unsigned long trace_total_entries_cpu(struct trace_array *tr, int cpu)
+{
+   unsigned long total, entries;
+
+   if (!tr)
+   tr = _trace;
+
+   get_total_entries_cpu(>trace_buffer, , , cpu);
+
+   return entries;
+}
+
+unsigned long trace_total_entries(struct trace_array *tr)
+{
+   unsigned long total, entries;
+
+   if (!tr)
+   tr = _trace;
+
+   get_total_entries(>trace_buffer, , );
+
+   return entries;
+}
+
 static void print_lat_help_header(struct seq_file *m)
 {
seq_puts(m, "#  _--=> CPU#\n"
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index da00a3d508c1..33f14b9e78b7 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -721,6 +721,9 @@ void trace_init_global_iter(struct trace_iterator *iter);
 
 void tracing_iter_reset(struct trace_iterator *iter, int cpu);
 
+unsigned long trace_total_entries_cpu(struct trace_array *tr, int cpu);
+unsigned long trace_total_entries(struct trace_array *tr);
+
 void trace_function(struct trace_array *tr,
unsigned long ip,
unsigned long parent_ip,
-- 
2.20.1

[PATCH] percpu: remove spurious lock dependency between percpu and sched

[John Sperbeck]

In free_percpu() we sometimes call pcpu_schedule_balance_work() to
queue a work item (which does a wakeup) while holding pcpu_lock.
This creates an unnecessary lock dependency between pcpu_lock and
the scheduler's pi_lock.  There are other places where we call
pcpu_schedule_balance_work() without hold pcpu_lock, and this case
doesn't need to be different.

Moving the call outside the lock prevents the following lockdep splat
when running tools/testing/selftests/bpf/{test_maps,test_progs} in
sequence with lockdep enabled:

==
WARNING: possible circular locking dependency detected
5.1.0-dbg-DEV #1 Not tainted
--
kworker/23:255/18872 is trying to acquire lock:
0bc79290 (&(>lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520

but task is already holding lock:
e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #4 (pcpu_lock){..-.}:
   lock_acquire+0x9e/0x180
   _raw_spin_lock_irqsave+0x3a/0x50
   pcpu_alloc+0xfa/0x780
   __alloc_percpu_gfp+0x12/0x20
   alloc_htab_elem+0x184/0x2b0
   __htab_percpu_map_update_elem+0x252/0x290
   bpf_percpu_hash_update+0x7c/0x130
   __do_sys_bpf+0x1912/0x1be0
   __x64_sys_bpf+0x1a/0x20
   do_syscall_64+0x59/0x400
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #3 (>buckets[i].lock){}:
   lock_acquire+0x9e/0x180
   _raw_spin_lock_irqsave+0x3a/0x50
   htab_map_update_elem+0x1af/0x3a0

-> #2 (>lock){-.-.}:
   lock_acquire+0x9e/0x180
   _raw_spin_lock+0x2f/0x40
   task_fork_fair+0x37/0x160
   sched_fork+0x211/0x310
   copy_process.part.43+0x7b1/0x2160
   _do_fork+0xda/0x6b0
   kernel_thread+0x29/0x30
   rest_init+0x22/0x260
   arch_call_rest_init+0xe/0x10
   start_kernel+0x4fd/0x520
   x86_64_start_reservations+0x24/0x26
   x86_64_start_kernel+0x6f/0x72
   secondary_startup_64+0xa4/0xb0

-> #1 (>pi_lock){-.-.}:
   lock_acquire+0x9e/0x180
   _raw_spin_lock_irqsave+0x3a/0x50
   try_to_wake_up+0x41/0x600
   wake_up_process+0x15/0x20
   create_worker+0x16b/0x1e0
   workqueue_init+0x279/0x2ee
   kernel_init_freeable+0xf7/0x288
   kernel_init+0xf/0x180
   ret_from_fork+0x24/0x30

-> #0 (&(>lock)->rlock){-.-.}:
   __lock_acquire+0x101f/0x12a0
   lock_acquire+0x9e/0x180
   _raw_spin_lock+0x2f/0x40
   __queue_work+0xb2/0x520
   queue_work_on+0x38/0x80
   free_percpu+0x221/0x260
   pcpu_freelist_destroy+0x11/0x20
   stack_map_free+0x2a/0x40
   bpf_map_free_deferred+0x3c/0x50
   process_one_work+0x1f7/0x580
   worker_thread+0x54/0x410
   kthread+0x10f/0x150
   ret_from_fork+0x24/0x30

other info that might help us debug this:

Chain exists of:
  &(>lock)->rlock --> >buckets[i].lock --> pcpu_lock

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(pcpu_lock);
   lock(>buckets[i].lock);
   lock(pcpu_lock);
  lock(&(>lock)->rlock);

 *** DEADLOCK ***

3 locks held by kworker/23:255/18872:
 #0: b36a6e16 ((wq_completion)events){+.+.},
 at: process_one_work+0x17a/0x580
 #1: dfd966f0 ((work_completion)(>work)){+.+.},
 at: process_one_work+0x17a/0x580
 #2: e3e7a6aa (pcpu_lock){..-.},
 at: free_percpu+0x36/0x260

stack backtrace:
CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1
Hardware name: ...
Workqueue: events bpf_map_free_deferred
Call Trace:
 dump_stack+0x67/0x95
 print_circular_bug.isra.38+0x1c6/0x220
 check_prev_add.constprop.50+0x9f6/0xd20
 __lock_acquire+0x101f/0x12a0
 lock_acquire+0x9e/0x180
 _raw_spin_lock+0x2f/0x40
 __queue_work+0xb2/0x520
 queue_work_on+0x38/0x80
 free_percpu+0x221/0x260
 pcpu_freelist_destroy+0x11/0x20
 stack_map_free+0x2a/0x40
 bpf_map_free_deferred+0x3c/0x50
 process_one_work+0x1f7/0x580
 worker_thread+0x54/0x410
 kthread+0x10f/0x150
 ret_from_fork+0x24/0x30

Signed-off-by: John Sperbeck 
---
 mm/percpu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/percpu.c b/mm/percpu.c
index 68dd2e7e73b5..d832793bf83a 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1738,6 +1738,7 @@ void free_percpu(void __percpu *ptr)
struct pcpu_chunk *chunk;
unsigned long flags;
int off;
+   bool need_balance = false;
 
if (!ptr)
return;
@@ -1759,7 +1760,7 @@ void free_percpu(void __percpu *ptr)
 
list_for_each_entry(pos, _slot[pcpu_nr_slots - 1], list)
if (pos != chunk) {
-   pcpu_schedule_balance_work();
+   need_balance = true;
break;
}
}
@@ -1767,6 +1768,9 @@ void 

Re: [tip:sched/core] sched/isolation: Require a present CPU in housekeeping mask

[Nicholas Piggin]

Frederic Weisbecker's on May 8, 2019 10:35 am:
> On Tue, May 07, 2019 at 09:50:24AM +1000, Nicholas Piggin wrote:
>> Frederic Weisbecker's on May 7, 2019 1:16 am:
>> > On Sat, May 04, 2019 at 04:59:12PM +1000, Nicholas Piggin wrote:
>> >> Frederic Weisbecker's on May 4, 2019 10:27 am:
>> >> > On Fri, May 03, 2019 at 10:47:37AM -0700, tip-bot for Nicholas Piggin 
>> >> > wrote:
>> >> >> Commit-ID:  9219565aa89033a9cfdae788c1940473a1253d6c
>> >> >> Gitweb: 
>> >> >> https://git.kernel.org/tip/9219565aa89033a9cfdae788c1940473a1253d6c
>> >> >> Author: Nicholas Piggin 
>> >> >> AuthorDate: Thu, 11 Apr 2019 13:34:47 +1000
>> >> >> Committer:  Ingo Molnar 
>> >> >> CommitDate: Fri, 3 May 2019 19:42:58 +0200
>> >> >> 
>> >> >> sched/isolation: Require a present CPU in housekeeping mask
>> >> >> 
>> >> >> During housekeeping mask setup, currently a possible CPU is required.
>> >> >> That does not guarantee the CPU would be available at boot time, so
>> >> >> check to ensure that at least one present CPU is in the mask.
>> >> > 
>> >> > I have a doubt about the requirements and semantics of cpu_present_mask.
>> >> > IIUC a present CPU means that it is physically plugged in (from ACPI
>> >> > perspective) but might not be logically plugged in (set on 
>> >> > cpu_online_mask).
>> >> 
>> >> Right, a superset of cpu_possible_mask, subset of cpu_online_mask. It 
>> >> means that CPU can be brought online at any time.
>> >> 
>> >> > But do we have the guarantee that a present CPU _will_ be online at 
>> >> > least once
>> >> > right after the boot? After all, kernel parameters such as "maxcpus=" 
>> >> > can prevent
>> >> > from turning some CPUs on. I guess there are even more creative ways to 
>> >> > achieve
>> >> > that.
>> >> > 
>> >> > In any case we really require the housekeeper to be forced online. 
>> >> > Perhaps
>> >> > I missed that enforcement somewhere in the patchset?
>> >> 
>> >> No I think you're right, that may be able to boot without anything in
>> >> the housekeeping mask. Maybe we can just cpu_up() a CPU in the 
>> >> housekeeping mask with a warning that it has overidden their SMP
>> >> command line option. I'll take a look at it.
>> > 
>> > But then what if cpu_up() fails? In this case I can think of only two
>> > answers:
>> > 
>> > * Force the boot CPU as the housekeeper.
>> > * Rollback the whole thing: nohz and all isolation.
>> 
>> If cpu_up fails despite being in the present map and we explicitly
>> selected it as the housekeeper? I think it would be okay to print
>> a message telling admin to correct the config, and panic.
>> 
>> We try a best effort to make the system boot and limp along, but if
>> you misconfigure it, crashing is not unreasonable. There's lots of
>> command line option misconfiguration that will cause the same thing.
>> 
>> The primary problem with my patch that needs to be addressed is that
>> the error is not explicitly caught and printed if the housekeeper
>> does not come up, so the system might die in non-obvious ways.
> 
> I usually reserve panic and BUG_ON() to last resort when data integrity is
> directly threatened. But indeed I guess that's all we have for now.

Right, specifying a CPU for housekeeping that excluded from coming
up at boot with maxcpus= or whatever, is not such a big deal to
panic I think. Just need to have a clear error message.

> If we take that path, I'd rather not call that cpu_up() and simply panic if
> the given CPU happens not to be online after SMP bootup.

Sure that's fine by me too.

Thanks,
Nick

[PATCH v3 1/2] net: phy: realtek: Add rtl8211e rx/tx delays config

[Serge Semin]

There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
delays to TXC and RXC for TXD/RXD latching. Alas this is the only
documented info regarding the RGMII timing control configurations the PHY
provides. It turns out the same settings can be setup via MDIO registers
hidden in the extension pages layout. Particularly the extension page 0xa4
provides a register 0x1c, which bits 1 and 2 control the described delays.
They are used to implement the "rgmii-{id,rxid,txid}" phy-mode.

The hidden RGMII configs register utilization was found in the rtl8211e
U-boot driver:
https://elixir.bootlin.com/u-boot/v2019.01/source/drivers/net/phy/realtek.c#L99

There is also a freebsd-folks discussion regarding this register:
https://reviews.freebsd.org/D13591

It confirms that the register bits field must control the so called
configuration pins described in the table 12-13 of the official PHY
datasheet:
8:6 = PHY Address
5:4 = Auto-Negotiation
3 = Interface Mode Select
2 = RX Delay
1 = TX Delay
0 = SELRGV

Reviewed-by: Andrew Lunn 
Signed-off-by: Serge Semin 

---
Changelog v2
- Disable delays for rgmii mode and leave them as is for the rest of
  the modes.
- Remove genphy_config_init() invocation. It's redundant for rtl8211e phy.
- Fix confused return value checking of extended-page selector call.
- Fix commit message typos.

Changelog v3
- Add Andrew' Reviewed-by tag
- Initialize ret with 0 to prevent the "may be used uninitialized" warning.
---
 drivers/net/phy/realtek.c | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 10df52ccddfe..d27f072f227b 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -23,11 +23,15 @@
 
 #define RTL821x_INSR   0x13
 
+#define RTL821x_EXT_PAGE_SELECT0x1e
 #define RTL821x_PAGE_SELECT0x1f
 
 #define RTL8211F_INSR  0x1d
 
 #define RTL8211F_TX_DELAY  BIT(8)
+#define RTL8211E_TX_DELAY  BIT(1)
+#define RTL8211E_RX_DELAY  BIT(2)
+#define RTL8211E_MODE_MII_GMII BIT(3)
 
 #define RTL8201F_ISR   0x1e
 #define RTL8201F_IER   0x13
@@ -174,6 +178,52 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return phy_modify_paged(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, val);
 }
 
+static int rtl8211e_config_init(struct phy_device *phydev)
+{
+   int ret = 0, oldpage;
+   u16 val;
+
+   /* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
+   switch (phydev->interface) {
+   case PHY_INTERFACE_MODE_RGMII:
+   val = 0;
+   break;
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   val = RTL8211E_TX_DELAY | RTL8211E_RX_DELAY;
+   break;
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   val = RTL8211E_RX_DELAY;
+   break;
+   case PHY_INTERFACE_MODE_RGMII_TXID:
+   val = RTL8211E_TX_DELAY;
+   break;
+   default: /* the rest of the modes imply leaving delays as is. */
+   return 0;
+   }
+
+   /* According to a sample driver there is a 0x1c config register on the
+* 0xa4 extension page (0x7) layout. It can be used to disable/enable
+* the RX/TX delays otherwise controlled by hardware strobes. It can
+* also be used to customize the whole configuration register:
+* 8:6 = PHY Address, 5:4 = Auto-Negotiation, 3 = Interface Mode Select,
+* 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
+* for details).
+*/
+   oldpage = phy_select_page(phydev, 0x7);
+   if (oldpage < 0)
+   goto err_restore_page;
+
+   ret = phy_write(phydev, RTL821x_EXT_PAGE_SELECT, 0xa4);
+   if (ret)
+   goto err_restore_page;
+
+   ret = phy_modify(phydev, 0x1c, RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
+val);
+
+err_restore_page:
+   return phy_restore_page(phydev, oldpage, ret);
+}
+
 static int rtl8211b_suspend(struct phy_device *phydev)
 {
phy_write(phydev, MII_MMD_DATA, BIT(9));
@@ -257,6 +307,7 @@ static struct phy_driver realtek_drvs[] = {
PHY_ID_MATCH_EXACT(0x001cc915),
.name   = "RTL8211E Gigabit Ethernet",
.features   = PHY_GBIT_FEATURES,
+   .config_init= _config_init,
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
.suspend= genphy_suspend,
-- 
2.21.0

Re: [PATCH] arm: socfpga: execute cold reboot by default

[Dinh Nguyen]

On 5/3/19 4:15 AM, Simon Goldschmidt wrote:
> This changes system reboot for socfpga to issue a cold reboot by
> default instead of a warm reboot.
> 
> Warm reboot can still be used by setting reboot_mode to
> REBOOT_WARM (e.g. via kernel command line 'reboot='), but this
> patch ensures cold reboot is issued for both REBOOT_COLD and
> REBOOT_HARD.
> 
> Also, cold reboot is more fail safe than warm reboot has some
> issues at least fo CSEL=0 and BSEL=qspi, where the boot rom does
> not set the qspi clock to a valid range.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> See discussion in this thread on the u-boot ML:
> https://lists.denx.de/pipermail/u-boot/2019-April/367463.html
> ---
>  arch/arm/mach-socfpga/socfpga.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index 816da0eb6..6abfbf140 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -85,10 +85,10 @@ static void socfpga_cyclone5_restart(enum reboot_mode 
> mode, const char *cmd)
>  
>   temp = readl(rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>  
> - if (mode == REBOOT_HARD)
> - temp |= RSTMGR_CTRL_SWCOLDRSTREQ;
> - else
> + if (mode == REBOOT_WARM)
>   temp |= RSTMGR_CTRL_SWWARMRSTREQ;
> + else
> + temp |= RSTMGR_CTRL_SWCOLDRSTREQ;
>   writel(temp, rst_manager_base_addr + SOCFPGA_RSTMGR_CTRL);
>  }
>  
> @@ -98,10 +98,10 @@ static void socfpga_arria10_restart(enum reboot_mode 
> mode, const char *cmd)
>  
>   temp = readl(rst_manager_base_addr + SOCFPGA_A10_RSTMGR_CTRL);
>  
> - if (mode == REBOOT_HARD)
> - temp |= RSTMGR_CTRL_SWCOLDRSTREQ;
> - else
> + if (mode == REBOOT_WARM)
>   temp |= RSTMGR_CTRL_SWWARMRSTREQ;
> + else
> + temp |= RSTMGR_CTRL_SWCOLDRSTREQ;
>   writel(temp, rst_manager_base_addr + SOCFPGA_A10_RSTMGR_CTRL);
>  }
>  
> 

Applied, thanks! I think this patch needs to get back-ported into stable
kernel version as well, right?

Dinh

[PATCH] dwmac4_prog_mtl_tx_algorithms() missing write operation

[Cheng Han]

Signed-off-by: Cheng Han 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 7e5d5db..b4bb562 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -192,6 +192,8 @@ static void dwmac4_prog_mtl_tx_algorithms(struct 
mac_device_info *hw,
default:
break;
}
+
+   writel(value, ioaddr + MTL_OPERATION_MODE);
 }
 
 static void dwmac4_set_mtl_tx_queue_weight(struct mac_device_info *hw,
-- 
1.9.1

Re: [GIT PULL] fscrypt updates for 5.2

[Eric Biggers]

On Tue, May 07, 2019 at 07:30:42PM -0400, Theodore Ts'o wrote:
> The following changes since commit dc4060a5dc2557e6b5aa813bf5b73677299d62d2:
> 
>   Linux 5.1-rc5 (2019-04-14 15:17:41 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt_for_linus
> 
> for you to fetch changes up to 2c58d548f5706d085c4b009f6abb945220460632:
> 
>   fscrypt: cache decrypted symlink target in ->i_link (2019-04-17 12:43:29 
> -0400)
> 
> 
> Clean up fscrypt's dcache revalidation support, and other
> miscellaneous cleanups.
> 
> 
> Eric Biggers (10):
>   fscrypt: drop inode argument from fscrypt_get_ctx()
>   fscrypt: remove WARN_ON_ONCE() when decryption fails
>   fscrypt: use READ_ONCE() to access ->i_crypt_info
>   fscrypt: clean up and improve dentry revalidation
>   fscrypt: fix race allowing rename() and link() of ciphertext dentries
>   fs, fscrypt: clear DCACHE_ENCRYPTED_NAME when unaliasing directory
>   fscrypt: only set dentry_operations on ciphertext dentries
>   fscrypt: fix race where ->lookup() marks plaintext dentry as ciphertext
>   vfs: use READ_ONCE() to access ->i_link
>   fscrypt: cache decrypted symlink target in ->i_link
> 

There will be a merge conflict between "fscrypt: cache decrypted symlink target
in ->i_link", and "ext4: make use of ->free_inode()" and "f2fs: switch to
->free_inode()".  The correct resolutions should be fairly straightforward:

static void ext4_free_in_core_inode(struct inode *inode)
{
fscrypt_free_inode(inode);
kmem_cache_free(ext4_inode_cachep, EXT4_I(inode));
}

and

static void f2fs_free_inode(struct inode *inode)
{
fscrypt_free_inode(inode);
kmem_cache_free(f2fs_inode_cachep, F2FS_I(inode));
}

- Eric

[PATCHv3 2/2] mtd: spi-nor: cadence-quadspi: add reset control

[Dinh Nguyen]

Get the reset control properties for the QSPI controller and bring them
out of reset. Most will have just one reset bit, but there is an additional
OCP reset bit that is used ECC. The OCP reset bit will also need to get
de-asserted as well. [1]

[1] 
https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#reg_soc_top/sfo1429890575955.html

Suggested-by: Tien-Fong Chee 
Signed-off-by: Dinh Nguyen 
---
v3: return full error by using PTR_ERR(rtsc)
move reset control calls until after the clock enables
use udelay(2) to be safe
Add optional OCP(Open Core Protocol) reset signal
v2: use devm_reset_control_get_optional_exclusive
print an error message
return -EPROBE_DEFER
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 30 +++
 1 file changed, 30 insertions(+)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 792628750eec..b9f138767d9e 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1336,6 +1337,8 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
+   struct reset_control *rstc;
+   struct reset_control *rstc_ocp;
const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1402,6 +1405,33 @@ static int cqspi_probe(struct platform_device *pdev)
goto probe_clk_failed;
}
 
+   /* Obtain QSPI reset control */
+   rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
+   if (IS_ERR(rstc)) {
+   dev_err(dev, "Cannot get QSPI reset.\n");
+   if (PTR_ERR(rstc) == -EPROBE_DEFER)
+   return PTR_ERR(rstc);
+   }
+
+   rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
+   if (IS_ERR(rstc_ocp)) {
+   dev_err(dev, "Cannot get QSPI OCP reset.\n");
+   if (PTR_ERR(rstc_ocp) == -EPROBE_DEFER)
+   return PTR_ERR(rstc_ocp);
+   }
+
+   if (rtsc) {
+   reset_control_assert(rstc);
+   udelay(2);
+   reset_control_deassert(rstc);
+   }
+
+   if (rtsc_ocp) {
+   reset_control_assert(rstc_ocp);
+   udelay(2);
+   reset_control_deassert(rstc_ocp);
+   }
+
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
ddata  = of_device_get_match_data(dev);
if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
-- 
2.20.0

[PATCHv3 1/2] dt-bindings: cadence-quadspi: add options reset property

[Dinh Nguyen]

The QSPI module can have an optional reset signals that will hold the
module in a reset state.

Signed-off-by: Dinh Nguyen 
---
 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index 4345c3a6f530..b6264323a03c 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -35,6 +35,8 @@ custom properties:
  (qspi_n_ss_out).
 - cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
   and first bit transfer.
+- resets   : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
 
 Example:
 
@@ -50,6 +52,8 @@ Example:
cdns,fifo-depth = <128>;
cdns,fifo-width = <4>;
cdns,trigger-address = <0x>;
+   resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
+   reset-names = "qspi", "qspi-ocp";
 
flash0: n25q00@0 {
...
-- 
2.20.0

Re: linux-next: manual merge of the vfs tree with the orangefs tree

[Stephen Rothwell]

Hi all,

On Fri, 3 May 2019 11:15:10 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/orangefs/super.c
> 
> between commit:
> 
>   77becb76042a ("orangefs: implement xattr cache")
> 
> from the orangefs tree and commit:
> 
>   f276ae0dd6d0 ("orangefs: make use of ->free_inode()")
> 
> from the vfs 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 fs/orangefs/super.c
> index 8fa30c13b7ed,3784f7e8b603..
> --- a/fs/orangefs/super.c
> +++ b/fs/orangefs/super.c
> @@@ -125,20 -124,9 +125,19 @@@ static struct inode *orangefs_alloc_ino
>   return _inode->vfs_inode;
>   }
>   
> - static void orangefs_i_callback(struct rcu_head *head)
> + static void orangefs_free_inode(struct inode *inode)
>   {
> - struct inode *inode = container_of(head, struct inode, i_rcu);
>  -kmem_cache_free(orangefs_inode_cache, ORANGEFS_I(inode));
>  +struct orangefs_inode_s *orangefs_inode = ORANGEFS_I(inode);
>  +struct orangefs_cached_xattr *cx;
>  +struct hlist_node *tmp;
>  +int i;
>  +
>  +hash_for_each_safe(orangefs_inode->xattr_cache, i, tmp, cx, node) {
>  +hlist_del(>node);
>  +kfree(cx);
>  +}
>  +
>  +kmem_cache_free(orangefs_inode_cache, orangefs_inode);
>   }
>   
>   static void orangefs_destroy_inode(struct inode *inode)
> @@@ -148,17 -136,8 +147,15 @@@
>   gossip_debug(GOSSIP_SUPER_DEBUG,
>   "%s: deallocated %p destroying inode %pU\n",
>   __func__, orangefs_inode, get_khandle_from_ino(inode));
> - 
> - call_rcu(>i_rcu, orangefs_i_callback);
>   }
>   
>  +static int orangefs_write_inode(struct inode *inode,
>  +struct writeback_control *wbc)
>  +{
>  +gossip_debug(GOSSIP_SUPER_DEBUG, "orangefs_write_inode\n");
>  +return orangefs_inode_setattr(inode);
>  +}
>  +
>   /*
>* NOTE: information filled in here is typically reflected in the
>* output of the system command 'df'
> @@@ -316,8 -295,8 +313,9 @@@ void fsid_key_table_finalize(void
>   
>   static const struct super_operations orangefs_s_ops = {
>   .alloc_inode = orangefs_alloc_inode,
> + .free_inode = orangefs_free_inode,
>   .destroy_inode = orangefs_destroy_inode,
>  +.write_inode = orangefs_write_inode,
>   .drop_inode = generic_delete_inode,
>   .statfs = orangefs_statfs,
>   .remount_fs = orangefs_remount_fs,

This is now a conflict between the orangefs tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpcL5AYYYQvg.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the vfs tree with the fscrypt tree

[Stephen Rothwell]

Hi all,

On Fri, 3 May 2019 11:09:51 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/ext4/super.c
>   fs/f2fs/super.c
> 
> between commit:
> 
>   2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link")
> 
> from the fscrypt tree and commits:
> 
>   94053139d482 ("ext4: make use of ->free_inode()")
>   d01718a050d0 ("f2fs: switch to ->free_inode()")
> 
> from the vfs 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.
> 
> Thanks, Al, for the heads up and example merge.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/ext4/super.c
> index 489cdeeab789,981f702848e7..
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@@ -,12 -1107,8 +,9 @@@ static int ext4_drop_inode(struct inod
>   return drop;
>   }
>   
> - static void ext4_i_callback(struct rcu_head *head)
> + static void ext4_free_in_core_inode(struct inode *inode)
>   {
> - struct inode *inode = container_of(head, struct inode, i_rcu);
> - 
>  +fscrypt_free_inode(inode);
> - 
>   kmem_cache_free(ext4_inode_cachep, EXT4_I(inode));
>   }
>   
> diff --cc fs/f2fs/super.c
> index f7605b3ff1f9,9924eac76254..
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@@ -1000,12 -1000,8 +1000,9 @@@ static void f2fs_dirty_inode(struct ino
>   f2fs_inode_dirtied(inode, false);
>   }
>   
> - static void f2fs_i_callback(struct rcu_head *head)
> + static void f2fs_free_inode(struct inode *inode)
>   {
> - struct inode *inode = container_of(head, struct inode, i_rcu);
> - 
>  +fscrypt_free_inode(inode);
> - 
>   kmem_cache_free(f2fs_inode_cachep, F2FS_I(inode));
>   }
>   

This is now a conflict between the fscrypt tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpHfko0Vep9m.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the vfs tree with the fuse tree

[Stephen Rothwell]

Hi all,

On Tue, 7 May 2019 09:53:23 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/fuse/inode.c
> 
> between commit:
> 
>   829f949b6e06 ("fuse: clean up fuse_alloc_inode")
> 
> from the fuse tree and commit:
> 
>   9baf28bbfea1 ("fuse: switch to ->free_inode()")
> 
> from the vfs 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 fs/fuse/inode.c
> index bc02bad1be7c,f485d09d14df..
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@@ -102,25 -104,16 +102,16 @@@ static struct inode *fuse_alloc_inode(s
>   return NULL;
>   }
>   
>  -return inode;
>  +return >inode;
>   }
>   
> - static void fuse_i_callback(struct rcu_head *head)
> - {
> - struct inode *inode = container_of(head, struct inode, i_rcu);
> - kmem_cache_free(fuse_inode_cachep, get_fuse_inode(inode));
> - }
> - 
> - static void fuse_destroy_inode(struct inode *inode)
> + static void fuse_free_inode(struct inode *inode)
>   {
>   struct fuse_inode *fi = get_fuse_inode(inode);
> - if (S_ISREG(inode->i_mode) && !is_bad_inode(inode)) {
> - WARN_ON(!list_empty(>write_files));
> - WARN_ON(!list_empty(>queued_writes));
> - }
> + 
>   mutex_destroy(>mutex);
>   kfree(fi->forget);
> - call_rcu(>i_rcu, fuse_i_callback);
> + kmem_cache_free(fuse_inode_cachep, fi);
>   }
>   
>   static void fuse_evict_inode(struct inode *inode)

This is now a conflict between the fuse tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpv6ecJO_5xe.pgp
Description: OpenPGP digital signature

Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters

[Aleksa Sarai]

On 2019-05-07, Aleksa Sarai  wrote:
> On 2019-05-06, Jann Horn  wrote:
> > On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai  wrote:
> > > The need to be able to scope path resolution of interpreters became
> > > clear with one of the possible vectors used in CVE-2019-5736 (which
> > > most major container runtimes were vulnerable to).
> > >
> > > Naively, it might seem that openat(2) -- which supports path scoping --
> > > can be combined with execveat(AT_EMPTY_PATH) to trivially scope the
> > > binary being executed. Unfortunately, a "bad binary" (usually a symlink)
> > > could be written as a #!-style script with the symlink target as the
> > > interpreter -- which would be completely missed by just scoping the
> > > openat(2). An example of this being exploitable is CVE-2019-5736.
> > >
> > > In order to get around this, we need to pass down to each binfmt_*
> > > implementation the scoping flags requested in execveat(2). In order to
> > > maintain backwards-compatibility we only pass the scoping AT_* flags.
> > >
> > > To avoid breaking userspace (in the exceptionally rare cases where you
> > > have #!-scripts with a relative path being execveat(2)-ed with dfd !=
> > > AT_FDCWD), we only pass dfd down to binfmt_* if any of our new flags are
> > > set in execveat(2).
> > 
> > This seems extremely dangerous. I like the overall series, but not this 
> > patch.
> > 
> > > @@ -1762,6 +1774,12 @@ static int __do_execve_file(int fd, struct 
> > > filename *filename,
> > >
> > > sched_exec();
> > >
> > > +   bprm->flags = flags & (AT_XDEV | AT_NO_MAGICLINKS | 
> > > AT_NO_SYMLINKS |
> > > +  AT_THIS_ROOT);
> > [...]
> > > +#define AT_THIS_ROOT   0x10 /* - Scope ".." resolution to 
> > > dirfd (like chroot(2)). */
> > 
> > So now what happens if there is a setuid root ELF binary with program
> > interpreter "/lib64/ld-linux-x86-64.so.2" (like /bin/su), and an
> > unprivileged user runs it with execveat(..., AT_THIS_ROOT)? Is that
> > going to let the unprivileged user decide which interpreter the
> > setuid-root process should use? From a high-level perspective, opening
> > the interpreter should be controlled by the program that is being
> > loaded, not by the program that invoked it.
> 
> I went a bit nuts with openat_exec(), and I did end up adding it to the
> ELF interpreter lookup (and you're completely right that this is a bad
> idea -- I will drop it from this patch if it's included in the next
> series).
> 
> The proposed solutions you give below are much nicer than this patch so
> I can drop it and work on fixing those issues separately.

Another possible solution would be to only allow (for instance)
AT_NO_MAGICLINKS for execveat(2). That way you cannot scope the
resolution but you can block the most concerning cases -- those
involving /proc-related access.

I've posted a v7 with this patch dropped (because we can always add AT_*
flags later in time), but I think having at least NO_MAGICLINKS would be
useful.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH 5.0 000/122] 5.0.14-stable review

[Kelsey Skunberg]

On Mon, May 06, 2019 at 04:30:58PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.0.14 release.
> There are 122 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 08 May 2019 02:29:09 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.14-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.0.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h


Compiled, booted, and no dmesg regressions on my system. 

-Kelsey 

[PATCH 0/1] usb: typec: tcpci: read the VBUS_VOLTAGE register

[Angus Ainslie (Purism)]

I don't have a setup that I can test this code right now.

I did test the tcpci_get_vbus_voltage and on my setup it is always 0.

I don't currently have setup that I can adjust the vbus voltage to
trigger the fault.

Angus Ainslie (Purism) (1):
  usb: typec: tcpci: add functions to read the VBUS voltage

 drivers/usb/typec/tcpm/tcpci.c | 35 ++
 1 file changed, 35 insertions(+)

-- 
2.17.1

Re: [PATCH] powerpc: restore current_thread_info()

[Michael Ellerman]

Yury Norov  writes:
> On Tue, May 07, 2019 at 11:58:56PM +0100, Al Viro wrote:
>> On Tue, May 07, 2019 at 03:51:21PM -0700, Yury Norov wrote:
>> > Commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
>> > removes the function current_thread_info(). It's wrong because the
>> > function is used in non-arch code and is part of API.
>> 
>> In include/linux/thread_info.h:
>> 
>> #ifdef CONFIG_THREAD_INFO_IN_TASK
>> /*
>>  * For CONFIG_THREAD_INFO_IN_TASK kernels we need  for the
>>  * definition of current, but for !CONFIG_THREAD_INFO_IN_TASK kernels,
>>  * including  can cause a circular dependency on some 
>> platforms.
>>  */
>> #include 
>> #define current_thread_info() ((struct thread_info *)current)
>> #endif
>
> Ah, sorry. Then it might be my rebase issue. I was confused because Christophe
> didn't remove the comment to current_thread_info(), so I decided he
> removed it erroneously.

Yeah you're right, that comment should have been removed too.

cheers

[PATCH] slab: skip kmemleak_object in leaks_show()

[Qian Cai]

Running tests on a debug kernel will usually generate a large number of
kmemleak objects.

  # grep kmemleak /proc/slabinfo
  kmemleak_object   2243606 3436210 ...

As the result, reading /proc/slab_allocators could easily loop forever
while processing the kmemleak_object cache and any additional freeing or
allocating objects will trigger a reprocessing. To make a situation
worse, soft-lockups could easily happen in this sitatuion which will
call printk() to allocate more kmemleak objects to guarantee a livelock.

Since kmemleak_object has a single call site (create_object()), there
isn't much new information compared with slabinfo. Just skip it.

Signed-off-by: Qian Cai 
---
 mm/slab.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/mm/slab.c b/mm/slab.c
index 20f318f4f56e..85d1d223f879 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4285,6 +4285,15 @@ static int leaks_show(struct seq_file *m, void *p)
if (!(cachep->flags & SLAB_RED_ZONE))
return 0;
 
+   /*
+* /proc/slabinfo has the same information, so skip kmemleak here due to
+* a high volume and its RCU free could make cachep->store_user_clean
+* dirty all the time.
+*/
+   if (IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) &&
+   !strcmp("kmemleak_object", cachep->name))
+   return 0;
+
/*
 * Set store_user_clean and start to grab stored user information
 * for all objects on this cache. If some alloc/free requests comes
-- 
2.20.1 (Apple Git-117)

Re: [tip:sched/core] sched/isolation: Require a present CPU in housekeeping mask

[Frederic Weisbecker]

On Tue, May 07, 2019 at 09:50:24AM +1000, Nicholas Piggin wrote:
> Frederic Weisbecker's on May 7, 2019 1:16 am:
> > On Sat, May 04, 2019 at 04:59:12PM +1000, Nicholas Piggin wrote:
> >> Frederic Weisbecker's on May 4, 2019 10:27 am:
> >> > On Fri, May 03, 2019 at 10:47:37AM -0700, tip-bot for Nicholas Piggin 
> >> > wrote:
> >> >> Commit-ID:  9219565aa89033a9cfdae788c1940473a1253d6c
> >> >> Gitweb: 
> >> >> https://git.kernel.org/tip/9219565aa89033a9cfdae788c1940473a1253d6c
> >> >> Author: Nicholas Piggin 
> >> >> AuthorDate: Thu, 11 Apr 2019 13:34:47 +1000
> >> >> Committer:  Ingo Molnar 
> >> >> CommitDate: Fri, 3 May 2019 19:42:58 +0200
> >> >> 
> >> >> sched/isolation: Require a present CPU in housekeeping mask
> >> >> 
> >> >> During housekeeping mask setup, currently a possible CPU is required.
> >> >> That does not guarantee the CPU would be available at boot time, so
> >> >> check to ensure that at least one present CPU is in the mask.
> >> > 
> >> > I have a doubt about the requirements and semantics of cpu_present_mask.
> >> > IIUC a present CPU means that it is physically plugged in (from ACPI
> >> > perspective) but might not be logically plugged in (set on 
> >> > cpu_online_mask).
> >> 
> >> Right, a superset of cpu_possible_mask, subset of cpu_online_mask. It 
> >> means that CPU can be brought online at any time.
> >> 
> >> > But do we have the guarantee that a present CPU _will_ be online at 
> >> > least once
> >> > right after the boot? After all, kernel parameters such as "maxcpus=" 
> >> > can prevent
> >> > from turning some CPUs on. I guess there are even more creative ways to 
> >> > achieve
> >> > that.
> >> > 
> >> > In any case we really require the housekeeper to be forced online. 
> >> > Perhaps
> >> > I missed that enforcement somewhere in the patchset?
> >> 
> >> No I think you're right, that may be able to boot without anything in
> >> the housekeeping mask. Maybe we can just cpu_up() a CPU in the 
> >> housekeeping mask with a warning that it has overidden their SMP
> >> command line option. I'll take a look at it.
> > 
> > But then what if cpu_up() fails? In this case I can think of only two
> > answers:
> > 
> > * Force the boot CPU as the housekeeper.
> > * Rollback the whole thing: nohz and all isolation.
> 
> If cpu_up fails despite being in the present map and we explicitly
> selected it as the housekeeper? I think it would be okay to print
> a message telling admin to correct the config, and panic.
> 
> We try a best effort to make the system boot and limp along, but if
> you misconfigure it, crashing is not unreasonable. There's lots of
> command line option misconfiguration that will cause the same thing.
> 
> The primary problem with my patch that needs to be addressed is that
> the error is not explicitly caught and printed if the housekeeper
> does not come up, so the system might die in non-obvious ways.

I usually reserve panic and BUG_ON() to last resort when data integrity is
directly threatened. But indeed I guess that's all we have for now.

If we take that path, I'd rather not call that cpu_up() and simply panic if
the given CPU happens not to be online after SMP bootup.

> 
> > 
> > The second solution looks sane to me. After all if the user doesn't
> > include CPU 0 in the housekeeping set, forcing it isn't going to
> > help much.
> > 
> > But that means we must enhance the isolation code (nohz included)
> > to be able to dynamically add/del CPUs to the houseeeping/isolation
> > set. That's not going to be easy but it's a necessary evolution
> > of that subsystem since we want to drive it through cpusets.
> > 
> > I should start working on that.
> 
> I considered that when looking at the series, but couldn't justify
> the complexity based on my usage (which is static boot time).
> 
> If you have other uses for it, then that would solve all these boot
> time issues as well, which will be nice.

Yeah cpuset is going to be a usecase.

I'm going to work on that so that the boot CPU is always the housekeeper
in the beginning, then that duty can be later passed to any secondary CPU
or the whole can be rolled back. The current situation with the temporary
housekeeper that isn't a real one makes me a bit uncomfortable.

Thanks.

Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters

[Eric W. Biederman]

Jann Horn  writes:
>
> In my opinion, CVE-2019-5736 points out two different problems:
>
> The big problem: The __ptrace_may_access() logic has a special-case
> short-circuit for "introspection" that you can't opt out of;

Once upon a time in a galaxy far far away I fixed a bug where we missing
ptrace_may_access checks on various proc files and systems using selinux
stopped working.  At the time selinux did not allow ptrace like access
to yourself.  The "introspection" special case was the quick and simple
work-around.

There is nothing fundamental in having the "introspection" special case
except that various lsms have probably grown to depend upon it being
there.  I expect without difficulty we could move the check down
into the various lsms.  Which would get that check out of the core
kernel code.

Then the special case would the lsms challenge to keep or remove.

Eric

[PATCH] watchdog: Enforce that at least one pretimeout governor is enabled

[Guenter Roeck]

Since commit "watchdog: Use depends instead of select for pretimeout
governors", it was possible to enable pretimeout governors but keep all
of them disabled. Doing this results in the following build failure.

../drivers/watchdog/watchdog_pretimeout.c:
In function ‘watchdog_register_governor’:
../drivers/watchdog/watchdog_pretimeout.c:139:26: error:
‘WATCHDOG_PRETIMEOUT_DEFAULT_GOV’ undeclared
   if (!strncmp(gov->name, WATCHDOG_PRETIMEOUT_DEFAULT_GOV,

Since it does not make sense to enable pretimeout support but disable
all pretimeout governors, enforce that at least one of them is always
enabled.

Fixes: f627ac0e12cd ("watchdog: Use depends instead of select for pretimeout 
governors")
Reported-by: Randy Dunlap 
Signed-off-by: Guenter Roeck 
---
Fixes: sha is from next-20190507.

 drivers/watchdog/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e19960ace0c0..4a3461afa96f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -71,6 +71,12 @@ config WATCHDOG_PRETIMEOUT_GOV
help
  The option allows to select watchdog pretimeout governors.
 
+config WATCHDOG_PRETIMEOUT_GOV_SEL
+   tristate
+   depends on WATCHDOG_PRETIMEOUT_GOV
+   default m
+   select WATCHDOG_PRETIMEOUT_GOV_PANIC if WATCHDOG_PRETIMEOUT_GOV_NOOP=n
+
 if WATCHDOG_PRETIMEOUT_GOV
 
 config WATCHDOG_PRETIMEOUT_GOV_NOOP
-- 
2.7.4

Re: [PATCH v2 6/7] nvme-pci: add device coredump support

[Minwoo Im]

> This is a bit of a mine field. The shutdown_lock is held when reclaiming
> requests that didn't see a response. If you're holding it here and your
> telemetry log page times out, we're going to deadlock. And since the
> controller is probably in a buggered state when you try to retrieve one,
> I would guess an unrecoverable timeout is the most likely outcome.

Akinobu,

I actually agree with Keith's one.  In my experience, there was always internal
error inside device when timeout occurs in nvme driver which means the
following command might not be completed due to lack of response from
device.

Re: [PATCH] watchdog: fix watchdog_pretimeout.c build error when no default gov. is set

[Randy Dunlap]

On 5/7/19 5:07 PM, Guenter Roeck wrote:
> On 5/7/19 4:33 PM, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> Fix build error when
>> CONFIG_WATCHDOG_PRETIMEOUT_GOV=y
>> # CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set
>> # CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC is not set
>>
>> Fixes this build error:
>>
>> ../drivers/watchdog/watchdog_pretimeout.c: In function 
>> ‘watchdog_register_governor’:
>> ../drivers/watchdog/watchdog_pretimeout.c:139:26: error: 
>> ‘WATCHDOG_PRETIMEOUT_DEFAULT_GOV’ undeclared (first use in this function)
>>    if (!strncmp(gov->name, WATCHDOG_PRETIMEOUT_DEFAULT_GOV,
>>
> 
> Ah, I knew I missed something. The following would be a better fix,
> though, since it enforces that at least one pretimeout governor is enabled
> (matching the old code):
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index e19960ace0c0..4a3461afa96f 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -71,6 +71,12 @@ config WATCHDOG_PRETIMEOUT_GOV
>     help
>   The option allows to select watchdog pretimeout governors.
> 
> +config WATCHDOG_PRETIMEOUT_GOV_SEL
> +   tristate
> +   depends on WATCHDOG_PRETIMEOUT_GOV
> +   default m
> +   select WATCHDOG_PRETIMEOUT_GOV_PANIC if WATCHDOG_PRETIMEOUT_GOV_NOOP=n
> +
>  if WATCHDOG_PRETIMEOUT_GOV
> 
> Can you send v2 with the above, or do you want me to send it and give you 
> credit ?
> 
> Thanks,
> Guenter

Hi Guenter,
That's your patch.  You can send it.  :)
No credit needed.

cheers.
-- 
~Randy

Re: [PATCH v2] Documentation/trace: Add clarification how histogram onmatch works

[Steven Rostedt]

Tom,

Can you review this patch.

Jon,

After Tom gives his review, can you take this in your tree?

Thanks!

Reviewed-by: Steven Rostedt (VMware) 

-- Steve


On Tue,  7 May 2019 17:49:46 +0300
Tzvetomir Stoyanov  wrote:

> The current trace documentation, the section describing histogram's "onmatch"
> is not straightforward enough about how this action is applied. It is not
> clear what criteria are used to "match" both events. A short note is added,
> describing what exactly is compared in order to match the events.
> 
> Signed-off-by: Tzvetomir Stoyanov 
> ---
>  Documentation/trace/histogram.txt | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/trace/histogram.txt 
> b/Documentation/trace/histogram.txt
> index 7ffea6aa22e3..d97f0530a731 100644
> --- a/Documentation/trace/histogram.txt
> +++ b/Documentation/trace/histogram.txt
> @@ -1863,7 +1863,10 @@ hist trigger specification.
>  
>  The 'matching.event' specification is simply the fully qualified
>  event name of the event that matches the target event for the
> -onmatch() functionality, in the form 'system.event_name'.
> +onmatch() functionality, in the form 'system.event_name'. Histogram
> +keys of both events are compared to find if events match. In the case
> +multiple histogram keys are used, both events must have the same
> +number of keys, and the keys must match in the same order.
>  
>  Finally, the number and type of variables/fields in the 'param
>  list' must match the number and types of the fields in the
> @@ -1920,9 +1923,10 @@ hist trigger specification.
>   /sys/kernel/debug/tracing/events/sched/sched_waking/trigger
>  
>  Then, when the corresponding thread is actually scheduled onto the
> -CPU by a sched_switch event, calculate the latency and use that
> -along with another variable and an event field to generate a
> -wakeup_latency synthetic event:
> +CPU by a sched_switch event (where the sched_waking key  "saved_pid"
> +matches the sched_switch key "next_pid"), calculate the latency and
> +use that along with another variable and an event field to generate
> +a wakeup_latency synthetic event:
>  
>  # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\
>  onmatch(sched.sched_waking).wakeup_latency($wakeup_lat,\

Re: [PATCH 4.19 38/99] net: stmmac: use correct DMA buffer size in the RX descriptor

[Nobuhiro Iwamatsu]

Hi,

On Mon, May 06, 2019 at 04:32:11PM +0200, Greg Kroah-Hartman wrote:
> [ Upstream commit 583e6361414903c5206258a30e5bd88cb03c0254 ]
> 
> We always program the maximum DMA buffer size into the receive descriptor,
> although the allocated size may be less. E.g. with the default MTU size
> we allocate only 1536 bytes. If somebody sends us a bigger frame, then
> memory may get corrupted.
> 
> Fix by using exact buffer sizes.
> 
> Signed-off-by: Aaro Koskinen 
> Signed-off-by: David S. Miller 
> Signed-off-by: Sasha Levin 
> ---
>  .../net/ethernet/stmicro/stmmac/descs_com.h   | 22 ---
>  .../ethernet/stmicro/stmmac/dwmac4_descs.c|  2 +-
>  .../ethernet/stmicro/stmmac/dwxgmac2_descs.c  |  2 +-
>  .../net/ethernet/stmicro/stmmac/enh_desc.c| 10 ++---
>  drivers/net/ethernet/stmicro/stmmac/hwif.h|  2 +-
>  .../net/ethernet/stmicro/stmmac/norm_desc.c   | 10 ++---
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c |  6 +++--

This commit is incomplete and we need the following commit:

commit f87db4dbd52f2f8a170a2b51cb0926221ca7c9e2
Author: YueHaibing 
Date:   Wed Apr 17 09:49:39 2019 +0800

net: stmmac: Use bfsize1 in ndesc_init_rx_desc

gcc warn this:

drivers/net/ethernet/stmicro/stmmac/norm_desc.c: In function 
ndesc_init_rx_desc:
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:138:6: warning: variable 
'bfsize1' set but not used [-Wunused-but-set-variable]

Like enh_desc_init_rx_desc, we should use bfsize1
in ndesc_init_rx_desc to calculate 'p->des1'

Fixes: 583e63614149 ("net: stmmac: use correct DMA buffer size in the RX 
descriptor")
Signed-off-by: YueHaibing 
Reviewed-by: Aaro Koskinen 
Signed-off-by: David S. Miller 

And this fix is also needed for 5.0.14-rc.
Please apply this commit to 4.19.y-rc and 5.0.y-rc.

Best regards,
  Nobuhiro

[PATCH v2 5/6] PCI/P2PDMA: Track pgmap references per resource, not globally

[Dan Williams]

In preparation for fixing a race between devm_memremap_pages_release()
and the final put of a page from the device-page-map, allocate a
percpu-ref per p2pdma resource mapping.

Cc: Logan Gunthorpe 
Cc: Bjorn Helgaas 
Cc: Christoph Hellwig 
Reviewed-by: Ira Weiny 
Signed-off-by: Dan Williams 
---
 drivers/pci/p2pdma.c |  124 +-
 1 file changed, 81 insertions(+), 43 deletions(-)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 595a534bd749..54d475569058 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -20,12 +20,16 @@
 #include 
 
 struct pci_p2pdma {
-   struct percpu_ref devmap_ref;
-   struct completion devmap_ref_done;
struct gen_pool *pool;
bool p2pmem_published;
 };
 
+struct p2pdma_pagemap {
+   struct dev_pagemap pgmap;
+   struct percpu_ref ref;
+   struct completion ref_done;
+};
+
 static ssize_t size_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -74,41 +78,45 @@ static const struct attribute_group p2pmem_group = {
.name = "p2pmem",
 };
 
+static struct p2pdma_pagemap *to_p2p_pgmap(struct percpu_ref *ref)
+{
+   return container_of(ref, struct p2pdma_pagemap, ref);
+}
+
 static void pci_p2pdma_percpu_release(struct percpu_ref *ref)
 {
-   struct pci_p2pdma *p2p =
-   container_of(ref, struct pci_p2pdma, devmap_ref);
+   struct p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(ref);
 
-   complete_all(>devmap_ref_done);
+   complete(_pgmap->ref_done);
 }
 
 static void pci_p2pdma_percpu_kill(struct percpu_ref *ref)
 {
-   /*
-* pci_p2pdma_add_resource() may be called multiple times
-* by a driver and may register the percpu_kill devm action multiple
-* times. We only want the first action to actually kill the
-* percpu_ref.
-*/
-   if (percpu_ref_is_dying(ref))
-   return;
-
percpu_ref_kill(ref);
 }
 
+static void pci_p2pdma_percpu_cleanup(void *ref)
+{
+   struct p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(ref);
+
+   wait_for_completion(_pgmap->ref_done);
+   percpu_ref_exit(_pgmap->ref);
+}
+
 static void pci_p2pdma_release(void *data)
 {
struct pci_dev *pdev = data;
+   struct pci_p2pdma *p2pdma = pdev->p2pdma;
 
-   if (!pdev->p2pdma)
+   if (!p2pdma)
return;
 
-   wait_for_completion(>p2pdma->devmap_ref_done);
-   percpu_ref_exit(>p2pdma->devmap_ref);
+   /* Flush and disable pci_alloc_p2p_mem() */
+   pdev->p2pdma = NULL;
+   synchronize_rcu();
 
-   gen_pool_destroy(pdev->p2pdma->pool);
+   gen_pool_destroy(p2pdma->pool);
sysfs_remove_group(>dev.kobj, _group);
-   pdev->p2pdma = NULL;
 }
 
 static int pci_p2pdma_setup(struct pci_dev *pdev)
@@ -124,12 +132,6 @@ static int pci_p2pdma_setup(struct pci_dev *pdev)
if (!p2p->pool)
goto out;
 
-   init_completion(>devmap_ref_done);
-   error = percpu_ref_init(>devmap_ref,
-   pci_p2pdma_percpu_release, 0, GFP_KERNEL);
-   if (error)
-   goto out_pool_destroy;
-
error = devm_add_action_or_reset(>dev, pci_p2pdma_release, pdev);
if (error)
goto out_pool_destroy;
@@ -163,6 +165,7 @@ static int pci_p2pdma_setup(struct pci_dev *pdev)
 int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar, size_t size,
u64 offset)
 {
+   struct p2pdma_pagemap *p2p_pgmap;
struct dev_pagemap *pgmap;
void *addr;
int error;
@@ -185,14 +188,32 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int 
bar, size_t size,
return error;
}
 
-   pgmap = devm_kzalloc(>dev, sizeof(*pgmap), GFP_KERNEL);
-   if (!pgmap)
+   p2p_pgmap = devm_kzalloc(>dev, sizeof(*p2p_pgmap), GFP_KERNEL);
+   if (!p2p_pgmap)
return -ENOMEM;
 
+   init_completion(_pgmap->ref_done);
+   error = percpu_ref_init(_pgmap->ref,
+   pci_p2pdma_percpu_release, 0, GFP_KERNEL);
+   if (error)
+   goto pgmap_free;
+
+   /*
+* FIXME: the percpu_ref_exit needs to be coordinated internal
+* to devm_memremap_pages_release(). Duplicate the same ordering
+* as other devm_memremap_pages() users for now.
+*/
+   error = devm_add_action(>dev, pci_p2pdma_percpu_cleanup,
+   _pgmap->ref);
+   if (error)
+   goto ref_cleanup;
+
+   pgmap = _pgmap->pgmap;
+
pgmap->res.start = pci_resource_start(pdev, bar) + offset;
pgmap->res.end = pgmap->res.start + size - 1;
pgmap->res.flags = pci_resource_flags(pdev, bar);
-   pgmap->ref = >p2pdma->devmap_ref;
+   pgmap->ref = _pgmap->ref;
pgmap->type = MEMORY_DEVICE_PCI_P2PDMA;
pgmap->pci_p2pdma_bus_offset = pci_bus_address(pdev, bar) -

[PATCH v2 2/6] mm/devm_memremap_pages: Introduce devm_memunmap_pages

[Dan Williams]

Use the new devm_relase_action() facility to allow
devm_memremap_pages_release() to be manually triggered.

Cc: Logan Gunthorpe 
Cc: Bjorn Helgaas 
Cc: Christoph Hellwig 
Reviewed-by: Ira Weiny 
Signed-off-by: Dan Williams 
---
 include/linux/memremap.h |6 ++
 kernel/memremap.c|6 ++
 2 files changed, 12 insertions(+)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index f0628660d541..7601ee314c4a 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -100,6 +100,7 @@ struct dev_pagemap {
 
 #ifdef CONFIG_ZONE_DEVICE
 void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap);
+void devm_memunmap_pages(struct device *dev, struct dev_pagemap *pgmap);
 struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
struct dev_pagemap *pgmap);
 
@@ -118,6 +119,11 @@ static inline void *devm_memremap_pages(struct device *dev,
return ERR_PTR(-ENXIO);
 }
 
+static inline void devm_memunmap_pages(struct device *dev,
+   struct dev_pagemap *pgmap)
+{
+}
+
 static inline struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
struct dev_pagemap *pgmap)
 {
diff --git a/kernel/memremap.c b/kernel/memremap.c
index a856cb5ff192..65afbacab44e 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -266,6 +266,12 @@ void *devm_memremap_pages(struct device *dev, struct 
dev_pagemap *pgmap)
 }
 EXPORT_SYMBOL_GPL(devm_memremap_pages);
 
+void devm_memunmap_pages(struct device *dev, struct dev_pagemap *pgmap)
+{
+   devm_release_action(dev, devm_memremap_pages_release, pgmap);
+}
+EXPORT_SYMBOL_GPL(devm_memunmap_pages);
+
 unsigned long vmem_altmap_offset(struct vmem_altmap *altmap)
 {
/* number of pfns from base where pfn_to_page() is valid */

[PATCH v2 6/6] mm/devm_memremap_pages: Fix final page put race

[Dan Williams]

Logan noticed that devm_memremap_pages_release() kills the percpu_ref
drops all the page references that were acquired at init and then
immediately proceeds to unplug, arch_remove_memory(), the backing pages
for the pagemap. If for some reason device shutdown actually collides
with a busy / elevated-ref-count page then arch_remove_memory() should
be deferred until after that reference is dropped.

As it stands the "wait for last page ref drop" happens *after*
devm_memremap_pages_release() returns, which is obviously too late and
can lead to crashes.

Fix this situation by assigning the responsibility to wait for the
percpu_ref to go idle to devm_memremap_pages() with a new ->cleanup()
callback. Implement the new cleanup callback for all
devm_memremap_pages() users: pmem, devdax, hmm, and p2pdma.

Reported-by: Logan Gunthorpe 
Fixes: 41e94a851304 ("add devm_memremap_pages")
Cc: Bjorn Helgaas 
Cc: "Jérôme Glisse" 
Cc: Christoph Hellwig 
Reviewed-by: Ira Weiny 
Signed-off-by: Dan Williams 
---
 drivers/dax/device.c  |   13 +++--
 drivers/nvdimm/pmem.c |   17 +
 drivers/pci/p2pdma.c  |   17 +++--
 include/linux/memremap.h  |2 ++
 kernel/memremap.c |   17 -
 mm/hmm.c  |   14 +++---
 tools/testing/nvdimm/test/iomap.c |2 ++
 7 files changed, 38 insertions(+), 44 deletions(-)

diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index e428468ab661..e3aa78dd1bb0 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -27,9 +27,8 @@ static void dev_dax_percpu_release(struct percpu_ref *ref)
complete(_dax->cmp);
 }
 
-static void dev_dax_percpu_exit(void *data)
+static void dev_dax_percpu_exit(struct percpu_ref *ref)
 {
-   struct percpu_ref *ref = data;
struct dev_dax *dev_dax = ref_to_dev_dax(ref);
 
dev_dbg(_dax->dev, "%s\n", __func__);
@@ -468,18 +467,12 @@ int dev_dax_probe(struct device *dev)
if (rc)
return rc;
 
-   rc = devm_add_action_or_reset(dev, dev_dax_percpu_exit, _dax->ref);
-   if (rc)
-   return rc;
-
dev_dax->pgmap.ref = _dax->ref;
dev_dax->pgmap.kill = dev_dax_percpu_kill;
+   dev_dax->pgmap.cleanup = dev_dax_percpu_exit;
addr = devm_memremap_pages(dev, _dax->pgmap);
-   if (IS_ERR(addr)) {
-   devm_remove_action(dev, dev_dax_percpu_exit, _dax->ref);
-   percpu_ref_exit(_dax->ref);
+   if (IS_ERR(addr))
return PTR_ERR(addr);
-   }
 
inode = dax_inode(dax_dev);
cdev = inode->i_cdev;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 0279eb1da3ef..1c9181712fa4 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -304,11 +304,19 @@ static const struct attribute_group 
*pmem_attribute_groups[] = {
NULL,
 };
 
-static void pmem_release_queue(void *q)
+static void __pmem_release_queue(struct percpu_ref *ref)
 {
+   struct request_queue *q;
+
+   q = container_of(ref, typeof(*q), q_usage_counter);
blk_cleanup_queue(q);
 }
 
+static void pmem_release_queue(void *ref)
+{
+   __pmem_release_queue(ref);
+}
+
 static void pmem_freeze_queue(struct percpu_ref *ref)
 {
struct request_queue *q;
@@ -400,12 +408,10 @@ static int pmem_attach_disk(struct device *dev,
if (!q)
return -ENOMEM;
 
-   if (devm_add_action_or_reset(dev, pmem_release_queue, q))
-   return -ENOMEM;
-
pmem->pfn_flags = PFN_DEV;
pmem->pgmap.ref = >q_usage_counter;
pmem->pgmap.kill = pmem_freeze_queue;
+   pmem->pgmap.cleanup = __pmem_release_queue;
if (is_nd_pfn(dev)) {
if (setup_pagemap_fsdax(dev, >pgmap))
return -ENOMEM;
@@ -426,6 +432,9 @@ static int pmem_attach_disk(struct device *dev,
pmem->pfn_flags |= PFN_MAP;
memcpy(_res, >pgmap.res, sizeof(bb_res));
} else {
+   if (devm_add_action_or_reset(dev, pmem_release_queue,
+   >q_usage_counter))
+   return -ENOMEM;
addr = devm_memremap(dev, pmem->phys_addr,
pmem->size, ARCH_MEMREMAP_PMEM);
memcpy(_res, >res, sizeof(bb_res));
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 54d475569058..a7a66b958720 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -95,7 +95,7 @@ static void pci_p2pdma_percpu_kill(struct percpu_ref *ref)
percpu_ref_kill(ref);
 }
 
-static void pci_p2pdma_percpu_cleanup(void *ref)
+static void pci_p2pdma_percpu_cleanup(struct percpu_ref *ref)
 {
struct p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(ref);
 
@@ -198,16 +198,6 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar, 
size_t size,
if (error)
goto pgmap_free;
 
-   /*
-

linux-next: manual merge of the ubifs tree with Linus' tree

[Stephen Rothwell]

Hi all,

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

  fs/ubifs/auth.c

between commit:

  877b5691f27a ("crypto: shash - remove shash_desc::flags")

from Linus' tree and commit:

  f4844b35d68a ("ubifs: work around high stack usage with clang")

from the ubifs 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 fs/ubifs/auth.c
index b758004085c4,3d049194afa4..
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@@ -85,12 -86,17 +84,16 @@@ int ubifs_prepare_auth_node(struct ubif
if (!hash)
return -ENOMEM;
  
-   hash_desc->tfm = c->hash_tfm;
-   ubifs_shash_copy_state(c, inhash, hash_desc);
+   {
+   SHASH_DESC_ON_STACK(hash_desc, c->hash_tfm);
  
-   err = crypto_shash_final(hash_desc, hash);
-   if (err)
-   goto out;
+   hash_desc->tfm = c->hash_tfm;
 -  hash_desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+   ubifs_shash_copy_state(c, inhash, hash_desc);
+ 
+   err = crypto_shash_final(hash_desc, hash);
+   if (err)
+   goto out;
+   }
  
err = ubifs_hash_calc_hmac(c, hash, auth->hmac);
if (err)


pgpnp2ywwSNbf.pgp
Description: OpenPGP digital signature

To: Andrew Sampson: Rights granted by the GPL _can_ be "retroactively" retracted. Yes I am a lawyer

[informator]

Dear Andrew Sampson;
The proclamations given in the thread: 
github.com/Codeusa/Borderless-Gaming/issues/312 are incorrect.


If the non-exclusive licensee did not pay the copyright holder 
consideration for receipt of the permissions given regarding the 
copyrighted work, the copyright holder can freely rescind those 
permissions _AT_ANY_TIME_ .


The reasons are as follows: For the licensee to "hold" the licensor to 
any promise regarding when and how rescission is to take place there 
must be a contract between the two. A contract requires valid 
bargained-for consideration. Otherwise any "promise" made is an Illusory 
Promise (unenforceable).


"Nothing" is not valid consideration.

Obeying a pre-existing duty is not valid consideration.

The licensee has a pre-existing duty to obey copyright law, without 
permission from the copyright holder he may not 
use/modify/make-derivative-works-of/distribute/distribute-derivative-works-of. 
That permission is what he is attempting to "contract" for. Saying one 
will follow those permissions is not valid consideration to "pay" for 
those permissions. Promising not to violate the copyright holder's 
rights -by promising to only use the copyrighted works as freely 
permitted by the copyright holder, is not valid consideration as that is 
a pre-existing duty.


Yes: Codeusa: you _C_A_N_ revoke GPL permissions from free-takers at 
your will. And you should do so if that is needed for your livelihood to 
succeed.


You should do so if it is simply your want.

Do not the pennyless leaches intimidate you from making your own 
decisions regarding your work of authorship. They gave you nothing, you 
asked for nothing, they have nothing. Remember: a non-exclusive license 
is not a transfer, it is permission. Permission that can be ended at any 
time unless there exists an attached interest (ie: the other side payed 
you for a license contract)
Also Remember: The FSF has _always_ (and still does) required Copyright 
Transfers before it would accept a contribution.


And yes: I am a lawyer.

Of course: consult your local copyright attorney. Strategy is important 
in these cases. The free-loaders feel they have the 9th circuit judges 
in the bag, and that the 9th circuit will invalidate the concept of 
consideration if needed to protect the California tech industry (so 
revoke from those outside the 9th circuit first).







For easy to read by lay-people discussions on this topic:
lkml.org/lkml/2019/5/4/334
lkml.org/lkml/2019/5/3/698

For legal articles and treatises that agree: no consideration from GPL 
free-taker, no contract, revocable by the copyright holder:

scholarship.law.duke.edu/faculty_scholarship/1857/
www.amazon.com/Open-Source-Licensing-Software-Intellectual/dp/0131487876
papers.ssrn.com/sol3/papers.cfm?abstract_id=243237



Note: I tried to inform you of this on your github account but was 
immediatly "hell banned" by github.



Sincerely;
Pro-Bono Attorney

Re: [PATCH] watchdog: fix watchdog_pretimeout.c build error when no default gov. is set

[Guenter Roeck]

On 5/7/19 4:33 PM, Randy Dunlap wrote:

From: Randy Dunlap 

Fix build error when
CONFIG_WATCHDOG_PRETIMEOUT_GOV=y
# CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP is not set
# CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC is not set

Fixes this build error:

../drivers/watchdog/watchdog_pretimeout.c: In function 
‘watchdog_register_governor’:
../drivers/watchdog/watchdog_pretimeout.c:139:26: error: 
‘WATCHDOG_PRETIMEOUT_DEFAULT_GOV’ undeclared (first use in this function)
   if (!strncmp(gov->name, WATCHDOG_PRETIMEOUT_DEFAULT_GOV,



Ah, I knew I missed something. The following would be a better fix,
though, since it enforces that at least one pretimeout governor is enabled
(matching the old code):

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e19960ace0c0..4a3461afa96f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -71,6 +71,12 @@ config WATCHDOG_PRETIMEOUT_GOV
help
  The option allows to select watchdog pretimeout governors.

+config WATCHDOG_PRETIMEOUT_GOV_SEL
+   tristate
+   depends on WATCHDOG_PRETIMEOUT_GOV
+   default m
+   select WATCHDOG_PRETIMEOUT_GOV_PANIC if WATCHDOG_PRETIMEOUT_GOV_NOOP=n
+
 if WATCHDOG_PRETIMEOUT_GOV

Can you send v2 with the above, or do you want me to send it and give you 
credit ?

Thanks,
Guenter

[GIT PULL] Devicetree for 5.2

[Rob Herring]

Linus,

Please pull DT updates for 5.2.

Rob

The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:

  Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-for-5.2

for you to fetch changes up to 2a656cb5a4a3473c5fc6bf4fddc3560ceed53220:

  of: unittest: Remove error printing on OOM (2019-05-02 16:38:59 -0500)


Devicetree for 5.2:

- Fix possible memory leak in reserved-memory failure case

- Support for DMA parent bus which are not a parent node

- Clang -Wunsequenced fix

- Remove some unnecessary prints on memory alloc failures

- Various printk msg and comment fixes

- Update DT schema tools repository location

- Convert simple-framebuffer binding to DT schema

- Bindings for isl68137 and ir38064 trivial devices

- New documentation on binding do's and don't's for binding writers to
  ignore


Chris Packham (1):
  of: use correct function prototype for of_overlay_fdt_apply()

Christian Lamparter (1):
  dt-bindings: pinctrl: fix bias-pull,up typo

Clément Péron (1):
  dt-bindings: mfd: axp20x: Add fallback for axp805

Florian Fainelli (1):
  of: Improve of_phandle_iterator_next() error message

Geert Uytterhoeven (2):
  of: irq: Remove WARN_ON() for kzalloc() failure
  of: unittest: Remove error printing on OOM

Jojo Zeng (1):
  of/device.c: fix the wrong comments

Maxime Ripard (6):
  of: property: Document that of_graph_get_endpoint_by_regs needs
of_node_put
  dt-bindings: interconnect: Add a dma interconnect name
  dt-bindings: bus: Add binding for the Allwinner MBUS controller
  of: address: Retrieve a parent through a callback in
__of_translate_address
  of: address: Add support for the parent DMA bus
  dt-bindings: Add schemas for simple-framebuffer

Miquel Raynal (1):
  dt-bindings: connector: Spelling mistake

Patrick Venture (2):
  dt-bindings: Add ir38064 as a trivial device
  dt-bindings: Add isl68137 as a trivial device

Phong Tran (1):
  of: fix clang -Wunsequenced for be32_to_cpu()

Rob Herring (3):
  dt-bindings: Add a guide of do's and don't's for writing bindings
  dt-bindings: Require child nodes type to be 'object'
  dt-bindings: Update schema project location to devicetree.org github group

pierre Kuo (1):
  of: reserved_mem: fix reserve memory leak

xiaojiangfeng (1):
  of: del redundant type conversion

 Documentation/devicetree/bindings/arm/cpus.yaml|   1 +
 .../devicetree/bindings/arm/sunxi/sunxi-mbus.txt   |  36 +
 .../bindings/connector/usb-connector.txt   |   2 +-
 .../display/amlogic,simple-framebuffer.txt |  33 -
 .../bindings/display/simple-framebuffer-sunxi.txt  |  36 -
 .../bindings/display/simple-framebuffer.txt|  91 
 .../bindings/display/simple-framebuffer.yaml   | 160 +
 .../bindings/interconnect/interconnect.txt |   4 +
 .../bindings/interrupt-controller/arm,gic.yaml |   1 +
 Documentation/devicetree/bindings/mfd/axp20x.txt   |   1 +
 .../bindings/pinctrl/qcom,apq8064-pinctrl.txt  |   2 +-
 .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt  |   2 +-
 .../bindings/pinctrl/qcom,ipq8064-pinctrl.txt  |   2 +-
 .../bindings/pinctrl/qcom,msm8660-pinctrl.txt  |   2 +-
 .../bindings/pinctrl/qcom,msm8974-pinctrl.txt  |   2 +-
 .../bindings/timer/arm,arch_timer_mmio.yaml|   1 +
 .../devicetree/bindings/trivial-devices.yaml   |   4 +
 .../devicetree/bindings/writing-bindings.txt   |  60 
 Documentation/devicetree/writing-schema.md |   2 +-
 drivers/of/address.c   |  40 +-
 drivers/of/base.c  |   5 +-
 drivers/of/device.c|   2 +-
 drivers/of/fdt.c   |   2 +-
 drivers/of/irq.c   |   2 +-
 drivers/of/of_reserved_mem.c   |  22 ++-
 drivers/of/property.c  |   2 +-
 drivers/of/unittest.c  |  13 +-
 include/linux/of.h |   7 +-
 28 files changed, 341 insertions(+), 196 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
 delete mode 100644
Documentation/devicetree/bindings/display/amlogic,simple-framebuffer.txt
 delete mode 100644
Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt
 delete mode 100644
Documentation/devicetree/bindings/display/simple-framebuffer.txt
 create mode 100644
Documentation/devicetree/bindings/display/simple-framebuffer.yaml
 create mode 100644 Documentation/devicetree/bindings/writing-bindings.txt

Re: [PATCH v4 0/2] thermal: rcar_gen3_thermal: fix IRQ issues

[Niklas Söderlund]

Hi Jiada,

Thanks for your patches.

On 2019-04-24 14:11:43 +0900, Jiada Wang wrote:
> There are issues with interrupt handling in rcar_gen3_thermal driver.
> 
> Currently IRQ is remain enabled after .remove, later if device is probed,
> IRQ is requested before .thermal_init, this may cause IRQ function be
> triggered but not able to clear IRQ status, thus cause system to hang.
> 
> Since the irq line isn't shared between different devices,
> so the proper interrupt type flag should be IRQF_ONESHOT.
> 
> This patch-set fix these interrupt handling retated issues.

I really like this series, nice work.

Tested-by: Niklas Söderlund 
Reviewed-by: Niklas Söderlund 

> 
> ---
> v4: remove 'spinlock_t lock'
> add Fixes tag in ("thermal: rcar_gen3_thermal: fix interrupt type")
> fix typos in ("thermal: rcar_gen3_thermal: disable interrupt in .remove")
> 
> v3: fix to use correct code base
> remove unused "flag" variable in rcar_gen3_thermal_irq
> 
> v2: use irq type IRQF_ONESHOT instead of IRQF_SHARED
> disable interrupt in .remove
> 
> v1: initial version
> 
> Jiada Wang (2):
>   thermal: rcar_gen3_thermal: fix interrupt type
>   thermal: rcar_gen3_thermal: disable interrupt in .remove
> 
>  drivers/thermal/rcar_gen3_thermal.c | 41 +++--
>  1 file changed, 9 insertions(+), 32 deletions(-)
> 
> -- 
> 2.19.2
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

[J. Bruce Fields]

On Tue, May 07, 2019 at 04:07:21AM -0400, Miklos Szeredi wrote:
> On Fri, May 3, 2019 at 11:35 AM J. Bruce Fields  wrote:
> >
> > On Thu, May 02, 2019 at 12:02:33PM +1000, NeilBrown wrote:
> 
> > >  Silently not copying the ACLs is probably not a good idea as it might
> > >  result in inappropriate permissions being given away.  So if the
> > >  sysadmin wants this (and some clearly do), they need a way to
> > >  explicitly say "I accept the risk".
> >
> > So, I feel like silently copying ACLs up *also* carries a risk, if that
> > means switching from server-enforcement to client-enforcement of those
> > permissions.
> 
> That's not correct: permissions are checked on the overlay layer,
> regardless of where the actual file resides.  For filesystems using a
> server enforced permission model that means possibly different
> permissions for accesses through overlayfs than for accesses without
> overlayfs.  Apparently this is missing from the documentation and
> definitely needs to be added.

Well, we did have a thread on this pretty recently, I think, and I'm
just not remembering the conclusion.  Yes, it'd be nice to have this
documented.

In the case of NFSv4 ACLs, we not only lack storage for them, we don't
even have code to evaluate them.

--b.

> So I think it's perfectly fine to allow copying up ACLs, as long as
> the ACL is representable on the upper fs.  If that cannot be ensured,
> then the only sane thing to do is to disable ACL checking across the
> overlay ("noacl" option).

[PATCH] phy: rockchip-dp: Avoid power leak by leaving the PHY power on

[Douglas Anderson]

While testing a newer kernel on rk3288-based Chromebooks I found that
the power draw in suspend was higher on newer kernels compared to the
downstream Chrome OS 3.14 kernel.  Specifically the power of an
rk3288-veyron-jerry board that I tested (as measured by the smart
battery) was ~16 mA on Chrome OS 3.14 and ~21 mA on a newer kernel.

I tracked the regression down to the fact that the "DP PHY" driver
didn't exist in our downstream 3.14.  We relied on the eDP driver to
turn on the clock and relied on the fact that the power for the PHY
was default turned on.

Specifically the thing that caused the power regression was turning
the eDP PHY _off_.  Presumably there is some sort of power leak in the
system and when we turn the PHY off something is leaching power from
something else and causing excessive power draw.

Doing a search through device trees shows that this PHY is only ever
used on rk3288.  Presumably this power leak is present on all
rk3288-SoCs running upstream Linux so let's just whack the driver to
make sure we never turn off power.  We'll still leave the parts that
turn _on_ the power and grab the clock, though.

NOTES:
A) If someone can identify what this power leak is and fix it in some
   other way we can revert this patch.
B) If someone can show that their particular board doesn't have this
   power leak (maybe they have rails hooked up differently?) we can
   perhaps add a device tree property indicating that for some boards
   it's OK to turn this rail off.  I don't want to add this property
   until I know of a board that needs it.

Fixes: fd968973de95 ("phy: Add driver for rockchip Display Port PHY")
Signed-off-by: Douglas Anderson 
---
As far as I know Yakir (the original author) is no longer at Rockchip.
I've added a few other Rockchip people and hopefully one of them can
help direct even if they're not directly responsible.

 drivers/phy/rockchip/phy-rockchip-dp.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-dp.c 
b/drivers/phy/rockchip/phy-rockchip-dp.c
index 8b267a746576..10bbcd69d6f5 100644
--- a/drivers/phy/rockchip/phy-rockchip-dp.c
+++ b/drivers/phy/rockchip/phy-rockchip-dp.c
@@ -35,7 +35,7 @@ struct rockchip_dp_phy {
 static int rockchip_set_phy_state(struct phy *phy, bool enable)
 {
struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
-   int ret;
+   int ret = 0;
 
if (enable) {
ret = regmap_write(dp->grf, GRF_SOC_CON12,
@@ -50,9 +50,12 @@ static int rockchip_set_phy_state(struct phy *phy, bool 
enable)
} else {
clk_disable_unprepare(dp->phy_24m);
 
-   ret = regmap_write(dp->grf, GRF_SOC_CON12,
-  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
-  GRF_EDP_PHY_SIDDQ_OFF);
+   /*
+* Intentionally don't turn SIDDQ off when disabling
+* the PHY.  There is a power leak on rk3288 and
+* suspend power _increases_ by 5 mA if you turn this
+* off.
+*/
}
 
return ret;
-- 
2.21.0.1020.gf2820cf01a-goog

Re: [PATCH] riscv: fix locking violation in page fault handler

[Palmer Dabbelt]

On Tue, 07 May 2019 00:36:46 PDT (-0700), sch...@suse.de wrote:

When a user mode process accesses an address in the vmalloc area
do_page_fault tries to unlock the mmap semaphore when it isn't locked.

Signed-off-by: Andreas Schwab 
---
 arch/riscv/mm/fault.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 88401d5125bc..c51878e5a66a 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -181,6 +181,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
up_read(>mmap_sem);
/* User mode accesses just cause a SIGSEGV */
if (user_mode(regs)) {
+bad_area_do_trap:
do_trap(regs, SIGSEGV, code, addr, tsk);
return;
}
@@ -230,7 +231,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
int index;

if (user_mode(regs))
-   goto bad_area;
+   goto bad_area_do_trap;

/*
 * Synchronize this task's top level page-table


I got lost with all the gotos, I think something like this is cleaner

   diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
   index 26293bc053a8..cec8be9e2d6a 100644
   --- a/arch/riscv/mm/fault.c
   +++ b/arch/riscv/mm/fault.c
   @@ -229,8 +229,9 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
   pte_t *pte_k;
   int index;
   
   +   /* User mode accesses just cause a SIGSEGV */

   if (user_mode(regs))
   -   goto bad_area;
   +   return do_trap(regs, SIGSEGV, code, addr, tsk);
   
   /*

* Synchronize this task's top level page-table

Unless anyone has a better idea?

Either way:

Reviewed-by: Palmer Dabbelt 

LMK if you, or anyone else, has a preference.  I'm assuming this will go in
through my tree, so I've picked up my version for now :)

Re: [PATCH] sched: introduce configurable delay before entering idle

[Marcelo Tosatti]

On Wed, May 08, 2019 at 12:15:19AM +0200, Peter Zijlstra wrote:
> On Tue, May 07, 2019 at 03:56:49PM -0300, Marcelo Tosatti wrote:
> > 
> > Certain workloads perform poorly on KVM compared to baremetal
> > due to baremetal's ability to perform mwait on NEED_RESCHED
> > bit of task flags (therefore skipping the IPI).
> > 
> > This patch introduces a configurable busy-wait delay before entering the
> > architecture delay routine, allowing wakeup IPIs to be skipped 
> > (if the IPI happens in that window).
> > 
> > The real-life workload which this patch improves performance
> > is SAP HANA (by 5-10%) (for which case setting idle_spin to 30 
> > is sufficient).
> > 
> > This patch improves the attached server.py and client.py example 
> > as follows:
> > 
> > Host:   31.814230202231556
> > Guest:  38.1771876513   (83 %)
> > Guest, idle_spin=50us:  33.31770989804  (95 %)
> > Guest, idle_spin=220us: 32.2782655149   (98 %)
> > 
> > Signed-off-by: Marcelo Tosatti 
> 
> Thanks for the CC..
> 
> NAK, this is something that should live in a virt idle governor or
> something along those lines.

Ok, makes sense, will rework the patch!

Re: [PATCH v3 2/2] hwmon: scmi: Scale values to target desired HWMON units

[Guenter Roeck]

On 5/7/19 4:09 PM, Florian Fainelli wrote:

If the SCMI firmware implementation is reporting values in a scale that
is different from the HWMON units, we need to scale up or down the value
according to how far appart they are.

Signed-off-by: Florian Fainelli 
---
  drivers/hwmon/scmi-hwmon.c | 43 +-
  1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
index a80183a488c5..7820854e5954 100644
--- a/drivers/hwmon/scmi-hwmon.c
+++ b/drivers/hwmon/scmi-hwmon.c
@@ -18,6 +18,47 @@ struct scmi_sensors {
const struct scmi_sensor_info **info[hwmon_max];
  };
  
+static inline u64 __pow10(u8 x)

+{
+   u64 r = 1;
+
+   if (unlikely(x > 18))
+   return r;
+


Strictly speaking that would be 19 (10^19=0x8AC7230489E8),
and I am not sure if returning 1 in that case is such a good idea.
If you really want to handle over/underflow situations, it should
be in the calling code.

Thanks,
Guenter


+   while (x--)
+   r *= 10;
+
+   return r;
+}
+
+static u64 scmi_hwmon_scale(const struct scmi_sensor_info *sensor, u64 value)
+{
+   s8 scale = sensor->scale;
+   u64 f;
+
+   switch (sensor->type) {
+   case TEMPERATURE_C:
+   case VOLTAGE:
+   case CURRENT:
+   scale += 3;
+   break;
+   case POWER:
+   case ENERGY:
+   scale += 6;
+   break;
+   default:
+   break;
+   }
+
+   f = __pow10(abs(scale));
+   if (scale > 0)
+   value *= f;
+   else
+   value = div64_u64(value, f);
+
+return value;
+}
+
  static int scmi_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
   u32 attr, int channel, long *val)
  {
@@ -30,7 +71,7 @@ static int scmi_hwmon_read(struct device *dev, enum 
hwmon_sensor_types type,
sensor = *(scmi_sensors->info[type] + channel);
ret = h->sensor_ops->reading_get(h, sensor->id, false, );
if (!ret)
-   *val = value;
+   *val = scmi_hwmon_scale(sensor, value);
  
  	return ret;

  }