RE: [LINUX PATCH v10 1/2] dt-bindings: mtd: arasan: Add device tree binding documentation

[Naga Sureshkumar Relli]

Hi Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, August 20, 2018 6:03 PM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 1/2] dt-bindings: mtd: arasan: Add device tree 
> binding
> documentation
> 
> On Fri, 17 Aug 2018 18:49:23 +0530
> Naga Sureshkumar Relli  wrote:
> 
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> > 
> > ---
> > Changes in v10:
> > - None
> > Changes in v9:
> > - None
> > Changes in v8:
> > - Updated compatible and clock-names as per Boris comments Changes in
> > v7:
> > - Corrected the acronyms those should be in caps changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> >  .../devicetree/bindings/mtd/arasan_nand.txt| 38 
> > ++
> >  1 file changed, 38 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mtd/arasan_nand.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > new file mode 100644
> > index 000..234d7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > @@ -0,0 +1,38 @@
> > +Arasan NAND Flash Controller with ONFI 3.1 support
> > +
> > +Required properties:
> > +- compatible:  Should be "xlnx,zynqmp-nand" or 
> > "arasan,nfc-v3p10"
> 
> In your example it's not an "or" since both are defined.
In our previous discussion (https://lore.kernel.org/patchwork/patch/748901/)
We decided to have compatible strings like " compatible = 
",", "arasan,";"
So it should be either of these.
so I will write something like below
"Possible values are  "xlnx,zynqmp-nand" 
"arasan,nfc-v3p10"
And in example I will mention any one compatible.
Is it ok?
> 
> > +- reg: Memory map for module access
> > +- interrupt-parent:Interrupt controller the interrupt is routed 
> > through
> > +- interrupts:  Should contain the interrupt for the device
> > +- clock-name:  List of input clocks - "sys", "flash"
> 
>  clock-names
Ok, will correct it in next version.
> 
> > +   (See clock bindings for details)
> > +- clocks:  Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables DMA support
> 
> Can't you detect that based on the compatible (or thanks to a register). If 
> it's something you
> choose when configuring the IP and can't detect at runtime I guess it's fine.
There is no way to select DMA when configuring the IP.
But it has internal DMA and there is a register to select PIO or DMA while 
starting a transfer.
So if user really don't want DMA, then we will never set DMA in the code based 
on DT property.
> 
> > +
> > +For NAND partition information please refer the below file
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > +   nand0: nand@ff10 {
> > +   compatible = "xlnx,zynqmp-nand", "arasan,nfc-v3p10"
> > +   reg = <0x0 0xff10 0x1000>;
> > +   clock-name = "sys", "flash"
> > +   clocks = <_clk _clk>;
> > +   interrupt-parent = <>;
> > +   interrupts = <0 14 4>;
> > +   arasan,has-mdma;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>
> > +
> > +   nand@0 {
> > +   reg = <0>
> > +   partition@0 {
> > +   label = "filesystem";
> > +   reg = <0x0 0x0 0x100>;
> > +   };
> 
> Hm, not sure you need to define partitions in this example, but if you do, 
> please define your
> partitions in a 'partitions' subnode:
> 
>   partitions {
>   compatible = "fixed-partitions";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   partition@0 {
>   reg = <0x0 0x100>;
>   ...
>   };
>   ...
>   };
> 
> > +   (...)
Ok, just now I saw Documentation/devicetree/bindings/mtd/marvell-nand.txt, I 
will update it accordingly in  next version.
> > + 

RE: [LINUX PATCH v10 1/2] dt-bindings: mtd: arasan: Add device tree binding documentation

[Naga Sureshkumar Relli]

Hi Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, August 20, 2018 6:03 PM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 1/2] dt-bindings: mtd: arasan: Add device tree 
> binding
> documentation
> 
> On Fri, 17 Aug 2018 18:49:23 +0530
> Naga Sureshkumar Relli  wrote:
> 
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> > 
> > ---
> > Changes in v10:
> > - None
> > Changes in v9:
> > - None
> > Changes in v8:
> > - Updated compatible and clock-names as per Boris comments Changes in
> > v7:
> > - Corrected the acronyms those should be in caps changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> >  .../devicetree/bindings/mtd/arasan_nand.txt| 38 
> > ++
> >  1 file changed, 38 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mtd/arasan_nand.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > new file mode 100644
> > index 000..234d7ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nand.txt
> > @@ -0,0 +1,38 @@
> > +Arasan NAND Flash Controller with ONFI 3.1 support
> > +
> > +Required properties:
> > +- compatible:  Should be "xlnx,zynqmp-nand" or 
> > "arasan,nfc-v3p10"
> 
> In your example it's not an "or" since both are defined.
In our previous discussion (https://lore.kernel.org/patchwork/patch/748901/)
We decided to have compatible strings like " compatible = 
",", "arasan,";"
So it should be either of these.
so I will write something like below
"Possible values are  "xlnx,zynqmp-nand" 
"arasan,nfc-v3p10"
And in example I will mention any one compatible.
Is it ok?
> 
> > +- reg: Memory map for module access
> > +- interrupt-parent:Interrupt controller the interrupt is routed 
> > through
> > +- interrupts:  Should contain the interrupt for the device
> > +- clock-name:  List of input clocks - "sys", "flash"
> 
>  clock-names
Ok, will correct it in next version.
> 
> > +   (See clock bindings for details)
> > +- clocks:  Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables DMA support
> 
> Can't you detect that based on the compatible (or thanks to a register). If 
> it's something you
> choose when configuring the IP and can't detect at runtime I guess it's fine.
There is no way to select DMA when configuring the IP.
But it has internal DMA and there is a register to select PIO or DMA while 
starting a transfer.
So if user really don't want DMA, then we will never set DMA in the code based 
on DT property.
> 
> > +
> > +For NAND partition information please refer the below file
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > +   nand0: nand@ff10 {
> > +   compatible = "xlnx,zynqmp-nand", "arasan,nfc-v3p10"
> > +   reg = <0x0 0xff10 0x1000>;
> > +   clock-name = "sys", "flash"
> > +   clocks = <_clk _clk>;
> > +   interrupt-parent = <>;
> > +   interrupts = <0 14 4>;
> > +   arasan,has-mdma;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>
> > +
> > +   nand@0 {
> > +   reg = <0>
> > +   partition@0 {
> > +   label = "filesystem";
> > +   reg = <0x0 0x0 0x100>;
> > +   };
> 
> Hm, not sure you need to define partitions in this example, but if you do, 
> please define your
> partitions in a 'partitions' subnode:
> 
>   partitions {
>   compatible = "fixed-partitions";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   partition@0 {
>   reg = <0x0 0x100>;
>   ...
>   };
>   ...
>   };
> 
> > +   (...)
Ok, just now I saw Documentation/devicetree/bindings/mtd/marvell-nand.txt, I 
will update it accordingly in  next version.
> > + 

Re: Enumeration issue with QCA9005 AR9462

[Lukas Wunner]

On Mon, Aug 20, 2018 at 06:06:24PM -0500, Bjorn Helgaas wrote:
> mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
> wifi device was present at boot, but disappeared after suspend/resume.
> 
> He also tested a recent kernel (5c60a7389d79, from Thu Aug 16),
> where the suspend/resume problem doesn't seem to happen, but the wifi
> device isn't enumerated correctly at boot-time.
> 
> [0.928714] pciehp :04:00.0:pcie204: Slot #0 AttnBtn- PwrCtrl- MRL- 
> AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
> [0.928752] pciehp :04:00.0:pcie204: Slot(0-1): Card not present
> [0.928811] pciehp :04:00.0:pcie204: Slot(0-1): Link Up
> [0.928815] pciehp :04:00.0:pcie204: Slot(0-1): No adapter
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=200839
> [2] https://bugzilla.kernel.org/attachment.cgi?id=277923

The hardware appears to be broken in that the Presence Detect State bit
in the Slot Status register is 0 (Slot Empty) even though the slot is
occupied.

Thus, as of v4.19, pciehp will initially consider the slot to be in
ON_STATE when it probes (because there are enumerated children).
It then looks at the PDS bit, sees that it's 0, believes that there
is no longer anything in the slot and synthesizes a Presence Detect
Changed event to bring down the slot.  The IRQ thread then removes
the device in the slot, sees that the link is up, tries to bring the
slot up again, but that fails because __pciehp_enable_slot() complains
that the Presence Detect State bit isn't set ("No adapter").

The slot is then considered to be in OFF_STATE by pciehp, even though
the rescan made the device reappear behind pciehp's back.  On resume
from system sleep, pciehp sees that the Presence Detect State bit
in the Slot Status register is still 0, and because it's already in
OFF_STATE, there's nothing to do.

Up until v4.18, an unoccupied slot was only brought down on resume:

/* Check if slot is occupied */
pciehp_get_adapter_status(slot, );
mutex_lock(>hotplug_lock);
if (status)
pciehp_enable_slot(slot);
else
pciehp_disable_slot(slot);
mutex_unlock(>hotplug_lock);

>From v4.19, this is now also done on probe for consistency.

The above hypothesis is confirmed by the lspci -vv output:

LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive+ BWMgmt+ 
ABWMgmt-
^
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
 

Possible solutions:

(a) Be lenient towards broken hardware and accept DLActive+ as a proxy
for PresDet+.

(b) Add a blacklist to pciehp such that it doesn't bind to [1ae9:0200].
The bug reporter writes that "it's a single Half Mini PCIe card,
with two chipsets (Wil6110? + AR9462) combined by a PCIe hub".
This sounds like it's not really hotpluggable.
(Is Mini PCIe hotplug capable at all?)

Let me go through the driver and see if (a) is feasible and how intrusive
it would be.

Thanks,

Lukas

Re: Enumeration issue with QCA9005 AR9462

[Lukas Wunner]

On Mon, Aug 20, 2018 at 06:06:24PM -0500, Bjorn Helgaas wrote:
> mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
> wifi device was present at boot, but disappeared after suspend/resume.
> 
> He also tested a recent kernel (5c60a7389d79, from Thu Aug 16),
> where the suspend/resume problem doesn't seem to happen, but the wifi
> device isn't enumerated correctly at boot-time.
> 
> [0.928714] pciehp :04:00.0:pcie204: Slot #0 AttnBtn- PwrCtrl- MRL- 
> AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
> [0.928752] pciehp :04:00.0:pcie204: Slot(0-1): Card not present
> [0.928811] pciehp :04:00.0:pcie204: Slot(0-1): Link Up
> [0.928815] pciehp :04:00.0:pcie204: Slot(0-1): No adapter
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=200839
> [2] https://bugzilla.kernel.org/attachment.cgi?id=277923

The hardware appears to be broken in that the Presence Detect State bit
in the Slot Status register is 0 (Slot Empty) even though the slot is
occupied.

Thus, as of v4.19, pciehp will initially consider the slot to be in
ON_STATE when it probes (because there are enumerated children).
It then looks at the PDS bit, sees that it's 0, believes that there
is no longer anything in the slot and synthesizes a Presence Detect
Changed event to bring down the slot.  The IRQ thread then removes
the device in the slot, sees that the link is up, tries to bring the
slot up again, but that fails because __pciehp_enable_slot() complains
that the Presence Detect State bit isn't set ("No adapter").

The slot is then considered to be in OFF_STATE by pciehp, even though
the rescan made the device reappear behind pciehp's back.  On resume
from system sleep, pciehp sees that the Presence Detect State bit
in the Slot Status register is still 0, and because it's already in
OFF_STATE, there's nothing to do.

Up until v4.18, an unoccupied slot was only brought down on resume:

/* Check if slot is occupied */
pciehp_get_adapter_status(slot, );
mutex_lock(>hotplug_lock);
if (status)
pciehp_enable_slot(slot);
else
pciehp_disable_slot(slot);
mutex_unlock(>hotplug_lock);

>From v4.19, this is now also done on probe for consistency.

The above hypothesis is confirmed by the lspci -vv output:

LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive+ BWMgmt+ 
ABWMgmt-
^
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
 

Possible solutions:

(a) Be lenient towards broken hardware and accept DLActive+ as a proxy
for PresDet+.

(b) Add a blacklist to pciehp such that it doesn't bind to [1ae9:0200].
The bug reporter writes that "it's a single Half Mini PCIe card,
with two chipsets (Wil6110? + AR9462) combined by a PCIe hub".
This sounds like it's not really hotpluggable.
(Is Mini PCIe hotplug capable at all?)

Let me go through the driver and see if (a) is feasible and how intrusive
it would be.

Thanks,

Lukas

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Frank Rowand]

On 08/20/18 19:08, Masahiro Yamada wrote:
> Hi Frank,
> 
> 2018-08-21 10:31 GMT+09:00 Frank Rowand :
>> On 08/20/18 14:32, Rob Herring wrote:
>>> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:

 On 07/03/18 18:59, Masahiro Yamada wrote:
> It is tedious to specify extra compiler options for every file.
> HOST_EXTRACFLAGS is useful to add options to all files in a
> directory.
>
> -I$(src)/libfdt is needed for all the files in this directory
> to include libfdt_env.h etc. from scripts/dtc/libfdt/.
>
> On the other hand, -I$(src) is used to include check-in headers
> from generated C files.  Thus, I added it only to dtc-lexer.lex.o
> and dtc-parser.tab.o .
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/dtc/Makefile | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> index 9cac65b..1c943e0 100644
> --- a/scripts/dtc/Makefile
> +++ b/scripts/dtc/Makefile
> @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
> livetree.o treesource.o \
>  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
>
>  # Source files need to get at the userspace version of libfdt_env.h to 
> compile
> +HOST_EXTRACFLAGS := -I$(src)/libfdt

 Shouldn't that be += instead of :=?
>>>
>>> I don't think so. The definition is local to the file (and reset
>>> before each makefile is included).
>>>
>>> Rob
>>>
>>
>> Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
>> instead of :=, including the example in Documentation/kbuild/makefiles.txt
>>
>> What makes scripts/dtc/Makefile different than the other makefiles?
>>
>> -Frank
>>
> 
> 
> := and += work in the same way in here.

Unless I do: HOST_EXTRACFLAGS=xxx make
where "xxx" is some random flag I feel like adding in a particular build.

Or is there something else buried in the kernel makefiles that leads to
a result different than I get from a simple example of recursive make files?

-Frank

> 
> 
> As Rob said, HOST_EXTRACFLAGS is reset in each makefile
> because HOST_EXTRACFLAGS is not export'ed.
> (scripts/gcc-plugins/Makefile actually export's it, but it is wrong.)
> 
> 
> Precisely speaking, HOST_EXTRACFLAGS is immediately expanded
> if it is set by :=, whereas it is lazily expanded if it is
> set by +=.  But, there is no effective difference in this case.
> 
> 

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Frank Rowand]

On 08/20/18 19:08, Masahiro Yamada wrote:
> Hi Frank,
> 
> 2018-08-21 10:31 GMT+09:00 Frank Rowand :
>> On 08/20/18 14:32, Rob Herring wrote:
>>> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:

 On 07/03/18 18:59, Masahiro Yamada wrote:
> It is tedious to specify extra compiler options for every file.
> HOST_EXTRACFLAGS is useful to add options to all files in a
> directory.
>
> -I$(src)/libfdt is needed for all the files in this directory
> to include libfdt_env.h etc. from scripts/dtc/libfdt/.
>
> On the other hand, -I$(src) is used to include check-in headers
> from generated C files.  Thus, I added it only to dtc-lexer.lex.o
> and dtc-parser.tab.o .
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/dtc/Makefile | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> index 9cac65b..1c943e0 100644
> --- a/scripts/dtc/Makefile
> +++ b/scripts/dtc/Makefile
> @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
> livetree.o treesource.o \
>  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
>
>  # Source files need to get at the userspace version of libfdt_env.h to 
> compile
> +HOST_EXTRACFLAGS := -I$(src)/libfdt

 Shouldn't that be += instead of :=?
>>>
>>> I don't think so. The definition is local to the file (and reset
>>> before each makefile is included).
>>>
>>> Rob
>>>
>>
>> Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
>> instead of :=, including the example in Documentation/kbuild/makefiles.txt
>>
>> What makes scripts/dtc/Makefile different than the other makefiles?
>>
>> -Frank
>>
> 
> 
> := and += work in the same way in here.

Unless I do: HOST_EXTRACFLAGS=xxx make
where "xxx" is some random flag I feel like adding in a particular build.

Or is there something else buried in the kernel makefiles that leads to
a result different than I get from a simple example of recursive make files?

-Frank

> 
> 
> As Rob said, HOST_EXTRACFLAGS is reset in each makefile
> because HOST_EXTRACFLAGS is not export'ed.
> (scripts/gcc-plugins/Makefile actually export's it, but it is wrong.)
> 
> 
> Precisely speaking, HOST_EXTRACFLAGS is immediately expanded
> if it is set by :=, whereas it is lazily expanded if it is
> set by +=.  But, there is no effective difference in this case.
> 
> 

Re: [PATCH] PCI: dwc: fix scheduling while atomic issues

[kbuild test robot]

Hi Jisheng,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Jisheng-Zhang/PCI-dwc-fix-scheduling-while-atomic-issues/20180821-110033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/pci/controller/dwc/pcie-designware.o: In function 
`dw_pcie_prog_outbound_atu':
>> pcie-designware.c:(.text+0x32c): undefined reference to `__bad_udelay'
   pcie-designware.c:(.text+0x424): undefined reference to `__bad_udelay'
   drivers/pci/controller/dwc/pcie-designware.o: In function 
`dw_pcie_prog_inbound_atu':
   pcie-designware.c:(.text+0x538): undefined reference to `__bad_udelay'
   pcie-designware.c:(.text+0x608): undefined reference to `__bad_udelay'

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


.config.gz
Description: application/gzip

Re: [PATCH] PCI: dwc: fix scheduling while atomic issues

[kbuild test robot]

Hi Jisheng,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Jisheng-Zhang/PCI-dwc-fix-scheduling-while-atomic-issues/20180821-110033
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/pci/controller/dwc/pcie-designware.o: In function 
`dw_pcie_prog_outbound_atu':
>> pcie-designware.c:(.text+0x32c): undefined reference to `__bad_udelay'
   pcie-designware.c:(.text+0x424): undefined reference to `__bad_udelay'
   drivers/pci/controller/dwc/pcie-designware.o: In function 
`dw_pcie_prog_inbound_atu':
   pcie-designware.c:(.text+0x538): undefined reference to `__bad_udelay'
   pcie-designware.c:(.text+0x608): undefined reference to `__bad_udelay'

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


.config.gz
Description: application/gzip

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Song,

> However, if I start a.out AFTER enabling the uprobe, there is something wrong:
> 
> root@virt-test:~# ~/a.out
> 11
> semaphore 0   <<< this should be non-zero, as the uprobe is already 
> enabled

Ok. I'm able to reproduce this. Digging deeper.

Ravi

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Song,

> However, if I start a.out AFTER enabling the uprobe, there is something wrong:
> 
> root@virt-test:~# ~/a.out
> 11
> semaphore 0   <<< this should be non-zero, as the uprobe is already 
> enabled

Ok. I'm able to reproduce this. Digging deeper.

Ravi

Re: [PATCH] staging: android: ion: check for kref overflow

[Greg Kroah-Hartman]

On Mon, Aug 20, 2018 at 06:30:57PM -0700, Daniel Rosenberg wrote:
> Userspace can cause the kref to handles to increment
> arbitrarily high. Ensure it does not overflow.
> 
> Signed-off-by: Daniel Rosenberg 
> ---
> 
> This patch is against 4.4. It does not apply to master due to a large
> rework of ion in 4.12 which removed the affected functions altogther.
> It applies from 3.18 to 4.11, although with a trivial conflict resolution
> for the later branches.
> 4c23cbff073f3b9b ("staging: android: ion: Remove import interface")
> 
>  drivers/staging/android/ion/ion.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 374f840f31a48..11f93a6314fdb 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -15,6 +15,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -387,6 +388,15 @@ static void ion_handle_get(struct ion_handle *handle)
>   kref_get(>ref);
>  }
>  
> +/* Must hold the client lock */
> +static struct ion_handle *ion_handle_get_check_overflow(
> + struct ion_handle *handle)
> +{
> + if (atomic_read(>ref.refcount) + 1 == 0)
> + return ERR_PTR(-EOVERFLOW);
> + ion_handle_get(handle);
> + return handle;
> +}
> +
>  static int ion_handle_put_nolock(struct ion_handle *handle)
>  {
>   int ret;

I tried to apply this patch, but it looks like you hand-edited it which
made it impossible to apply.  Did you do that, or did git really create
this broken diff exactly as-is?

Try applying this patch yourself, you will see the error.  I could fix
it by manually editing the diff metadata but I really shouldn't have to
as that implies you did not test the patch you sent me :(

thanks,

greg k-h

Re: [PATCH] staging: android: ion: check for kref overflow

[Greg Kroah-Hartman]

On Mon, Aug 20, 2018 at 06:30:57PM -0700, Daniel Rosenberg wrote:
> Userspace can cause the kref to handles to increment
> arbitrarily high. Ensure it does not overflow.
> 
> Signed-off-by: Daniel Rosenberg 
> ---
> 
> This patch is against 4.4. It does not apply to master due to a large
> rework of ion in 4.12 which removed the affected functions altogther.
> It applies from 3.18 to 4.11, although with a trivial conflict resolution
> for the later branches.
> 4c23cbff073f3b9b ("staging: android: ion: Remove import interface")
> 
>  drivers/staging/android/ion/ion.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 374f840f31a48..11f93a6314fdb 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -15,6 +15,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -387,6 +388,15 @@ static void ion_handle_get(struct ion_handle *handle)
>   kref_get(>ref);
>  }
>  
> +/* Must hold the client lock */
> +static struct ion_handle *ion_handle_get_check_overflow(
> + struct ion_handle *handle)
> +{
> + if (atomic_read(>ref.refcount) + 1 == 0)
> + return ERR_PTR(-EOVERFLOW);
> + ion_handle_get(handle);
> + return handle;
> +}
> +
>  static int ion_handle_put_nolock(struct ion_handle *handle)
>  {
>   int ret;

I tried to apply this patch, but it looks like you hand-edited it which
made it impossible to apply.  Did you do that, or did git really create
this broken diff exactly as-is?

Try applying this patch yourself, you will see the error.  I could fix
it by manually editing the diff metadata but I really shouldn't have to
as that implies you did not test the patch you sent me :(

thanks,

greg k-h

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

[Konstantin Khlebnikov]

On Sat, Aug 18, 2018 at 4:22 AM, Matthew Wilcox  wrote:
> On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
>> - scan = div64_u64(scan * fraction[file],
>> -  denominator);
>> + if (scan > 1)
>> + scan = div64_u64(scan * fraction[file],
>> +  denominator);
>
> Wouldn't we be better off doing a div_round_up?  ie:
>
> scan = div64_u64(scan * fraction[file] + denominator - 1, 
> denominator);
>
> although i'd rather hide that in a new macro in math64.h than opencode it
> here.

All numbers here should be up to nr_pages * 200 and fit into unsigned long.
I see no reason for u64. If they overflow then u64 wouldn't help either.

There is macro DIV_ROUND_UP in kernel.h

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

[Konstantin Khlebnikov]

On Sat, Aug 18, 2018 at 4:22 AM, Matthew Wilcox  wrote:
> On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
>> - scan = div64_u64(scan * fraction[file],
>> -  denominator);
>> + if (scan > 1)
>> + scan = div64_u64(scan * fraction[file],
>> +  denominator);
>
> Wouldn't we be better off doing a div_round_up?  ie:
>
> scan = div64_u64(scan * fraction[file] + denominator - 1, 
> denominator);
>
> although i'd rather hide that in a new macro in math64.h than opencode it
> here.

All numbers here should be up to nr_pages * 200 and fit into unsigned long.
I see no reason for u64. If they overflow then u64 wouldn't help either.

There is macro DIV_ROUND_UP in kernel.h

Re: [BUG][BISECT] NFSv4 root failures after "fs/locks: allow a lock request to block other requests."

[NeilBrown]

On Thu, Aug 16 2018, NeilBrown wrote:

> On Wed, Aug 15 2018, Jeff Layton wrote:
>
>> On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
>>> Hi,
>>> 
>>> Bisect pointed commit ce3147990450a68b3f549088b30f087742a08b5d
>>> ("fs/locks: allow a lock request to block other requests.") to failure
>>> boot of NFSv4 with root on several boards.
>>> 
>>> Log is here:
>>> https://krzk.eu/#/builders/21/builds/836/steps/12/logs/serial0
>>> 
>>> With several errors:
>>> kernel BUG at ../fs/locks.c:336!
>>> Unable to handle kernel NULL pointer dereference at virtual address 0004
>>> 
>>> Configuration:
>>> 1. exynos_defconfig
>>> 2. Arch ARM Linux
>>> 3. Boards:
>>> a. Odroid family (ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC)
>>> b. Toradex Colibri VF50 (ARMv7, UP, Cortex-A5)
>>> 4. Systemd: v236, 238
>>> 5. All boards boot from TFTP with NFS root (NFSv4)
>>> 
>>> On Colibri VF50 I got slightly different errors:
>>> [   11.663204] Internal error: Oops - undefined instruction: 0 [#1] ARM
>>> [   12.455273] Unable to handle kernel NULL pointer dereference at
>>> virtual address 0004
>>> and only with some specific GCC (v6.3) or with other conditions which
>>> I did not bisect yet. Maybe Colibri's failure is unrelated to that
>>> commit.
>>> 
>>> Best regards,
>>> Krzysztof
>
> Thanks a lot for the report Krzysztof!!
>
>>
>> The BUG is due to a lock being freed when the fl_blocked list wasn't
>> empty (implying that there were still blocked locks waiting on it).
>>
>> There are a number of calls to locks_delete_lock_ctx in posix_lock_inode
>> and I don't think the fl_blocked list is being handled properly with all
>> of them. It only transplants the blocked locks to a new lock when there
>> are surviving locks on the list, and that may not be the case when the
>> whole file is being unlocked.
>
> locks_delete_lock_ctx() calls locks_unlink_lock_ctx() which calls
> locks_wake_up_block() which doesn't only wake_up the blocks, but also
> detached them. When that function completes, ->fl_blocked must be empty.
>
> The trace shows the locks_free_lock() call at the end of fcntl_setlk64()
> as the problematic call.
> This suggests that do_lock_file_wait() exited with ->fl_blocked
> non-empty, which it shouldn't.
>
> I think we need to insert a call to locks_wake_up_block() in
> do_lock_file_wait() before it returns.
> I cannot find a sequence that would make this necessary, but
> it isn't surprising that there might be one.
>
> I'll dig through the code a bit more later and make sure I understand
> what is happening.
>

I think this problem if fixed by the following.  It is probably
triggered when the owner already has a lock for part of the requested
range.  After waiting for some other lock, the pending request gets
merged with the existing lock, and blocked requests aren't moved across
in that case.

I still haven't done more testing, so this is just FYI, not a
submission.

Thanks,
NeilBrown

From: NeilBrown 
Date: Tue, 21 Aug 2018 15:09:06 +1000
Subject: [PATCH] fs/locks: always delete_block after waiting.

Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we much clean them up.
If the lock was granted, the requests might have been
moved to the new lock, though when merged with a
pre-exiting lock, this might not happen.
No all cases we don't want blocked locks to remain
attached, so we remove them to be safe.

Signed-off-by: NeilBrown 
---
 fs/locks.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index de38bafb7f7b..6b310112cf3b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1276,12 +1276,10 @@ static int posix_lock_inode_wait(struct inode *inode, 
struct file_lock *fl)
if (error != FILE_LOCK_DEFERRED)
break;
error = wait_event_interruptible(fl->fl_wait, !fl->fl_blocker);
-   if (!error)
-   continue;
-
-   locks_delete_block(fl);
-   break;
+   if (error)
+   break;
}
+   locks_delete_block(fl);
return error;
 }
 
@@ -1971,12 +1969,10 @@ static int flock_lock_inode_wait(struct inode *inode, 
struct file_lock *fl)
if (error != FILE_LOCK_DEFERRED)
break;
error = wait_event_interruptible(fl->fl_wait, !fl->fl_blocker);
-   if (!error)
-   continue;
-
-   locks_delete_block(fl);
-   break;
+   if (error)
+   break;
}
+   locks_delete_block(fl);
return error;
 }
 
@@ -2250,12 +2246,10 @@ static int do_lock_file_wait(struct file *filp, 
unsigned int cmd,
if (error != FILE_LOCK_DEFERRED)
break;
error = 

Re: [BUG][BISECT] NFSv4 root failures after "fs/locks: allow a lock request to block other requests."

[NeilBrown]

On Thu, Aug 16 2018, NeilBrown wrote:

> On Wed, Aug 15 2018, Jeff Layton wrote:
>
>> On Wed, 2018-08-15 at 14:28 +0200, Krzysztof Kozlowski wrote:
>>> Hi,
>>> 
>>> Bisect pointed commit ce3147990450a68b3f549088b30f087742a08b5d
>>> ("fs/locks: allow a lock request to block other requests.") to failure
>>> boot of NFSv4 with root on several boards.
>>> 
>>> Log is here:
>>> https://krzk.eu/#/builders/21/builds/836/steps/12/logs/serial0
>>> 
>>> With several errors:
>>> kernel BUG at ../fs/locks.c:336!
>>> Unable to handle kernel NULL pointer dereference at virtual address 0004
>>> 
>>> Configuration:
>>> 1. exynos_defconfig
>>> 2. Arch ARM Linux
>>> 3. Boards:
>>> a. Odroid family (ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC)
>>> b. Toradex Colibri VF50 (ARMv7, UP, Cortex-A5)
>>> 4. Systemd: v236, 238
>>> 5. All boards boot from TFTP with NFS root (NFSv4)
>>> 
>>> On Colibri VF50 I got slightly different errors:
>>> [   11.663204] Internal error: Oops - undefined instruction: 0 [#1] ARM
>>> [   12.455273] Unable to handle kernel NULL pointer dereference at
>>> virtual address 0004
>>> and only with some specific GCC (v6.3) or with other conditions which
>>> I did not bisect yet. Maybe Colibri's failure is unrelated to that
>>> commit.
>>> 
>>> Best regards,
>>> Krzysztof
>
> Thanks a lot for the report Krzysztof!!
>
>>
>> The BUG is due to a lock being freed when the fl_blocked list wasn't
>> empty (implying that there were still blocked locks waiting on it).
>>
>> There are a number of calls to locks_delete_lock_ctx in posix_lock_inode
>> and I don't think the fl_blocked list is being handled properly with all
>> of them. It only transplants the blocked locks to a new lock when there
>> are surviving locks on the list, and that may not be the case when the
>> whole file is being unlocked.
>
> locks_delete_lock_ctx() calls locks_unlink_lock_ctx() which calls
> locks_wake_up_block() which doesn't only wake_up the blocks, but also
> detached them. When that function completes, ->fl_blocked must be empty.
>
> The trace shows the locks_free_lock() call at the end of fcntl_setlk64()
> as the problematic call.
> This suggests that do_lock_file_wait() exited with ->fl_blocked
> non-empty, which it shouldn't.
>
> I think we need to insert a call to locks_wake_up_block() in
> do_lock_file_wait() before it returns.
> I cannot find a sequence that would make this necessary, but
> it isn't surprising that there might be one.
>
> I'll dig through the code a bit more later and make sure I understand
> what is happening.
>

I think this problem if fixed by the following.  It is probably
triggered when the owner already has a lock for part of the requested
range.  After waiting for some other lock, the pending request gets
merged with the existing lock, and blocked requests aren't moved across
in that case.

I still haven't done more testing, so this is just FYI, not a
submission.

Thanks,
NeilBrown

From: NeilBrown 
Date: Tue, 21 Aug 2018 15:09:06 +1000
Subject: [PATCH] fs/locks: always delete_block after waiting.

Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we much clean them up.
If the lock was granted, the requests might have been
moved to the new lock, though when merged with a
pre-exiting lock, this might not happen.
No all cases we don't want blocked locks to remain
attached, so we remove them to be safe.

Signed-off-by: NeilBrown 
---
 fs/locks.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index de38bafb7f7b..6b310112cf3b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1276,12 +1276,10 @@ static int posix_lock_inode_wait(struct inode *inode, 
struct file_lock *fl)
if (error != FILE_LOCK_DEFERRED)
break;
error = wait_event_interruptible(fl->fl_wait, !fl->fl_blocker);
-   if (!error)
-   continue;
-
-   locks_delete_block(fl);
-   break;
+   if (error)
+   break;
}
+   locks_delete_block(fl);
return error;
 }
 
@@ -1971,12 +1969,10 @@ static int flock_lock_inode_wait(struct inode *inode, 
struct file_lock *fl)
if (error != FILE_LOCK_DEFERRED)
break;
error = wait_event_interruptible(fl->fl_wait, !fl->fl_blocker);
-   if (!error)
-   continue;
-
-   locks_delete_block(fl);
-   break;
+   if (error)
+   break;
}
+   locks_delete_block(fl);
return error;
 }
 
@@ -2250,12 +2246,10 @@ static int do_lock_file_wait(struct file *filp, 
unsigned int cmd,
if (error != FILE_LOCK_DEFERRED)
break;
error = 

Re: [PATCH] kobject: Access kobject name with caution if state is not initialized

[Srikar Dronamraju]

* Greg Kroah-Hartman  [2018-08-20 21:22:47]:

> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > A stupid module test like
> > https://github.com/srikard/tests/blob/master/modules/kobject_test.c
> > can panic the system.
> 
> Lots of stupid modules can do dumb things.  Just don't do that.  The
> kernel is not built to keep you from doing stupid things in kernel code
> :)
> 

Completely agree. kernel/module code is not for doing stupid things.
However we seem to be hitting this once in a while in a weird case with
a slightly older kernel with no out of tree modules.

crash> bt
PID: 54813  TASK: c00c4c76c160  CPU: 40  COMMAND: "lvm"
 #0 [c0004ac0eb50] crash_kexec at c01a1be4
 #1 [c0004ac0eb80] die at c0025668
 #2 [c0004ac0ec20] bad_page_fault at c005d7a0
 #3 [c0004ac0ec90] handle_page_fault at c0009608
 Data Access [300] exception frame:
 R0:  c0521cb4R1:  c0004ac0ef80R2:  c1274800   
 R3:  0002R4:  R5:  0002   
 R6:  R7:  R8:     
 R9:  0004R10: c0521c90R11: c1434800   
 R12: c00e3750R13: c7b16800R14: 3fff85970520   
 R15: 3fffd442c6c0R16: R17: 005c   
 R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400   
 R21: 0100333c23d0R22: 0025R23: c143a648   
 R24: 03e0R25: 0020R26: c0004ac0f140   
 R27: R28: 0002R29:    
 R30: c143aa28R31: c143a654   
 NIP: c051bda8MSR: 80019033OR3: c00093ec
 CTR: c0521c90LR:  c051e7b8XER: 
 CCR: 88048444MQ:  DAR: 0002
 DSISR: 4000 Syscall Result: 
 #4 [c0004ac0ef80] strnlen at c051bda8
 [Link Register] [c0004ac0ef80] string at c051e7b8
 #5 [c0004ac0efd0] vsnprintf at c0521cb4
 #6 [c0004ac0f050] vscnprintf at c05226e0
 #7 [c0004ac0f080] vprintk_default at c00e381c
 #8 [c0004ac0f0f0] printk at c0a2047c
 #9 [c0004ac0f110] kobject_put at c0510c34
#10 [c0004ac0f1a0] of_node_put at c0813034
#11 [c0004ac0f1c0] pci_release_of_node at c05ae724
#12 [c0004ac0f1f0] pci_release_dev at c056ff60
#13 [c0004ac0f220] device_release at c065a468
#14 [c0004ac0f2a0] kobject_put at c0510abc
#15 [c0004ac0f330] put_device at c065aaf4
#16 [c0004ac0f350] scsi_host_dev_release at c06a2f10
#17 [c0004ac0f390] device_release at c065a468
#18 [c0004ac0f410] kobject_put at c0510abc
#19 [c0004ac0f4a0] put_device at c065aaf4
#20 [c0004ac0f4c0] scsi_target_dev_release at c06b2bb4
#21 [c0004ac0f4f0] device_release at c065a468
#22 [c0004ac0f570] kobject_put at c0510abc
#23 [c0004ac0f600] put_device at c065aaf4
#24 [c0004ac0f620] scsi_device_dev_release_usercontext at c06b8790
#25 [c0004ac0f670] execute_in_process_context at c01185b4
#26 [c0004ac0f6a0] scsi_device_dev_release at c06b8644
#27 [c0004ac0f6c0] device_release at c065a468
#28 [c0004ac0f740] kobject_put at c0510abc
#29 [c0004ac0f7d0] put_device at c065aaf4
#30 [c0004ac0f7f0] scsi_device_put at c069ff98
#31 [c0004ac0f820] sd_release at d8013f4c [sd_mod]
#32 [c0004ac0f8a0] __blkdev_put at c03a7318
#33 [c0004ac0f900] dm_put_table_device at d6ed09fc [dm_mod]
#34 [c0004ac0f940] dm_put_device at d6ed663c [dm_mod]
#35 [c0004ac0f9b0] linear_dtr at d6eda2d4 [dm_mod]
#36 [c0004ac0f9e0] dm_table_destroy at d6ed7380 [dm_mod]
#37 [c0004ac0fa70] dev_suspend at d6edf114 [dm_mod]
#38 [c0004ac0faf0] ctl_ioctl at d6edc2e0 [dm_mod]
#39 [c0004ac0fcf0] dm_ctl_ioctl at d6edc548 [dm_mod]
#40 [c0004ac0fd10] do_vfs_ioctl at c035a9a8
#41 [c0004ac0fdd0] sys_ioctl at c035aea4
#42 [c0004ac0fe30] system_call at c000a284
 System Call [c00] exception frame:
 R0:  0036R1:  3fffd442c4b0R2:  3fff858a7400   
 R3:  0006R4:  c138fd06R5:  0100333c23d0   
 R6:  0004R7:  3fff8597a2f0R8:  0006   
 R9:  R10: R11:    
 R12: R13: 3fff85b42ff0R14: 3fff85970520   
 R15: 3fffd442c6c0R16: R17: 005c   
 R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400   
 R21: 0100333c23d0R22: 

Re: [PATCH] kobject: Access kobject name with caution if state is not initialized

[Srikar Dronamraju]

* Greg Kroah-Hartman  [2018-08-20 21:22:47]:

> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > A stupid module test like
> > https://github.com/srikard/tests/blob/master/modules/kobject_test.c
> > can panic the system.
> 
> Lots of stupid modules can do dumb things.  Just don't do that.  The
> kernel is not built to keep you from doing stupid things in kernel code
> :)
> 

Completely agree. kernel/module code is not for doing stupid things.
However we seem to be hitting this once in a while in a weird case with
a slightly older kernel with no out of tree modules.

crash> bt
PID: 54813  TASK: c00c4c76c160  CPU: 40  COMMAND: "lvm"
 #0 [c0004ac0eb50] crash_kexec at c01a1be4
 #1 [c0004ac0eb80] die at c0025668
 #2 [c0004ac0ec20] bad_page_fault at c005d7a0
 #3 [c0004ac0ec90] handle_page_fault at c0009608
 Data Access [300] exception frame:
 R0:  c0521cb4R1:  c0004ac0ef80R2:  c1274800   
 R3:  0002R4:  R5:  0002   
 R6:  R7:  R8:     
 R9:  0004R10: c0521c90R11: c1434800   
 R12: c00e3750R13: c7b16800R14: 3fff85970520   
 R15: 3fffd442c6c0R16: R17: 005c   
 R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400   
 R21: 0100333c23d0R22: 0025R23: c143a648   
 R24: 03e0R25: 0020R26: c0004ac0f140   
 R27: R28: 0002R29:    
 R30: c143aa28R31: c143a654   
 NIP: c051bda8MSR: 80019033OR3: c00093ec
 CTR: c0521c90LR:  c051e7b8XER: 
 CCR: 88048444MQ:  DAR: 0002
 DSISR: 4000 Syscall Result: 
 #4 [c0004ac0ef80] strnlen at c051bda8
 [Link Register] [c0004ac0ef80] string at c051e7b8
 #5 [c0004ac0efd0] vsnprintf at c0521cb4
 #6 [c0004ac0f050] vscnprintf at c05226e0
 #7 [c0004ac0f080] vprintk_default at c00e381c
 #8 [c0004ac0f0f0] printk at c0a2047c
 #9 [c0004ac0f110] kobject_put at c0510c34
#10 [c0004ac0f1a0] of_node_put at c0813034
#11 [c0004ac0f1c0] pci_release_of_node at c05ae724
#12 [c0004ac0f1f0] pci_release_dev at c056ff60
#13 [c0004ac0f220] device_release at c065a468
#14 [c0004ac0f2a0] kobject_put at c0510abc
#15 [c0004ac0f330] put_device at c065aaf4
#16 [c0004ac0f350] scsi_host_dev_release at c06a2f10
#17 [c0004ac0f390] device_release at c065a468
#18 [c0004ac0f410] kobject_put at c0510abc
#19 [c0004ac0f4a0] put_device at c065aaf4
#20 [c0004ac0f4c0] scsi_target_dev_release at c06b2bb4
#21 [c0004ac0f4f0] device_release at c065a468
#22 [c0004ac0f570] kobject_put at c0510abc
#23 [c0004ac0f600] put_device at c065aaf4
#24 [c0004ac0f620] scsi_device_dev_release_usercontext at c06b8790
#25 [c0004ac0f670] execute_in_process_context at c01185b4
#26 [c0004ac0f6a0] scsi_device_dev_release at c06b8644
#27 [c0004ac0f6c0] device_release at c065a468
#28 [c0004ac0f740] kobject_put at c0510abc
#29 [c0004ac0f7d0] put_device at c065aaf4
#30 [c0004ac0f7f0] scsi_device_put at c069ff98
#31 [c0004ac0f820] sd_release at d8013f4c [sd_mod]
#32 [c0004ac0f8a0] __blkdev_put at c03a7318
#33 [c0004ac0f900] dm_put_table_device at d6ed09fc [dm_mod]
#34 [c0004ac0f940] dm_put_device at d6ed663c [dm_mod]
#35 [c0004ac0f9b0] linear_dtr at d6eda2d4 [dm_mod]
#36 [c0004ac0f9e0] dm_table_destroy at d6ed7380 [dm_mod]
#37 [c0004ac0fa70] dev_suspend at d6edf114 [dm_mod]
#38 [c0004ac0faf0] ctl_ioctl at d6edc2e0 [dm_mod]
#39 [c0004ac0fcf0] dm_ctl_ioctl at d6edc548 [dm_mod]
#40 [c0004ac0fd10] do_vfs_ioctl at c035a9a8
#41 [c0004ac0fdd0] sys_ioctl at c035aea4
#42 [c0004ac0fe30] system_call at c000a284
 System Call [c00] exception frame:
 R0:  0036R1:  3fffd442c4b0R2:  3fff858a7400   
 R3:  0006R4:  c138fd06R5:  0100333c23d0   
 R6:  0004R7:  3fff8597a2f0R8:  0006   
 R9:  R10: R11:    
 R12: R13: 3fff85b42ff0R14: 3fff85970520   
 R15: 3fffd442c6c0R16: R17: 005c   
 R18: 3fff859797c8R19: 3fff859a28f0R20: 0100333c2400   
 R21: 0100333c23d0R22: 

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Song Liu]

On Mon, Aug 20, 2018 at 9:42 PM, Ravi Bangoria
 wrote:
> Hi Song,
>
>> root@virt-test:~# ~/a.out
>> 11
>> semaphore 0
>> semaphore 0
>> semaphore 2  <<<  when the uprobe is enabled
>
> Yes, this happens when multiple vmas points to the same file portion.
> Can you check /proc/`pgrep a.out`/maps.
>
> Logic is simple. If we are going to patch an instruction, increment the
> reference counter. If we are going to unpatch an instruction, decrement
> the reference counter. In this case, we patched instruction twice and
> thus incremented reference counter twice as well.

Yes, this makes sense.

Song

>
> Ravi
>

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Song Liu]

On Mon, Aug 20, 2018 at 9:42 PM, Ravi Bangoria
 wrote:
> Hi Song,
>
>> root@virt-test:~# ~/a.out
>> 11
>> semaphore 0
>> semaphore 0
>> semaphore 2  <<<  when the uprobe is enabled
>
> Yes, this happens when multiple vmas points to the same file portion.
> Can you check /proc/`pgrep a.out`/maps.
>
> Logic is simple. If we are going to patch an instruction, increment the
> reference counter. If we are going to unpatch an instruction, decrement
> the reference counter. In this case, we patched instruction twice and
> thus incremented reference counter twice as well.

Yes, this makes sense.

Song

>
> Ravi
>

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Song,

> root@virt-test:~# ~/a.out
> 11
> semaphore 0
> semaphore 0
> semaphore 2  <<<  when the uprobe is enabled

Yes, this happens when multiple vmas points to the same file portion.
Can you check /proc/`pgrep a.out`/maps.

Logic is simple. If we are going to patch an instruction, increment the
reference counter. If we are going to unpatch an instruction, decrement
the reference counter. In this case, we patched instruction twice and
thus incremented reference counter twice as well.

Ravi

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Ravi Bangoria]

Hi Song,

> root@virt-test:~# ~/a.out
> 11
> semaphore 0
> semaphore 0
> semaphore 2  <<<  when the uprobe is enabled

Yes, this happens when multiple vmas points to the same file portion.
Can you check /proc/`pgrep a.out`/maps.

Logic is simple. If we are going to patch an instruction, increment the
reference counter. If we are going to unpatch an instruction, decrement
the reference counter. In this case, we patched instruction twice and
thus incremented reference counter twice as well.

Ravi

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

[Steve French]

fixed
On Mon, Aug 20, 2018 at 11:18 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> Commit
>
>   eacb610d8fc4 ("cifs: create a define for how many iovs we need for an 
> SMB2_open()")
>
> is missing a Signed-off-by from its committer.
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

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

[Steve French]

fixed
On Mon, Aug 20, 2018 at 11:18 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> Commit
>
>   eacb610d8fc4 ("cifs: create a define for how many iovs we need for an 
> SMB2_open()")
>
> is missing a Signed-off-by from its committer.
>
> --
> Cheers,
> Stephen Rothwell



-- 
Thanks,

Steve

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

[Stephen Rothwell]

Hi all,

Commit

  eacb610d8fc4 ("cifs: create a define for how many iovs we need for an 
SMB2_open()")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpol1tOxkm1O.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

Commit

  eacb610d8fc4 ("cifs: create a define for how many iovs we need for an 
SMB2_open()")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpol1tOxkm1O.pgp
Description: OpenPGP digital signature

linux-next: Tree for Aug 21

[Stephen Rothwell]

Hi all,

Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.

Changes since 20180820:

The xarray tree gained a conflict against the nvdimm tree.

Non-merge commits (relative to Linus' tree): 2411
 2504 files changed, 95839 insertions(+), 36325 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (cc26ebbebde8 ia64: Fix kernel BUG at lib/ioremap.c:72!)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma())
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper 
PAGE_SHIFT bits in pfn_valid())
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (176eb614b118 r8152: disable RX aggregation on new Dell TB16 
dock)
Merging bpf/master (f6069b9aa993 bpf: fix redirect to map under tail calls)
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (9c86336c15db ip6_vti: fix a null pointer deference 
when destroy vti6 tunnel)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (8a54d8fc160e cfg80211: remove division by size of 
sizeof(struct ieee80211_wmm_rule))
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (250ea7c5f56e ALSA: ac97: fix unbalanced 
pm_runtime_enable)
Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18)
Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3

linux-next: Tree for Aug 21

[Stephen Rothwell]

Hi all,

Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.

Changes since 20180820:

The xarray tree gained a conflict against the nvdimm tree.

Non-merge commits (relative to Linus' tree): 2411
 2504 files changed, 95839 insertions(+), 36325 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (cc26ebbebde8 ia64: Fix kernel BUG at lib/ioremap.c:72!)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma())
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper 
PAGE_SHIFT bits in pfn_valid())
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (176eb614b118 r8152: disable RX aggregation on new Dell TB16 
dock)
Merging bpf/master (f6069b9aa993 bpf: fix redirect to map under tail calls)
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (9c86336c15db ip6_vti: fix a null pointer deference 
when destroy vti6 tunnel)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (8a54d8fc160e cfg80211: remove division by size of 
sizeof(struct ieee80211_wmm_rule))
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (250ea7c5f56e ALSA: ac97: fix unbalanced 
pm_runtime_enable)
Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18)
Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3

Re: [Skiboot] [PATCH] opal/hmi: Wakeup the cpu before reading core_fir

[Nicholas Piggin]

On Mon, 20 Aug 2018 19:36:05 +0530
Vaibhav Jain  wrote:

> When stop state 5 is enabled, reading the core_fir during an HMI can
> result in a xscom read error with xscom_read() returning the
> OPAL_XSCOM_PARTIAL_GOOD error code and core_fir value of all FFs. At
> present this return error code is not handled in decode_core_fir()
> hence the invalid core_fir value is sent to the kernel where it
> interprets it as a FATAL hmi causing a system check-stop.
> 
> This can be prevented by forcing the core to wake-up using before
> reading the core_fir. Hence this patch wraps the call to
> read_core_fir() within calls to dctl_set_special_wakeup() and
> dctl_clear_special_wakeup().

Would it be feasible to enumerate the ranges of scoms that require
special wakeup and check for those in xscom_read/write, and warn if
spwkup was not set?

Thanks,
Nick

> 
> Suggested-by: Michael Neuling 
> Signed-off-by: Vaibhav Jain 
> Signed-off-by: Mahesh J Salgaonkar 
> ---
>  core/hmi.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/core/hmi.c b/core/hmi.c
> index 1f665a2f..67c520a0 100644
> --- a/core/hmi.c
> +++ b/core/hmi.c
> @@ -379,7 +379,7 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>  {
>   uint64_t core_fir;
>   uint32_t core_id;
> - int i;
> + int i, swkup_rc = OPAL_UNSUPPORTED;
>   bool found = false;
>   int64_t ret;
>   const char *loc;
> @@ -390,14 +390,15 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>  
>   core_id = pir_to_core_id(cpu->pir);
>  
> + /* Force the core to wakeup, otherwise reading core_fir is unrealiable
> +  * if stop-state 5 is enabled.
> +  */
> + swkup_rc = dctl_set_special_wakeup(cpu);
> +
>   /* Get CORE FIR register value. */
>   ret = read_core_fir(cpu->chip_id, core_id, _fir);
>  
> - if (ret == OPAL_HARDWARE) {
> - prerror("XSCOM error reading CORE FIR\n");
> - /* If the FIR can't be read, we should checkstop. */
> - return true;
> - } else if (ret == OPAL_WRONG_STATE) {
> + if (ret == OPAL_WRONG_STATE) {
>   /*
>* CPU is asleep, so it probably didn't cause the checkstop.
>* If no other HMI cause is found a "catchall" checkstop
> @@ -407,11 +408,16 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>   prlog(PR_DEBUG,
> "FIR read failed, chip %d core %d asleep\n",
> cpu->chip_id, core_id);
> - return false;
> + goto out;
> + } else if (ret != OPAL_SUCCESS) {
> + prerror("XSCOM error reading CORE FIR\n");
> + /* If the FIR can't be read, we should checkstop. */
> + found = true;
> + goto out;
>   }
>  
>   if (!core_fir)
> - return false;
> + goto out;
>  
>   loc = chip_loc_code(cpu->chip_id);
>   prlog(PR_INFO, "[Loc: %s]: CHIP ID: %x, CORE ID: %x, FIR: %016llx\n",
> @@ -426,6 +432,9 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>   |= xstop_bits[i].reason;
>   }
>   }
> +out:
> + if (!swkup_rc)
> + dctl_clear_special_wakeup(cpu);
>   return found;
>  }
>  

Re: [Skiboot] [PATCH] opal/hmi: Wakeup the cpu before reading core_fir

[Nicholas Piggin]

On Mon, 20 Aug 2018 19:36:05 +0530
Vaibhav Jain  wrote:

> When stop state 5 is enabled, reading the core_fir during an HMI can
> result in a xscom read error with xscom_read() returning the
> OPAL_XSCOM_PARTIAL_GOOD error code and core_fir value of all FFs. At
> present this return error code is not handled in decode_core_fir()
> hence the invalid core_fir value is sent to the kernel where it
> interprets it as a FATAL hmi causing a system check-stop.
> 
> This can be prevented by forcing the core to wake-up using before
> reading the core_fir. Hence this patch wraps the call to
> read_core_fir() within calls to dctl_set_special_wakeup() and
> dctl_clear_special_wakeup().

Would it be feasible to enumerate the ranges of scoms that require
special wakeup and check for those in xscom_read/write, and warn if
spwkup was not set?

Thanks,
Nick

> 
> Suggested-by: Michael Neuling 
> Signed-off-by: Vaibhav Jain 
> Signed-off-by: Mahesh J Salgaonkar 
> ---
>  core/hmi.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/core/hmi.c b/core/hmi.c
> index 1f665a2f..67c520a0 100644
> --- a/core/hmi.c
> +++ b/core/hmi.c
> @@ -379,7 +379,7 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>  {
>   uint64_t core_fir;
>   uint32_t core_id;
> - int i;
> + int i, swkup_rc = OPAL_UNSUPPORTED;
>   bool found = false;
>   int64_t ret;
>   const char *loc;
> @@ -390,14 +390,15 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>  
>   core_id = pir_to_core_id(cpu->pir);
>  
> + /* Force the core to wakeup, otherwise reading core_fir is unrealiable
> +  * if stop-state 5 is enabled.
> +  */
> + swkup_rc = dctl_set_special_wakeup(cpu);
> +
>   /* Get CORE FIR register value. */
>   ret = read_core_fir(cpu->chip_id, core_id, _fir);
>  
> - if (ret == OPAL_HARDWARE) {
> - prerror("XSCOM error reading CORE FIR\n");
> - /* If the FIR can't be read, we should checkstop. */
> - return true;
> - } else if (ret == OPAL_WRONG_STATE) {
> + if (ret == OPAL_WRONG_STATE) {
>   /*
>* CPU is asleep, so it probably didn't cause the checkstop.
>* If no other HMI cause is found a "catchall" checkstop
> @@ -407,11 +408,16 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>   prlog(PR_DEBUG,
> "FIR read failed, chip %d core %d asleep\n",
> cpu->chip_id, core_id);
> - return false;
> + goto out;
> + } else if (ret != OPAL_SUCCESS) {
> + prerror("XSCOM error reading CORE FIR\n");
> + /* If the FIR can't be read, we should checkstop. */
> + found = true;
> + goto out;
>   }
>  
>   if (!core_fir)
> - return false;
> + goto out;
>  
>   loc = chip_loc_code(cpu->chip_id);
>   prlog(PR_INFO, "[Loc: %s]: CHIP ID: %x, CORE ID: %x, FIR: %016llx\n",
> @@ -426,6 +432,9 @@ static bool decode_core_fir(struct cpu_thread *cpu,
>   |= xstop_bits[i].reason;
>   }
>   }
> +out:
> + if (!swkup_rc)
> + dctl_clear_special_wakeup(cpu);
>   return found;
>  }
>  

Re: [RFC PATCH v2 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

[Liang Yang]

Hi Boris,

On 8/17/2018 9:56 PM, Boris Brezillon wrote:

On Fri, 17 Aug 2018 21:03:59 +0800
Liang Yang  wrote:


Hi Boris,
On 2018/8/2 5:50, Boris Brezillon wrote:


Hi Yixun,

On Thu, 19 Jul 2018 17:46:12 +0800
Yixun Lan  wrote:

I haven't finished reviewing the driver yet (I'll try to do that later
this week), but I already pointed a few things to fix/improve.
  

+
+static int meson_nfc_exec_op(struct nand_chip *chip,
+const struct nand_operation *op, bool check_only)
+{
+   struct mtd_info *mtd = nand_to_mtd(chip);
+   struct meson_nfc *nfc = nand_get_controller_data(chip);
+   const struct nand_op_instr *instr = NULL;
+   int ret = 0, cmd;
+   unsigned int op_id;
+   int i;
+
+   for (op_id = 0; op_id < op->ninstrs; op_id++) {
+   instr = >instrs[op_id];
+   switch (instr->type) {
+   case NAND_OP_CMD_INSTR:
+   cmd = nfc->param.chip_select | NFC_CMD_CLE;
+   cmd |= instr->ctx.cmd.opcode & 0xff;
+   writel(cmd, nfc->reg_base + NFC_REG_CMD);
+   meson_nfc_cmd_idle(nfc, NAND_TWB_TIME_CYCLE);

This is not necessarily TWB you have to wait after a CMD cycle. It can
be tWHR. And you should definitely not hardcode the value, since,
AFAIR, it depends on the selected SDR timings. Probably something you
should calculate in ->setup_data_interface().


Indeed. TWB is not necessarily. And tWHR will be promised by NFC.
so I will delete it.


Are you sure the engine always applies a tWHR delay, even when tWB is
expected? tWB should be applied everytime you are about to wait for a
R/B transition. tWHR is about switching IO pins from input to output on
the NAND chip side.



it seems work well even do not add tWHR, but software needs to promise 
tWHR, also the same as TWB. I will check the code and add them.





+   meson_nfc_drain_cmd(nfc);

I don't know exactly how the NAND controller works, but it's usually
not a good idea to execute the operation right away, especially if you
have address/cmd/data cycles following this cmd and those can be
packed in the same controller operation.


it doesn't need meson_nfc_drain_cmd(nfc) here. i will delete it next version


What's the CMD queue depth? I think you'll have to ensure the requested
op fits in the CMD FIFO and split things in several sub-ops if it does
not.



there are maximum 32 commands.
I think it should be enough to promise ONE maximum number of 
operations(cmd - addr - dma - 2 ilde commands).





+   break;
+
+   case NAND_OP_ADDR_INSTR:
+   for (i = 0; i < instr->ctx.addr.naddrs; i++) {
+   cmd = nfc->param.chip_select | NFC_CMD_ALE;
+   cmd |= instr->ctx.addr.addrs[i] & 0xff;
+   writel(cmd, nfc->reg_base + NFC_REG_CMD);
+   }
+   break;
+
+   case NAND_OP_DATA_IN_INSTR:
+   meson_nfc_read_buf(mtd, instr->ctx.data.buf.in,
+  instr->ctx.data.len);
+   break;
+
+   case NAND_OP_DATA_OUT_INSTR:
+   meson_nfc_write_buf(mtd, instr->ctx.data.buf.out,
+   instr->ctx.data.len);

Well, I'm not entirely sure what happens when you call
read/write_buf(), but it seems you're doing that one byte at a time,
and that sounds not so efficient given the operation you do for each
byte read/written. Don't you have a way to tell the engine that you
want to read/write X bytes?


As i known, there is no way to read/write X bytes once.


Okay, then maybe you can queue several byte read/write reqs before
flushing the queue (meson_nfc_drain_cmd() +
meson_nfc_wait_cmd_finish()).




+   break;
+
+   case NAND_OP_WAITRDY_INSTR:
+   mdelay(instr->ctx.waitrdy.timeout_ms);
+   ret = nand_soft_waitrdy(chip,
+   instr->ctx.waitrdy.timeout_ms);

Hm, i'd be surprised if the controller does not have a way to optimize
waits on R/B transitions.


When i delete the delay here, erasing operation will be failed.
Does it mean NFC send 0x70 to nand device when rb is busy(low)?


I was not even talking about the delay, but yes, mdelay() seems way too
big. Remember that it's a timeout, and you usually don't have to wait
that much. You can do ndelay(instr->ctx.delay_ns) before calling
nand_soft_waitrdy() to make sure tWB is enforced.

Anyway, that's not what I was initially referring to. What I meant is
that nand_soft_waitrdy() should be replaced by native R/B pin or status
polling wait logic so that the CPU is released while waiting for a R/B
transition.


If so, i will ask our NFC designer for comfirmation or grasping the waveform.


You have to wait tWB, that's 

Re: [RFC PATCH v2 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

[Liang Yang]

Hi Boris,

On 8/17/2018 9:56 PM, Boris Brezillon wrote:

On Fri, 17 Aug 2018 21:03:59 +0800
Liang Yang  wrote:


Hi Boris,
On 2018/8/2 5:50, Boris Brezillon wrote:


Hi Yixun,

On Thu, 19 Jul 2018 17:46:12 +0800
Yixun Lan  wrote:

I haven't finished reviewing the driver yet (I'll try to do that later
this week), but I already pointed a few things to fix/improve.
  

+
+static int meson_nfc_exec_op(struct nand_chip *chip,
+const struct nand_operation *op, bool check_only)
+{
+   struct mtd_info *mtd = nand_to_mtd(chip);
+   struct meson_nfc *nfc = nand_get_controller_data(chip);
+   const struct nand_op_instr *instr = NULL;
+   int ret = 0, cmd;
+   unsigned int op_id;
+   int i;
+
+   for (op_id = 0; op_id < op->ninstrs; op_id++) {
+   instr = >instrs[op_id];
+   switch (instr->type) {
+   case NAND_OP_CMD_INSTR:
+   cmd = nfc->param.chip_select | NFC_CMD_CLE;
+   cmd |= instr->ctx.cmd.opcode & 0xff;
+   writel(cmd, nfc->reg_base + NFC_REG_CMD);
+   meson_nfc_cmd_idle(nfc, NAND_TWB_TIME_CYCLE);

This is not necessarily TWB you have to wait after a CMD cycle. It can
be tWHR. And you should definitely not hardcode the value, since,
AFAIR, it depends on the selected SDR timings. Probably something you
should calculate in ->setup_data_interface().


Indeed. TWB is not necessarily. And tWHR will be promised by NFC.
so I will delete it.


Are you sure the engine always applies a tWHR delay, even when tWB is
expected? tWB should be applied everytime you are about to wait for a
R/B transition. tWHR is about switching IO pins from input to output on
the NAND chip side.



it seems work well even do not add tWHR, but software needs to promise 
tWHR, also the same as TWB. I will check the code and add them.





+   meson_nfc_drain_cmd(nfc);

I don't know exactly how the NAND controller works, but it's usually
not a good idea to execute the operation right away, especially if you
have address/cmd/data cycles following this cmd and those can be
packed in the same controller operation.


it doesn't need meson_nfc_drain_cmd(nfc) here. i will delete it next version


What's the CMD queue depth? I think you'll have to ensure the requested
op fits in the CMD FIFO and split things in several sub-ops if it does
not.



there are maximum 32 commands.
I think it should be enough to promise ONE maximum number of 
operations(cmd - addr - dma - 2 ilde commands).





+   break;
+
+   case NAND_OP_ADDR_INSTR:
+   for (i = 0; i < instr->ctx.addr.naddrs; i++) {
+   cmd = nfc->param.chip_select | NFC_CMD_ALE;
+   cmd |= instr->ctx.addr.addrs[i] & 0xff;
+   writel(cmd, nfc->reg_base + NFC_REG_CMD);
+   }
+   break;
+
+   case NAND_OP_DATA_IN_INSTR:
+   meson_nfc_read_buf(mtd, instr->ctx.data.buf.in,
+  instr->ctx.data.len);
+   break;
+
+   case NAND_OP_DATA_OUT_INSTR:
+   meson_nfc_write_buf(mtd, instr->ctx.data.buf.out,
+   instr->ctx.data.len);

Well, I'm not entirely sure what happens when you call
read/write_buf(), but it seems you're doing that one byte at a time,
and that sounds not so efficient given the operation you do for each
byte read/written. Don't you have a way to tell the engine that you
want to read/write X bytes?


As i known, there is no way to read/write X bytes once.


Okay, then maybe you can queue several byte read/write reqs before
flushing the queue (meson_nfc_drain_cmd() +
meson_nfc_wait_cmd_finish()).




+   break;
+
+   case NAND_OP_WAITRDY_INSTR:
+   mdelay(instr->ctx.waitrdy.timeout_ms);
+   ret = nand_soft_waitrdy(chip,
+   instr->ctx.waitrdy.timeout_ms);

Hm, i'd be surprised if the controller does not have a way to optimize
waits on R/B transitions.


When i delete the delay here, erasing operation will be failed.
Does it mean NFC send 0x70 to nand device when rb is busy(low)?


I was not even talking about the delay, but yes, mdelay() seems way too
big. Remember that it's a timeout, and you usually don't have to wait
that much. You can do ndelay(instr->ctx.delay_ns) before calling
nand_soft_waitrdy() to make sure tWB is enforced.

Anyway, that's not what I was initially referring to. What I meant is
that nand_soft_waitrdy() should be replaced by native R/B pin or status
polling wait logic so that the CPU is released while waiting for a R/B
transition.


If so, i will ask our NFC designer for comfirmation or grasping the waveform.


You have to wait tWB, that's 

[PATCH] ubifs: remove unnecessary check in ubifs_log_start_commit

[Liu Song]

The value of c->lhead_offs cannot exceed max_len which much
smaller than c->leb_size. So the check will never be true.
Just remove it.

Signed-off-by: Liu Song 
Reviewed-by: Jiang Biao 
---
 fs/ubifs/log.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/fs/ubifs/log.c b/fs/ubifs/log.c
index 7cffa120a750..5a338737223b 100644
--- a/fs/ubifs/log.c
+++ b/fs/ubifs/log.c
@@ -427,10 +427,6 @@ int ubifs_log_start_commit(struct ubifs_info *c, int 
*ltail_lnum)
*ltail_lnum = c->lhead_lnum;
 
c->lhead_offs += len;
-   if (c->lhead_offs == c->leb_size) {
-   c->lhead_lnum = ubifs_next_log_lnum(c, c->lhead_lnum);
-   c->lhead_offs = 0;
-   }
 
remove_buds(c);
 
-- 
2.17.1

[PATCH] ubifs: remove unnecessary check in ubifs_log_start_commit

[Liu Song]

The value of c->lhead_offs cannot exceed max_len which much
smaller than c->leb_size. So the check will never be true.
Just remove it.

Signed-off-by: Liu Song 
Reviewed-by: Jiang Biao 
---
 fs/ubifs/log.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/fs/ubifs/log.c b/fs/ubifs/log.c
index 7cffa120a750..5a338737223b 100644
--- a/fs/ubifs/log.c
+++ b/fs/ubifs/log.c
@@ -427,10 +427,6 @@ int ubifs_log_start_commit(struct ubifs_info *c, int 
*ltail_lnum)
*ltail_lnum = c->lhead_lnum;
 
c->lhead_offs += len;
-   if (c->lhead_offs == c->leb_size) {
-   c->lhead_lnum = ubifs_next_log_lnum(c, c->lhead_lnum);
-   c->lhead_offs = 0;
-   }
 
remove_buds(c);
 
-- 
2.17.1

Re: [PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h

[Masahiro Yamada]

Hi Paul,


The code diff looks good to me.

Reviewed-by: Masahiro Yamada 


Just comments in the commit description.   See below.


2018-08-21 7:36 GMT+09:00 Paul Burton :
> We have a need to override the definition of
> barrier_before_unreachable() for MIPS, which means we either need to add
> architecture-specific code into linux/compiler-gcc.h or we need to allow
> the architecture to provide a header that can define the macro before
> the generic definition. The latter seems like the better approach.
>
> A straightforward approach to the per-arch header is to make use of
> asm-generic to provide a default empty header & adjust architectures
> which don't need anything specific to make use of that by adding the
> header to generic-y. Unfortunately this doesn't work so well due to
> commit a95b37e20db9 ("kbuild: get  out of
> ") which moved the inclusion of linux/compiler.h to
> cflags using the -include compiler flag.


I doubt this statement.

Commit a95b37e20db9 is not the cause of the problem.

include/linux/kconfig.h is also included
by using the -include compiler flag.


See the top-level Makefile.

USERINCLUDE:= \
-I$(srctree)/arch/$(SRCARCH)/include/uapi \
-I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
-I$(srctree)/include/uapi \
-I$(objtree)/include/generated/uapi \
-include $(srctree)/include/linux/kconfig.h


So,  (then, )
would be also required for all C files
in the archprepare stage regardless of commit a95b37e20db9.


The change happened in commit 28128c61e08e.



One more thing, you are not touching any makefile in this version.

Maybe, you can prefix the subject with "compiler.h:" or something
instead of "kbuild:".





> Because the -include flag is present for all C files we compile, we need
> the architecture-provided header to be present before any C files are
> compiled. If any C files can be compiled prior to the asm-generic header
> wrappers being generated then we hit a build failure due to missing
> header. Such cases do exist - one pointed out by the kbuild test robot
> is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> of the archprepare target [1].
>
> This leaves us with a few options:
>
>   1) Use generic-y & fix any build failures we find by enforcing
>  ordering such that the asm-generic target occurs before any C
>  compilation, such that linux/compiler_types.h can always include
>  the generated asm-generic wrapper which in turn includes the empty
>  asm-generic header. This would rely on us finding all the
>  problematic cases - I don't know for sure that the ia64 issue is
>  the only one.
>
>   2) Add an actual empty header to each architecture, so that we don't
>  need the generated asm-generic wrapper. This seems messy.
>
>   3) Give up & add #ifdef CONFIG_MIPS or similar to
>  linux/compiler_types.h. This seems messy too.
>
>   4) Include the arch header only when it's actually needed, removing
>  the need for the asm-generic wrapper for all other architectures.
>
> This patch allows us to use approach 4, by including an asm/compiler.h
> header from linux/compiler_types.h after the inclusion of the
> compiler-specific linux/compiler-*.h header(s). We do this
> conditionally, only when CONFIG_HAVE_ARCH_COMPILER_H is selected, in
> order to avoid the need for asm-generic wrappers & the associated build
> ordering issue described above. The asm/compiler.h header is included
> after the generic linux/compiler-*.h header(s) for consistency with the
> way linux/compiler-intel.h & linux/compiler-clang.h are included after
> the linux/compiler-gcc.h header that they override.
>
> [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
>
> Signed-off-by: Paul Burton 
> Cc: Arnd Bergmann 
> Cc: James Hogan 
> Cc: Masahiro Yamada 
> Cc: Ralf Baechle 
> Cc: linux-a...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@linux-mips.org

Re: [PATCH v9 1/2] kbuild: Allow arch-specific asm/compiler.h

[Masahiro Yamada]

Hi Paul,


The code diff looks good to me.

Reviewed-by: Masahiro Yamada 


Just comments in the commit description.   See below.


2018-08-21 7:36 GMT+09:00 Paul Burton :
> We have a need to override the definition of
> barrier_before_unreachable() for MIPS, which means we either need to add
> architecture-specific code into linux/compiler-gcc.h or we need to allow
> the architecture to provide a header that can define the macro before
> the generic definition. The latter seems like the better approach.
>
> A straightforward approach to the per-arch header is to make use of
> asm-generic to provide a default empty header & adjust architectures
> which don't need anything specific to make use of that by adding the
> header to generic-y. Unfortunately this doesn't work so well due to
> commit a95b37e20db9 ("kbuild: get  out of
> ") which moved the inclusion of linux/compiler.h to
> cflags using the -include compiler flag.


I doubt this statement.

Commit a95b37e20db9 is not the cause of the problem.

include/linux/kconfig.h is also included
by using the -include compiler flag.


See the top-level Makefile.

USERINCLUDE:= \
-I$(srctree)/arch/$(SRCARCH)/include/uapi \
-I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
-I$(srctree)/include/uapi \
-I$(objtree)/include/generated/uapi \
-include $(srctree)/include/linux/kconfig.h


So,  (then, )
would be also required for all C files
in the archprepare stage regardless of commit a95b37e20db9.


The change happened in commit 28128c61e08e.



One more thing, you are not touching any makefile in this version.

Maybe, you can prefix the subject with "compiler.h:" or something
instead of "kbuild:".





> Because the -include flag is present for all C files we compile, we need
> the architecture-provided header to be present before any C files are
> compiled. If any C files can be compiled prior to the asm-generic header
> wrappers being generated then we hit a build failure due to missing
> header. Such cases do exist - one pointed out by the kbuild test robot
> is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> of the archprepare target [1].
>
> This leaves us with a few options:
>
>   1) Use generic-y & fix any build failures we find by enforcing
>  ordering such that the asm-generic target occurs before any C
>  compilation, such that linux/compiler_types.h can always include
>  the generated asm-generic wrapper which in turn includes the empty
>  asm-generic header. This would rely on us finding all the
>  problematic cases - I don't know for sure that the ia64 issue is
>  the only one.
>
>   2) Add an actual empty header to each architecture, so that we don't
>  need the generated asm-generic wrapper. This seems messy.
>
>   3) Give up & add #ifdef CONFIG_MIPS or similar to
>  linux/compiler_types.h. This seems messy too.
>
>   4) Include the arch header only when it's actually needed, removing
>  the need for the asm-generic wrapper for all other architectures.
>
> This patch allows us to use approach 4, by including an asm/compiler.h
> header from linux/compiler_types.h after the inclusion of the
> compiler-specific linux/compiler-*.h header(s). We do this
> conditionally, only when CONFIG_HAVE_ARCH_COMPILER_H is selected, in
> order to avoid the need for asm-generic wrappers & the associated build
> ordering issue described above. The asm/compiler.h header is included
> after the generic linux/compiler-*.h header(s) for consistency with the
> way linux/compiler-intel.h & linux/compiler-clang.h are included after
> the linux/compiler-gcc.h header that they override.
>
> [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
>
> Signed-off-by: Paul Burton 
> Cc: Arnd Bergmann 
> Cc: James Hogan 
> Cc: Masahiro Yamada 
> Cc: Ralf Baechle 
> Cc: linux-a...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@linux-mips.org

[PATCH] PCI: dwc: fix scheduling while atomic issues

[Jisheng Zhang]

When programming inbound/outbound atu, we call usleep_range() after
each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
can be called in atomic context:

inbound atu programming could be called through
pci_epc_write_header()
  =>dw_pcie_ep_write_header()
=>dw_pcie_prog_inbound_atu()

outbound atu programming could be called through
pci_bus_read_config_dword()
  =>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()

Fix this issue by calling udelay() instead.

Signed-off-by: Jisheng Zhang 
---
 drivers/pci/controller/dwc/pcie-designware.c | 8 
 drivers/pci/controller/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 778c4f76a884..4c15929d9c79 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -135,7 +135,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -178,7 +178,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -236,7 +236,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
@@ -282,7 +282,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 96126fd8403c..8bab329c5cd3 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -26,8 +26,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU 9000
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.18.0

[PATCH] PCI: dwc: fix scheduling while atomic issues

[Jisheng Zhang]

When programming inbound/outbound atu, we call usleep_range() after
each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
can be called in atomic context:

inbound atu programming could be called through
pci_epc_write_header()
  =>dw_pcie_ep_write_header()
=>dw_pcie_prog_inbound_atu()

outbound atu programming could be called through
pci_bus_read_config_dword()
  =>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()

Fix this issue by calling udelay() instead.

Signed-off-by: Jisheng Zhang 
---
 drivers/pci/controller/dwc/pcie-designware.c | 8 
 drivers/pci/controller/dwc/pcie-designware.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 778c4f76a884..4c15929d9c79 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -135,7 +135,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -178,7 +178,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
if (val & PCIE_ATU_ENABLE)
return;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Outbound iATU is not being enabled\n");
 }
@@ -236,7 +236,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
*pci, int index,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
@@ -282,7 +282,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
index, int bar,
if (val & PCIE_ATU_ENABLE)
return 0;
 
-   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
+   udelay(LINK_WAIT_IATU);
}
dev_err(pci->dev, "Inbound iATU is not being enabled\n");
 
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 96126fd8403c..8bab329c5cd3 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -26,8 +26,7 @@
 
 /* Parameters for the waiting for iATU enabled routine */
 #define LINK_WAIT_MAX_IATU_RETRIES 5
-#define LINK_WAIT_IATU_MIN 9000
-#define LINK_WAIT_IATU_MAX 1
+#define LINK_WAIT_IATU 9000
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-- 
2.18.0

Re: [PATCH v4 3/5] Cleanup ISA string setting

[Alan Kao]

On Mon, Aug 20, 2018 at 03:22:55PM -0700, Palmer Dabbelt wrote:
> On Tue, 07 Aug 2018 20:24:43 PDT (-0700), alan...@andestech.com wrote:
> >Just a side note: (Assume that atomic and compressed is on)
> >
> >Before this patch, assembler was always given the riscv64imafdc
> >MARCH string because there are fld/fsd's in entry.S; compiler was
> >always given riscv64imac because kernel doesn't need floating point
> >code generation.  After this, the MARCH string in AFLAGS and CFLAGS
> >become the same.
> >
> >Signed-off-by: Alan Kao 
> >Cc: Greentime Hu 
> >Cc: Vincent Chen 
> >Cc: Zong Li 
> >Cc: Nick Hu 
> >Reviewed-by: Christoph Hellwig 
> >---
> > arch/riscv/Makefile | 19 ---
> > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> >diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> >index 6d4a5f6c3f4f..e0fe6790624f 100644
> >--- a/arch/riscv/Makefile
> >+++ b/arch/riscv/Makefile
> >@@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
> >
> > KBUILD_CFLAGS += -mabi=lp64
> > KBUILD_AFLAGS += -mabi=lp64
> >-KBUILD_MARCH = rv64im
> > LDFLAGS += -melf64lriscv
> > else
> > BITS := 32
> >@@ -34,22 +33,20 @@ else
> >
> > KBUILD_CFLAGS += -mabi=ilp32
> > KBUILD_AFLAGS += -mabi=ilp32
> >-KBUILD_MARCH = rv32im
> > LDFLAGS += -melf32lriscv
> > endif
> >
> > KBUILD_CFLAGS += -Wall
> >
> >-ifeq ($(CONFIG_RISCV_ISA_A),y)
> >-KBUILD_ARCH_A = a
> >-endif
> >-ifeq ($(CONFIG_RISCV_ISA_C),y)
> >-KBUILD_ARCH_C = c
> >-endif
> >-
> >-KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C)
> >+# ISA string setting
> >+riscv-march-$(CONFIG_ARCH_RV32I):= rv32im
> >+riscv-march-$(CONFIG_ARCH_RV64I):= rv64im
> >+riscv-march-$(CONFIG_RISCV_ISA_A)   := $(riscv-march-y)a
> >+riscv-march-y   := $(riscv-march-y)fd
> >+riscv-march-$(CONFIG_RISCV_ISA_C)   := $(riscv-march-y)c
> >+KBUILD_CFLAGS += -march=$(riscv-march-y)
> >+KBUILD_AFLAGS += -march=$(riscv-march-y)
> >
> >-KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C)
> 
> We used to have "fd" disabled in KBUILD_CFLAGS because we wanted to ensure
> that any use of floating-point types within the kernel would trigger the
> inclusion of soft-float libraries rather than emitting hardware
> floating-point instructions.  The worry here is that we'd end up corrupting
> the user's floating-point state with the kernel accesses because of the lazy
> save/restore stuff going on.

Thanks for pointing that out.

Just as you said, the use of KBUILD_CFLAGS=*fd* is based on the assumption that
not a single floating-point instruction involves in the kernel, and that might
be wrong.

> I remember at some point it was illegal to use floating-point within the
> kernel, but for some reason I thought that had changed.  I do see a handful
> of references to "float" and "double" in the kernel source, and most of
> references to kernel_fpu_begin() appear to be in SSE-specific stuff.  My one
> worry are the usages in drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c, as
> I can't quickly demonstrate they won't happen.

Empirically, this CFLAGS with *fd* did not cause any trouble to me, but of
course this is not a good statement to support this patch.

Meanwhile, I find a flaw in "[PATCH 4/5] Allow to Disable FPU Support." 
The purpose of this "[PATCH 3/5] Cleanup ISA String" was to make CONFIG_FPU
a switch for the appearance of "fd" in both KBUILD_CFLAGS and KBUILD_ASFLAGS,
but somehow the modification was forgotten.

> 
> If we do this I think we should at least ensure kernel_fpu_{begin,end}() do
> the right thing for RISC-V.  I'd still feel safer telling the C compiler to
> disallow floating-point, though, as I'm a bit paranoid that GCC might go and
> emit a floating-point instruction even when it's not explicitly asked for.
> I just asked Jim, who actually understands GCC, and he said that it'll spill
> to floating-point registers if the cost function determines it's cheaper
> than the stack.  While he thinks that's unlikely, I don't really want to
> rely a GCC cost function for the correctness of our kernel port.

The purpose of this whole patchset was to remove all floating-point-related
logic in kernel space (while remainging FPU systems work as usual), so
implementing the two APIs would be out of scope here.

I suggest that, some people have to provide these APIs if they do need hardware
floating-point calculation in kernel space (kernel or module) in the future.
It seems that we don't need those for the kernel and any already supported
hardware drivers at least for now.  Please correct me if my understanding is
out-of-date.

> 
> I'd like to avoid having "-march=*fd*" in CFLAGS, unless someone can
> convince me it's safe and that I'm just being too paranoid :).

I will send a new version of the patchset, which will make sure that CFLAGS has
no *fd* (3/5) and the CONFIG_FPU did remove *fd* from ASFLAGS (4/5).

> 
> > KBUILD_CFLAGS += -mno-save-restore
> > KBUILD_CFLAGS 

Re: [PATCH v4 3/5] Cleanup ISA string setting

[Alan Kao]

On Mon, Aug 20, 2018 at 03:22:55PM -0700, Palmer Dabbelt wrote:
> On Tue, 07 Aug 2018 20:24:43 PDT (-0700), alan...@andestech.com wrote:
> >Just a side note: (Assume that atomic and compressed is on)
> >
> >Before this patch, assembler was always given the riscv64imafdc
> >MARCH string because there are fld/fsd's in entry.S; compiler was
> >always given riscv64imac because kernel doesn't need floating point
> >code generation.  After this, the MARCH string in AFLAGS and CFLAGS
> >become the same.
> >
> >Signed-off-by: Alan Kao 
> >Cc: Greentime Hu 
> >Cc: Vincent Chen 
> >Cc: Zong Li 
> >Cc: Nick Hu 
> >Reviewed-by: Christoph Hellwig 
> >---
> > arch/riscv/Makefile | 19 ---
> > 1 file changed, 8 insertions(+), 11 deletions(-)
> >
> >diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> >index 6d4a5f6c3f4f..e0fe6790624f 100644
> >--- a/arch/riscv/Makefile
> >+++ b/arch/riscv/Makefile
> >@@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
> >
> > KBUILD_CFLAGS += -mabi=lp64
> > KBUILD_AFLAGS += -mabi=lp64
> >-KBUILD_MARCH = rv64im
> > LDFLAGS += -melf64lriscv
> > else
> > BITS := 32
> >@@ -34,22 +33,20 @@ else
> >
> > KBUILD_CFLAGS += -mabi=ilp32
> > KBUILD_AFLAGS += -mabi=ilp32
> >-KBUILD_MARCH = rv32im
> > LDFLAGS += -melf32lriscv
> > endif
> >
> > KBUILD_CFLAGS += -Wall
> >
> >-ifeq ($(CONFIG_RISCV_ISA_A),y)
> >-KBUILD_ARCH_A = a
> >-endif
> >-ifeq ($(CONFIG_RISCV_ISA_C),y)
> >-KBUILD_ARCH_C = c
> >-endif
> >-
> >-KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C)
> >+# ISA string setting
> >+riscv-march-$(CONFIG_ARCH_RV32I):= rv32im
> >+riscv-march-$(CONFIG_ARCH_RV64I):= rv64im
> >+riscv-march-$(CONFIG_RISCV_ISA_A)   := $(riscv-march-y)a
> >+riscv-march-y   := $(riscv-march-y)fd
> >+riscv-march-$(CONFIG_RISCV_ISA_C)   := $(riscv-march-y)c
> >+KBUILD_CFLAGS += -march=$(riscv-march-y)
> >+KBUILD_AFLAGS += -march=$(riscv-march-y)
> >
> >-KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C)
> 
> We used to have "fd" disabled in KBUILD_CFLAGS because we wanted to ensure
> that any use of floating-point types within the kernel would trigger the
> inclusion of soft-float libraries rather than emitting hardware
> floating-point instructions.  The worry here is that we'd end up corrupting
> the user's floating-point state with the kernel accesses because of the lazy
> save/restore stuff going on.

Thanks for pointing that out.

Just as you said, the use of KBUILD_CFLAGS=*fd* is based on the assumption that
not a single floating-point instruction involves in the kernel, and that might
be wrong.

> I remember at some point it was illegal to use floating-point within the
> kernel, but for some reason I thought that had changed.  I do see a handful
> of references to "float" and "double" in the kernel source, and most of
> references to kernel_fpu_begin() appear to be in SSE-specific stuff.  My one
> worry are the usages in drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c, as
> I can't quickly demonstrate they won't happen.

Empirically, this CFLAGS with *fd* did not cause any trouble to me, but of
course this is not a good statement to support this patch.

Meanwhile, I find a flaw in "[PATCH 4/5] Allow to Disable FPU Support." 
The purpose of this "[PATCH 3/5] Cleanup ISA String" was to make CONFIG_FPU
a switch for the appearance of "fd" in both KBUILD_CFLAGS and KBUILD_ASFLAGS,
but somehow the modification was forgotten.

> 
> If we do this I think we should at least ensure kernel_fpu_{begin,end}() do
> the right thing for RISC-V.  I'd still feel safer telling the C compiler to
> disallow floating-point, though, as I'm a bit paranoid that GCC might go and
> emit a floating-point instruction even when it's not explicitly asked for.
> I just asked Jim, who actually understands GCC, and he said that it'll spill
> to floating-point registers if the cost function determines it's cheaper
> than the stack.  While he thinks that's unlikely, I don't really want to
> rely a GCC cost function for the correctness of our kernel port.

The purpose of this whole patchset was to remove all floating-point-related
logic in kernel space (while remainging FPU systems work as usual), so
implementing the two APIs would be out of scope here.

I suggest that, some people have to provide these APIs if they do need hardware
floating-point calculation in kernel space (kernel or module) in the future.
It seems that we don't need those for the kernel and any already supported
hardware drivers at least for now.  Please correct me if my understanding is
out-of-date.

> 
> I'd like to avoid having "-march=*fd*" in CFLAGS, unless someone can
> convince me it's safe and that I'm just being too paranoid :).

I will send a new version of the patchset, which will make sure that CFLAGS has
no *fd* (3/5) and the CONFIG_FPU did remove *fd* from ASFLAGS (4/5).

> 
> > KBUILD_CFLAGS += -mno-save-restore
> > KBUILD_CFLAGS 

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Masahiro Yamada]

Hi Frank,

2018-08-21 10:31 GMT+09:00 Frank Rowand :
> On 08/20/18 14:32, Rob Herring wrote:
>> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:
>>>
>>> On 07/03/18 18:59, Masahiro Yamada wrote:
 It is tedious to specify extra compiler options for every file.
 HOST_EXTRACFLAGS is useful to add options to all files in a
 directory.

 -I$(src)/libfdt is needed for all the files in this directory
 to include libfdt_env.h etc. from scripts/dtc/libfdt/.

 On the other hand, -I$(src) is used to include check-in headers
 from generated C files.  Thus, I added it only to dtc-lexer.lex.o
 and dtc-parser.tab.o .

 Signed-off-by: Masahiro Yamada 
 ---

  scripts/dtc/Makefile | 18 --
  1 file changed, 4 insertions(+), 14 deletions(-)

 diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
 index 9cac65b..1c943e0 100644
 --- a/scripts/dtc/Makefile
 +++ b/scripts/dtc/Makefile
 @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
 livetree.o treesource.o \
  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o

  # Source files need to get at the userspace version of libfdt_env.h to 
 compile
 +HOST_EXTRACFLAGS := -I$(src)/libfdt
>>>
>>> Shouldn't that be += instead of :=?
>>
>> I don't think so. The definition is local to the file (and reset
>> before each makefile is included).
>>
>> Rob
>>
>
> Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
> instead of :=, including the example in Documentation/kbuild/makefiles.txt
>
> What makes scripts/dtc/Makefile different than the other makefiles?
>
> -Frank
>


:= and += work in the same way in here.


As Rob said, HOST_EXTRACFLAGS is reset in each makefile
because HOST_EXTRACFLAGS is not export'ed.
(scripts/gcc-plugins/Makefile actually export's it, but it is wrong.)


Precisely speaking, HOST_EXTRACFLAGS is immediately expanded
if it is set by :=, whereas it is lazily expanded if it is
set by +=.  But, there is no effective difference in this case.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Masahiro Yamada]

Hi Frank,

2018-08-21 10:31 GMT+09:00 Frank Rowand :
> On 08/20/18 14:32, Rob Herring wrote:
>> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:
>>>
>>> On 07/03/18 18:59, Masahiro Yamada wrote:
 It is tedious to specify extra compiler options for every file.
 HOST_EXTRACFLAGS is useful to add options to all files in a
 directory.

 -I$(src)/libfdt is needed for all the files in this directory
 to include libfdt_env.h etc. from scripts/dtc/libfdt/.

 On the other hand, -I$(src) is used to include check-in headers
 from generated C files.  Thus, I added it only to dtc-lexer.lex.o
 and dtc-parser.tab.o .

 Signed-off-by: Masahiro Yamada 
 ---

  scripts/dtc/Makefile | 18 --
  1 file changed, 4 insertions(+), 14 deletions(-)

 diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
 index 9cac65b..1c943e0 100644
 --- a/scripts/dtc/Makefile
 +++ b/scripts/dtc/Makefile
 @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
 livetree.o treesource.o \
  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o

  # Source files need to get at the userspace version of libfdt_env.h to 
 compile
 +HOST_EXTRACFLAGS := -I$(src)/libfdt
>>>
>>> Shouldn't that be += instead of :=?
>>
>> I don't think so. The definition is local to the file (and reset
>> before each makefile is included).
>>
>> Rob
>>
>
> Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
> instead of :=, including the example in Documentation/kbuild/makefiles.txt
>
> What makes scripts/dtc/Makefile different than the other makefiles?
>
> -Frank
>


:= and += work in the same way in here.


As Rob said, HOST_EXTRACFLAGS is reset in each makefile
because HOST_EXTRACFLAGS is not export'ed.
(scripts/gcc-plugins/Makefile actually export's it, but it is wrong.)


Precisely speaking, HOST_EXTRACFLAGS is immediately expanded
if it is set by :=, whereas it is lazily expanded if it is
set by +=.  But, there is no effective difference in this case.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] nios2: kconfig: remove duplicate DEBUG_STACK_USAGE symbol defintions

[Ley Foon Tan]

On Tue, 2018-08-21 at 01:15 +0900, Masahiro Yamada wrote:
> 2018-08-16 16:05 GMT+09:00 Tobias Klauser :
> > 
> > DEBUG_STACK_USAGE is already defined in lib/Kconfig.debug
> > 
> > Signed-off-by: Tobias Klauser 
> 
> Reviewed-by: Masahiro Yamada 
> 
Acked-by: Ley Foon Tan 

> 
> > 
> > ---
> >  arch/nios2/Kconfig.debug | 9 -
> >  1 file changed, 9 deletions(-)
> > 
> > diff --git a/arch/nios2/Kconfig.debug b/arch/nios2/Kconfig.debug
> > index 7a49f0d28d14..f1da8a7b17ff 100644
> > --- a/arch/nios2/Kconfig.debug
> > +++ b/arch/nios2/Kconfig.debug
> > @@ -3,15 +3,6 @@
> >  config TRACE_IRQFLAGS_SUPPORT
> > def_bool y
> > 
> > -config DEBUG_STACK_USAGE
> > -   bool "Enable stack utilization instrumentation"
> > -   depends on DEBUG_KERNEL
> > -   help
> > - Enables the display of the minimum amount of free stack
> > which each
> > - task has ever had available in the sysrq-T and sysrq-P
> > debug output.
> > -
> > - This option will slow down process creation somewhat.
> > -
> >  config EARLY_PRINTK
> > bool "Activate early kernel debugging"
> > default y
> > --
> > 2.18.0.130.g98da2f6b3e4a
> > 
> > 
> 
> 
> --
> Best Regards
> Masahiro Yamada
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.

Re: [PATCH] nios2: kconfig: remove duplicate DEBUG_STACK_USAGE symbol defintions

[Ley Foon Tan]

On Tue, 2018-08-21 at 01:15 +0900, Masahiro Yamada wrote:
> 2018-08-16 16:05 GMT+09:00 Tobias Klauser :
> > 
> > DEBUG_STACK_USAGE is already defined in lib/Kconfig.debug
> > 
> > Signed-off-by: Tobias Klauser 
> 
> Reviewed-by: Masahiro Yamada 
> 
Acked-by: Ley Foon Tan 

> 
> > 
> > ---
> >  arch/nios2/Kconfig.debug | 9 -
> >  1 file changed, 9 deletions(-)
> > 
> > diff --git a/arch/nios2/Kconfig.debug b/arch/nios2/Kconfig.debug
> > index 7a49f0d28d14..f1da8a7b17ff 100644
> > --- a/arch/nios2/Kconfig.debug
> > +++ b/arch/nios2/Kconfig.debug
> > @@ -3,15 +3,6 @@
> >  config TRACE_IRQFLAGS_SUPPORT
> > def_bool y
> > 
> > -config DEBUG_STACK_USAGE
> > -   bool "Enable stack utilization instrumentation"
> > -   depends on DEBUG_KERNEL
> > -   help
> > - Enables the display of the minimum amount of free stack
> > which each
> > - task has ever had available in the sysrq-T and sysrq-P
> > debug output.
> > -
> > - This option will slow down process creation somewhat.
> > -
> >  config EARLY_PRINTK
> > bool "Activate early kernel debugging"
> > default y
> > --
> > 2.18.0.130.g98da2f6b3e4a
> > 
> > 
> 
> 
> --
> Best Regards
> Masahiro Yamada
> 
> 
> 
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

[Wolfram Sang]

Linus,

> Wolfram, should I just take that patch as-is and get rid of the
> deprecated atach_adapter thing, or will you send me a pull request?

I'll send you a pull request.

Thanks,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning

[Wolfram Sang]

Linus,

> Wolfram, should I just take that patch as-is and get rid of the
> deprecated atach_adapter thing, or will you send me a pull request?

I'll send you a pull request.

Thanks,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH] locking: Remove an insn from spin and write locks

[Will Deacon]

On Mon, Aug 20, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 05:56:50PM +0200, Peter Zijlstra wrote:
> > Yeah, _acquire should be retained; sorry about loosing that. I'm neck
> > deep into tlb invalidate stuff and wrote this without much thinking
> > involved.
> 
> NP.  Here's the current version I've got, with some updated likely()
> hints.
> 
> From 337298a88266f7b21492f893c2bf05409a5392c8 Mon Sep 17 00:00:00 2001
> From: Matthew Wilcox 
> Date: Mon, 20 Aug 2018 10:19:14 -0400
> Subject: [PATCH] locking: Remove an insn from spin and write locks
> 
> Both spin locks and write locks currently do:
> 
>  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
>  85 c0   test   %eax,%eax
>  75 05   jne[slowpath]
> 
> This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
> appropriately.  Peter pointed out that using atomic_try_cmpxchg_acquire()
> will let the compiler know this is true.  Comparing before/after
> disassemblies show the only effect is to remove this insn.
> 
> Take this opportunity to make the spin & write lock code resemble each
> other more closely and have similar likely() hints.
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Matthew Wilcox 
> ---
>  include/asm-generic/qrwlock.h   |  7 ---
>  include/asm-generic/qspinlock.h | 17 ++---
>  2 files changed, 14 insertions(+), 10 deletions(-)

Shouldn't make any difference on arm64, so:

Acked-by: Will Deacon 

Will

Re: [PATCH] locking: Remove an insn from spin and write locks

[Will Deacon]

On Mon, Aug 20, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 05:56:50PM +0200, Peter Zijlstra wrote:
> > Yeah, _acquire should be retained; sorry about loosing that. I'm neck
> > deep into tlb invalidate stuff and wrote this without much thinking
> > involved.
> 
> NP.  Here's the current version I've got, with some updated likely()
> hints.
> 
> From 337298a88266f7b21492f893c2bf05409a5392c8 Mon Sep 17 00:00:00 2001
> From: Matthew Wilcox 
> Date: Mon, 20 Aug 2018 10:19:14 -0400
> Subject: [PATCH] locking: Remove an insn from spin and write locks
> 
> Both spin locks and write locks currently do:
> 
>  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
>  85 c0   test   %eax,%eax
>  75 05   jne[slowpath]
> 
> This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
> appropriately.  Peter pointed out that using atomic_try_cmpxchg_acquire()
> will let the compiler know this is true.  Comparing before/after
> disassemblies show the only effect is to remove this insn.
> 
> Take this opportunity to make the spin & write lock code resemble each
> other more closely and have similar likely() hints.
> 
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Matthew Wilcox 
> ---
>  include/asm-generic/qrwlock.h   |  7 ---
>  include/asm-generic/qspinlock.h | 17 ++---
>  2 files changed, 14 insertions(+), 10 deletions(-)

Shouldn't make any difference on arm64, so:

Acked-by: Will Deacon 

Will

linux-next: manual merge of the xarray tree with the nvdimm tree

[Stephen Rothwell]

Hi Matthew,

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

  mm/memory-failure.c

between commit:

  6100e34b2526 ("mm, memory_failure: Teach memory_failure() about dev_pagemap 
pages")

from the nvdimm tree and commit:

  0c2b437d7e2b ("mm, memory_failure: Teach memory_failure() about dev_pagemap 
pages")

from the xarray tree.

I fixed it up (the former looks like an updated version (after Linus'
"review", so I used that version) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I guess the xarray tree needs to be rebased on the changes in the
nvdimm tree.  :-(

-- 
Cheers,
Stephen Rothwell


pgpkU6OxUpPKa.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the xarray tree with the nvdimm tree

[Stephen Rothwell]

Hi Matthew,

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

  mm/memory-failure.c

between commit:

  6100e34b2526 ("mm, memory_failure: Teach memory_failure() about dev_pagemap 
pages")

from the nvdimm tree and commit:

  0c2b437d7e2b ("mm, memory_failure: Teach memory_failure() about dev_pagemap 
pages")

from the xarray tree.

I fixed it up (the former looks like an updated version (after Linus'
"review", so I used that version) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I guess the xarray tree needs to be rebased on the changes in the
nvdimm tree.  :-(

-- 
Cheers,
Stephen Rothwell


pgpkU6OxUpPKa.pgp
Description: OpenPGP digital signature

[PATCH] staging: rtl8188eu: Fix spelling mistake

[Bhaskar Singh]

This patch fix spelling mistakes in TODO.

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/TODO b/drivers/staging/rtl8188eu/TODO
index 7581e25f231d..5faa0a9bba25 100644
--- a/drivers/staging/rtl8188eu/TODO
+++ b/drivers/staging/rtl8188eu/TODO
@@ -1,5 +1,5 @@
 TODO:
-- find and remove remaining code valid only for 5 HGz. Most of the obvious
+- find and remove remaining code valid only for 5 GHz. Most of the obvious
   ones have been removed, but things like channel > 14 still exist.
 - find and remove any code for other chips that is left over
 - convert any remaining unusual variable types
-- 
2.16.4

[PATCH] staging: rtl8188eu: Fix spelling mistake

[Bhaskar Singh]

This patch fix spelling mistakes in TODO.

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/TODO b/drivers/staging/rtl8188eu/TODO
index 7581e25f231d..5faa0a9bba25 100644
--- a/drivers/staging/rtl8188eu/TODO
+++ b/drivers/staging/rtl8188eu/TODO
@@ -1,5 +1,5 @@
 TODO:
-- find and remove remaining code valid only for 5 HGz. Most of the obvious
+- find and remove remaining code valid only for 5 GHz. Most of the obvious
   ones have been removed, but things like channel > 14 still exist.
 - find and remove any code for other chips that is left over
 - convert any remaining unusual variable types
-- 
2.16.4

[PATCH v2] staging: rtl8188eu: Removed code valid for 5GHz

[Bhaskar Singh]

This patch removes support for channels > 14. That is from the TODO which
says:

-find and remove remaining code valid only for 5HGz. Most of
obvious ones have been removed, but things like channel > 14 still
exist.

Signed-off-by: Bhaskar Singh 
---

Changes in v2:
- Make the commit message more clearer.
- Rectify indentation as per Linux kernel coding style.
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 7d5cbaf50f1c..9e5c7e62d26f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -100,19 +100,13 @@ bool rtw_is_cckratesonly_included(u8 *rate)
 
 int rtw_check_network_type(unsigned char *rate, int ratelen, int channel)
 {
-   if (channel > 14) {
-   if (rtw_is_cckrates_included(rate))
-   return WIRELESS_INVALID;
-   else
-   return WIRELESS_11A;
-   } else {  /*  could be pure B, pure G, or B/G */
-   if (rtw_is_cckratesonly_included(rate))
-   return WIRELESS_11B;
-   else if (rtw_is_cckrates_included(rate))
-   return  WIRELESS_11BG;
-   else
-   return WIRELESS_11G;
-   }
+   /*  could be pure B, pure G, or B/G */
+   if (rtw_is_cckratesonly_included(rate))
+   return WIRELESS_11B;
+   else if (rtw_is_cckrates_included(rate))
+   return  WIRELESS_11BG;
+   else
+   return WIRELESS_11G;
 }
 
 u8 *rtw_set_fixed_ie(void *pbuf, unsigned int len, void *source,
-- 
2.16.4

[PATCH v2] staging: rtl8188eu: Removed code valid for 5GHz

[Bhaskar Singh]

This patch removes support for channels > 14. That is from the TODO which
says:

-find and remove remaining code valid only for 5HGz. Most of
obvious ones have been removed, but things like channel > 14 still
exist.

Signed-off-by: Bhaskar Singh 
---

Changes in v2:
- Make the commit message more clearer.
- Rectify indentation as per Linux kernel coding style.
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 7d5cbaf50f1c..9e5c7e62d26f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -100,19 +100,13 @@ bool rtw_is_cckratesonly_included(u8 *rate)
 
 int rtw_check_network_type(unsigned char *rate, int ratelen, int channel)
 {
-   if (channel > 14) {
-   if (rtw_is_cckrates_included(rate))
-   return WIRELESS_INVALID;
-   else
-   return WIRELESS_11A;
-   } else {  /*  could be pure B, pure G, or B/G */
-   if (rtw_is_cckratesonly_included(rate))
-   return WIRELESS_11B;
-   else if (rtw_is_cckrates_included(rate))
-   return  WIRELESS_11BG;
-   else
-   return WIRELESS_11G;
-   }
+   /*  could be pure B, pure G, or B/G */
+   if (rtw_is_cckratesonly_included(rate))
+   return WIRELESS_11B;
+   else if (rtw_is_cckrates_included(rate))
+   return  WIRELESS_11BG;
+   else
+   return WIRELESS_11G;
 }
 
 u8 *rtw_set_fixed_ie(void *pbuf, unsigned int len, void *source,
-- 
2.16.4

[PATCH] staging: android: ion: check for kref overflow

[Daniel Rosenberg]

Userspace can cause the kref to handles to increment
arbitrarily high. Ensure it does not overflow.

Signed-off-by: Daniel Rosenberg 
---

This patch is against 4.4. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
It applies from 3.18 to 4.11, although with a trivial conflict resolution
for the later branches.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface")

 drivers/staging/android/ion/ion.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 374f840f31a48..11f93a6314fdb 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -15,6 +15,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -387,6 +388,15 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
+/* Must hold the client lock */
+static struct ion_handle *ion_handle_get_check_overflow(
+   struct ion_handle *handle)
+{
+   if (atomic_read(>ref.refcount) + 1 == 0)
+   return ERR_PTR(-EOVERFLOW);
+   ion_handle_get(handle);
+   return handle;
+}
+
 static int ion_handle_put_nolock(struct ion_handle *handle)
 {
int ret;
@@ -433,9 +443,9 @@ static struct ion_handle 
*ion_handle_get_by_id_nolock(struct ion_client *client,
 
handle = idr_find(>idr, id);
if (handle)
-   ion_handle_get(handle);
+   return ion_handle_get_check_overflow(handle);
 
-   return handle ? handle : ERR_PTR(-EINVAL);
+   return ERR_PTR(-EINVAL);
 }
 
 struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
@@ -1202,7 +1212,7 @@ struct ion_handle *ion_import_dma_buf(struct ion_client 
*client, int fd)
/* if a handle exists for this buffer just take a reference to it */
handle = ion_handle_lookup(client, buffer);
if (!IS_ERR(handle)) {
-   ion_handle_get(handle);
+   handle = ion_handle_get_check_overflow(handle);
mutex_unlock(>lock);
goto end;
}
-- 
2.18.0.865.gffc8e1a3cd6-goog

[PATCH] staging: android: ion: check for kref overflow

[Daniel Rosenberg]

Userspace can cause the kref to handles to increment
arbitrarily high. Ensure it does not overflow.

Signed-off-by: Daniel Rosenberg 
---

This patch is against 4.4. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
It applies from 3.18 to 4.11, although with a trivial conflict resolution
for the later branches.
4c23cbff073f3b9b ("staging: android: ion: Remove import interface")

 drivers/staging/android/ion/ion.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 374f840f31a48..11f93a6314fdb 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -15,6 +15,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -387,6 +388,15 @@ static void ion_handle_get(struct ion_handle *handle)
kref_get(>ref);
 }
 
+/* Must hold the client lock */
+static struct ion_handle *ion_handle_get_check_overflow(
+   struct ion_handle *handle)
+{
+   if (atomic_read(>ref.refcount) + 1 == 0)
+   return ERR_PTR(-EOVERFLOW);
+   ion_handle_get(handle);
+   return handle;
+}
+
 static int ion_handle_put_nolock(struct ion_handle *handle)
 {
int ret;
@@ -433,9 +443,9 @@ static struct ion_handle 
*ion_handle_get_by_id_nolock(struct ion_client *client,
 
handle = idr_find(>idr, id);
if (handle)
-   ion_handle_get(handle);
+   return ion_handle_get_check_overflow(handle);
 
-   return handle ? handle : ERR_PTR(-EINVAL);
+   return ERR_PTR(-EINVAL);
 }
 
 struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
@@ -1202,7 +1212,7 @@ struct ion_handle *ion_import_dma_buf(struct ion_client 
*client, int fd)
/* if a handle exists for this buffer just take a reference to it */
handle = ion_handle_lookup(client, buffer);
if (!IS_ERR(handle)) {
-   ion_handle_get(handle);
+   handle = ion_handle_get_check_overflow(handle);
mutex_unlock(>lock);
goto end;
}
-- 
2.18.0.865.gffc8e1a3cd6-goog

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Frank Rowand]

On 08/20/18 14:32, Rob Herring wrote:
> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:
>>
>> On 07/03/18 18:59, Masahiro Yamada wrote:
>>> It is tedious to specify extra compiler options for every file.
>>> HOST_EXTRACFLAGS is useful to add options to all files in a
>>> directory.
>>>
>>> -I$(src)/libfdt is needed for all the files in this directory
>>> to include libfdt_env.h etc. from scripts/dtc/libfdt/.
>>>
>>> On the other hand, -I$(src) is used to include check-in headers
>>> from generated C files.  Thus, I added it only to dtc-lexer.lex.o
>>> and dtc-parser.tab.o .
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  scripts/dtc/Makefile | 18 --
>>>  1 file changed, 4 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
>>> index 9cac65b..1c943e0 100644
>>> --- a/scripts/dtc/Makefile
>>> +++ b/scripts/dtc/Makefile
>>> @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
>>> livetree.o treesource.o \
>>>  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
>>>
>>>  # Source files need to get at the userspace version of libfdt_env.h to 
>>> compile
>>> +HOST_EXTRACFLAGS := -I$(src)/libfdt
>>
>> Shouldn't that be += instead of :=?
> 
> I don't think so. The definition is local to the file (and reset
> before each makefile is included).
> 
> Rob
> 

Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
instead of :=, including the example in Documentation/kbuild/makefiles.txt

What makes scripts/dtc/Makefile different than the other makefiles?

-Frank

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Frank Rowand]

On 08/20/18 14:32, Rob Herring wrote:
> On Mon, Aug 20, 2018 at 1:55 PM Frank Rowand  wrote:
>>
>> On 07/03/18 18:59, Masahiro Yamada wrote:
>>> It is tedious to specify extra compiler options for every file.
>>> HOST_EXTRACFLAGS is useful to add options to all files in a
>>> directory.
>>>
>>> -I$(src)/libfdt is needed for all the files in this directory
>>> to include libfdt_env.h etc. from scripts/dtc/libfdt/.
>>>
>>> On the other hand, -I$(src) is used to include check-in headers
>>> from generated C files.  Thus, I added it only to dtc-lexer.lex.o
>>> and dtc-parser.tab.o .
>>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  scripts/dtc/Makefile | 18 --
>>>  1 file changed, 4 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
>>> index 9cac65b..1c943e0 100644
>>> --- a/scripts/dtc/Makefile
>>> +++ b/scripts/dtc/Makefile
>>> @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o 
>>> livetree.o treesource.o \
>>>  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
>>>
>>>  # Source files need to get at the userspace version of libfdt_env.h to 
>>> compile
>>> +HOST_EXTRACFLAGS := -I$(src)/libfdt
>>
>> Shouldn't that be += instead of :=?
> 
> I don't think so. The definition is local to the file (and reset
> before each makefile is included).
> 
> Rob
> 

Every other place where HOST_EXTRACFLAGS is assigned a value, += is used
instead of :=, including the example in Documentation/kbuild/makefiles.txt

What makes scripts/dtc/Makefile different than the other makefiles?

-Frank

[PATCH] ufs: remove set but not used variable 'usb3'

[Yue Haibing]

Fixes gcc '-Wunused-but-set-variable' warning:

fs/ufs/super.c: In function 'ufs_statfs':
fs/ufs/super.c:1409:32: warning:
 variable 'usb3' set but not used [-Wunused-but-set-variable]
  struct ufs_super_block_third *usb3;
^

Signed-off-by: Yue Haibing 
---
 fs/ufs/super.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index a4e07e9..6a5db06 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -1406,11 +1406,9 @@ static int ufs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
struct super_block *sb = dentry->d_sb;
struct ufs_sb_private_info *uspi= UFS_SB(sb)->s_uspi;
unsigned  flags = UFS_SB(sb)->s_flags;
-   struct ufs_super_block_third *usb3;
u64 id = huge_encode_dev(sb->s_bdev->bd_dev);
 
mutex_lock(_SB(sb)->s_lock);
-   usb3 = ubh_get_usb_third(uspi);

if ((flags & UFS_TYPE_MASK) == UFS_TYPE_UFS2)
buf->f_type = UFS2_MAGIC;

[PATCH] ufs: remove set but not used variable 'usb3'

[Yue Haibing]

Fixes gcc '-Wunused-but-set-variable' warning:

fs/ufs/super.c: In function 'ufs_statfs':
fs/ufs/super.c:1409:32: warning:
 variable 'usb3' set but not used [-Wunused-but-set-variable]
  struct ufs_super_block_third *usb3;
^

Signed-off-by: Yue Haibing 
---
 fs/ufs/super.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index a4e07e9..6a5db06 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -1406,11 +1406,9 @@ static int ufs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
struct super_block *sb = dentry->d_sb;
struct ufs_sb_private_info *uspi= UFS_SB(sb)->s_uspi;
unsigned  flags = UFS_SB(sb)->s_flags;
-   struct ufs_super_block_third *usb3;
u64 id = huge_encode_dev(sb->s_bdev->bd_dev);
 
mutex_lock(_SB(sb)->s_lock);
-   usb3 = ubh_get_usb_third(uspi);

if ((flags & UFS_TYPE_MASK) == UFS_TYPE_UFS2)
buf->f_type = UFS2_MAGIC;

[PATCH v3 4/5] x86/mm: optimize static_protection() by using overlap()

[Bin Yang]

When changing a 4K page attr inside the large page range,
try_preserve_large_page() will call static_protections() to check all
4K pages inside the large page range.

In the worst case, when changing a 4K page attr inside 1G large page
range, static_protections() will be called for 262144 times for single
4K page check.

It can be optimized to check for overlapping ranges instead of looping
all pages. If the checking range has overlap with a specific protection
area, it should add the corresponding protection flag.

Suggested-by: Dave Hansen 
Suggested-by: Shevchenko, Andriy 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index f630eb4..fd90c5b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -106,6 +106,21 @@ within_inclusive(unsigned long addr, unsigned long start, 
unsigned long end)
return addr >= start && addr <= end;
 }
 
+static inline bool
+overlap(unsigned long start1, unsigned long end1,
+   unsigned long start2, unsigned long end2)
+{
+   /* Is 'start2' within area 1? */
+   if (start1 <= start2 && end1 > start2)
+   return true;
+
+   /* Is 'start1' within area 2? */
+   if (start2 <= start1 && end2 > start1)
+   return true;
+
+   return false;
+}
+
 #ifdef CONFIG_X86_64
 
 static inline unsigned long highmap_start_pfn(void)
@@ -293,7 +308,7 @@ static void cpa_flush_array(unsigned long *start, int 
numpages, int cache,
  * checks and fixes these known static required protection bits.
  */
 static inline pgprot_t static_protections(pgprot_t prot, unsigned long address,
-  unsigned long pfn)
+  unsigned long len, unsigned long pfn)
 {
pgprot_t forbidden = __pgprot(0);
 
@@ -302,7 +317,9 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * PCI BIOS based config access (CONFIG_PCI_GOBIOS) support.
 */
 #ifdef CONFIG_PCI_BIOS
-   if (pcibios_enabled && within(pfn, BIOS_BEGIN >> PAGE_SHIFT, BIOS_END 
>> PAGE_SHIFT))
+   if (pcibios_enabled &&
+   overlap(pfn, pfn + PFN_DOWN(len),
+   PFN_DOWN(BIOS_BEGIN), PFN_DOWN(BIOS_END)))
pgprot_val(forbidden) |= _PAGE_NX;
 #endif
 
@@ -311,7 +328,8 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * Does not cover __inittext since that is gone later on. On
 * 64bit we do not enforce !NX on the low mapping
 */
-   if (within(address, (unsigned long)_text, (unsigned long)_etext))
+   if (overlap(address, address + len,
+   (unsigned long)_text, (unsigned long)_etext))
pgprot_val(forbidden) |= _PAGE_NX;
 
/*
@@ -320,8 +338,9 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * so do not enforce until kernel_set_to_readonly is true.
 */
if (kernel_set_to_readonly &&
-   within(pfn, __pa_symbol(__start_rodata) >> PAGE_SHIFT,
-  __pa_symbol(__end_rodata) >> PAGE_SHIFT))
+   overlap(pfn, pfn + PFN_DOWN(len),
+   PFN_DOWN(__pa_symbol(__start_rodata)),
+   PFN_DOWN(__pa_symbol(__end_rodata
pgprot_val(forbidden) |= _PAGE_RW;
 
 #if defined(CONFIG_X86_64)
@@ -335,8 +354,8 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * at no extra cost.
 */
if (kernel_set_to_readonly &&
-   within(address, (unsigned long)_text,
-  (unsigned long)__end_rodata_hpage_align)) {
+   overlap(address, address + len, (unsigned long)_text,
+   (unsigned long)__end_rodata_hpage_align)) {
unsigned int level;
 
/*
@@ -375,19 +394,14 @@ static inline bool
 needs_static_protections(pgprot_t prot, unsigned long address,
unsigned long len, unsigned long pfn)
 {
-   int i;
+   pgprot_t chk_prot;
 
address &= PAGE_MASK;
len = PFN_ALIGN(len);
-   for (i = 0; i < (len >> PAGE_SHIFT); i++, address += PAGE_SIZE, pfn++) {
-   pgprot_t chk_prot = static_protections(prot, address, pfn);
-
-   if (pgprot_val(chk_prot) != pgprot_val(prot))
-   return true;
-   }
+   chk_prot = static_protections(prot, address, len, pfn);
 
/* Does static_protections() demand a change ? */
-   return false;
+   return pgprot_val(chk_prot) != pgprot_val(prot);
 }
 
 /*
@@ -650,7 +664,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
pfn = old_pfn + ((address & (psize - 1)) >> PAGE_SHIFT);
cpa->pfn = pfn;
 
-   new_prot = static_protections(req_prot, address, pfn);
+   new_prot = 

[PATCH v3 4/5] x86/mm: optimize static_protection() by using overlap()

[Bin Yang]

When changing a 4K page attr inside the large page range,
try_preserve_large_page() will call static_protections() to check all
4K pages inside the large page range.

In the worst case, when changing a 4K page attr inside 1G large page
range, static_protections() will be called for 262144 times for single
4K page check.

It can be optimized to check for overlapping ranges instead of looping
all pages. If the checking range has overlap with a specific protection
area, it should add the corresponding protection flag.

Suggested-by: Dave Hansen 
Suggested-by: Shevchenko, Andriy 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 50 +-
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index f630eb4..fd90c5b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -106,6 +106,21 @@ within_inclusive(unsigned long addr, unsigned long start, 
unsigned long end)
return addr >= start && addr <= end;
 }
 
+static inline bool
+overlap(unsigned long start1, unsigned long end1,
+   unsigned long start2, unsigned long end2)
+{
+   /* Is 'start2' within area 1? */
+   if (start1 <= start2 && end1 > start2)
+   return true;
+
+   /* Is 'start1' within area 2? */
+   if (start2 <= start1 && end2 > start1)
+   return true;
+
+   return false;
+}
+
 #ifdef CONFIG_X86_64
 
 static inline unsigned long highmap_start_pfn(void)
@@ -293,7 +308,7 @@ static void cpa_flush_array(unsigned long *start, int 
numpages, int cache,
  * checks and fixes these known static required protection bits.
  */
 static inline pgprot_t static_protections(pgprot_t prot, unsigned long address,
-  unsigned long pfn)
+  unsigned long len, unsigned long pfn)
 {
pgprot_t forbidden = __pgprot(0);
 
@@ -302,7 +317,9 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * PCI BIOS based config access (CONFIG_PCI_GOBIOS) support.
 */
 #ifdef CONFIG_PCI_BIOS
-   if (pcibios_enabled && within(pfn, BIOS_BEGIN >> PAGE_SHIFT, BIOS_END 
>> PAGE_SHIFT))
+   if (pcibios_enabled &&
+   overlap(pfn, pfn + PFN_DOWN(len),
+   PFN_DOWN(BIOS_BEGIN), PFN_DOWN(BIOS_END)))
pgprot_val(forbidden) |= _PAGE_NX;
 #endif
 
@@ -311,7 +328,8 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * Does not cover __inittext since that is gone later on. On
 * 64bit we do not enforce !NX on the low mapping
 */
-   if (within(address, (unsigned long)_text, (unsigned long)_etext))
+   if (overlap(address, address + len,
+   (unsigned long)_text, (unsigned long)_etext))
pgprot_val(forbidden) |= _PAGE_NX;
 
/*
@@ -320,8 +338,9 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * so do not enforce until kernel_set_to_readonly is true.
 */
if (kernel_set_to_readonly &&
-   within(pfn, __pa_symbol(__start_rodata) >> PAGE_SHIFT,
-  __pa_symbol(__end_rodata) >> PAGE_SHIFT))
+   overlap(pfn, pfn + PFN_DOWN(len),
+   PFN_DOWN(__pa_symbol(__start_rodata)),
+   PFN_DOWN(__pa_symbol(__end_rodata
pgprot_val(forbidden) |= _PAGE_RW;
 
 #if defined(CONFIG_X86_64)
@@ -335,8 +354,8 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 * at no extra cost.
 */
if (kernel_set_to_readonly &&
-   within(address, (unsigned long)_text,
-  (unsigned long)__end_rodata_hpage_align)) {
+   overlap(address, address + len, (unsigned long)_text,
+   (unsigned long)__end_rodata_hpage_align)) {
unsigned int level;
 
/*
@@ -375,19 +394,14 @@ static inline bool
 needs_static_protections(pgprot_t prot, unsigned long address,
unsigned long len, unsigned long pfn)
 {
-   int i;
+   pgprot_t chk_prot;
 
address &= PAGE_MASK;
len = PFN_ALIGN(len);
-   for (i = 0; i < (len >> PAGE_SHIFT); i++, address += PAGE_SIZE, pfn++) {
-   pgprot_t chk_prot = static_protections(prot, address, pfn);
-
-   if (pgprot_val(chk_prot) != pgprot_val(prot))
-   return true;
-   }
+   chk_prot = static_protections(prot, address, len, pfn);
 
/* Does static_protections() demand a change ? */
-   return false;
+   return pgprot_val(chk_prot) != pgprot_val(prot);
 }
 
 /*
@@ -650,7 +664,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
pfn = old_pfn + ((address & (psize - 1)) >> PAGE_SHIFT);
cpa->pfn = pfn;
 
-   new_prot = static_protections(req_prot, address, pfn);
+   new_prot = 

[PATCH v3 2/5] x86/mm: avoid static_protection() checking if not whole large page attr change

[Bin Yang]

The range check whether the address is aligned to the large page and
covers the full large page (1G or 2M) is obvious to do _before_
static_protection() check, because if the requested range does not fit
and has a different pgprot_val() then it will decide to split after the
check anyway.

The approach and some of the comments came from Thomas Gleixner's
email example for how to do this

Suggested-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 68613fd..091f1d3 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -645,11 +645,21 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
address,
}
 
/*
+* If the requested address range is not aligned to the start of
+* the large page or does not cover the full range, split it up.
+* No matter what the static_protections() check below does, it
+* would anyway result in a split after doing all the check work
+* for nothing.
+*/
+   addr = address & pmask;
+   if (address != addr || cpa->numpages != numpages)
+   goto out_unlock;
+
+   /*
 * We need to check the full range, whether
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
 */
-   addr = address & pmask;
pfn = old_pfn;
for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
pgprot_t chk_prot = static_protections(req_prot, addr, pfn);
@@ -659,24 +669,11 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
address,
}
 
 
-   /*
-* We need to change the attributes. Check, whether we can
-* change the large page in one go. We request a split, when
-* the address is not aligned and the number of pages is
-* smaller than the number of pages in the large page. Note
-* that we limited the number of possible pages already to
-* the number of pages in the large page.
-*/
-   if (address == (address & pmask) && cpa->numpages == (psize >> 
PAGE_SHIFT)) {
-   /*
-* The address is aligned and the number of pages
-* covers the full page.
-*/
-   new_pte = pfn_pte(old_pfn, new_prot);
-   __set_pmd_pte(kpte, address, new_pte);
-   cpa->flags |= CPA_FLUSHTLB;
-   do_split = 0;
-   }
+   /* All checks passed. Just change the large mapping entry */
+   new_pte = pfn_pte(old_pfn, new_prot);
+   __set_pmd_pte(kpte, address, new_pte);
+   cpa->flags |= CPA_FLUSHTLB;
+   do_split = 0;
 
 out_unlock:
spin_unlock(_lock);
-- 
2.7.4

[PATCH v3 3/5] x86/mm: add help function to check specific protection flags in range

[Bin Yang]

Introduce the needs_static_protections() helper to check specific
protection flags in range. It calls static_protection() to check
whether any part of the address/len range is forced to change from 'prot'.

Suggested-by: Dave Hansen 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 091f1d3..f630eb4 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -367,6 +367,30 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 }
 
 /*
+ * static_protections() "forces" page protections for some address
+ * ranges.  Return true if any part of the address/len range is forced
+ * to change from 'prot'.
+ */
+static inline bool
+needs_static_protections(pgprot_t prot, unsigned long address,
+   unsigned long len, unsigned long pfn)
+{
+   int i;
+
+   address &= PAGE_MASK;
+   len = PFN_ALIGN(len);
+   for (i = 0; i < (len >> PAGE_SHIFT); i++, address += PAGE_SIZE, pfn++) {
+   pgprot_t chk_prot = static_protections(prot, address, pfn);
+
+   if (pgprot_val(chk_prot) != pgprot_val(prot))
+   return true;
+   }
+
+   /* Does static_protections() demand a change ? */
+   return false;
+}
+
+/*
  * Lookup the page table entry for a virtual address in a specific pgd.
  * Return a pointer to the entry and the level of the mapping.
  */
@@ -556,7 +580,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
unsigned long nextpage_addr, numpages, pmask, psize, addr, pfn, old_pfn;
pte_t new_pte, old_pte, *tmp;
pgprot_t old_prot, new_prot, req_prot;
-   int i, do_split = 1;
+   int do_split = 1;
enum pg_level level;
 
if (cpa->force_split)
@@ -660,14 +684,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
 */
-   pfn = old_pfn;
-   for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
-   pgprot_t chk_prot = static_protections(req_prot, addr, pfn);
-
-   if (pgprot_val(chk_prot) != pgprot_val(new_prot))
-   goto out_unlock;
-   }
-
+   if (needs_static_protections(new_prot, addr, psize, old_pfn))
+   goto out_unlock;
 
/* All checks passed. Just change the large mapping entry */
new_pte = pfn_pte(old_pfn, new_prot);
-- 
2.7.4

[PATCH v3 2/5] x86/mm: avoid static_protection() checking if not whole large page attr change

[Bin Yang]

The range check whether the address is aligned to the large page and
covers the full large page (1G or 2M) is obvious to do _before_
static_protection() check, because if the requested range does not fit
and has a different pgprot_val() then it will decide to split after the
check anyway.

The approach and some of the comments came from Thomas Gleixner's
email example for how to do this

Suggested-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 68613fd..091f1d3 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -645,11 +645,21 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
address,
}
 
/*
+* If the requested address range is not aligned to the start of
+* the large page or does not cover the full range, split it up.
+* No matter what the static_protections() check below does, it
+* would anyway result in a split after doing all the check work
+* for nothing.
+*/
+   addr = address & pmask;
+   if (address != addr || cpa->numpages != numpages)
+   goto out_unlock;
+
+   /*
 * We need to check the full range, whether
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
 */
-   addr = address & pmask;
pfn = old_pfn;
for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
pgprot_t chk_prot = static_protections(req_prot, addr, pfn);
@@ -659,24 +669,11 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
address,
}
 
 
-   /*
-* We need to change the attributes. Check, whether we can
-* change the large page in one go. We request a split, when
-* the address is not aligned and the number of pages is
-* smaller than the number of pages in the large page. Note
-* that we limited the number of possible pages already to
-* the number of pages in the large page.
-*/
-   if (address == (address & pmask) && cpa->numpages == (psize >> 
PAGE_SHIFT)) {
-   /*
-* The address is aligned and the number of pages
-* covers the full page.
-*/
-   new_pte = pfn_pte(old_pfn, new_prot);
-   __set_pmd_pte(kpte, address, new_pte);
-   cpa->flags |= CPA_FLUSHTLB;
-   do_split = 0;
-   }
+   /* All checks passed. Just change the large mapping entry */
+   new_pte = pfn_pte(old_pfn, new_prot);
+   __set_pmd_pte(kpte, address, new_pte);
+   cpa->flags |= CPA_FLUSHTLB;
+   do_split = 0;
 
 out_unlock:
spin_unlock(_lock);
-- 
2.7.4

[PATCH v3 3/5] x86/mm: add help function to check specific protection flags in range

[Bin Yang]

Introduce the needs_static_protections() helper to check specific
protection flags in range. It calls static_protection() to check
whether any part of the address/len range is forced to change from 'prot'.

Suggested-by: Dave Hansen 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 091f1d3..f630eb4 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -367,6 +367,30 @@ static inline pgprot_t static_protections(pgprot_t prot, 
unsigned long address,
 }
 
 /*
+ * static_protections() "forces" page protections for some address
+ * ranges.  Return true if any part of the address/len range is forced
+ * to change from 'prot'.
+ */
+static inline bool
+needs_static_protections(pgprot_t prot, unsigned long address,
+   unsigned long len, unsigned long pfn)
+{
+   int i;
+
+   address &= PAGE_MASK;
+   len = PFN_ALIGN(len);
+   for (i = 0; i < (len >> PAGE_SHIFT); i++, address += PAGE_SIZE, pfn++) {
+   pgprot_t chk_prot = static_protections(prot, address, pfn);
+
+   if (pgprot_val(chk_prot) != pgprot_val(prot))
+   return true;
+   }
+
+   /* Does static_protections() demand a change ? */
+   return false;
+}
+
+/*
  * Lookup the page table entry for a virtual address in a specific pgd.
  * Return a pointer to the entry and the level of the mapping.
  */
@@ -556,7 +580,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
unsigned long nextpage_addr, numpages, pmask, psize, addr, pfn, old_pfn;
pte_t new_pte, old_pte, *tmp;
pgprot_t old_prot, new_prot, req_prot;
-   int i, do_split = 1;
+   int do_split = 1;
enum pg_level level;
 
if (cpa->force_split)
@@ -660,14 +684,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
 */
-   pfn = old_pfn;
-   for (i = 0; i < (psize >> PAGE_SHIFT); i++, addr += PAGE_SIZE, pfn++) {
-   pgprot_t chk_prot = static_protections(req_prot, addr, pfn);
-
-   if (pgprot_val(chk_prot) != pgprot_val(new_prot))
-   goto out_unlock;
-   }
-
+   if (needs_static_protections(new_prot, addr, psize, old_pfn))
+   goto out_unlock;
 
/* All checks passed. Just change the large mapping entry */
new_pte = pfn_pte(old_pfn, new_prot);
-- 
2.7.4

[PATCH v3 1/5] x86/mm: avoid redundant checking if pgprot has no change

[Bin Yang]

In try_preserve_large_page(), the check for
pgprot_val(new_prot) == pgprot_val(old_port) can definitely
be done at first to avoid redundant checking.

The approach and some of the comments came from Thomas Gleixner's
email example for how to do this

Suggested-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 8d6c34f..68613fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
new_prot = static_protections(req_prot, address, pfn);
 
/*
+* The static_protections() is used to check specific protection flags
+* for certain areas of memory. The old pgprot should be checked already
+* when it was applied before. If it's not, then this is a bug in some
+* other code and needs to be fixed there.
+*
+* If new pgprot is same as old pgprot, return directly without any
+* additional checking. The following static_protections() checking is
+* pointless if pgprot has no change. It can avoid the redundant
+* checking and optimize the performance of large page split checking.
+*/
+   if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
+   do_split = 0;
+   goto out_unlock;
+   }
+
+   /*
 * We need to check the full range, whether
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
@@ -642,14 +658,6 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
goto out_unlock;
}
 
-   /*
-* If there are no changes, return. maxpages has been updated
-* above:
-*/
-   if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
-   do_split = 0;
-   goto out_unlock;
-   }
 
/*
 * We need to change the attributes. Check, whether we can
-- 
2.7.4

[PATCH v3 0/5] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr

[Bin Yang]

One problem is found when optimizing the x86 kernel boot time, that sometimes
the free_initmem() will take about 600ms, which is way too much for fast boot.

When changing a 4K page attr inside the large page range,
__change_page_attr() will call try_preserve_large_page() to decide
to split the big page or not. And try_preserve_large_page() will
call static_protections() to check all 4K pages inside the large page
range one by one.

free_initmem()  <-- free N pages
  free_init_pages()
set_memory_rw()
  change_page_attr_set()
change_page_attr_set_clr()
  __change_page_attr_set_clr()
__change_page_attr() <-- loop N times
  try_preserve_large_page()
static_protections() <-- worst case: loop (1G/4K = 262144) * N 
times

The problem is,  most of the  256K * N  times of call of static_proetections()
is _not_ necessary at all, as pointed out by Thomas Gleixner :

"The current code does the static_protection() check loop _before_ checking:

  1) Whether the new and the old pgprot are the same
  
  2) Whether the address range which needs to be changed is aligned to and
 covers the full large mapping

It does the static_protections() loop before #1 and #2 which can be
optimized."

The static_protections() check loop can be optimized to check for overlapping
ranges and then check explicitly for those without any looping.

Here are 5 patches for these optimizations:

Patch 1: check whether new pgprot is same as old pgprot first to avoid
 unnecessary static_protection() checking.

Patch 2: check whether it is whole large page attr change first to avoid
 unnecessary static_protection() checking.

Patch 3: add help function to check specific protection flags in range

Patch 4: Optimize the static_protection() by using overlap() check instead
 of within()

Patch 5: Add a check for catching a case where the existing mapping is wrong
 already

The approach and some of the comments came from Thomas's email example for how
to do this. Thanks again for Thomas's kind help.

Thanks,
Bin

Bin Yang (5):
  x86/mm: avoid redundant checking if pgprot has no change
  x86/mm: avoid static_protection() checking if not whole large page
attr change
  x86/mm: add help function to check specific protection flags in range
  x86/mm: optimize static_protection() by using overlap()
  x86/mm: add WARN_ON_ONCE() for wrong large page mapping

 arch/x86/mm/pageattr.c | 127 +
 1 file changed, 86 insertions(+), 41 deletions(-)

-- 
2.7.4

[PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping

[Bin Yang]

If there is a large page which contains an area which requires a
different mapping that the one which the large page provides,
then something went wrong _before_ this code is called.

Here we can catch a case where the existing mapping is wrong
already.

Inspired-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index fd90c5b..91a250c 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
psize = page_level_size(level);
pmask = page_level_mask(level);
+   addr = address & pmask;
 
/*
 * Calculate the number of pages, which fit into this large
@@ -636,6 +637,12 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
cpa->numpages = numpages;
 
/*
+* The old pgprot should not have any protection bit. Otherwise,
+* the existing mapping is wrong already.
+*/
+   WARN_ON_ONCE(needs_static_protections(old_prot, addr, psize, old_pfn));
+
+   /*
 * We are safe now. Check whether the new pgprot is the same:
 * Convert protection attributes to 4k-format, as cpa->mask* are set
 * up accordingly.
@@ -690,7 +697,6 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 * would anyway result in a split after doing all the check work
 * for nothing.
 */
-   addr = address & pmask;
if (address != addr || cpa->numpages != numpages)
goto out_unlock;
 
-- 
2.7.4

[PATCH v3 1/5] x86/mm: avoid redundant checking if pgprot has no change

[Bin Yang]

In try_preserve_large_page(), the check for
pgprot_val(new_prot) == pgprot_val(old_port) can definitely
be done at first to avoid redundant checking.

The approach and some of the comments came from Thomas Gleixner's
email example for how to do this

Suggested-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 8d6c34f..68613fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
new_prot = static_protections(req_prot, address, pfn);
 
/*
+* The static_protections() is used to check specific protection flags
+* for certain areas of memory. The old pgprot should be checked already
+* when it was applied before. If it's not, then this is a bug in some
+* other code and needs to be fixed there.
+*
+* If new pgprot is same as old pgprot, return directly without any
+* additional checking. The following static_protections() checking is
+* pointless if pgprot has no change. It can avoid the redundant
+* checking and optimize the performance of large page split checking.
+*/
+   if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
+   do_split = 0;
+   goto out_unlock;
+   }
+
+   /*
 * We need to check the full range, whether
 * static_protection() requires a different pgprot for one of
 * the pages in the range we try to preserve:
@@ -642,14 +658,6 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
goto out_unlock;
}
 
-   /*
-* If there are no changes, return. maxpages has been updated
-* above:
-*/
-   if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
-   do_split = 0;
-   goto out_unlock;
-   }
 
/*
 * We need to change the attributes. Check, whether we can
-- 
2.7.4

[PATCH v3 0/5] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr

[Bin Yang]

One problem is found when optimizing the x86 kernel boot time, that sometimes
the free_initmem() will take about 600ms, which is way too much for fast boot.

When changing a 4K page attr inside the large page range,
__change_page_attr() will call try_preserve_large_page() to decide
to split the big page or not. And try_preserve_large_page() will
call static_protections() to check all 4K pages inside the large page
range one by one.

free_initmem()  <-- free N pages
  free_init_pages()
set_memory_rw()
  change_page_attr_set()
change_page_attr_set_clr()
  __change_page_attr_set_clr()
__change_page_attr() <-- loop N times
  try_preserve_large_page()
static_protections() <-- worst case: loop (1G/4K = 262144) * N 
times

The problem is,  most of the  256K * N  times of call of static_proetections()
is _not_ necessary at all, as pointed out by Thomas Gleixner :

"The current code does the static_protection() check loop _before_ checking:

  1) Whether the new and the old pgprot are the same
  
  2) Whether the address range which needs to be changed is aligned to and
 covers the full large mapping

It does the static_protections() loop before #1 and #2 which can be
optimized."

The static_protections() check loop can be optimized to check for overlapping
ranges and then check explicitly for those without any looping.

Here are 5 patches for these optimizations:

Patch 1: check whether new pgprot is same as old pgprot first to avoid
 unnecessary static_protection() checking.

Patch 2: check whether it is whole large page attr change first to avoid
 unnecessary static_protection() checking.

Patch 3: add help function to check specific protection flags in range

Patch 4: Optimize the static_protection() by using overlap() check instead
 of within()

Patch 5: Add a check for catching a case where the existing mapping is wrong
 already

The approach and some of the comments came from Thomas's email example for how
to do this. Thanks again for Thomas's kind help.

Thanks,
Bin

Bin Yang (5):
  x86/mm: avoid redundant checking if pgprot has no change
  x86/mm: avoid static_protection() checking if not whole large page
attr change
  x86/mm: add help function to check specific protection flags in range
  x86/mm: optimize static_protection() by using overlap()
  x86/mm: add WARN_ON_ONCE() for wrong large page mapping

 arch/x86/mm/pageattr.c | 127 +
 1 file changed, 86 insertions(+), 41 deletions(-)

-- 
2.7.4

[PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping

[Bin Yang]

If there is a large page which contains an area which requires a
different mapping that the one which the large page provides,
then something went wrong _before_ this code is called.

Here we can catch a case where the existing mapping is wrong
already.

Inspired-by: Thomas Gleixner 
Signed-off-by: Bin Yang 
---
 arch/x86/mm/pageattr.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index fd90c5b..91a250c 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
psize = page_level_size(level);
pmask = page_level_mask(level);
+   addr = address & pmask;
 
/*
 * Calculate the number of pages, which fit into this large
@@ -636,6 +637,12 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
cpa->numpages = numpages;
 
/*
+* The old pgprot should not have any protection bit. Otherwise,
+* the existing mapping is wrong already.
+*/
+   WARN_ON_ONCE(needs_static_protections(old_prot, addr, psize, old_pfn));
+
+   /*
 * We are safe now. Check whether the new pgprot is the same:
 * Convert protection attributes to 4k-format, as cpa->mask* are set
 * up accordingly.
@@ -690,7 +697,6 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 * would anyway result in a split after doing all the check work
 * for nothing.
 */
-   addr = address & pmask;
if (address != addr || cpa->numpages != numpages)
goto out_unlock;
 
-- 
2.7.4

[PATCH v2] staging: rtl8188eu: Removed a function and coded inline

[Bhaskar Singh]

This patch removed function named rtw_malloc2d.

I removed this function because this function is used exactly once and
function call have some overhead also.

Maybe this will improve code runtime slightly.

Signed-off-by: Bhaskar Singh 
---

Changes in v2:
- Incorporated comments from Dan Carpenter.
---
 drivers/staging/rtl8188eu/core/rtw_efuse.c|  8 ++--
 drivers/staging/rtl8188eu/include/osdep_service.h |  2 --
 drivers/staging/rtl8188eu/os_dep/osdep_service.c  | 14 --
 3 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..ddd7f67fe5a2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -86,16 +86,20 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
_size_byte, u8  *pbuf)
u16 **eFuseWord = NULL;
u16 efuse_utilized = 0;
u8 u1temp = 0;
+   void **tmp = NULL;
 
efuseTbl = kzalloc(EFUSE_MAP_LEN_88E, GFP_KERNEL);
if (!efuseTbl)
return;
 
-   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
EFUSE_MAX_WORD_UNIT, sizeof(u16));
-   if (!eFuseWord) {
+   tmp = kzalloc(EFUSE_MAX_SECTION_88E * (sizeof(void *) + 
EFUSE_MAX_WORD_UNIT * sizeof(u16)), GFP_KERNEL);
+   if (!tmp) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
}
+   for (i = 0; i < EFUSE_MAX_SECTION_88E; i++)
+   tmp[i] = ((char *)(tmp + EFUSE_MAX_SECTION_88E)) + i * 
EFUSE_MAX_WORD_UNIT * sizeof(u16);
+   eFuseWord = (u16 **)tmp;
 
/*  0. Refresh efuse init map as all oxFF. */
for (i = 0; i < EFUSE_MAX_SECTION_88E; i++)
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h 
b/drivers/staging/rtl8188eu/include/osdep_service.h
index fbcba79a0927..cfe5698fbbb1 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -64,8 +64,6 @@ static inline int rtw_netif_queue_stopped(struct net_device 
*pnetdev)
 u8 *_rtw_malloc(u32 sz);
 #define rtw_malloc(sz) _rtw_malloc((sz))
 
-void *rtw_malloc2d(int h, int w, int size);
-
 void _rtw_init_queue(struct __queue *pqueue);
 
 struct rtw_netdev_priv_indicator {
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 78daef6704ac..105f3f21bdea 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -18,20 +18,6 @@ u8 *_rtw_malloc(u32 sz)
return kmalloc(sz, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
 }
 
-void *rtw_malloc2d(int h, int w, int size)
-{
-   int j;
-   void **a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
-
-   if (!a)
-   goto out;
-
-   for (j = 0; j < h; j++)
-   a[j] = ((char *)(a + h)) + j * w * size;
-out:
-   return a;
-}
-
 void _rtw_init_queue(struct __queue *pqueue)
 {
INIT_LIST_HEAD(>queue);
-- 
2.16.4

[PATCH v2] staging: rtl8188eu: Removed a function and coded inline

[Bhaskar Singh]

This patch removed function named rtw_malloc2d.

I removed this function because this function is used exactly once and
function call have some overhead also.

Maybe this will improve code runtime slightly.

Signed-off-by: Bhaskar Singh 
---

Changes in v2:
- Incorporated comments from Dan Carpenter.
---
 drivers/staging/rtl8188eu/core/rtw_efuse.c|  8 ++--
 drivers/staging/rtl8188eu/include/osdep_service.h |  2 --
 drivers/staging/rtl8188eu/os_dep/osdep_service.c  | 14 --
 3 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..ddd7f67fe5a2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -86,16 +86,20 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
_size_byte, u8  *pbuf)
u16 **eFuseWord = NULL;
u16 efuse_utilized = 0;
u8 u1temp = 0;
+   void **tmp = NULL;
 
efuseTbl = kzalloc(EFUSE_MAP_LEN_88E, GFP_KERNEL);
if (!efuseTbl)
return;
 
-   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
EFUSE_MAX_WORD_UNIT, sizeof(u16));
-   if (!eFuseWord) {
+   tmp = kzalloc(EFUSE_MAX_SECTION_88E * (sizeof(void *) + 
EFUSE_MAX_WORD_UNIT * sizeof(u16)), GFP_KERNEL);
+   if (!tmp) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
}
+   for (i = 0; i < EFUSE_MAX_SECTION_88E; i++)
+   tmp[i] = ((char *)(tmp + EFUSE_MAX_SECTION_88E)) + i * 
EFUSE_MAX_WORD_UNIT * sizeof(u16);
+   eFuseWord = (u16 **)tmp;
 
/*  0. Refresh efuse init map as all oxFF. */
for (i = 0; i < EFUSE_MAX_SECTION_88E; i++)
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h 
b/drivers/staging/rtl8188eu/include/osdep_service.h
index fbcba79a0927..cfe5698fbbb1 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -64,8 +64,6 @@ static inline int rtw_netif_queue_stopped(struct net_device 
*pnetdev)
 u8 *_rtw_malloc(u32 sz);
 #define rtw_malloc(sz) _rtw_malloc((sz))
 
-void *rtw_malloc2d(int h, int w, int size);
-
 void _rtw_init_queue(struct __queue *pqueue);
 
 struct rtw_netdev_priv_indicator {
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 78daef6704ac..105f3f21bdea 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -18,20 +18,6 @@ u8 *_rtw_malloc(u32 sz)
return kmalloc(sz, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
 }
 
-void *rtw_malloc2d(int h, int w, int size)
-{
-   int j;
-   void **a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
-
-   if (!a)
-   goto out;
-
-   for (j = 0; j < h; j++)
-   a[j] = ((char *)(a + h)) + j * w * size;
-out:
-   return a;
-}
-
 void _rtw_init_queue(struct __queue *pqueue)
 {
INIT_LIST_HEAD(>queue);
-- 
2.16.4

[PATCH v2] mtd/ubi: Make sure to read volume record from LEB 0 or LEB 1

[Liu Song]

Even though we protect on-flash data by CRC checksums,
we still don't trust the media. If lnum is not 0 or 1,
access exceed array boundary can lead to bad situation.

Signed-off-by: Liu Song 
Reviewed-by: Jiang Biao 
---
v2: fix the name in *From*.

 drivers/mtd/ubi/vtbl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index 94d7a86..64a2937 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -410,6 +410,10 @@ static struct ubi_vtbl_record *process_lvol(struct 
ubi_device *ubi,
 
/* Read both LEB 0 and LEB 1 into memory */
ubi_rb_for_each_entry(rb, aeb, >root, u.rb) {
+   if (aeb->lnum != 0 && aeb->lnum != 1) {
+   ubi_warn(ubi, "volume store in LEB %d", aeb->lnum);
+   continue;
+   }
leb[aeb->lnum] = vzalloc(ubi->vtbl_size);
if (!leb[aeb->lnum]) {
err = -ENOMEM;
-- 
2.1.0.GIT

[PATCH v2] mtd/ubi: Make sure to read volume record from LEB 0 or LEB 1

[Liu Song]

Even though we protect on-flash data by CRC checksums,
we still don't trust the media. If lnum is not 0 or 1,
access exceed array boundary can lead to bad situation.

Signed-off-by: Liu Song 
Reviewed-by: Jiang Biao 
---
v2: fix the name in *From*.

 drivers/mtd/ubi/vtbl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index 94d7a86..64a2937 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -410,6 +410,10 @@ static struct ubi_vtbl_record *process_lvol(struct 
ubi_device *ubi,
 
/* Read both LEB 0 and LEB 1 into memory */
ubi_rb_for_each_entry(rb, aeb, >root, u.rb) {
+   if (aeb->lnum != 0 && aeb->lnum != 1) {
+   ubi_warn(ubi, "volume store in LEB %d", aeb->lnum);
+   continue;
+   }
leb[aeb->lnum] = vzalloc(ubi->vtbl_size);
if (!leb[aeb->lnum]) {
err = -ENOMEM;
-- 
2.1.0.GIT

Re: [PATCH] sched/fair: vruntime should normalize when switching from fair

[Miguel de Dios]

On 08/17/2018 11:27 AM, Steve Muckle wrote:

From: John Dias 

When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted to RT via rt_mutex_setprio, which changes
   the task to RT and calls check_class_changed.
- check_class_changed leads to detach_task_cfs_rq, at which point
   the vruntime_normalized check sees that the task's state is TASK_WAKING,
   which results in skipping the subtraction of the rq's min_vruntime
   from the task's vruntime
- later, when the prio is deboosted and the task is moved back
   to the fair class, the fair rq's min_vruntime is added to
   the task's vruntime, even though it wasn't subtracted earlier.
The immediate result is inflation of the task's vruntime, giving
it lower priority (starving it if there's enough available work).
The longer-term effect is inflation of all vruntimes because the
task's vruntime becomes the rq's min_vruntime when the higher
priority tasks go idle. That leads to a vicious cycle, where
the vruntime inflation repeatedly doubled.

The change here is to detect when vruntime_normalized is being
called when the task is waking but is waking in another class,
and to conclude that this is a case where vruntime has not
been normalized.

Signed-off-by: John Dias 
Signed-off-by: Steve Muckle 
---
  kernel/sched/fair.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b39fb596f6c1..14011d7929d8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9638,7 +9638,8 @@ static inline bool vruntime_normalized(struct task_struct 
*p)
 * - A task which has been woken up by try_to_wake_up() and
 *   waiting for actually being woken up by sched_ttwu_pending().
 */
-   if (!se->sum_exec_runtime || p->state == TASK_WAKING)
+   if (!se->sum_exec_runtime ||
+   (p->state == TASK_WAKING && p->sched_class == _sched_class))
return true;
  
  	return false;
The normalization of vruntime used to exist in task_waking but it was 
removed and the normalization was moved into migrate_task_rq_fair. The 
reasoning being that task_waking_fair was only hit when a task is queued 
onto a different core and migrate_task_rq_fair should do the same work.


However, we're finding that there's one case which migrate_task_rq_fair 
doesn't hit: that being the case where rt_mutex_setprio changes a task's 
scheduling class to RT when its scheduled out. The task never hits 
migrate_task_rq_fair because it is switched to RT and migrates as an RT 
task. Because of this we're getting an unbounded addition of 
min_vruntime when the task is re-attached to the CFS runqueue when it 
loses the inherited priority. The patch above works because now the 
kernel specifically checks for this case and normalizes accordingly.


Here's the patch I was talking about: 
https://lore.kernel.org/patchwork/patch/677689/. In our testing we were 
seeing vruntimes nearly double every time after rt_mutex_setprio boosts 
the task to RT.


Signed-off-by: Miguel de Dios 
Tested-by: Miguel de Dios 

Re: [PATCH] sched/fair: vruntime should normalize when switching from fair

[Miguel de Dios]

On 08/17/2018 11:27 AM, Steve Muckle wrote:

From: John Dias 

When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted to RT via rt_mutex_setprio, which changes
   the task to RT and calls check_class_changed.
- check_class_changed leads to detach_task_cfs_rq, at which point
   the vruntime_normalized check sees that the task's state is TASK_WAKING,
   which results in skipping the subtraction of the rq's min_vruntime
   from the task's vruntime
- later, when the prio is deboosted and the task is moved back
   to the fair class, the fair rq's min_vruntime is added to
   the task's vruntime, even though it wasn't subtracted earlier.
The immediate result is inflation of the task's vruntime, giving
it lower priority (starving it if there's enough available work).
The longer-term effect is inflation of all vruntimes because the
task's vruntime becomes the rq's min_vruntime when the higher
priority tasks go idle. That leads to a vicious cycle, where
the vruntime inflation repeatedly doubled.

The change here is to detect when vruntime_normalized is being
called when the task is waking but is waking in another class,
and to conclude that this is a case where vruntime has not
been normalized.

Signed-off-by: John Dias 
Signed-off-by: Steve Muckle 
---
  kernel/sched/fair.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b39fb596f6c1..14011d7929d8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9638,7 +9638,8 @@ static inline bool vruntime_normalized(struct task_struct 
*p)
 * - A task which has been woken up by try_to_wake_up() and
 *   waiting for actually being woken up by sched_ttwu_pending().
 */
-   if (!se->sum_exec_runtime || p->state == TASK_WAKING)
+   if (!se->sum_exec_runtime ||
+   (p->state == TASK_WAKING && p->sched_class == _sched_class))
return true;
  
  	return false;
The normalization of vruntime used to exist in task_waking but it was 
removed and the normalization was moved into migrate_task_rq_fair. The 
reasoning being that task_waking_fair was only hit when a task is queued 
onto a different core and migrate_task_rq_fair should do the same work.


However, we're finding that there's one case which migrate_task_rq_fair 
doesn't hit: that being the case where rt_mutex_setprio changes a task's 
scheduling class to RT when its scheduled out. The task never hits 
migrate_task_rq_fair because it is switched to RT and migrates as an RT 
task. Because of this we're getting an unbounded addition of 
min_vruntime when the task is re-attached to the CFS runqueue when it 
loses the inherited priority. The patch above works because now the 
kernel specifically checks for this case and normalizes accordingly.


Here's the patch I was talking about: 
https://lore.kernel.org/patchwork/patch/677689/. In our testing we were 
seeing vruntimes nearly double every time after rt_mutex_setprio boosts 
the task to RT.


Signed-off-by: Miguel de Dios 
Tested-by: Miguel de Dios 

Re: [GIT PULL] RTC for 4.19

[Alexandre Belloni]

On 20/08/2018 16:34:18-0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 2:22 PM Alexandre Belloni
>  wrote:
> >
> > Subsystem:
> >  - struct rtc_task removal along with rtc_irq_register/rtc_irq_unregister
> 
> You can still find stale mentions of it by grepping for it:
> 
>  * @task: currently registered with rtc_irq_register()
> 
> which should presumably be fixed up too.
> 

Ah right, I'll clean that up along with another suggestion from Arnd.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL] RTC for 4.19

[Alexandre Belloni]

On 20/08/2018 16:34:18-0700, Linus Torvalds wrote:
> On Mon, Aug 20, 2018 at 2:22 PM Alexandre Belloni
>  wrote:
> >
> > Subsystem:
> >  - struct rtc_task removal along with rtc_irq_register/rtc_irq_unregister
> 
> You can still find stale mentions of it by grepping for it:
> 
>  * @task: currently registered with rtc_irq_register()
> 
> which should presumably be fixed up too.
> 

Ah right, I'll clean that up along with another suggestion from Arnd.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Linus Torvalds]

On Mon, Aug 20, 2018 at 4:27 PM Dave Hansen  wrote:
>
> You're right that we could have a full physmap that we switch to for
> kmap()-like access to user pages.  But, the real problem is
> transitioning pages from kernel to user usage since it requires shooting
> down the old kernel mappings for those pages in some way.

You might decide that you simply don't care enough, and are willing to
leave possible stale TLB entries rather than shoot things down.

Then you'd still possibly see user pages in the kernel map, but only
for a fairly limited time, and only until the TLB entry gets re-used
for other reasons.

Even with kernel page table entries being marked global, their
lifetime in the TLB is likely not very long, and definitely not long
enough for some user that tries to scan for pages.

 Linus

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Linus Torvalds]

On Mon, Aug 20, 2018 at 4:27 PM Dave Hansen  wrote:
>
> You're right that we could have a full physmap that we switch to for
> kmap()-like access to user pages.  But, the real problem is
> transitioning pages from kernel to user usage since it requires shooting
> down the old kernel mappings for those pages in some way.

You might decide that you simply don't care enough, and are willing to
leave possible stale TLB entries rather than shoot things down.

Then you'd still possibly see user pages in the kernel map, but only
for a fairly limited time, and only until the TLB entry gets re-used
for other reasons.

Even with kernel page table entries being marked global, their
lifetime in the TLB is likely not very long, and definitely not long
enough for some user that tries to scan for pages.

 Linus

Re: [GIT PULL] RTC for 4.19

[Linus Torvalds]

On Mon, Aug 20, 2018 at 2:22 PM Alexandre Belloni
 wrote:
>
> Subsystem:
>  - struct rtc_task removal along with rtc_irq_register/rtc_irq_unregister

You can still find stale mentions of it by grepping for it:

 * @task: currently registered with rtc_irq_register()

which should presumably be fixed up too.

That's not holding me from doing the pull, but I thought I'd mention it.

   Linus

Re: [GIT PULL] RTC for 4.19

[Linus Torvalds]

On Mon, Aug 20, 2018 at 2:22 PM Alexandre Belloni
 wrote:
>
> Subsystem:
>  - struct rtc_task removal along with rtc_irq_register/rtc_irq_unregister

You can still find stale mentions of it by grepping for it:

 * @task: currently registered with rtc_irq_register()

which should presumably be fixed up too.

That's not holding me from doing the pull, but I thought I'd mention it.

   Linus

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Palmer Dabbelt]

On Tue, 14 Aug 2018 06:39:23 PDT (-0700), Christoph Hellwig wrote:

 SYSCALL_DEFINE3(riscv_flush_icache, uintptr_t, start, uintptr_t, end,
uintptr_t, flags)
 {
+#ifdef CONFIG_SMP
struct mm_struct *mm = current->mm;
bool local = (flags & SYS_RISCV_FLUSH_ICACHE_LOCAL) != 0;
+#endif

/* Check the reserved flags. */
if (unlikely(flags & ~SYS_RISCV_FLUSH_ICACHE_ALL))
return -EINVAL;

+   /*
+* Without CONFIG_SMP flush_icache_mm is a just a flush_icache_all(),
+* which generates unused variable warnings all over this function.
+*/
+#ifdef CONFIG_SMP
flush_icache_mm(mm, local);
+#else
+   flush_icache_all();
+#endif


Eeek.

Something like an unconditional:

flush_icache_mm(current->mm, flags & SYS_RISCV_FLUSH_ICACHE_LOCAL);

should solve those issues.

Also in the longer run we should turn the !SMP flush_icache_mm stub
into an inline function to solve this problem for all potential
callers.  Excepte that flush_icache_mm happens to be a RISC-V specific
API without any other callers.  So for now I think the above is what
I'd do, but this area has a lot of room for cleanup.


Thanks, that's a lot cleaner.  I missed this for the PR, but I'll submit a 
cleanup patch after RC1.

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Palmer Dabbelt]

On Tue, 14 Aug 2018 06:39:23 PDT (-0700), Christoph Hellwig wrote:

 SYSCALL_DEFINE3(riscv_flush_icache, uintptr_t, start, uintptr_t, end,
uintptr_t, flags)
 {
+#ifdef CONFIG_SMP
struct mm_struct *mm = current->mm;
bool local = (flags & SYS_RISCV_FLUSH_ICACHE_LOCAL) != 0;
+#endif

/* Check the reserved flags. */
if (unlikely(flags & ~SYS_RISCV_FLUSH_ICACHE_ALL))
return -EINVAL;

+   /*
+* Without CONFIG_SMP flush_icache_mm is a just a flush_icache_all(),
+* which generates unused variable warnings all over this function.
+*/
+#ifdef CONFIG_SMP
flush_icache_mm(mm, local);
+#else
+   flush_icache_all();
+#endif


Eeek.

Something like an unconditional:

flush_icache_mm(current->mm, flags & SYS_RISCV_FLUSH_ICACHE_LOCAL);

should solve those issues.

Also in the longer run we should turn the !SMP flush_icache_mm stub
into an inline function to solve this problem for all potential
callers.  Excepte that flush_icache_mm happens to be a RISC-V specific
API without any other callers.  So for now I think the above is what
I'd do, but this area has a lot of room for cleanup.


Thanks, that's a lot cleaner.  I missed this for the PR, but I'll submit a 
cleanup patch after RC1.

Re: [PATCH v3 2/2] RISC-V: Don't use a global include guard for uapi/asm/syscalls.h

[Palmer Dabbelt]

On Tue, 14 Aug 2018 06:40:27 PDT (-0700), Christoph Hellwig wrote:

index 818655b0d535..690beb002d1d 100644
--- a/arch/riscv/include/uapi/asm/syscalls.h
+++ b/arch/riscv/include/uapi/asm/syscalls.h
@@ -1,10 +1,13 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+// SPDX-License-Identifier: GPL-2.0


/* ... */  is the right style SPDX tag for headers, so please keep it
as-is.


Thanks, I didn't miss this one so I managed to fix it before the PR!

Re: [PATCH v3 2/2] RISC-V: Don't use a global include guard for uapi/asm/syscalls.h

[Palmer Dabbelt]

On Tue, 14 Aug 2018 06:40:27 PDT (-0700), Christoph Hellwig wrote:

index 818655b0d535..690beb002d1d 100644
--- a/arch/riscv/include/uapi/asm/syscalls.h
+++ b/arch/riscv/include/uapi/asm/syscalls.h
@@ -1,10 +1,13 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+// SPDX-License-Identifier: GPL-2.0


/* ... */  is the right style SPDX tag for headers, so please keep it
as-is.


Thanks, I didn't miss this one so I managed to fix it before the PR!

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Dave Hansen]

On 08/20/2018 04:14 PM, David Woodhouse wrote:
> If you need the physmap, then rather than manually mapping with 4KiB
> pages, you just switch. Having first ensured that no malicious guest or
> userspace is running on a sibling, of course.

The problem is determining when "you need the physmap".  Tycho's
patches, as I remember them basically classify pages between being
"user" pages which are accessed only via kmap() and friends and "kernel"
pages which need to be mapped all the time because they might have a
'task_struct' or a page table or a 'struct file'.

You're right that we could have a full physmap that we switch to for
kmap()-like access to user pages.  But, the real problem is
transitioning pages from kernel to user usage since it requires shooting
down the old kernel mappings for those pages in some way.

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Dave Hansen]

On 08/20/2018 04:14 PM, David Woodhouse wrote:
> If you need the physmap, then rather than manually mapping with 4KiB
> pages, you just switch. Having first ensured that no malicious guest or
> userspace is running on a sibling, of course.

The problem is determining when "you need the physmap".  Tycho's
patches, as I remember them basically classify pages between being
"user" pages which are accessed only via kmap() and friends and "kernel"
pages which need to be mapped all the time because they might have a
'task_struct' or a page table or a 'struct file'.

You're right that we could have a full physmap that we switch to for
kmap()-like access to user pages.  But, the real problem is
transitioning pages from kernel to user usage since it requires shooting
down the old kernel mappings for those pages in some way.

Re: [PATCH RESEND v1 1/5] dt-bindings: pinctrl: add wakeup capable GPIOs for SDM845

[Bjorn Andersson]

On Fri 17 Aug 12:10 PDT 2018, Lina Iyer wrote:
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
[..]
> @@ -155,11 +166,52 @@ Example:
>   tlmm: pinctrl@340 {
>   compatible = "qcom,sdm845-pinctrl";
>   reg = <0x0340 0xc0>;
> - interrupts = ;
>   gpio-controller;
>   #gpio-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
> + interrupts-extended = < GIC_SPI 208 0>,
> + < 510 0>, < 511 0>, < 512 0>, < 513 0>,
> + < 514 0>, < 515 0>, < 516 0>, < 517 0>,
> + < 518 0>, < 519 0>, < 632 0>, < 639 0>,
> + < 521 0>, < 522 0>, < 523 0>, < 524 0>,
> + < 525 0>, < 526 0>, < 527 0>, < 630 0>,
> + < 637 0>, < 529 0>, < 530 0>, < 531 0>,
> + < 532 0>, < 633 0>, < 640 0>, < 534 0>,
> + < 535 0>, < 536 0>, < 537 0>, < 538 0>,
> + < 539 0>, < 540 0>, < 541 0>, < 542 0>,
> + < 543 0>, < 544 0>, < 545 0>, < 546 0>,
> + < 547 0>, < 548 0>, < 549 0>, < 550 0>,
> + < 551 0>, < 552 0>, < 553 0>, < 554 0>,
> + < 555 0>, < 556 0>, < 557 0>, < 631 0>,
> + < 638 0>, < 559 0>, < 560 0>, < 561 0>,
> + < 562 0>, < 563 0>, < 564 0>, < 565 0>,
> + < 566 0>, < 570 0>, < 571 0>, < 572 0>,
> + < 573 0>, < 609 0>, < 610 0>, < 611 0>,
> + < 612 0>, < 613 0>, < 614 0>, < 615 0>,
> + < 617 0>, < 618 0>, < 619 0>, < 620 0>,
> + < 621 0>, < 622 0>, < 623 0>;

I would expect that there are about 80 WARN_ON() hit in the irq code
when you boot mainline with this. Have you tried that?


Looks reasonable otherwise.

Regards,
Bjorn

Re: [PATCH RESEND v1 1/5] dt-bindings: pinctrl: add wakeup capable GPIOs for SDM845

[Bjorn Andersson]

On Fri 17 Aug 12:10 PDT 2018, Lina Iyer wrote:
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
[..]
> @@ -155,11 +166,52 @@ Example:
>   tlmm: pinctrl@340 {
>   compatible = "qcom,sdm845-pinctrl";
>   reg = <0x0340 0xc0>;
> - interrupts = ;
>   gpio-controller;
>   #gpio-cells = <2>;
>   interrupt-controller;
>   #interrupt-cells = <2>;
> + interrupts-extended = < GIC_SPI 208 0>,
> + < 510 0>, < 511 0>, < 512 0>, < 513 0>,
> + < 514 0>, < 515 0>, < 516 0>, < 517 0>,
> + < 518 0>, < 519 0>, < 632 0>, < 639 0>,
> + < 521 0>, < 522 0>, < 523 0>, < 524 0>,
> + < 525 0>, < 526 0>, < 527 0>, < 630 0>,
> + < 637 0>, < 529 0>, < 530 0>, < 531 0>,
> + < 532 0>, < 633 0>, < 640 0>, < 534 0>,
> + < 535 0>, < 536 0>, < 537 0>, < 538 0>,
> + < 539 0>, < 540 0>, < 541 0>, < 542 0>,
> + < 543 0>, < 544 0>, < 545 0>, < 546 0>,
> + < 547 0>, < 548 0>, < 549 0>, < 550 0>,
> + < 551 0>, < 552 0>, < 553 0>, < 554 0>,
> + < 555 0>, < 556 0>, < 557 0>, < 631 0>,
> + < 638 0>, < 559 0>, < 560 0>, < 561 0>,
> + < 562 0>, < 563 0>, < 564 0>, < 565 0>,
> + < 566 0>, < 570 0>, < 571 0>, < 572 0>,
> + < 573 0>, < 609 0>, < 610 0>, < 611 0>,
> + < 612 0>, < 613 0>, < 614 0>, < 615 0>,
> + < 617 0>, < 618 0>, < 619 0>, < 620 0>,
> + < 621 0>, < 622 0>, < 623 0>;

I would expect that there are about 80 WARN_ON() hit in the irq code
when you boot mainline with this. Have you tried that?


Looks reasonable otherwise.

Regards,
Bjorn

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[David Woodhouse]

On Mon, 2018-08-20 at 15:59 -0700, Dave Hansen wrote:
> On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> > Since meltdown hit, I haven't worked seriously on understand and
> > implementing his suggestions, in part because it wasn't clear to me
> > what pieces of the infrastructure we might be able to re-use. Someone
> > who knows more about mm/ might be able to suggest an approach, though
> 
> Unfortunately, I'm not sure there's much of KPTI we can reuse.  KPTI
> still has a very static kernel map (well, two static kernel maps) and
> XPFO really needs a much more dynamic map.
> 
> We do have a bit of infrastructure now to do TLB flushes near the kernel
> exit point, but it's entirely for the user address space, which isn't
> affected by XPFO.

One option is to have separate kernel address spaces, both with and
without the full physmap.

If you need the physmap, then rather than manually mapping with 4KiB
pages, you just switch. Having first ensured that no malicious guest or
userspace is running on a sibling, of course.

I'm not sure it's a win, but it might be worth looking at.

smime.p7s
Description: S/MIME cryptographic signature

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[David Woodhouse]

On Mon, 2018-08-20 at 15:59 -0700, Dave Hansen wrote:
> On 08/20/2018 03:35 PM, Tycho Andersen wrote:
> > Since meltdown hit, I haven't worked seriously on understand and
> > implementing his suggestions, in part because it wasn't clear to me
> > what pieces of the infrastructure we might be able to re-use. Someone
> > who knows more about mm/ might be able to suggest an approach, though
> 
> Unfortunately, I'm not sure there's much of KPTI we can reuse.  KPTI
> still has a very static kernel map (well, two static kernel maps) and
> XPFO really needs a much more dynamic map.
> 
> We do have a bit of infrastructure now to do TLB flushes near the kernel
> exit point, but it's entirely for the user address space, which isn't
> affected by XPFO.

One option is to have separate kernel address spaces, both with and
without the full physmap.

If you need the physmap, then rather than manually mapping with 4KiB
pages, you just switch. Having first ensured that no malicious guest or
userspace is running on a sibling, of course.

I'm not sure it's a win, but it might be worth looking at.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] dt-bindings: riscv,cpu-intc: Cleanups from a missed review

[Atish Patra]

On 8/20/18 4:01 PM, Palmer Dabbelt wrote:

I managed to miss one of Rob's code reviews on the mailing list
.
The patch has already been merged, so I'm submitting a fixup.

Sorry!

Fixes: b67bc7cb4088 ("dt-bindings: interrupt-controller: RISC-V local interrupt 
controller")
Cc: Rob Herring 
Cc: Christoph Hellwig 
Cc: Karsten Merker 
Signed-off-by: Palmer Dabbelt 
---
  .../bindings/interrupt-controller/riscv,cpu-intc.txt   | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
index b0a8af51c388..265b223cd978 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -11,7 +11,7 @@ The RISC-V supervisor ISA manual specifies three interrupt 
sources that are
  attached to every HLIC: software interrupts, the timer interrupt, and external
  interrupts.  Software interrupts are used to send IPIs between cores.  The
  timer interrupt comes from an architecturally mandated real-time timer that is
-controller via Supervisor Binary Interface (SBI) calls and CSR reads.  External
+controlled via Supervisor Binary Interface (SBI) calls and CSR reads.  External
  interrupts connect all other device interrupts to the HLIC, which are routed
  via the platform-level interrupt controller (PLIC).
  
@@ -25,7 +25,15 @@ in the system.
  
  Required properties:

  - compatible : "riscv,cpu-intc"


Since this is a fix up patch, we should update the compatible string 
with the sifive specific one as well. no?


Regards,
Atish

-- #interrupt-cells : should be <1>
+- #interrupt-cells : should be <1>.  The interrupt sources are defined by the
+  RISC-V supervisor ISA manual, with only the following three interrupts being
+  defined for supervisor mode:
+- Source 1 is the supervisor software interrupt, which can be sent by an 
SBI
+  call and is reserved for use by software.
+- Source 5 is the supervisor timer interrupt, which can be configured by
+  SBI calls and implements a one-shot timer.
+- Source 9 is the supervisor external interrupt, which chains to all other
+  device interrupts.
  - interrupt-controller : Identifies the node as an interrupt controller
  
  Furthermore, this interrupt-controller MUST be embedded inside the cpu

@@ -38,7 +46,7 @@ An example device tree entry for a HLIC is show below.
...
cpu1-intc: interrupt-controller {
#interrupt-cells = <1>;
-   compatible = "riscv,cpu-intc", 
"sifive,fu540-c000-cpu-intc";
+   compatible = "sifive,fu540-c000-cpu-intc", 
"riscv,cpu-intc";
interrupt-controller;
};
};

Re: [PATCH] dt-bindings: riscv,cpu-intc: Cleanups from a missed review

[Atish Patra]

On 8/20/18 4:01 PM, Palmer Dabbelt wrote:

I managed to miss one of Rob's code reviews on the mailing list
.
The patch has already been merged, so I'm submitting a fixup.

Sorry!

Fixes: b67bc7cb4088 ("dt-bindings: interrupt-controller: RISC-V local interrupt 
controller")
Cc: Rob Herring 
Cc: Christoph Hellwig 
Cc: Karsten Merker 
Signed-off-by: Palmer Dabbelt 
---
  .../bindings/interrupt-controller/riscv,cpu-intc.txt   | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
index b0a8af51c388..265b223cd978 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -11,7 +11,7 @@ The RISC-V supervisor ISA manual specifies three interrupt 
sources that are
  attached to every HLIC: software interrupts, the timer interrupt, and external
  interrupts.  Software interrupts are used to send IPIs between cores.  The
  timer interrupt comes from an architecturally mandated real-time timer that is
-controller via Supervisor Binary Interface (SBI) calls and CSR reads.  External
+controlled via Supervisor Binary Interface (SBI) calls and CSR reads.  External
  interrupts connect all other device interrupts to the HLIC, which are routed
  via the platform-level interrupt controller (PLIC).
  
@@ -25,7 +25,15 @@ in the system.
  
  Required properties:

  - compatible : "riscv,cpu-intc"


Since this is a fix up patch, we should update the compatible string 
with the sifive specific one as well. no?


Regards,
Atish

-- #interrupt-cells : should be <1>
+- #interrupt-cells : should be <1>.  The interrupt sources are defined by the
+  RISC-V supervisor ISA manual, with only the following three interrupts being
+  defined for supervisor mode:
+- Source 1 is the supervisor software interrupt, which can be sent by an 
SBI
+  call and is reserved for use by software.
+- Source 5 is the supervisor timer interrupt, which can be configured by
+  SBI calls and implements a one-shot timer.
+- Source 9 is the supervisor external interrupt, which chains to all other
+  device interrupts.
  - interrupt-controller : Identifies the node as an interrupt controller
  
  Furthermore, this interrupt-controller MUST be embedded inside the cpu

@@ -38,7 +46,7 @@ An example device tree entry for a HLIC is show below.
...
cpu1-intc: interrupt-controller {
#interrupt-cells = <1>;
-   compatible = "riscv,cpu-intc", 
"sifive,fu540-c000-cpu-intc";
+   compatible = "sifive,fu540-c000-cpu-intc", 
"riscv,cpu-intc";
interrupt-controller;
};
};

Enumeration issue with QCA9005 AR9462

[Bjorn Helgaas]

mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
wifi device was present at boot, but disappeared after suspend/resume.

He/she also tested a recent kernel (5c60a7389d79, from Thu Aug 16),
where the suspend/resume problem doesn't seem to happen, but the wifi
device isn't enumerated correctly at boot-time.

  pci :00:1c.3: PCIe Root Port to [bus 03-07]
  pci :03:00.0: [1ae9:0101] PCIe Switch Upstream Port to [bus 04-07]
  pci :04:00.0: [1ae9:0200] PCIe Switch Downstream Port to [bus 05]
  pci :05:00.0: [168c:0034] QCA9005 AR9462 wifi NIC

These messages are extracted from [2]:

[0.928714] pciehp :04:00.0:pcie204: Slot #0 AttnBtn- PwrCtrl- MRL- 
AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[0.928752] pciehp :04:00.0:pcie204: Slot(0-1): Card not present
[0.928811] pciehp :04:00.0:pcie204: Slot(0-1): Link Up
[0.928815] pciehp :04:00.0:pcie204: Slot(0-1): No adapter

After manually executing:

  echo 1 > 
/sys/devices/pci\:00/\:00\:1c.3/\:03\:00.0/\:04\:00.0/rescan

the wifi NIC is discovered correctly:

[  114.649896] pci :05:00.0: [168c:0034] type 00 class 0x028000
[  114.649977] pci :05:00.0: reg 0x10: [mem 0xf740-0xf747 64bit]
[  114.650090] pci :05:00.0: reg 0x30: [mem 0xf748-0xf748 pref]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=200839
[2] https://bugzilla.kernel.org/attachment.cgi?id=277923

Enumeration issue with QCA9005 AR9462

[Bjorn Helgaas]

mmyan...@gmail.com reported a problem [1]: on v4.17, a QCA9005 AR9462
wifi device was present at boot, but disappeared after suspend/resume.

He/she also tested a recent kernel (5c60a7389d79, from Thu Aug 16),
where the suspend/resume problem doesn't seem to happen, but the wifi
device isn't enumerated correctly at boot-time.

  pci :00:1c.3: PCIe Root Port to [bus 03-07]
  pci :03:00.0: [1ae9:0101] PCIe Switch Upstream Port to [bus 04-07]
  pci :04:00.0: [1ae9:0200] PCIe Switch Downstream Port to [bus 05]
  pci :05:00.0: [168c:0034] QCA9005 AR9462 wifi NIC

These messages are extracted from [2]:

[0.928714] pciehp :04:00.0:pcie204: Slot #0 AttnBtn- PwrCtrl- MRL- 
AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
[0.928752] pciehp :04:00.0:pcie204: Slot(0-1): Card not present
[0.928811] pciehp :04:00.0:pcie204: Slot(0-1): Link Up
[0.928815] pciehp :04:00.0:pcie204: Slot(0-1): No adapter

After manually executing:

  echo 1 > 
/sys/devices/pci\:00/\:00\:1c.3/\:03\:00.0/\:04\:00.0/rescan

the wifi NIC is discovered correctly:

[  114.649896] pci :05:00.0: [168c:0034] type 00 class 0x028000
[  114.649977] pci :05:00.0: reg 0x10: [mem 0xf740-0xf747 64bit]
[  114.650090] pci :05:00.0: reg 0x30: [mem 0xf748-0xf748 pref]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=200839
[2] https://bugzilla.kernel.org/attachment.cgi?id=277923

[PATCH] x86/mm: Simplify p[g4um]d_page() macros

[Andi Kleen]

From: Tom Lendacky 

[backport of fd7e315988b78 from mainline for stable to fix stable crashes
suggested by Michael Hocko. Should be applied to 4.9 and 4.4.]

Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.

Signed-off-by: Tom Lendacky 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brijesh Singh 
Cc: Dave Young 
Cc: Dmitry Vyukov 
Cc: Jonathan Corbet 
Cc: Konrad Rzeszutek Wilk 
Cc: Larry Woodman 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Toshimitsu Kani 
Cc: kasan-...@googlegroups.com
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link: 
http://lkml.kernel.org/r/e61eb533a6d0aac941db2723d8aa63ef6b882dee.1500319216.git.thomas.lenda...@amd.com
[Backported to 4.9 stable by AK, suggested by Michael Hocko]
Signed-off-by: Ingo Molnar 
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/pgtable.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4de6c282c02a..68a55273ce0f 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -173,6 +173,11 @@ static inline unsigned long pud_pfn(pud_t pud)
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+   return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)  pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)
@@ -578,8 +583,7 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pmd_page(pmd)  \
-   pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd)  pfn_to_page(pmd_pfn(pmd))
 
 /*
  * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -647,8 +651,7 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pud_page(pud)  \
-   pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
 
 /* Find an entry in the second-level page table.. */
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -688,7 +691,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pgd_page(pgd)  pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd)  pfn_to_page(pgd_pfn(pgd))
 
 /* to find an entry in a page-table-directory. */
 static inline unsigned long pud_index(unsigned long address)
-- 
2.17.1

[PATCH] x86/mm: Simplify p[g4um]d_page() macros

[Andi Kleen]

From: Tom Lendacky 

[backport of fd7e315988b78 from mainline for stable to fix stable crashes
suggested by Michael Hocko. Should be applied to 4.9 and 4.4.]

Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.

Signed-off-by: Tom Lendacky 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brijesh Singh 
Cc: Dave Young 
Cc: Dmitry Vyukov 
Cc: Jonathan Corbet 
Cc: Konrad Rzeszutek Wilk 
Cc: Larry Woodman 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Toshimitsu Kani 
Cc: kasan-...@googlegroups.com
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link: 
http://lkml.kernel.org/r/e61eb533a6d0aac941db2723d8aa63ef6b882dee.1500319216.git.thomas.lenda...@amd.com
[Backported to 4.9 stable by AK, suggested by Michael Hocko]
Signed-off-by: Ingo Molnar 
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/pgtable.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4de6c282c02a..68a55273ce0f 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -173,6 +173,11 @@ static inline unsigned long pud_pfn(pud_t pud)
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+   return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)  pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)
@@ -578,8 +583,7 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pmd_page(pmd)  \
-   pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd)  pfn_to_page(pmd_pfn(pmd))
 
 /*
  * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -647,8 +651,7 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pud_page(pud)  \
-   pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
 
 /* Find an entry in the second-level page table.. */
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -688,7 +691,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pgd_page(pgd)  pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd)  pfn_to_page(pgd_pfn(pgd))
 
 /* to find an entry in a page-table-directory. */
 static inline unsigned long pud_index(unsigned long address)
-- 
2.17.1