Re: [PATCH 07/14] qcom: mtd: nand: support for passing flags in transfer functions

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

The BAM has multiple flags to control the transfer. This patch
adds flags parameter in register and data transfer functions and
modifies all these function call with appropriate flags.

Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 114 --
  1 file changed, 65 insertions(+), 49 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 7042a65..65c9059 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -170,6 +170,14 @@
  #define   ECC_BCH_4BITBIT(2)
  #define   ECC_BCH_8BITBIT(3)
  
+/* Flags used for BAM DMA desc preparation*/

+/* Don't set the EOT in current tx sgl */
+#define NAND_BAM_NO_EOT(0x0001)
+/* Set the NWD flag in current sgl */
+#define NAND_BAM_NWD   (0x0002)
+/* Finish writing in the current sgl and start writing in another sgl */
+#define NAND_BAM_NEXT_SGL  (0x0004)
+
  #define QPIC_PER_CW_MAX_CMD_ELEMENTS  (32)
  #define QPIC_PER_CW_MAX_CMD_SGL   (32)
  #define QPIC_PER_CW_MAX_DATA_SGL  (8)
@@ -712,7 +720,7 @@ static int prep_dma_desc(struct qcom_nand_controller 
*nandc, bool read,
   * @num_regs: number of registers to read
   */
  static int read_reg_dma(struct qcom_nand_controller *nandc, int first,
-   int num_regs)
+   int num_regs, unsigned int flags)
  {
bool flow_control = false;
void *vaddr;
@@ -736,7 +744,7 @@ static int read_reg_dma(struct qcom_nand_controller *nandc, 
int first,
   * @num_regs: number of registers to write
   */
  static int write_reg_dma(struct qcom_nand_controller *nandc, int first,
-int num_regs)
+int num_regs, unsigned int flags)


Adding flags to read_reg_dma and write_reg_dma is making things a bit messy. I 
can't
think of a better way to share the code either, though.

One thing we could consider doing is something like below. I don't know if it 
would
make things more legible.

union nand_dma_props {
bool adm_flow_control;
unsigned int bam_flags;
};

config_cw_read()
{
union nand_dma_props dma_props;
...
...

if (is_bam)
dma_props.bam_flags = NAND_BAM_NWD;
else
dma_props.adm_flow_control = false;

write_reg_dma(nandc, NAND_EXEC_CMD, 1, _props);
...
...
}

Thanks,
Archit


  {
bool flow_control = false;
struct nandc_regs *regs = nandc->regs;
@@ -748,6 +756,9 @@ static int write_reg_dma(struct qcom_nand_controller 
*nandc, int first,
if (first == NAND_FLASH_CMD)
flow_control = true;
  
+	if (first == NAND_EXEC_CMD)

+   flags |= NAND_BAM_NWD;
+
if (first == NAND_DEV_CMD1_RESTORE)
first = NAND_DEV_CMD1;
  
@@ -768,7 +779,7 @@ static int write_reg_dma(struct qcom_nand_controller *nandc, int first,

   * @size: DMA transaction size in bytes
   */
  static int read_data_dma(struct qcom_nand_controller *nandc, int reg_off,
-const u8 *vaddr, int size)
+const u8 *vaddr, int size, unsigned int flags)
  {
return prep_dma_desc(nandc, true, reg_off, vaddr, size, false);
  }
@@ -782,7 +793,7 @@ static int read_data_dma(struct qcom_nand_controller 
*nandc, int reg_off,
   * @size: DMA transaction size in bytes
   */
  static int write_data_dma(struct qcom_nand_controller *nandc, int reg_off,
- const u8 *vaddr, int size)
+ const u8 *vaddr, int size, unsigned int flags)
  {
return prep_dma_desc(nandc, false, reg_off, vaddr, size, false);
  }
@@ -793,14 +804,16 @@ static int write_data_dma(struct qcom_nand_controller 
*nandc, int reg_off,
   */
  static void config_cw_read(struct qcom_nand_controller *nandc)
  {
-   write_reg_dma(nandc, NAND_FLASH_CMD, 3);
-   write_reg_dma(nandc, NAND_DEV0_CFG0, 3);
-   write_reg_dma(nandc, NAND_EBI2_ECC_BUF_CFG, 1);
+   write_reg_dma(nandc, NAND_FLASH_CMD, 3, 0);
+   write_reg_dma(nandc, NAND_DEV0_CFG0, 3, 0);
+   write_reg_dma(nandc, NAND_EBI2_ECC_BUF_CFG, 1, 0);
  
-	write_reg_dma(nandc, NAND_EXEC_CMD, 1);

+   write_reg_dma(nandc, NAND_EXEC_CMD, 1,
+ NAND_BAM_NWD | NAND_BAM_NEXT_SGL);
  
-	read_reg_dma(nandc, NAND_FLASH_STATUS, 2);

-   read_reg_dma(nandc, NAND_ERASED_CW_DETECT_STATUS, 1);
+   read_reg_dma(nandc, NAND_FLASH_STATUS, 2, 0);
+   read_reg_dma(nandc, NAND_ERASED_CW_DETECT_STATUS, 1,
+NAND_BAM_NEXT_SGL);
  }
  
  /*

@@ -809,19 +822,20 @@ static void config_cw_read(struct qcom_nand_controller 
*nandc)
   */
  static void config_cw_write_pre(struct qcom_nand_controller *nandc)
  {
-   write_reg_dma(nandc, NAND_FLASH_CMD, 

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Jisheng Zhang]

On Mon, 3 Jul 2017 08:27:04 -0500 wrote:

> [+cc Jingoo, Joao]
> 
> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
> > On 3 July 2017 at 00:18, Bjorn Helgaas  wrote:  
> > > On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:  
> > >> This driver is required to work around several hardware bugs
> > >> in the PCIe controller.
> > >>
> > >> NB: Revision 1 does not support legacy interrupts, or IO space.  
> > >
> > > I had to apply these manually because of conflicts in Kconfig and
> > > Makefile.  What are these based on?  Easiest for me is if you base
> > > them on the current -rc1 tag.
> > >  
> > >> Signed-off-by: Marc Gonzalez 
> > >> ---
> > >>  drivers/pci/host/Kconfig  |   8 +++
> > >>  drivers/pci/host/Makefile |   1 +
> > >>  drivers/pci/host/pcie-tango.c | 164 
> > >> ++
> > >>  include/linux/pci_ids.h   |   2 +
> > >>  4 files changed, 175 insertions(+)
> > >>  create mode 100644 drivers/pci/host/pcie-tango.c
> > >>  
> > [..]  
> > >> + /*
> > >> +  * QUIRK #2
> > >> +  * Unfortunately, config and mem spaces are muxed.
> > >> +  * Linux does not support such a setting, since drivers are free
> > >> +  * to access mem space directly, at any time.
> > >> +  * Therefore, we can only PRAY that config and mem space accesses
> > >> +  * NEVER occur concurrently.
> > >> +  */
> > >> + writel_relaxed(1, pcie->mux);
> > >> + ret = pci_generic_config_read(bus, devfn, where, size, val);
> > >> + writel_relaxed(0, pcie->mux);  
> > >
> > > I'm very hesitant about this.  When people stress this, we're going to
> > > get reports of data corruption.  Even with the disclaimer below, I
> > > don't feel good about this.  Adding the driver is an implicit claim
> > > that we support the device, but we know it can't be made reliable.  
> > 
> > I noticed that the Synopsys driver suffers from a similar issue: in
> > dw_pcie_rd_other_conf(), it happily reprograms the outbound I/O window
> > to perform a config space access, and switches it back to I/O space
> > afterwards (unless it has more than 2 viewports, in which case it uses
> > dedicated windows for I/O space and config space)  
> 
> That doesn't sound good.  Jingoo, Joao?  I remember some discussion
> about this, but not the details.
> 
> I/O accesses use wrappers (inb(), etc), so there's at least the
> possibility of a mutex to serialize them with respect to config
> accesses.
> 

IIRC, for 2 viewports, we don't need to worry about the config space
access, because config space access is serialized by pci_lock; We
do have race between config space and io space. But the accessing config
space and io space at the same time is rare. And the PCIe EPs which
has io space are rare too, supporting these EPs are not the potential
target of those platforms with 2 viewports.

Thanks,
Jisheng

Re: [PATCH] x86/platform/uv/BAU: minor cleanup, make some local functions static

[Thomas Gleixner]

On Tue, 4 Jul 2017, Dou Liyang wrote:
> At 07/03/2017 10:22 PM, Colin King wrote:
> > -int normal_busy(struct bau_control *bcp)
> > +static int normal_busy(struct bau_control *bcp)
> 
> In my opinion, there is no need to mark *normal_busy* static, remove it
> directly.
> 
> the commit c5d35d399e68(x86/UV2: Work around BAU bug) add it to
> handle_uv2_busy(), but the handle_uv2_busy() is rewritten now. the
> normal_busy is unused, can be remove.

Correct.

> By the way, there are also an other function named
> uv_bau_message_interrupt() can be remove.

Not so much.

# git grep uv_bau_message_interrupt arch/x86/
arch/x86/entry/entry_64.S:apicinterrupt3 UV_BAU_MESSAGE 
uv_bau_message_intr1uv_bau_message_interrupt
arch/x86/platform/uv/tlb_uv.c:void uv_bau_message_interrupt(struct pt_regs 
*regs)

Thanks,

tglx

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 3 July 2017 at 23:50, Sebastian Reichel
 wrote:
> Hi,
>
> On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown 
>> Signed-off-by: Baolin Wang 
>
> Missing DT binding documentation, otherwise fine with me.
> Would be nice to convert existing drivers:
>
> $ git grep -l extcon -- drivers/power/supply
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c

I'll create new patches with adding the DT binding documentation if
there are no objections for USB phy modification, moreover I will help
to convert these drivers you listed. Thanks.

>
> -- Sebastian
>
>> ---
>>  drivers/power/supply/wm831x_power.c |   61 
>> +++
>>  1 file changed, 61 insertions(+)
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..3e3480708 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (IS_ERR(power->usb_phy)) {
>> + ret = PTR_ERR(power->usb_phy);
>> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy,
>> + >usb_notify);
>> + if (ret) {
>> + dev_err(>dev, "Failed to register notifier: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>>   return ret;
>>
>>  err_bat_irq:
>> @@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
>> *pdev)
>>   struct wm831x *wm831x = wm831x_power->wm831x;
>>   int irq, i;
>>
>> + if (wm831x_power->usb_phy) {
>> + usb_unregister_notifier(wm831x_power->usb_phy,
>> + _power->usb_notify);
>> + }
>> +
>>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>>   irq = wm831x_irq(wm831x,
>>platform_get_irq_byname(pdev,
>> --
>> 1.7.9.5
>>



-- 
Baolin.wang
Best Regards

Re: [PATCH RFC 1/2] media: V3s: Add support for Allwinner CSI.

[Yong]

On Mon, 3 Jul 2017 13:25:21 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Mon, Jul 03, 2017 at 06:59:52PM +0800, Yong wrote:
> > > > +   select VIDEOBUF2_DMA_CONTIG
> > > > +   select REGMAP_MMIO
> > > > +   ---help---
> > > > +  Support for the Allwinner Camera Sensor Interface Controller.
> > > 
> > > This controller is the same for all Allwinner SoC models?
> > 
> > No.
> > I will change the Kconfig and Makefile.
> 
> This is basically a design that has been introduced in the A31 (sun6i
> family). I guess we should just call the driver and Kconfig symbols
> sun6i_csi (even though we don't support it yet). It also used on the
> A23, A33, A80, A83T, H3, and probably the H5 and A64.
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Thanks for the advice. That's good.
My purpose is to make the code reusable. People working on other
Allwinner SoC could easily make their CSI working by just filling the
SoC specific code. But I'm not familiar with other Allwinner SoCs 
except V3s. I hope to get more advice.

Re: [PATCH v6 10/18] xen/pvcalls: implement listen command

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Call inet_listen to implement the listen command.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

Re: [PATCH 4.9 000/172] 4.9.36-stable review

[Greg Kroah-Hartman]

On Mon, Jul 03, 2017 at 12:51:32PM -0700, Guenter Roeck wrote:
> On 07/03/2017 06:33 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.36 release.
> > There are 172 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Jul  5 13:33:25 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 122 pass: 122 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing this, and the other trees, and letting me know.

greg k-h

Re: [PATCH 4.4 000/101] 4.4.76-stable review

[Greg Kroah-Hartman]

On Mon, Jul 03, 2017 at 12:37:35PM -0700, Guenter Roeck wrote:
> On 07/03/2017 06:34 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.76 release.
> > There are 101 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Jul  5 13:32:59 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 143 fail: 2
> Failed builds:
>   arm64:allnoconfig
>   arm64:allmodconfig
> 
> Qemu test results:
>   total: 115 pass: 111 fail: 4
> Failed tests:
>   arm64:virt:smp:defconfig
>   arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
>   arm64:virt:nosmp:defconfig
>   arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
> 
> Details are available at http://kerneltests.org/builders.
> 
> Bisect points to commit 0aebadf7b7c9 ("arm64: assembler: make adr_l work
> in modules under KASLR" as the culprit for the build failures. Reverting
> that patch fixes the problem.

Thanks for the notice, I've now dropped that patch, it was my fault,
shouldn't have backported it to 4.4-stable.

greg k-h

Re: [PATCH v6 02/18] xen/pvcalls: introduce the pvcalls xenbus backend

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Introduce a xenbus backend for the pvcalls protocol, as defined by
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
> 
> This patch only adds the stubs, the code will be added by the following
> patches.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

[PATCH v2 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

[Baoquan He]

Our customer reported that Kernel text may be located on non-mirror
region (movable zone) when both address range mirroring feature and
KASLR are enabled.

The functions of address range mirroring feature are as follows.
- The physical memory region whose descriptors in EFI memory map have
  EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are mirrored
- The function arranges such mirror region into normal zone and other region
  into movable zone in order to locate kernel code and data on mirror region

So we need restrict kernel to be located inside mirror regions if it
is existed.

The method is very simple. If efi is enabled, just iterate all efi
memory map and pick mirror region to process for adding candidate
of slot. If efi disabled or no mirror region existed, still process
e820 memory map. This won't bring much efficiency loss, at worst we
just go through all efi memory maps and found no mirror.

v1->v2:
  Removed debug code.

  Taku suggested that we should put kernel to mirrored region always
  whether or not "kernelcore=mirror" is specified since kernel text is
  important and mirrored region is reliable.

  Change code according to kbuild report and Chao Fan's comment.

Test:
Chao has tested the v1 (RFC patchset) 100 times. And he said in the 100
times, 50 times are with this patchset applied, 50 times are without it.
The test result showed the v1 patchset works very well.

Baoquan He (2):
  x86/boot/KASLR: Adapt process_e820_entry for any type of memory entry
  x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

 arch/x86/boot/compressed/kaslr.c | 108 +--
 1 file changed, 82 insertions(+), 26 deletions(-)

-- 
2.5.5

Re: [PATCH] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Kalle Valo  [170703 04:30]:
> "Reizer, Eyal"  writes:
> 
> > When working with wl18xx the nvs file is used for defining an alternate
> > mac address and override the default mac address that is stored inside
> > the wl18xx chip.
> > update the structure field with the same default nvs file name that has
> > been used in the past, otherwise userspace backward compatibility is
> > broken when upgrading from older kernels, as the alternate mac address
> > would not be read from the nvs that is already present in the file system
> > (lib/firmware/ti-connectivity/wl1271-nvs.bin) causing mac address change
> > of the wlan interface.
> >
> > Signed-off-by: Eyal Reizer 
> 
> Should we also cc stable? And a Fixes line would be nice.

Argh this mess again. I think there are few things to consider here. What
about booting the same rootfs on multiple devices for example with NFSroot?

Not sure if this really is a regression as we've always had a bogus
wl1271-nvs.bin in linux-firmware.git. Sure would be nice to fix it,
but going back to using a generic wl1271-nvs.bin sure does not seem
like a good long term fix to me :)

Isn't the nvs file supposed to be device specific? If so, we should not
provide it in linux-firmware.git at all because of the issues it causes..

And since it's provided, how are people supposed to know to remove it
from their file system and replace it with something board specific?

Maybe add a check to first try to find wl18xx-nvs.bin if it exists (and
not add it to linux-firmware.git), and if not found, then fall back to
wl1271-nvs.bin, but only if it's not the bogus generic file.. Produce
a warning if the bogux linux-firmware.git wl1271-nvs.bin is being used..

Regards,

Tony

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[Christoffer Dall]

Hi Dongjiu,

On Tue, Jul 04, 2017 at 12:46:23PM +0800, gengdongjiu wrote:
> Hi Christoffer,
>   thanks for the review.
> 
> 
> On 2017/7/3 16:39, Christoffer Dall wrote:
> > Hi Dongjiu,
> > 
> > On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
> >> when SError happen, kvm notifies user space to record the CPER,
> >> user space specifies and passes the contents of ESR_EL1 on taking
> >> a virtual SError interrupt to KVM, KVM enables virtual system
> >> error or asynchronous abort with this specifies syndrome. This
> >> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
> >> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
> >> HCR_EL2.VSE injects an SError. This register is added by the
> >> RAS Extensions.
> > 
> > This commit message is confusing and doesn't help me understand the
> > patch.
> (1) what is the rationale for the guest OS SError interrupt(SEI) handling in 
> the RAS solution?
>   you can refer to document: "RAS_Extension_PRD03-PRDC-010953-32-0, 6.5.3 
> Example software sequences"
>   a). In the firmware-first RAS solution, when guest OS happen a SError 
> interrupt (SEI), it will firstly trap to EL3(SCR_EL3.EA = 1);
>   b). The firmware logs, triages, and delegates the error exception to the 
> hypervisor. As the error came from guest OS  EL1, firmware
>   does by faking an SError interrupt exception entry to EL2.
>   c). Control transfers to the hypervisor's delegated error recovery 
> agent.Because HCR_EL2.AMO is set to 1, the hypervisor can use a
>   Virtual SError interrupt to delegate an asynchronous abort to EL1, by 
> setting HCR_EL2.VSE to 1 and using VESR_EL2 to pass syndrome.
> 
> (2) what is this patch mainly do?
>   As mentioned above, the hypervisor needs to enable virtual SError and pass 
> the virtual syndrome to the guest OS.
> 
>   a). when Control transfers to the hypervisor from firmware by faking an 
> SError interrupt, the hypervisor delivered the syndrome_info(esr_el2) and
>   host VA address( Qemu translate this VA address to the virtual machine 
> physical address(IPA)) using below new added "serror_intr" struct.
>   /* KVM_EXIT_SERROR_INTR */
>   struct {
>   __u32 syndrome_info;
>   __u64 address;
>   } serror_intr;
> 
>   b). Qemu gets the address(host VA) delivered by KVM, translate this host VA 
> address to virtual machine physical address(IPA), and runtime record this 
> virtual
>  machine physical address(IPA) to the guest OS's APEI table.
> 
>   c). Qemu gets the syndrome_info delivered by KVM, it refers to this 
> syndrome value(but can be different from it) to specify the virtual SError 
> interrupt's syndrome through setting VESR_EL2.
> 
> the vsesr_el2 is armv8.2 register, its explanation can be found in 
> "RAS_Extension_PRD03-PRDC-010953-33-0, 5.6.18 VSESR_EL2, Virtual SError 
> Exception Syndrome Register"
> 
>   >>The VSESR_EL2 characteristics are:
>   >>Purpose:
>   >>Provides the syndrome value reported to software on taking a virtual 
> SError interrupt exception:
>   >>  — If the virtual SError interrupt is taken to EL1 using AArch64 
> then VSESR_EL2 provides the
>   >>syndrome value reported in ESR_EL1.
>   >>  — If the virtual SError interrupt is taken to EL1 using AArch32 
> then VSESR_EL2 provides the
>   >>syndrome values reported in DFSR.{AET, ExT} and the remainder 
> of the DFSR is set as
>   >>   defined by VMSAv8-32.
> 
>  so in the KVM, I added a new IOCTL(#define KVM_ARM_SEI  _IO(KVMIO,  
> 0xb8)) to pass the virtual SError syndrome value specified by Qemu and enable 
> a virtual System Error.
> 
> 
>  d). when world switch to guest OS, guest OS will happen virtual SError(this 
> virtual SError can not be route to EL3 firmware), guest OS uses the specified 
> syndrome value to do the recovery and
>  parses the guest OS CPER which is dynamically recorded by the Qemu in 
> the APEI table .
> 
> 

Please format the text nicely, and try to simplify the message when
resubmitting these patches.  I hope it will be easier for you to write
a meaningful commit message if you split these patches into multiple
ones.

One specific thing currently lacking from the commit message is a
discussion of why this API is needed in the first place - why can't we
reuse KVM_SET_ONE_REG, for example.

> 
> > 
> > I think this patch is trying to do too many things.  I suggest you split
> > the patch into (at least) one patch that captures exception information
> > from the world-switch path, one patch that deals with the new exit
> > reason, and finally a patch with the new ioctl.  That way you can write
> > a commit message for each patch describing first what the patch does,
> > and then why this is a good idea.
>   Ok, thanks for the good suggestion.
> 
> > 
> > Neverthess, I added some random comments below.
> > 
> >>
> >> Changes since v3:
> >> (1) Move 

Re: [PATCH 1/1] bridge: mdb: report complete_info ptr as not a kmemleak

[David Miller]

From: Eduardo Valentin 
Date: Mon, 3 Jul 2017 10:06:34 -0700

> We currently get the following kmemleak report:
 ...
> This patch flags the complete_info ptr object as not a leak as it will
> get freed when .complete_priv() is called,

We don't call .complete_priv().  We call .complete().

 for the br mdb case, it
> will be freed at br_mdb_complete().
> 
> Cc: stable  # v4.9+
> Reviewed-by: Vallish Vaidyeshwara 
> Signed-off-by: Eduardo Valentin 

I don't understand why kmemleak cannot see this.

We store the pointer globally when we do the switchdev_port_obv_add()
call and it should be able to see that.

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

[Peter Zijlstra]

On Fri, Jun 30, 2017 at 06:10:35AM -0700, tip-bot for Gustavo A. R. Silva wrote:
> Commit-ID:  72298e5c92c50edd8cb7cfda4519483ce65fa166
> Gitweb: http://git.kernel.org/tip/72298e5c92c50edd8cb7cfda4519483ce65fa166
> Author: Gustavo A. R. Silva 
> AuthorDate: Thu, 29 Jun 2017 13:41:28 -0500
> Committer:  Ingo Molnar 
> CommitDate: Fri, 30 Jun 2017 09:37:59 +0200
> 
> sched/cputime: Refactor the cputime_adjust() code
> 
> Address a Coverity false positive, which is caused by overly
> convoluted code:
> 
> Value assigned to variable 'utime' at line 619:utime = rtime;
> is overwritten at line 642:utime = rtime - stime; before it
> can be used. This makes such variable assignment useless.
> 
> Remove this variable assignment and refactor the code related.
> 
> Addresses-Coverity-ID: 1371643
> Signed-off-by: Gustavo A. R. Silva 
> Cc: Frans Klaver 
> Cc: Frederic Weisbecker 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Stanislaw Gruszka 
> Cc: Thomas Gleixner 
> Cc: Wanpeng Li 
> Link: http://lkml.kernel.org/r/20170629184128.GA5271@embeddedgus
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/cputime.c | 16 +---
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index aea3135..67c70e2 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -615,19 +615,13 @@ static void cputime_adjust(struct task_cputime *curr,
>* userspace. Once a task gets some ticks, the monotonicy code at
>* 'update' will ensure things converge to the observed ratio.
>*/
> - if (stime == 0) {
> - utime = rtime;
> - goto update;
> + if (stime != 0) {
> + if (utime == 0)
> + stime = rtime;
> + else
> + stime = scale_stime(stime, rtime, stime + utime);
>   }
>  
> - if (utime == 0) {
> - stime = rtime;
> - goto update;
> - }
> -
> - stime = scale_stime(stime, rtime, stime + utime);
> -
> -update:
>   /*
>* Make sure stime doesn't go backwards; this preserves monotonicity
>* for utime because rtime is monotonic.


Argh, no... That code was perfectly fine. The new code otoh is
convoluted crap.

It had the form:

if (exception1)
  deal with exception1

if (execption2)
  deal with exception2

do normal stuff

Which is as simple and straight forward as it gets.

The new code otoh reads like:

if (!exception1) {
if (exception2)
  deal with exception 2
else
  do normal stuff
}

which is absolute shit.

So NAK on this.

[PATCH] genirq/debugfs: fix build for !CONFIG_IRQ_DOMAIN

[Sebastian Ott]

Fix this build error:

kernel/irq/internals.h:440:20: error: inlining failed in call to always_inline
  'irq_domain_debugfs_init': function body not available
kernel/irq/debugfs.c:202:2: note: called from here
  irq_domain_debugfs_init(root_dir);
  ^

Signed-off-by: Sebastian Ott 
---
 kernel/irq/internals.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 9da14d1..dbfba99 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -437,7 +437,9 @@ static inline void irq_remove_debugfs_entry(struct irq_desc 
*desc)
 # ifdef CONFIG_IRQ_DOMAIN
 void irq_domain_debugfs_init(struct dentry *root);
 # else
-static inline void irq_domain_debugfs_init(struct dentry *root);
+static inline void irq_domain_debugfs_init(struct dentry *root)
+{
+}
 # endif
 #else /* CONFIG_GENERIC_IRQ_DEBUGFS */
 static inline void irq_add_debugfs_entry(unsigned int irq, struct irq_desc *d)
-- 
2.7.4

Re: [PATCH v1 1/1] KVM: trigger uevents when starting or stopping a VM

[Christian Borntraeger]

On 07/04/2017 11:23 AM, Paolo Bonzini wrote:
> 
> 
> On 04/07/2017 11:03, Claudio Imbrenda wrote:
>> This patch adds a few lines to the KVM common code to fire a
>> KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
>> carries two environment variables:
>> KVM_VM_CREATED which indicates how many times a new VM has been created,
>> KVM_VM_COUNT which indicates how many VMs are currently active.
> 
> I'm not sure why KVM_VM_CREATED is useful, KVM_VM_COUNT can be a bit
> more interesting though not much.

I am certainly interested in an trigger from "kvm was never used" to "kvm was 
used",
so having something like KVM_VM_CREATED has a value for me.


> 
> But since we are at it, let's also add a PID.  That one is the really
> useful one, because it gives you something to look at in debugfs.
> Another possibility is to add the debugfs directory name directly
> (KVM_VM_STATS_PATH or something like that).
> 
> Paolo
> 
>> Specific udev rules can be then set up in userspace to deal with the
>> creation or destruction of VMs as needed.
>>
>> Signed-off-by: Claudio Imbrenda 
>> ---
>>  virt/kvm/kvm_main.c | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 6e3b12c..f67aa59 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -130,6 +130,10 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
>>  
>>  static bool largepages_enabled = true;
>>  
>> +static void kvm_uevent_notify_change(u64 created, u64 active);
>> +static u64 kvm_createvm_count;
>> +static u64 kvm_active_vms;
>> +
>>  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
>>  {
>>  if (pfn_valid(pfn))
>> @@ -627,6 +631,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
>>  {
>>  int r, i;
>>  struct kvm *kvm = kvm_arch_alloc_vm();
>> +u64 activevms, createdvms;
>>  
>>  if (!kvm)
>>  return ERR_PTR(-ENOMEM);
>> @@ -686,9 +691,12 @@ static struct kvm *kvm_create_vm(unsigned long type)
>>  
>>  spin_lock(_lock);
>>  list_add(>vm_list, _list);
>> +createdvms = ++kvm_createvm_count;
>> +activevms = ++kvm_active_vms;
>>  spin_unlock(_lock);
>>  
>>  preempt_notifier_inc();
>> +kvm_uevent_notify_change(createdvms, activevms);
>>  
>>  return kvm;
>>  
>> @@ -739,11 +747,14 @@ static void kvm_destroy_vm(struct kvm *kvm)
>>  {
>>  int i;
>>  struct mm_struct *mm = kvm->mm;
>> +u64 activevms, createdvms;
>>  
>>  kvm_destroy_vm_debugfs(kvm);
>>  kvm_arch_sync_events(kvm);
>>  spin_lock(_lock);
>>  list_del(>vm_list);
>> +activevms = --kvm_active_vms;
>> +createdvms = kvm_createvm_count;
>>  spin_unlock(_lock);
>>  kvm_free_irq_routing(kvm);
>>  for (i = 0; i < KVM_NR_BUSES; i++) {
>> @@ -767,6 +778,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
>>  preempt_notifier_dec();
>>  hardware_disable_all();
>>  mmdrop(mm);
>> +kvm_uevent_notify_change(createdvms, activevms);
>>  }
>>  
>>  void kvm_get_kvm(struct kvm *kvm)
>> @@ -3864,6 +3876,19 @@ static const struct file_operations *stat_fops[] = {
>>  [KVM_STAT_VM]   = _stat_fops,
>>  };
>>  
>> +static void kvm_uevent_notify_change(u64 created, u64 active)
>> +{
>> +char createvm_buf[40];
>> +char activevm_buf[40];
>> +char *ptr[3] = {createvm_buf, activevm_buf, NULL};
>> +
>> +if (!kvm_dev.this_device)
>> +return;
>> +snprintf(createvm_buf, 40, "KVM_VM_CREATED=%llu", created);
>> +snprintf(activevm_buf, 40, "KVM_VM_ACTIVE=%llu", active);
>> +kobject_uevent_env(_dev.this_device->kobj, KOBJ_CHANGE, ptr);
>> +}
>> +
>>  static int kvm_init_debug(void)
>>  {
>>  int r = -EEXIST;
>>
> 

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

[Peter Zijlstra]

On Tue, Jul 04, 2017 at 10:33:45AM +0100, Mark Rutland wrote:

> > That said, with a per-cpu event the TID sample value is indeed subject
> > to skid like you describe.
> 
> For per-cpu events, does that matter? Those don't have TID filters in
> the first place, no?

eBPF can do all sorts I suppose.

But yes, at some point you just have to give up, there's only so much
one can do.

[PATCH 3/3] irq: gic-v3: Honor forced affinity setting

[Suzuki K Poulose]

Honor the 'force' flag for set_affinity, by selecting a CPU
from the given mask (which may not be reported "online" by
the cpu_online_mask). Some drivers, like ARM PMU, rely on it.

Cc: Marc Zyngier 
Reported-by: Mark Rutland 
Signed-off-by: Suzuki K Poulose 
---
 drivers/irqchip/irq-gic-v3.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ea82342..883597f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -642,11 +642,16 @@ static void gic_smp_init(void)
 static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
bool force)
 {
-   unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   unsigned int cpu;
void __iomem *reg;
int enabled;
u64 val;
 
+   if (force)
+   cpu = cpumask_first(mask_val);
+   else
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+
if (cpu >= nr_cpu_ids)
return -EINVAL;
 
-- 
2.7.5

[PATCH 2/3] irqchip: gic-v2: Report failures in gic_irq_domain_alloc

[Suzuki K Poulose]

If the GIC cannot map an IRQ via irq_domain_ops->alloc(), it doesn't
return an error code.  This can cause a problem with drivers, where
it thinks it has successfully got an IRQ for the device, but requesting
the same ends up failure with -ENOSYS (as the IRQ's chip is not set).

Fixes: commit 9a1091ef0017c ("irqchip: gic: Support hierarchy irq domain.")
Cc: Yingjoe Chen 
Cc: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
---
 drivers/irqchip/irq-gic.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1b1df4f..940c162 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1027,8 +1027,11 @@ static int gic_irq_domain_alloc(struct irq_domain 
*domain, unsigned int virq,
if (ret)
return ret;
 
-   for (i = 0; i < nr_irqs; i++)
-   gic_irq_domain_map(domain, virq + i, hwirq + i);
+   for (i = 0; i < nr_irqs; i++) {
+   ret = gic_irq_domain_map(domain, virq + i, hwirq + i);
+   if (ret)
+   return ret;
+   }
 
return 0;
 }
-- 
2.7.5

[PATCH 0/3] irqchip: Miscellaneous fixes for GIC/GICv3

[Suzuki K Poulose]

This series contains some fixes for GIC/GIC-v3 to behave as expected
by the generic management layer.

Suzuki K Poulose (3):
  irqchip: gic-v3: Report failures in gic_irq_domain_alloc
  irqchip: gic-v2: Report failures in gic_irq_domain_alloc
  irq: gic-v3: Honor forced affinity setting

 drivers/irqchip/irq-gic-v3.c | 14 +++---
 drivers/irqchip/irq-gic.c|  7 +--
 2 files changed, 16 insertions(+), 5 deletions(-)

-- 
2.7.5

Re: [PATCH v2] sched/pelt: fix false running accounting

[Vincent Guittot]

On 4 July 2017 at 11:44, Peter Zijlstra  wrote:
> On Tue, Jul 04, 2017 at 11:12:34AM +0200, Vincent Guittot wrote:
>> On 4 July 2017 at 10:34, Peter Zijlstra  wrote:
>> > On Tue, Jul 04, 2017 at 09:27:07AM +0200, Peter Zijlstra wrote:
>> >> On Sat, Jul 01, 2017 at 07:06:13AM +0200, Vincent Guittot wrote:
>> >> > The running state is a subset of runnable state which means that running
>> >> > can't be set if runnable (weight) is cleared. There are corner cases
>> >> > where the current sched_entity has been already dequeued but 
>> >> > cfs_rq->curr
>> >> > has not been updated yet and still points to the dequeued sched_entity.
>> >> > If ___update_load_avg is called at that time, weight will be 0 and 
>> >> > running
>> >> > will be set which is not possible.
>> >> >
>> >> > This case happens during pick_next_task_fair() when a cfs_rq becomes 
>> >> > idles.
>> >> > The current sched_entity has been dequeued so se->on_rq is cleared and
>> >> > cfs_rq->weight is null. But cfs_rq->curr still points to se (it will be
>> >> > cleared when picking the idle thread). Because the cfs_rq becomes idle,
>> >> > idle_balance() is called and ends up to call update_blocked_averages()
>> >> > with these wrong running and runnable states.
>> >> >
>> >> > Add a test in ___update_load_avg to correct the running state in this 
>> >> > case.
>> >>
>> >> Cute, however did you find that ?
>> >
>> > Hmm,.. could you give a little more detail?
>> >
>> > Because if ->on_rq=0, we'll have done dequeue_task() which will have
>> > done update_curr() with ->on_rq, weight and ->running consistently.
>> >
>> > Then the above, inconsistent update should not happen, because delta=0.
>>
>> In fact, the delta between dequeue_entity_load_avg() and
>> update_blocked_averages() is not 0 on my platform (hikey) but can be
>> longer than 60us (at lowest frequency with only 1 task group level)
>
> But but but, how can that happen? Should it not all be under the same
> rq->lock and thus have only a single update_rq_clock() and thus be at
> the same 'instant' ?

idle_balance() unlock rq->lock before calling  update_blocked_averages
And update_blocked_averages() starts by calling update_rq_clock()

[PATCH] genirq: Force inlining of __irq_startup_managed to prevent build failure

[Geert Uytterhoeven]

If CONFIG_SMP=n, and gcc (e.g. 4.1.2) decides not to inline
__irq_startup_managed(), the build fails with:

kernel/built-in.o: In function `irq_startup':
(.text+0x38ed8): undefined reference to `irq_set_affinity_locked'

Fix this by forcing inlining of __irq_startup_managed().

Fixes: 761ea388e8c4e3ac ("genirq: Handle managed irqs gracefully in 
irq_startup()")
Signed-off-by: Geert Uytterhoeven 
---
 kernel/irq/chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index ad43468e89f0e903..d171bc57e1e01830 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -234,7 +234,7 @@ __irq_startup_managed(struct irq_desc *desc, struct cpumask 
*aff, bool force)
return IRQ_STARTUP_MANAGED;
 }
 #else
-static int
+static __always_inline int
 __irq_startup_managed(struct irq_desc *desc, struct cpumask *aff, bool force)
 {
return IRQ_STARTUP_NORMAL;
-- 
2.7.4

Re: [PATCH] gpio: drop unnecessary includes from include/linux/gpio/driver.h

[Andy Shevchenko]

On Tue, 2017-07-04 at 12:53 +0900, Masahiro Yamada wrote:
> Some of include directives in include/linux/gpio/driver.h are
> unneeded because the header does not need to know the content of
> struct device, irq_chip, etc.  Just declare they are structures.
> 
> On the other hand,  and 
> turned out to be necessary for irq_flow_handler_t and spinlock_t,
> respectively.
> 
> Each driver should include what it needs without relying on what is
> implicitly included from .  This will cut down
> unnecessary header parsing.

If Linus is okay with the following proposal I would rather go with it,
i.e. logical split the series to

1. Fix IRQ related headers inclusion
2. Fix pinconf-generic.h inclusion
3. Fix OF headers inclusion (btw, of_gpio.h is not enough there?)

In any case take my tag

Reviewed-by: Andy Shevchenko 

for the drivers I have been involved into development of:

 drivers/gpio/gpio-dwapb.c    |  1 +
 drivers/gpio/gpio-intel-mid.c    |  2 ++
 drivers/gpio/gpio-lynxpoint.c    |  2 ++
 drivers/gpio/gpio-merrifield.c   |  4 
 drivers/gpio/gpio-pca953x.c  |  1 +
 drivers/gpio/gpio-wcove.c    |  2 ++

And 

Acked-by: Andy Shevchenko 

for

 drivers/gpio/gpiolib-acpi.c  |  1 +


> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/gpio/gpio-104-dio-48e.c  |  1 +
>  drivers/gpio/gpio-104-idi-48.c   |  1 +
>  drivers/gpio/gpio-104-idio-16.c  |  1 +
>  drivers/gpio/gpio-altera-a10sr.c |  2 ++
>  drivers/gpio/gpio-altera.c   |  3 +++
>  drivers/gpio/gpio-aspeed.c   |  5 +
>  drivers/gpio/gpio-ath79.c|  2 ++
>  drivers/gpio/gpio-bcm-kona.c |  1 +
>  drivers/gpio/gpio-clps711x.c |  1 +
>  drivers/gpio/gpio-crystalcove.c  |  2 ++
>  drivers/gpio/gpio-dln2.c |  1 +
>  drivers/gpio/gpio-dwapb.c|  1 +
>  drivers/gpio/gpio-etraxfs.c  |  1 +
>  drivers/gpio/gpio-f7188x.c   |  1 +
>  drivers/gpio/gpio-ftgpio010.c|  3 +++
>  drivers/gpio/gpio-ingenic.c  |  1 +
>  drivers/gpio/gpio-intel-mid.c|  2 ++
>  drivers/gpio/gpio-lp873x.c   |  1 +
>  drivers/gpio/gpio-lynxpoint.c|  2 ++
>  drivers/gpio/gpio-max732x.c  |  1 +
>  drivers/gpio/gpio-max77620.c |  1 +
>  drivers/gpio/gpio-menz127.c  |  1 +
>  drivers/gpio/gpio-merrifield.c   |  4 
>  drivers/gpio/gpio-omap.c |  3 +++
>  drivers/gpio/gpio-pca953x.c  |  1 +
>  drivers/gpio/gpio-pci-idio-16.c  |  2 ++
>  drivers/gpio/gpio-pisosr.c   |  1 +
>  drivers/gpio/gpio-pl061.c|  1 +
>  drivers/gpio/gpio-rcar.c |  1 +
>  drivers/gpio/gpio-stmpe.c|  2 ++
>  drivers/gpio/gpio-tc3589x.c  |  3 +++
>  drivers/gpio/gpio-tegra.c|  1 +
>  drivers/gpio/gpio-tps65218.c |  1 +
>  drivers/gpio/gpio-vf610.c|  3 +++
>  drivers/gpio/gpio-vx855.c|  1 +
>  drivers/gpio/gpio-wcove.c|  2 ++
>  drivers/gpio/gpio-wm831x.c   |  1 +
>  drivers/gpio/gpio-wm8994.c   |  1 +
>  drivers/gpio/gpio-ws16c48.c  |  1 +
>  drivers/gpio/gpio-xgene-sb.c |  2 ++
>  drivers/gpio/gpio-xlp.c  |  1 +
>  drivers/gpio/gpio-zx.c   |  1 +
>  drivers/gpio/gpio-zynq.c |  3 +++
>  drivers/gpio/gpiolib-acpi.c  |  1 +
>  drivers/gpio/gpiolib.c   |  2 ++
>  include/linux/gpio/driver.h  | 11 ++-
>  46 files changed, 80 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-
> dio-48e.c
> index 598e209efa2d..bdc52be7902a 100644
> --- a/drivers/gpio/gpio-104-dio-48e.c
> +++ b/drivers/gpio/gpio-104-dio-48e.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-
> idi-48.c
> index 51f046e29ff7..7bbb0e8573d1 100644
> --- a/drivers/gpio/gpio-104-idi-48.c
> +++ b/drivers/gpio/gpio-104-idi-48.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-
> idio-16.c
> index ec2ce34ff473..7e3fc0bf3398 100644
> --- a/drivers/gpio/gpio-104-idio-16.c
> +++ b/drivers/gpio/gpio-104-idio-16.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpio/gpio-altera-a10sr.c b/drivers/gpio/gpio-
> altera-a10sr.c
> index 16a8951b2bed..4cdca9332043 100644
> --- a/drivers/gpio/gpio-altera-a10sr.c
> +++ b/drivers/gpio/gpio-altera-a10sr.c
> @@ -21,6 +21,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /**
>   * struct altr_a10sr_gpio - Altera Max5 GPIO device private data
> structure
> diff --git a/drivers/gpio/gpio-altera.c b/drivers/gpio/gpio-altera.c
> index 17485dc20384..40b26274acaf 100644
> --- a/drivers/gpio/gpio-altera.c
> +++ b/drivers/gpio/gpio-altera.c
> @@ -17,6 +17,9 @@
>   */
>  
>  #include 

Re: [PATCH 06/14] qcom: mtd: nand: add bam dma descriptor handling

[Archit Taneja]

On 06/29/2017 12:45 PM, Abhishek Sahu wrote:

1. prepare_bam_async_desc is the function which will call
all the DMA API’s. It will fetch the outstanding scatter gather
list for passed channel and will do the DMA descriptor formation.
The DMA flag is dependent upon the type of channel.

2. For ADM DMA, the descriptor is being formed for every DMA
request so its sgl count will be always 1 while in BAM DMA, the
clubbing of descriptor is being done to increase throughput.

3. ADM uses only one channel while in BAM, data descriptors
will be submitted to tx channel (for write) or rx channel
(for read) and all the registers read/write descriptors in
command channel.

Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 119 --
  1 file changed, 114 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index f8d0bde..7042a65 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -206,14 +206,22 @@ struct bam_transaction {
   * This data type corresponds to the nand dma descriptor
   * @list - list for desc_info
   * @dir - DMA transfer direction
- * @sgl - sgl which will be used for single sgl dma descriptor
+ * @sgl - sgl which will be used for single sgl dma descriptor. Only used by 
ADM
+ * @bam_sgl - sgl which will be used for dma descriptor. Only used by BAM
+ * @sgl_cnt - number of SGL in bam_sgl. Only used by BAM
   * @dma_desc - low level dma engine descriptor
   */
  struct desc_info {
struct list_head node;
  
  	enum dma_data_direction dir;

-   struct scatterlist sgl;
+   union {
+   struct scatterlist sgl;


Can you make this adm_sgl instead for consistency? Also, please use only
two tabs instead of one here for indentation.


+   struct {
+   struct scatterlist *bam_sgl;
+   int sgl_cnt;
+   };
+   };
struct dma_async_tx_descriptor *dma_desc;
  };
  
@@ -564,6 +572,68 @@ static void update_rw_regs(struct qcom_nand_host *host, int num_cw, bool read)

nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
  }
  
+/*

+ * Maps the scatter gather list for DMA transfer and forms the DMA descriptor
+ * for BAM. This descriptor will be added in the NAND DMA descriptor queue
+ * which will be submitted to DMA engine.
+ */
+static int prepare_bam_async_desc(struct qcom_nand_controller *nandc,
+ struct dma_chan *chan,
+ unsigned long flags)


From what I gathered in patch #10, this would be called by
prep_dma_desc_data_bam() and prep_dma_desc_command(). Can you rename these
two to something like prep_bam_dma_desc_data() and prep_bam_dma_desc_cmd()



+{
+   struct desc_info *desc;
+   struct scatterlist *sgl;
+   unsigned int sgl_cnt;
+   struct bam_transaction *bam_txn = nandc->bam_txn;
+   enum dma_transfer_direction dir_eng;
+   struct dma_async_tx_descriptor *dma_desc;
+
+   desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+   if (!desc)
+   return -ENOMEM;
+
+   if (chan == nandc->cmd_chan) {
+   sgl = _txn->cmd_sgl[bam_txn->cmd_sgl_start];
+   sgl_cnt = bam_txn->cmd_sgl_pos - bam_txn->cmd_sgl_start;
+   bam_txn->cmd_sgl_start = bam_txn->cmd_sgl_pos;
+   dir_eng = DMA_MEM_TO_DEV;
+   desc->dir = DMA_TO_DEVICE;
+   } else if (chan == nandc->tx_chan) {
+   sgl = _txn->data_sg[bam_txn->tx_sgl_start];
+   sgl_cnt = bam_txn->tx_sgl_pos - bam_txn->tx_sgl_start;
+   bam_txn->tx_sgl_start = bam_txn->tx_sgl_pos;
+   dir_eng = DMA_MEM_TO_DEV;
+   desc->dir = DMA_TO_DEVICE;
+   } else {
+   sgl = _txn->data_sg[bam_txn->rx_sgl_start];
+   sgl_cnt = bam_txn->rx_sgl_pos - bam_txn->rx_sgl_start;
+   bam_txn->rx_sgl_start = bam_txn->rx_sgl_pos;
+   desc->dir = DMA_FROM_DEVICE;
+   dir_eng = DMA_DEV_TO_MEM;
+   }
+
+   sg_mark_end(sgl + sgl_cnt - 1);
+   dma_map_sg(nandc->dev, sgl, sgl_cnt, desc->dir);


Is it safe to assume here that dma_map_sg won't return an error?


+
+   desc->sgl_cnt = sgl_cnt;
+   desc->bam_sgl = sgl;
+
+   dma_desc = dmaengine_prep_slave_sg(chan, sgl, sgl_cnt, dir_eng,
+  flags);
+
+   if (!dma_desc) {
+   dev_err(nandc->dev, "failure in prep desc\n");
+   kfree(desc);
+   return -EINVAL;
+   }
+
+   desc->dma_desc = dma_desc;
+
+   list_add_tail(>node, >desc_list);
+
+   return 0;
+}
+




  static int prep_dma_desc(struct qcom_nand_controller *nandc, bool read,
 int reg_off, const void *vaddr, int size,
 bool 

[PATCH 4/4] selftests: ftrace: Output only to console with "--logdir -"

[Masami Hiramatsu]

Output logs only to console if "-" is given to --logdir
option. In this case, ftracetest doesn't record any log
on the disk, and all logs immediately shown (including
all command logs.) Since there is no "tee" in the middle
of command and console, it outputs the log really soon.

This option is useful only when the console is logged.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |   29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 892ca4e..25792ee 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -19,6 +19,7 @@ echo "-vvv   Alias of -v -v -v (Show all 
commands immediately)"
 echo " --fail-unsupported Treat UNSUPPORTED as a failure"
 echo " -d|--debug Debug mode (trace all shell commands)"
 echo " -l|--logdir  Save logs on the "
+echo " If  is -, all logs output in console only"
 exit $1
 }
 
@@ -127,14 +128,20 @@ if [ -z "$TRACING_DIR" -o ! -d "$TRACING_DIR" ]; then
 fi
 
 # Preparing logs
-LOG_FILE=$LOG_DIR/ftracetest.log
-mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
-date > $LOG_FILE
+if [ "x$LOG_DIR" = "x-" ]; then
+  LOG_FILE=
+  date
+else
+  LOG_FILE=$LOG_DIR/ftracetest.log
+  mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
+  date > $LOG_FILE
+fi
+
 prlog() { # messages
-  echo "$@" | tee -a $LOG_FILE
+  [ -z "$LOG_FILE" ] && echo "$@" || echo "$@" | tee -a $LOG_FILE
 }
 catlog() { #file
-  cat $1 | tee -a $LOG_FILE
+  [ -z "$LOG_FILE" ] && cat $1 || cat $1 | tee -a $LOG_FILE
 }
 prlog "=== Ftrace unit tests ==="
 
@@ -255,12 +262,18 @@ __run_test() { # testfile
 # Run one test case
 run_test() { # testfile
   local testname=`basename $1`
-  local testlog=`mktemp $LOG_DIR/${testname}-log.XX`
+  if [ "$LOG_FILE" ] ; then
+local testlog=`mktemp $LOG_DIR/${testname}-log.XX`
+  else
+local testlog=`/proc/self/fd/1`
+  fi
   export TMPDIR=`mktemp -d /tmp/ftracetest-dir.XX`
   testcase $1
   echo "execute$INSTANCE: "$1 > $testlog
   SIG_RESULT=0
-  if [ $VERBOSE -ge 3 ]; then
+  if [ -z "$LOG_FILE" ]; then
+__run_test $1 2>&1
+  elif [ $VERBOSE -ge 3 ]; then
 __run_test $1 | tee -a $testlog 2>&1
   elif [ $VERBOSE -eq 2 ]; then
 __run_test $1 2>> $testlog | tee -a $testlog
@@ -270,7 +283,7 @@ run_test() { # testfile
   eval_result $SIG_RESULT
   if [ $? -eq 0 ]; then
 # Remove test log if the test was done as it was expected.
-[ $KEEP_LOG -eq 0 ] && rm $testlog
+[ $KEEP_LOG -eq 0 -a "$LOG_FILE" ] && rm $testlog
   else
 [ $VERBOSE -eq 1 -o $VERBOSE -eq 2 ] && catlog $testlog
 TOTAL_RESULT=1

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 3 July 2017 at 16:53, Charles Keepax  wrote:
> On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown 
>> Signed-off-by: Baolin Wang 
>> ---
> 
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (IS_ERR(power->usb_phy)) {
>> + ret = PTR_ERR(power->usb_phy);
>> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>
> We should probably update the binding documentation for this as
> well: mfd/wm831x.txt

Yes, I will update the binding documentation.

>
> Also I am not sure this needs to be implemented now, but what is
> the plan regarding pdata systems? Generally the driver supports
> both and it would be nice to know there is a way forward for that
> even if we don't implement it yet.

OK, I'll modify this in next version. Thanks.

-- 
Baolin.wang
Best Regards

Re: [PATCH v6 12/18] xen/pvcalls: implement poll command

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Implement poll on passive sockets by requesting a delayed response with
> mappass->reqcopy, and reply back when there is data on the passive
> socket.
> 
> Poll on active socket is unimplemented as by the spec, as the frontend
> should just wait for events and check the indexes on the indexes page.
> 
> Only support one outstanding poll (or accept) request for every passive
> socket at any given time.
> 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

Re: [PATCH v6 07/18] xen/pvcalls: implement socket command

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Just reply with success to the other end for now. Delay the allocation
> of the actual socket to bind and/or connect.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

Re: [PATCH v6 04/18] xen/pvcalls: xenbus state handling

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Introduce the code to handle xenbus state changes.
> 
> Implement the probe function for the pvcalls backend. Write the
> supported versions, max-page-order and function-calls nodes to xenstore,
> as required by the protocol.
> 
> Introduce stub functions for disconnecting/connecting to a frontend.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Boris Ostrovsky 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-back.c | 152 
> +
>  1 file changed, 152 insertions(+)
> 
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index 9044cf2..7bce750 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -25,20 +25,172 @@
>  #include 
>  #include 
>  
> +#define PVCALLS_VERSIONS "1"
> +#define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
> +
>  struct pvcalls_back_global {
>   struct list_head frontends;
>   struct semaphore frontends_lock;
>  } pvcalls_back_global;
>  
> +static int backend_connect(struct xenbus_device *dev)
> +{
> + return 0;
> +}
> +
> +static int backend_disconnect(struct xenbus_device *dev)
> +{
> + return 0;
> +}
> +
>  static int pvcalls_back_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
>  {
> + int err, abort;
> + struct xenbus_transaction xbt;
> +
> +again:
> + abort = 1;
> +
> + err = xenbus_transaction_start();
> + if (err) {
> + pr_warn("%s cannot create xenstore transaction\n", __func__);
> + return err;
> + }
> +
> + err = xenbus_printf(xbt, dev->nodename, "versions", "%s",
> + PVCALLS_VERSIONS);
> + if (err) {
> + pr_warn("%s write out 'version' failed\n", __func__);

s/version/versions/ ?

> + goto abort;
> + }
> +
> + err = xenbus_printf(xbt, dev->nodename, "max-page-order", "%u",
> + MAX_RING_ORDER);
> + if (err) {
> + pr_warn("%s write out 'max-page-order' failed\n", __func__);
> + goto abort;
> + }
> +
> + err = xenbus_printf(xbt, dev->nodename, "function-calls",
> + XENBUS_FUNCTIONS_CALLS);
> + if (err) {
> + pr_warn("%s write out 'function-calls' failed\n", __func__);
> + goto abort;
> + }
> +
> + abort = 0;
> +abort:
> + err = xenbus_transaction_end(xbt, abort);
> + if (err) {
> + if (err == -EAGAIN && !abort)

Hmm, while I don't think xenbus_transaction_end() will ever
return -EAGAIN in the abort case I'm not sure you should limit
the retry loop to the non-abort case.

> + goto again;
> + pr_warn("%s cannot complete xenstore transaction\n", __func__);
> + return err;
> + }
> +
> + xenbus_switch_state(dev, XenbusStateInitWait);

I don't think you should switch state in case of abort set, no?


Juergen

[PATCH 4/6] ARM: dts: rockchip: enable eMMC for rk3229-evb

[Frank Wang]

This patch enables eMMC support for rk3229-evb board.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk3229-evb.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index b64f86c..bae0dbf 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -130,6 +130,17 @@
cpu-supply = <_arm>;
 };
 
+ {
+   broken-cd;
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   supports-emmc;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   status = "okay";
+};
+
  {
assigned-clocks = < SCLK_MAC_EXTCLK>, < SCLK_MAC>;
assigned-clock-parents = <_gmac>, < SCLK_MAC_EXTCLK>;
-- 
2.0.0

[PATCH 3/6] ARM: dts: rockchip: enable io-domain for rk3229-evb

[Frank Wang]

From: David Wu 

This patch enables io-domain support for rk3229-evb board.

The power domain of VCCIO3 is selected from maskrom, so we do not
need to configure it.

Signed-off-by: David Wu 
Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk3229-evb.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index cfa7baa..b64f86c 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -146,6 +146,14 @@
status = "okay";
 };
 
+_domains {
+   status = "okay";
+
+   vccio1-supply = <_3v3_reg>;
+   vccio2-supply = <_1v8_reg>;
+   vccio4-supply = <_3v3_reg>;
+};
+
  {
usb {
host_vbus_drv: host-vbus-drv {
-- 
2.0.0

[PATCH 1/6] ARM: dts: rockchip: add regulator nodes for rk3229-evb

[Frank Wang]

This patch adds vcc_io, vdd_arm and vdd_log regulator nodes
for rk3229-evb board.

Signed-off-by: Frank Wang 
---
 arch/arm/boot/dts/rk3229-evb.dts | 54 
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index 82e8a53..8b10c64 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -78,6 +78,52 @@
regulator-always-on;
regulator-boot-on;
};
+
+   vdd_arm: vdd-arm-regulator {
+   compatible = "pwm-regulator";
+   rockchip,pwm_id = <1>;
+   rockchip,pwm_voltage = <110>;
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_arm";
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vdd_log: vdd-log-regulator {
+   compatible = "pwm-regulator";
+   rockchip,pwm_id = <2>;
+   rockchip,pwm_voltage = <120>;
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vccio_1v8_reg: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   vccio_3v3_reg: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   };
 };
 
  {
@@ -104,6 +150,14 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.0.0

Re: [GIT pull] irq updates for 4.13

[Thomas Gleixner]

On Mon, 3 Jul 2017, Linus Torvalds wrote:

> On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner  wrote:
> >
> > please pull the latest irq-core-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > irq-core-for-linus
> 
> Ugh, this caused conflicts with the block tree, with commits
> 
>  - fe631457ff3e: "blk-mq: map all HWQ also in hyperthreaded system"
> 
>  - 5f042e7cbd9e "blk-mq: Include all present CPUs in the default queue 
> mapping"
> 
> clashing.
> 
> I'm not at all understanding why that second commit came in through
> the irq tree at all, in fact. Very annoying. Why was that not sent
> through the block tree? It doesn't seem to have anything fundamentally
> to do with irqs, really: it's a driver CPU choice for irq chocie.

There is a dependency. The changes in the block code rely on the new
features of the generic interrupt affinity management. See below.

> Anyway, I absolutely detested that code, and the obvious resolution
> was too disgusting to live. So I did an evil merge and moved some
> things around in the merge to make it at least not cause me to dig my
> eyes out.
> 
> But I'd like people to look at that - not so much due to the evil
> merge itself (but check that too, by any means), but just because the
> code seems fundamentally broken for the hotplug case. We end up
> picking a possible metric shit-ton of CPU's for queue 0, if they were
> "possible but not online".

The mechanism is:

Spread out the queues and the associated interrupts accross the possible
CPUs. This results in a queue/interrupt per group of CPUs (group can be a
single CPU)

If a group is offline, then the interrupt is kept in managed shutdown
mode. If a CPU of the group comes online then the core management starts up
the interrupt and makes it affine to that CPU.

If the last CPU of a group goes offline, the interrupt is not moved to some
random other CPU. It's put in managed shutdown mode and then restarted when
the a CPU of the group comes online again.

That exercise avoids exactly the 'metric tons of irqs' moved to random CPUs
and then brought back to the target CPUs when they come online
again. On/offline seems to be (ab)used frequently for power management
purposes nowadays.

Sorry, if I did not make that clear enough in the pull request message.

Thanks,

tglx

[PATCH 0/6] add and enable some device nodes for rk3229-evb board

[Frank Wang]

These series add and enable regulators, gpio-keys, eMMC and other device
nodes support for rk3229-evb board.

David Wu (1):
  ARM: dts: rockchip: enable io-domain for rk3229-evb

Finley Xiao (1):
  ARM: dts: rockchip: add cpu-supply property for cpu node of rk3229-evb

Frank Wang (4):
  ARM: dts: rockchip: add regulator nodes for rk3229-evb
  ARM: dts: rockchip: enable eMMC for rk3229-evb
  ARM: dts: rockchip: enable tsadc for rk3229-evb
  ARM: dts: rockchip: add gpio power-key for rk3229-evb

 arch/arm/boot/dts/rk3229-evb.dts | 106 +++
 1 file changed, 106 insertions(+)

-- 
2.0.0

[PATCH 2/6] ARM: dts: rockchip: add cpu-supply property for cpu node of rk3229-evb

[Frank Wang]

From: Finley Xiao 

This patch adds the cpu-supply property so that cpu can do dvfs
on rk3229-evb board.

Signed-off-by: Finley Xiao 
---
 arch/arm/boot/dts/rk3229-evb.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3229-evb.dts b/arch/arm/boot/dts/rk3229-evb.dts
index 8b10c64..cfa7baa 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -126,6 +126,10 @@
};
 };
 
+ {
+   cpu-supply = <_arm>;
+};
+
  {
assigned-clocks = < SCLK_MAC_EXTCLK>, < SCLK_MAC>;
assigned-clock-parents = <_gmac>, < SCLK_MAC_EXTCLK>;
-- 
2.0.0

[PATCH v2] mux: remove the Kconfig question for the subsystem

[Peter Rosin]

The MULTIPLEXER question in the Kconfig might be confusing and is
of dubious value. Remove it. This makes consumers responsible for
selecting MULTIPLEXER, which they already do.

Signed-off-by: Peter Rosin 
---
 drivers/mux/Kconfig | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

On 2017-07-04 08:00, Linus Torvalds wrote:
> On Jul 3, 2017 22:53, "Peter Rosin"  > wrote:
>> But ok, is something like this what you wanted?
> 
> I *think* this week just result in an empty menu if there are
> no drivers selecting it.
> 
> Shouldn't the 'if' be outside the menu? But I didn't test
> anything, since I'm not in front of my computer any more..

Right, the previous patch also had the problem that it removed
the MULTIPLEXER option completely and was therefore total crap.

I have tested this patch more thoroughly and it should be a
definite improvement. Sorry for the noise...

Cheers,
peda

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 7c754a0..19e4e90 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -2,20 +2,11 @@
 # Multiplexer devices
 #
 
-menuconfig MULTIPLEXER
-   tristate "Multiplexer subsystem"
-   help
- Multiplexer controller subsystem. Multiplexers are used in a
- variety of settings, and this subsystem abstracts their use
- so that the rest of the kernel sees a common interface. When
- multiple parallel multiplexers are controlled by one single
- multiplexer controller, this subsystem also coordinates the
- multiplexer accesses.
-
- To compile the subsystem as a module, choose M here: the module will
- be called mux-core.
+config MULTIPLEXER
+   tristate
 
-if MULTIPLEXER
+menu "Multiplexer drivers"
+   depends on MULTIPLEXER
 
 config MUX_ADG792A
tristate "Analog Devices ADG792A/ADG792G Multiplexers"
@@ -56,4 +47,4 @@ config MUX_MMIO
  To compile the driver as a module, choose M here: the module will
  be called mux-mmio.
 
-endif
+endmenu
-- 
2.1.4

Re: [PATCH v2] devfreq: tegra: fix error return code in tegra_devfreq_probe()

[Jon Hunter]

On 03/07/17 13:47, Gustavo A. R. Silva wrote:
> platform_get_irq() returns an error code, but the tegra-devfreq
> driver ignores it and always returns -ENODEV. This is not correct,
> and prevents -EPROBE_DEFER from being propagated properly.
> 
> Notice that platform_get_irq() no longer returns 0 on error:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af
> 
> Print and propagate the return value of platform_get_irq on failure.
> 
> Reviewed-by: Chanwoo Choi 
> Acked-by: MyungJoo Ham 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  Rewrite commit message.
> 
>  drivers/devfreq/tegra-devfreq.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 214fff9..ae71215 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -688,9 +688,9 @@ static int tegra_devfreq_probe(struct platform_device 
> *pdev)
>   }
>  
>   irq = platform_get_irq(pdev, 0);
> - if (irq <= 0) {
> - dev_err(>dev, "Failed to get IRQ\n");
> - return -ENODEV;
> + if (irq < 0) {
> + dev_err(>dev, "Failed to get IRQ: %d\n", irq);
> + return irq;
>   }
>  
>   platform_set_drvdata(pdev, tegra);

Thanks.

Acked-by: Jon Hunter 

Cheers
Jon

-- 
nvpublic

Re: [PATCH] KVM: arm/arm64: Handle hva aging while destroying the vm

[Christoffer Dall]

On Tue, Jul 04, 2017 at 01:41:49AM +0200, Andrea Arcangeli wrote:
> Hello,
> 
> On Mon, Jul 03, 2017 at 10:48:03AM +0200, Alexander Graf wrote:
> > On 07/03/2017 10:03 AM, Christoffer Dall wrote:
> > > Hi Alex,
> > >
> > > On Fri, Jun 23, 2017 at 05:21:59PM +0200, Alexander Graf wrote:
> > >> If we want to age an HVA while the VM is getting destroyed, we have a
> > >> tiny race window during which we may end up dereferencing an invalid
> > >> kvm->arch.pgd value.
> > >>
> > >> CPU0   CPU1
> > >>
> > >> kvm_age_hva()
> > >>kvm_mmu_notifier_release()
> > >>kvm_arch_flush_shadow_all()
> > >>kvm_free_stage2_pgd()
> > >>
> > >> stage2_get_pmd()
> > >> 
> > >>set kvm->arch.pgd = 0
> > >>
> > >> 
> > >> stage2_get_pud()
> > >> arch.pgd>
> > >> 
> > > I don't think this sequence, can happen, but I think kvm_age_hva() can
> > > be called with the mmu_lock held and kvm->pgd already being NULL.
> > >
> > > Is that possible for the mmu notifiers to be calling clear(_flush)_young
> > > while also calling notifier_release?
> > 
> > I *think* the aging happens completely orthogonally to release. But 
> > let's ask Andrea - I'm sure he knows :).
> 
> I think the sequence can happen. All mmu notifier methods are flushed
> out of CPUs only through synchronize_srcu() which is called as the
> last step in __mmu_notifier_release/unregister. Only after _unregister
> returns you're sure kvm_age_hva cannot run anymore, until that point
> it can still run. Even during exit_mmap->mmu_notifier_release it can
> still run if invoked through rmap walks.
> 
> So while the ->release method runs, all other mmu notifier methods
> could be still invoked concurrently.
> 
> mmu notifier methods are only protected by srcu to prevent the mmu
> notifier structure to be freed from under them, but there's no
> additional locking to serialize them (except for the synchronize_srcu
> that happens as the last step of mmu_notifier_release/unregister, well
> after they may have called the ->release method).
> 
> There's also a comment about it in __mmu_notifier_release:
> 
>  * runs with mm_users == 0. Other tasks may still invoke mmu notifiers
>  * in parallel despite there being no task using this mm any more,
>  * through the vmas outside of the exit_mmap context, such as with
>  * vmtruncate. This serializes against mmu_notifier_unregister with
> 
> And in the mmu_notifier_unregister too:
> 
>  * calling mmu_notifier_unregister. ->release or any other notifier
>  * method may be invoked concurrently with mmu_notifier_unregister,
>  * and only after mmu_notifier_unregister returned we're guaranteed
>  * that ->release or any other method can't run anymore.
> 
> Even ->release could in theory run concurrently against itself if
> mmu_notifier_unregister runs concurrently with mmu_notifier_release
> but that's purely theoretical possibility.
> 

Thanks for the clarification.

So Alex, I think you just need to fix the commit message of this patch.

Thanks,
-Christoffer

Re: [PATCH] mm: larger stack guard gap, between vmas

[Michal Hocko]

On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings  wrote:
> >
> > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> > Apparently Rust maps its own guard page at the lower limit of the stack
> > (determined using pthread_getattr_np() and pthread_attr_getstack()).  I
> > don't think this ever actually worked for the main thread stack, but it
> > now also blocks expansion as the default stack size of 8 MiB is smaller
> > than the stack gap of 16 MiB.  Would it make sense to skip over
> > PROT_NONE mappings when checking whether it's safe to expand?

This is what my workaround for the older patch was doing, actually. We
have deployed that as a follow up fix on our older code bases. And this
has fixed verious issues with Java which was doing the similar thing.

> Hmm. Maybe.
> 
> Also, the whole notion that the gap should be relative to the page
> size never made sense to me. So I think we could/should just make the
> default gap size be one megabyte, not that "256 pages" abortion.

The reason for having this in page units was that MAX_ARG_STRLEN is in
page units as well. And this is used as an on stack variable quite
often. 1MB wouldn't be sufficient for that to cover - we could go with a
larger gap but who knows how many other traps are there.

> > Secondly, LibreOffice is crashing on i386 when running components
> > implemented in Java.  I don't have a diagnosis for this yet.
> 
> Ugh. Nobody seeing this inside SuSe/Red Hat? I don't think I've heard
> about this..

No reports yet but we do not support 32b kernels on newer kernels which
had the upstream fix.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4 1/3] arm64: kvm: support user space to detect RAS extension feature

[Christoffer Dall]

Hi Dongjiu,

On Tue, Jul 04, 2017 at 03:04:54PM +0800, gengdongjiu wrote:
> Hi Christoffer,
> 
> On 2017/7/3 16:21, Christoffer Dall wrote:
> > On Mon, Jun 26, 2017 at 08:45:43PM +0800, Dongjiu Geng wrote:
> >> Handle userspace's detection for RAS extension, because sometimes
> >> the userspace needs to know the CPU's capacity
> > 
> > Why?  Can you please provide some more rationale.
> 
> userspace mainly want to know whether CPU has RAS extension capability to 
> decide whether need to specify the syndrome value.
> if have, userspace specify the syndrome value. otherwise, not specify the 
> value.
> 
> James ever suggest not want userspace to know the capability, and let KVM to 
> judge the RAS extension capability.
> 
> but I consider it again, userspace know the RAS extension capability may be 
> better, which can avoid KVM return error if
> CPU does not support RAS extension.

So first of all, while I appreciate your efforts to explain your
rationale here, I am also asking you to provide a more comprehensive
commit message for the next version of the patch.

> 
> could you give me some suggestion that whether let userspace to know the RAS 
> extension capability?
> 

I haven't thought much about it, but there are unanswered questions to
me.  For example, does the type and capabilities of the guest in any way
affect whether or not this features should be available?  Are there any
concerns with respect to migration?

And then the point I raised below, which is that this KVM-specific ioctl
is returning a hardware property of the CPU (the one the ioctl happens
to run on - what happens on a heterogeneous system?), but not really
what KVM can and cannot do.  At the very least this should be based on
a more generic in-kernel functionality, which reports the capabilities
of a system to KVM, and KVM could then tell userspace if it has a
certain capability.

Hope this helps,
-Christoffer

Re: [PATCH 1/7] serial: imx: only set DMA rx-ing when DMA starts

[Romain Perier]

Hello,


Le 03/07/2017 à 08:48, Uwe Kleine-König a écrit :
> Hello,
>
> On Fri, Jun 30, 2017 at 02:04:40PM +0200, Romain Perier wrote:
>> From: Nandor Han 
>>
>> Avoid the situation when `dma_is_rxing` could incorrectly signal that
>> DMA RX channel is receiving data in case DMA preparation or sg mapping
>> fails.
> Just from reading the commit log and the patch I didn't understand the
> problem that is supposed to be fixed here. After looking at it for some
> I understood. I don't suggest a new commit log here as it has to look
> different if you pick up my comment below.
>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 5437b34..1d35293 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -725,11 +725,11 @@ static irqreturn_t imx_rxint(int irq, void *dev_id)
>>  return IRQ_HANDLED;
>>  }
>>  
>> -static void imx_disable_rx_int(struct imx_port *sport)
>> +static void imx_disable_rx_int(struct imx_port *sport, bool is_rxing)
>>  {
>>  unsigned long temp;
>>  
>> -sport->dma_is_rxing = 1;
>> +sport->dma_is_rxing = is_rxing;
>>  
>>  /* disable the receiver ready and aging timer interrupts */
>>  temp = readl(sport->port.membase + UCR1);
>> @@ -762,7 +762,7 @@ static void imx_dma_rxint(struct imx_port *sport)
>>  temp = readl(sport->port.membase + USR2);
>>  if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
>>  
>> -imx_disable_rx_int(sport);
>> +imx_disable_rx_int(sport, false);
>>  
>>  /* tell the DMA to receive the data. */
>>  start_rx_dma(sport);
>> @@ -1083,6 +1083,7 @@ static int start_rx_dma(struct imx_port *sport)
>>  desc->callback_param = sport;
>>  
>>  dev_dbg(dev, "RX: prepare for the DMA.\n");
>> +sport->dma_is_rxing = 1;
>>  sport->rx_cookie = dmaengine_submit(desc);
>>  dma_async_issue_pending(chan);
>>  return 0;
>> @@ -1362,7 +1363,7 @@ static int imx_startup(struct uart_port *port)
>>  spin_unlock(>files_lock);
>>  
>>  if (readcnt > 0) {
>> -imx_disable_rx_int(sport);
>> +imx_disable_rx_int(sport, true);
> I wonder if it would be saner to not assign to dma_is_rxing in
> imx_disable_rx_int() at all but do this only in start_rx_dma() and
> imx_dma_rxint().

It was "mostly" done, in 4.11 in fact.  dma_is_rxing was set to 0 from
imx_dma_rxint() and was not set
at all from start_rx_dma(), resulting to the same issue. We could move
assignment of dma_is_rxing out of imx_disable_rx_int()
and set it to one from start_rx_dma() only. What do you think ?

Best Regards,
Romain

>
> Best regards
> Uwe
>

Re: [PATCH stable-only] mm: fix classzone_idx underflow in shrink_zones()

[Greg KH]

On Tue, Jul 04, 2017 at 10:45:43AM +0200, Vlastimil Babka wrote:
> Hi,
> 
> I realize this is against the standard stable policy, but I see no other
> way, because the mainline accidental fix is part of 34+ patch reclaim
> rework, that would be absurd to try to backport into stable. The fix is
> a one-liner though.
> 
> The bug affects at least 4.4.y, and likely also older stable trees that
> backported commit 7bf52fb891b6, which itself was a fix for 3.19 commit
> 6b4f7799c6a5. You could revert the 7bf52fb891b6 backport, but then 32bit
> with highmem might suffer from OOM or thrashing.

I need a bunch of acks from developers in this area before I can take
this patch :)

thanks,

greg k-h

Re: [PATCH] coccinelle: api: detect unnecessary le16_to_cpu

[Julia Lawall]

Here is a revised version (not a patch because it doesn't support all of
the various modes) and the results.  It doesn't return anything beyond
what was mentioned in previous mails.

For the following code:

ret = i2c_smbus_read_word_data(chip->client, reg << 1);
val[0] = (u16)ret & 0xFF;
val[1] = (u16)ret >> 8;

do we want to see:

put_unaligned(val,i2c_smbus_read_word_data(chip->client, reg << 1));

julia

---

@@
expression e, x;
@@

* x = i2c_smbus_read_word_data(...)
... when != x = e
* le16_to_cpu(x)

@@
expression e, e1, x, y;
@@

* x = i2c_smbus_read_word_data(...)
... when != x = e
* y = x;
... when != y = e1
* le16_to_cpu(y)

@@
@@

* le16_to_cpu(i2c_smbus_read_word_data(...))

// -

@@
expression e, e1, e2, x;
type T;
@@

* x = cpu_to_le16(...)
... when != x = e
* i2c_smbus_write_word_data(e1,e2,(T)x)

@@
expression e, e1, e2, e3, x, y;
type T;
@@

* x = cpu_to_le16(...)
... when != x = e
* y = x
... when != y = e3
* i2c_smbus_write_word_data(e1,e2,(T)y)

@@
expression e1,e2;
@@

* i2c_smbus_write_word_data(e1,e2,cpu_to_le16(...))

// -

@@
expression e1,e2;
typedef u16;
@@

*   e1[0] = (u16)e2 & 0xFF;
e1[1] = (u16)e2 >> 8;

---

- means line of interest, not line to remove.

diff -u -p a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -187,10 +187,7 @@ static int pca953x_write_regs_8(struct p

 static int pca953x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
 {
-   __le16 word = cpu_to_le16(get_unaligned((u16 *)val));

-   return i2c_smbus_write_word_data(chip->client,
-reg << 1, (__force u16)word);
 }

 static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
@@ -241,7 +238,6 @@ static int pca953x_read_regs_16(struct p
int ret;

ret = i2c_smbus_read_word_data(chip->client, reg << 1);
-   val[0] = (u16)ret & 0xFF;
val[1] = (u16)ret >> 8;

return ret;
diff -u -p a/drivers/macintosh/windfarm_smu_sat.c 
b/drivers/macintosh/windfarm_smu_sat.c
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -77,18 +77,15 @@ struct smu_sdbp_header *smu_sat_get_sdb_
return NULL;
}

-   err = i2c_smbus_read_word_data(sat->i2c, 9);
if (err < 0) {
printk(KERN_ERR "smu_sat_get_sdb_part rd len error\n");
return NULL;
}
-   len = err;
if (len == 0) {
printk(KERN_ERR "smu_sat_get_sdb_part no partition %x\n", id);
return NULL;
}

-   len = le16_to_cpu(len);
len = (len + 3) & ~3;
buf = kmalloc(len, GFP_KERNEL);
if (buf == NULL)
diff -u -p a/drivers/macintosh/windfarm_lm75_sensor.c 
b/drivers/macintosh/windfarm_lm75_sensor.c
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -68,7 +68,6 @@ static int wf_lm75_get(struct wf_sensor
}

/* Read temperature register */
-   data = (s32)le16_to_cpu(i2c_smbus_read_word_data(lm->i2c, 0));
data <<= 8;
*value = data;

Re: [PATCH 4.4 072/101] arm64: assembler: make adr_l work in modules under KASLR

[Ard Biesheuvel]

On 3 July 2017 at 14:35, Greg Kroah-Hartman  wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Ard Biesheuvel 
>
>
> [ Upstream commit 41c066f2c4d436c535616fe182331766c57838f0 ]
>
> When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> modules and the core kernel may exceed 4 GB, putting symbols exported
> by the core kernel out of the reach of the ordinary adrp/add instruction
> pairs used to generate relative symbol references. So make the adr_l
> macro emit a movz/movk sequence instead when executing in module context.
>
> While at it, remove the pointless special case for the stack pointer.
>

As it turns out, this 'pointless special case' was not so pointless in
v4.4, and removing it breaks the build.

Given that the only in-module user of adr_l is the new scalar AES
code, which is not backported to v4.4, there is really no point in
backporting this to v4.4.

-- 
Ard.


> Acked-by: Mark Rutland 
> Acked-by: Will Deacon 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Catalin Marinas 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  arch/arm64/include/asm/assembler.h |   36 
> +++-
>  1 file changed, 27 insertions(+), 9 deletions(-)
>
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -147,22 +147,25 @@ lr.reqx30 // link register
>
>  /*
>   * Pseudo-ops for PC-relative adr/ldr/str ,  where
> - *  is within the range +/- 4 GB of the PC.
> + *  is within the range +/- 4 GB of the PC when running
> + * in core kernel context. In module context, a movz/movk sequence
> + * is used, since modules may be loaded far away from the kernel
> + * when KASLR is in effect.
>   */
> /*
>  * @dst: destination register (64 bit wide)
>  * @sym: name of the symbol
> -* @tmp: optional scratch register to be used if  == sp, which
> -*   is not allowed in an adrp instruction
>  */
> -   .macro  adr_l, dst, sym, tmp=
> -   .ifb\tmp
> +   .macro  adr_l, dst, sym
> +#ifndef MODULE
> adrp\dst, \sym
> add \dst, \dst, :lo12:\sym
> -   .else
> -   adrp\tmp, \sym
> -   add \dst, \tmp, :lo12:\sym
> -   .endif
> +#else
> +   movz\dst, #:abs_g3:\sym
> +   movk\dst, #:abs_g2_nc:\sym
> +   movk\dst, #:abs_g1_nc:\sym
> +   movk\dst, #:abs_g0_nc:\sym
> +#endif
> .endm
>
> /*
> @@ -173,6 +176,7 @@ lr  .reqx30 // link register
>  *   the address
>  */
> .macro  ldr_l, dst, sym, tmp=
> +#ifndef MODULE
> .ifb\tmp
> adrp\dst, \sym
> ldr \dst, [\dst, :lo12:\sym]
> @@ -180,6 +184,15 @@ lr .reqx30 // link register
> adrp\tmp, \sym
> ldr \dst, [\tmp, :lo12:\sym]
> .endif
> +#else
> +   .ifb\tmp
> +   adr_l   \dst, \sym
> +   ldr \dst, [\dst]
> +   .else
> +   adr_l   \tmp, \sym
> +   ldr \dst, [\tmp]
> +   .endif
> +#endif
> .endm
>
> /*
> @@ -189,8 +202,13 @@ lr .reqx30 // link register
>  *   while  needs to be preserved.
>  */
> .macro  str_l, src, sym, tmp
> +#ifndef MODULE
> adrp\tmp, \sym
> str \src, [\tmp, :lo12:\sym]
> +#else
> +   adr_l   \tmp, \sym
> +   str \src, [\tmp]
> +#endif
> .endm
>
>  /*
>
>

Re: [PATCH v1 1/1] KVM: trigger uevents when starting or stopping a VM

[Paolo Bonzini]

On 04/07/2017 11:03, Claudio Imbrenda wrote:
> This patch adds a few lines to the KVM common code to fire a
> KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
> carries two environment variables:
> KVM_VM_CREATED which indicates how many times a new VM has been created,
> KVM_VM_COUNT which indicates how many VMs are currently active.

I'm not sure why KVM_VM_CREATED is useful, KVM_VM_COUNT can be a bit
more interesting though not much.

But since we are at it, let's also add a PID.  That one is the really
useful one, because it gives you something to look at in debugfs.
Another possibility is to add the debugfs directory name directly
(KVM_VM_STATS_PATH or something like that).

Paolo

> Specific udev rules can be then set up in userspace to deal with the
> creation or destruction of VMs as needed.
> 
> Signed-off-by: Claudio Imbrenda 
> ---
>  virt/kvm/kvm_main.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 6e3b12c..f67aa59 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -130,6 +130,10 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
>  
>  static bool largepages_enabled = true;
>  
> +static void kvm_uevent_notify_change(u64 created, u64 active);
> +static u64 kvm_createvm_count;
> +static u64 kvm_active_vms;
> +
>  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
>  {
>   if (pfn_valid(pfn))
> @@ -627,6 +631,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
>  {
>   int r, i;
>   struct kvm *kvm = kvm_arch_alloc_vm();
> + u64 activevms, createdvms;
>  
>   if (!kvm)
>   return ERR_PTR(-ENOMEM);
> @@ -686,9 +691,12 @@ static struct kvm *kvm_create_vm(unsigned long type)
>  
>   spin_lock(_lock);
>   list_add(>vm_list, _list);
> + createdvms = ++kvm_createvm_count;
> + activevms = ++kvm_active_vms;
>   spin_unlock(_lock);
>  
>   preempt_notifier_inc();
> + kvm_uevent_notify_change(createdvms, activevms);
>  
>   return kvm;
>  
> @@ -739,11 +747,14 @@ static void kvm_destroy_vm(struct kvm *kvm)
>  {
>   int i;
>   struct mm_struct *mm = kvm->mm;
> + u64 activevms, createdvms;
>  
>   kvm_destroy_vm_debugfs(kvm);
>   kvm_arch_sync_events(kvm);
>   spin_lock(_lock);
>   list_del(>vm_list);
> + activevms = --kvm_active_vms;
> + createdvms = kvm_createvm_count;
>   spin_unlock(_lock);
>   kvm_free_irq_routing(kvm);
>   for (i = 0; i < KVM_NR_BUSES; i++) {
> @@ -767,6 +778,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
>   preempt_notifier_dec();
>   hardware_disable_all();
>   mmdrop(mm);
> + kvm_uevent_notify_change(createdvms, activevms);
>  }
>  
>  void kvm_get_kvm(struct kvm *kvm)
> @@ -3864,6 +3876,19 @@ static const struct file_operations *stat_fops[] = {
>   [KVM_STAT_VM]   = _stat_fops,
>  };
>  
> +static void kvm_uevent_notify_change(u64 created, u64 active)
> +{
> + char createvm_buf[40];
> + char activevm_buf[40];
> + char *ptr[3] = {createvm_buf, activevm_buf, NULL};
> +
> + if (!kvm_dev.this_device)
> + return;
> + snprintf(createvm_buf, 40, "KVM_VM_CREATED=%llu", created);
> + snprintf(activevm_buf, 40, "KVM_VM_ACTIVE=%llu", active);
> + kobject_uevent_env(_dev.this_device->kobj, KOBJ_CHANGE, ptr);
> +}
> +
>  static int kvm_init_debug(void)
>  {
>   int r = -EEXIST;
> 

Re: [PATCH] staging: comedi: Use offset_in_page macro

[Ian Abbott]

On 04/07/17 00:13, Amitoj Kaur Chawla wrote:

Use offset_in_page macro instead of (var & ~PAGE_MASK)

The Coccinelle semantic patch used to make this change is as follows:
// 
@@
unsigned long p;
@@
- p & ~PAGE_MASK
+ offset_in_page(p)
// 

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/staging/comedi/comedi_buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/comedi_buf.c 
b/drivers/staging/comedi/comedi_buf.c
index 8e9b30b..b455ff6 100644
--- a/drivers/staging/comedi/comedi_buf.c
+++ b/drivers/staging/comedi/comedi_buf.c
@@ -165,7 +165,7 @@ int comedi_buf_map_put(struct comedi_buf_map *bm)
 int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
  void *buf, int len, int write)
 {
-   unsigned int pgoff = offset & ~PAGE_MASK;
+   unsigned int pgoff = offset_in_page(offset);
unsigned long pg = offset >> PAGE_SHIFT;
int done = 0;




Seems reasonable, thanks.  Being picky, I'd prefer it if the line 
`#include ` was added, since that is where the 
`offset_in_page` macro is defined.  But it doesn't matter that much as 
the "mm.h" header file gets included indirectly, and there are plenty of 
examples where `offset_in_page` is used without including  
directly.


Signed-off-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[patch V2 2/2] mm/memory-hotplug: Switch locking to a percpu rwsem

[Thomas Gleixner]

Andrey reported a potential deadlock with the memory hotplug lock and the
cpu hotplug lock.

The reason is that memory hotplug takes the memory hotplug lock and then
calls stop_machine() which calls get_online_cpus(). That's the reverse lock
order to get_online_cpus(); get_online_mems(); in mm/slub_common.c

The problem has been there forever. The reason why this was never reported
is that the cpu hotplug locking had this homebrewn recursive reader writer
semaphore construct which due to the recursion evaded the full lock dep
coverage. The memory hotplug code copied that construct verbatim and
therefor has similar issues.

Three steps to fix this:

1) Convert the memory hotplug locking to a per cpu rwsem so the potential
   issues get reported proper by lockdep.

2) Lock the online cpus in mem_hotplug_begin() before taking the memory
   hotplug rwsem and use stop_machine_cpuslocked() in the page_alloc code
   and use to avoid recursive locking.

3) The cpu hotpluck locking in #2 causes a recursive locking of the cpu
   hotplug lock via __offline_pages() -> lru_add_drain_all(). Solve this by
   invoking lru_add_drain_all_cpuslocked() instead.

Reported-by: Andrey Ryabinin 
Signed-off-by: Thomas Gleixner 
Cc: Michal Hocko 
Cc: linux...@kvack.org
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Vladimir Davydov 
---
 mm/memory_hotplug.c |   89 
 mm/page_alloc.c |2 -
 2 files changed, 16 insertions(+), 75 deletions(-)

--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -52,32 +52,17 @@ static void generic_online_page(struct p
 static online_page_callback_t online_page_callback = generic_online_page;
 static DEFINE_MUTEX(online_page_callback_lock);
 
-/* The same as the cpu_hotplug lock, but for memory hotplug. */
-static struct {
-   struct task_struct *active_writer;
-   struct mutex lock; /* Synchronizes accesses to refcount, */
-   /*
-* Also blocks the new readers during
-* an ongoing mem hotplug operation.
-*/
-   int refcount;
+DEFINE_STATIC_PERCPU_RWSEM(mem_hotplug_lock);
 
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-   struct lockdep_map dep_map;
-#endif
-} mem_hotplug = {
-   .active_writer = NULL,
-   .lock = __MUTEX_INITIALIZER(mem_hotplug.lock),
-   .refcount = 0,
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-   .dep_map = {.name = "mem_hotplug.lock" },
-#endif
-};
+void get_online_mems(void)
+{
+   percpu_down_read(_hotplug_lock);
+}
 
-/* Lockdep annotations for get/put_online_mems() and mem_hotplug_begin/end() */
-#define memhp_lock_acquire_read() lock_map_acquire_read(_hotplug.dep_map)
-#define memhp_lock_acquire()  lock_map_acquire(_hotplug.dep_map)
-#define memhp_lock_release()  lock_map_release(_hotplug.dep_map)
+void put_online_mems(void)
+{
+   percpu_up_read(_hotplug_lock);
+}
 
 #ifndef CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
 bool memhp_auto_online;
@@ -97,60 +82,16 @@ static int __init setup_memhp_default_st
 }
 __setup("memhp_default_state=", setup_memhp_default_state);
 
-void get_online_mems(void)
-{
-   might_sleep();
-   if (mem_hotplug.active_writer == current)
-   return;
-   memhp_lock_acquire_read();
-   mutex_lock(_hotplug.lock);
-   mem_hotplug.refcount++;
-   mutex_unlock(_hotplug.lock);
-
-}
-
-void put_online_mems(void)
-{
-   if (mem_hotplug.active_writer == current)
-   return;
-   mutex_lock(_hotplug.lock);
-
-   if (WARN_ON(!mem_hotplug.refcount))
-   mem_hotplug.refcount++; /* try to fix things up */
-
-   if (!--mem_hotplug.refcount && unlikely(mem_hotplug.active_writer))
-   wake_up_process(mem_hotplug.active_writer);
-   mutex_unlock(_hotplug.lock);
-   memhp_lock_release();
-
-}
-
-/* Serializes write accesses to mem_hotplug.active_writer. */
-static DEFINE_MUTEX(memory_add_remove_lock);
-
 void mem_hotplug_begin(void)
 {
-   mutex_lock(_add_remove_lock);
-
-   mem_hotplug.active_writer = current;
-
-   memhp_lock_acquire();
-   for (;;) {
-   mutex_lock(_hotplug.lock);
-   if (likely(!mem_hotplug.refcount))
-   break;
-   __set_current_state(TASK_UNINTERRUPTIBLE);
-   mutex_unlock(_hotplug.lock);
-   schedule();
-   }
+   cpus_read_lock();
+   percpu_down_write(_hotplug_lock);
 }
 
 void mem_hotplug_done(void)
 {
-   mem_hotplug.active_writer = NULL;
-   mutex_unlock(_hotplug.lock);
-   memhp_lock_release();
-   mutex_unlock(_add_remove_lock);
+   percpu_up_write(_hotplug_lock);
+   cpus_read_unlock();
 }
 
 /* add this memory to iomem resource */
@@ -1919,7 +1860,7 @@ static int __ref __offline_pages(unsigne
goto failed_removal;
ret = 0;
if (drain) {
-   

Re: [PATCH 1/6] ARM: dts: rockchip: add regulator nodes for rk3229-evb

[Frank Wang]

Hi Heiko,

On 2017/7/4 16:34, Heiko Stübner wrote:

Hi Frank,

Am Dienstag, 4. Juli 2017, 16:12:42 CEST schrieb Frank Wang:

This patch adds vcc_io, vdd_arm and vdd_log regulator nodes
for rk3229-evb board.

Signed-off-by: Frank Wang 
---
  arch/arm/boot/dts/rk3229-evb.dts | 54
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/rk3229-evb.dts
b/arch/arm/boot/dts/rk3229-evb.dts index 82e8a53..8b10c64 100644
--- a/arch/arm/boot/dts/rk3229-evb.dts
+++ b/arch/arm/boot/dts/rk3229-evb.dts
@@ -78,6 +78,52 @@
regulator-always-on;
regulator-boot-on;
};
+
+   vdd_arm: vdd-arm-regulator {
+   compatible = "pwm-regulator";
+   rockchip,pwm_id = <1>;
+   rockchip,pwm_voltage = <110>;

This doesn't look like a part of the mainline pwm-regulator binding
(both rockchip,* properties)


+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_arm";
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   };

please also add supplies for regulators. Information on supplies
should be easily extractable from the board schematics.

This not only results in a nice tree in debugfs (regulator/regulator_summary)
but also makes sure supplying regulators are not accidentially turned off.
(pwm-supply for pwm-regulators, vin-supply for fixed regulators)



+
+   vdd_log: vdd-log-regulator {
+   compatible = "pwm-regulator";
+   rockchip,pwm_id = <2>;
+   rockchip,pwm_voltage = <120>;
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   regulators {
+   compatible = "simple-bus";

don't create a subnode/bus for regulators. Just add them
regularly. Take a look at all the other boards (like rk3399-firefly,
gru, veyron) for reference.


+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vccio_1v8_reg: regulator@0 {

Same here, no regulator@0 please, just name this one
vccio_1v8: vccio-1v8-regulator {

(removed _reg from phandle and changed node name)


+   compatible = "regulator-fixed";
+   regulator-name = "vccio_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   vccio_3v3_reg: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+   };
  };


Thanks and noted your comments above. I will fix them (also include 
another comment about eMMC in PATCH 4/6 ) and resend these series soon.



BR.
Frank



Thanks
Heiko

[PATCH 1/3] irqchip: gic-v3: Report failures in gic_irq_domain_alloc

[Suzuki K Poulose]

If the GIC cannot map an IRQ via irq_domain_ops->alloc(), it doesn't
return an error code.  This can cause a problem with drivers, where
it thinks it has successfully got an IRQ for the device, but requesting
the same ends up failure with -ENOSYS (as the IRQ's chip is not set).

Fixes: commit 443acc4f37f6 ("irqchip: GICv3: Convert to domain hierarchy")
Cc: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
---
 drivers/irqchip/irq-gic-v3.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index fc037d9..ea82342 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -835,8 +835,11 @@ static int gic_irq_domain_alloc(struct irq_domain *domain, 
unsigned int virq,
if (ret)
return ret;
 
-   for (i = 0; i < nr_irqs; i++)
-   gic_irq_domain_map(domain, virq + i, hwirq + i);
+   for (i = 0; i < nr_irqs; i++) {
+   ret = gic_irq_domain_map(domain, virq + i, hwirq + i);
+   if (ret)
+   return ret;
+   }
 
return 0;
 }
-- 
2.7.5

Re: [PATCH 12/14] qcom: mtd: nand: change register offset defines with enums

[Archit Taneja]

On 06/29/2017 12:46 PM, Abhishek Sahu wrote:

The current driver defines the register offset with preprocessor
macro which is defined crossponding to NAND controller version
1.4.0. This patch changes these macro with enumeration. It also
adds mapping array which contains controller register offsets for
each register offset enumeration. This mapping array will be
referenced before each register read and writes, where the register
offset enumeration is being replaced with actual register offsets.

Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 136 +++---
  1 file changed, 89 insertions(+), 47 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 6d749b6..24750e6 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -24,43 +24,6 @@
  #include 
  #include 
  
-/* NANDc reg offsets */

-#defineNAND_FLASH_CMD  0x00
-#defineNAND_ADDR0  0x04
-#defineNAND_ADDR1  0x08
-#defineNAND_FLASH_CHIP_SELECT  0x0c
-#defineNAND_EXEC_CMD   0x10
-#defineNAND_FLASH_STATUS   0x14
-#defineNAND_BUFFER_STATUS  0x18
-#defineNAND_DEV0_CFG0  0x20
-#defineNAND_DEV0_CFG1  0x24
-#defineNAND_DEV0_ECC_CFG   0x28
-#defineNAND_DEV1_ECC_CFG   0x2c
-#defineNAND_DEV1_CFG0  0x30
-#defineNAND_DEV1_CFG1  0x34
-#defineNAND_READ_ID0x40
-#defineNAND_READ_STATUS0x44
-#defineNAND_DEV_CMD0   0xa0
-#defineNAND_DEV_CMD1   0xa4
-#defineNAND_DEV_CMD2   0xa8
-#defineNAND_DEV_CMD_VLD0xac
-#defineSFLASHC_BURST_CFG   0xe0
-#defineNAND_ERASED_CW_DETECT_CFG   0xe8
-#defineNAND_ERASED_CW_DETECT_STATUS0xec
-#defineNAND_EBI2_ECC_BUF_CFG   0xf0
-#defineFLASH_BUF_ACC   0x100
-
-#defineNAND_CTRL   0xf00
-#defineNAND_VERSION0xf08
-#defineNAND_READ_LOCATION_00xf20
-#defineNAND_READ_LOCATION_10xf24
-#defineNAND_READ_LOCATION_20xf28
-#defineNAND_READ_LOCATION_30xf2c
-
-/* dummy register offsets, used by write_reg_dma */
-#defineNAND_DEV_CMD1_RESTORE   0xdead
-#defineNAND_DEV_CMD_VLD_RESTORE0xbeef
-
  /* NAND_FLASH_CMD bits */
  #define   PAGE_ACCBIT(4)
  #define   LAST_PAGE   BIT(5)
@@ -204,6 +167,44 @@
  #define QPIC_PER_CW_MAX_CMD_SGL   (32)
  #define QPIC_PER_CW_MAX_DATA_SGL  (8)
  
+/* NANDc reg offsets enumeration */

+enum {
+   NAND_FLASH_CMD,
+   NAND_ADDR0,
+   NAND_ADDR1,
+   NAND_FLASH_CHIP_SELECT,
+   NAND_EXEC_CMD,
+   NAND_FLASH_STATUS,
+   NAND_BUFFER_STATUS,
+   NAND_DEV0_CFG0,
+   NAND_DEV0_CFG1,
+   NAND_DEV0_ECC_CFG,
+   NAND_DEV1_ECC_CFG,
+   NAND_DEV1_CFG0,
+   NAND_DEV1_CFG1,
+   NAND_READ_ID,
+   NAND_READ_STATUS,
+   NAND_DEV_CMD0,
+   NAND_DEV_CMD1,
+   NAND_DEV_CMD2,
+   NAND_DEV_CMD_VLD,
+   SFLASHC_BURST_CFG,
+   NAND_ERASED_CW_DETECT_CFG,
+   NAND_ERASED_CW_DETECT_STATUS,
+   NAND_EBI2_ECC_BUF_CFG,
+   FLASH_BUF_ACC,
+   NAND_CTRL,
+   NAND_VERSION,
+   NAND_READ_LOCATION_0,
+   NAND_READ_LOCATION_1,
+   NAND_READ_LOCATION_2,
+   NAND_READ_LOCATION_3,
+
+   /* dummy register offsets, used by write_reg_dma */
+   NAND_DEV_CMD1_RESTORE,
+   NAND_DEV_CMD_VLD_RESTORE,
+};
+
  /*
   * This data type corresponds to the BAM transaction which will be used for 
all
   * NAND transfers.
@@ -326,6 +327,7 @@ struct nandc_regs {
   *bam dma
   * @max_cwperpage:maximum qpic codeword required. calcualted
   *from all nand device pagesize
+ * @regs_offsets:  register offset mapping array
   */
  struct qcom_nand_controller {
struct nand_hw_control controller;
@@ -371,6 +373,7 @@ struct qcom_nand_controller {
  
  	u32 cmd1, vld;

u32 ecc_modes;
+   const u32 *regs_offsets;


minor quirk:

s/regs_offsets/reg_offsets


  };
  
  /*

@@ -434,6 +437,40 @@ struct qcom_nand_driver_data {
bool dma_bam_enabled;
  };
  
+/* Mapping table which contains the actual register offsets */

+static const u32 regs_offsets[] = {
+   [NAND_FLASH_CMD] = 0x00,
+   [NAND_ADDR0] = 0x04,
+   [NAND_ADDR1] = 0x08,
+   [NAND_FLASH_CHIP_SELECT] = 0x0c,
+   [NAND_EXEC_CMD] = 0x10,
+   [NAND_FLASH_STATUS] = 0x14,
+   

Re: [PATCH v4 2/3] arm64: kvm: route synchronous external abort exceptions to el2

[gengdongjiu]

Hi Christoffer,

On 2017/7/3 16:23, Christoffer Dall wrote:
> On Tue, Jun 27, 2017 at 08:15:49PM +0800, gengdongjiu wrote:
>> correct the commit message:
>>
>>  In the firmware-first RAS solution, OS receives an synchronous
>>  external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
>>  the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
>>  If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
>>  otherwise it delegates to the host OS kernel
> 
> This commit text has nothing (directly) to do with the content of the
> patch.  Whether or not seting these bits are used by firmware to emulate
> injecting an exception or by the CPU raising a an exception is not the
> core of the issue.
> 
> Please describe your change, then provide rationale.

(1)Below hcr_el2.TEA/TERR two field is introduced by armv8.2, RAS extension.

TEA, bit [37]
Route synchronous External Abort exceptions to EL2. The possible values 
of this bit are:
0 Do not route synchronous External Abort exceptions from Non-secure 
EL0 and EL1 to EL2.
1 Route synchronous External Abort exceptions from Non-secure EL0 and 
EL1 to EL2, if not routed
to EL3.
This bit is RES0 if the RAS extension is not implemented.
TERR, bit [36]
Trap Error record accesses. The possible values of this bit are:
0 Do not trap accesses to error record registers from Non-secure EL1 to 
EL2.
1 Accesses to the ER* registers from Non-secure EL1 generate a Trap 
exception to EL2.
This bit is RES0 if the RAS extension is not implemented.

(2) when synchronous External Abort(SEA) OS happen SEA, it trap to EL3 firmware.
then the firmware needs to do by faking an exception entry to  hypervisor EL2; 
or
by faking an exception entry to EL1
so if the hcr_el2.TEA is set, firmware will eret to EL2; otherwise, eret to EL1.
hcr_el2.TEA is only set for the guest OS.
not set for the host OS.


(3) setting hcr_el2.HCR_TERR want to trap the EL1 error record access to EL2.


> 
> Thanks,
> -Christoffer
> 
> 
>>
>>
>> On 2017/6/26 20:45, Dongjiu Geng wrote:
>>> In the firmware-first RAS solution, guest OS receives an synchronous
>>> external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
>>> the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
>>> If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
>>> otherwise it delegates to the guest OS kernel
>>>
>>> Signed-off-by: Dongjiu Geng 
>>> ---
>>>  arch/arm64/include/asm/kvm_arm.h | 2 ++
>>>  arch/arm64/include/asm/kvm_emulate.h | 7 +++
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_arm.h 
>>> b/arch/arm64/include/asm/kvm_arm.h
>>> index 61d694c..1188272 100644
>>> --- a/arch/arm64/include/asm/kvm_arm.h
>>> +++ b/arch/arm64/include/asm/kvm_arm.h
>>> @@ -23,6 +23,8 @@
>>>  #include 
>>>  
>>>  /* Hyp Configuration Register (HCR) bits */
>>> +#define HCR_TEA(UL(1) << 37)
>>> +#define HCR_TERR   (UL(1) << 36)
>>>  #define HCR_E2H(UL(1) << 34)
>>>  #define HCR_ID (UL(1) << 33)
>>>  #define HCR_CD (UL(1) << 32)
>>> diff --git a/arch/arm64/include/asm/kvm_emulate.h 
>>> b/arch/arm64/include/asm/kvm_emulate.h
>>> index f5ea0ba..5f64ab2 100644
>>> --- a/arch/arm64/include/asm/kvm_emulate.h
>>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>>> @@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
>>> vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>>> if (is_kernel_in_hyp_mode())
>>> vcpu->arch.hcr_el2 |= HCR_E2H;
>>> +   if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
>>> +   /* route synchronous external abort exceptions to EL2 */
>>> +   vcpu->arch.hcr_el2 |= HCR_TEA;
>>> +   /* trap error record accesses */
>>> +   vcpu->arch.hcr_el2 |= HCR_TERR;
>>> +   }
>>> +
>>> if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
>>> vcpu->arch.hcr_el2 &= ~HCR_RW;
>>>  }
>>>
>>
> 
> .
> 

[PATCH 3/4] selftests: ftrace: Add more verbosity for immediate log

[Masami Hiramatsu]

Add 3-level verbosity for showing traced command log
on console immediately. Since some test cases can cause
kernel pacic if there is a probrem (like regression etc.),
we can not know which command caused the problem without
traced command log. This verbosity (-vvv) solves that
because it shows the log on console immediately. User
can get continuous command/error log.

Note that this is a kind of kernel debug mode, if you
don't see any kernel related issue, you don't need this
verbosity.

Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
- Do not show failure log on console again.
---
 tools/testing/selftests/ftrace/ftracetest |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index e033f54..892ca4e 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -15,6 +15,7 @@ echo "-h|--help  Show help message"
 echo " -k|--keep  Keep passed test logs"
 echo " -v|--verbose Increase verbosity of test messages"
 echo " -vvAlias of -v -v (Show all results in stdout)"
+echo " -vvv   Alias of -v -v -v (Show all commands immediately)"
 echo " --fail-unsupported Treat UNSUPPORTED as a failure"
 echo " -d|--debug Debug mode (trace all shell commands)"
 echo " -l|--logdir  Save logs on the "
@@ -57,9 +58,10 @@ parse_opts() { # opts
   KEEP_LOG=1
   shift 1
 ;;
---verbose|-v|-vv)
+--verbose|-v|-vv|-vvv)
   VERBOSE=$((VERBOSE + 1))
   [ $1 = '-vv' ] && VERBOSE=$((VERBOSE + 1))
+  [ $1 = '-vvv' ] && VERBOSE=$((VERBOSE + 2))
   shift 1
 ;;
 --debug|-d)
@@ -258,7 +260,9 @@ run_test() { # testfile
   testcase $1
   echo "execute$INSTANCE: "$1 > $testlog
   SIG_RESULT=0
-  if [ $VERBOSE -ge 2 ]; then
+  if [ $VERBOSE -ge 3 ]; then
+__run_test $1 | tee -a $testlog 2>&1
+  elif [ $VERBOSE -eq 2 ]; then
 __run_test $1 2>> $testlog | tee -a $testlog
   else
 __run_test $1 >> $testlog 2>&1
@@ -268,7 +272,7 @@ run_test() { # testfile
 # Remove test log if the test was done as it was expected.
 [ $KEEP_LOG -eq 0 ] && rm $testlog
   else
-[ $VERBOSE -ge 1 ] && catlog $testlog
+[ $VERBOSE -eq 1 -o $VERBOSE -eq 2 ] && catlog $testlog
 TOTAL_RESULT=1
   fi
   rm -rf $TMPDIR

[PATCH 3/9] net, ipv6: convert inet6_ifaddr.refcnt from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 include/net/addrconf.h | 6 +++---
 include/net/if_inet6.h | 2 +-
 net/ipv6/addrconf.c| 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 620bd9a..6df79e9 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -350,18 +350,18 @@ void inet6_ifa_finish_destroy(struct inet6_ifaddr *ifp);
 
 static inline void in6_ifa_put(struct inet6_ifaddr *ifp)
 {
-   if (atomic_dec_and_test(>refcnt))
+   if (refcount_dec_and_test(>refcnt))
inet6_ifa_finish_destroy(ifp);
 }
 
 static inline void __in6_ifa_put(struct inet6_ifaddr *ifp)
 {
-   atomic_dec(>refcnt);
+   refcount_dec(>refcnt);
 }
 
 static inline void in6_ifa_hold(struct inet6_ifaddr *ifp)
 {
-   atomic_inc(>refcnt);
+   refcount_inc(>refcnt);
 }
 
 
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index e7a17b2..2b41cb8 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -46,7 +46,7 @@ struct inet6_ifaddr {
/* In seconds, relative to tstamp. Expiry is at tstamp + HZ * lft. */
__u32   valid_lft;
__u32   prefered_lft;
-   atomic_trefcnt;
+   refcount_t  refcnt;
spinlock_t  lock;
 
int state;
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2365f12..3c46e95 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1050,7 +1050,7 @@ ipv6_add_addr(struct inet6_dev *idev, const struct 
in6_addr *addr,
 
ifa->idev = idev;
/* For caller */
-   in6_ifa_hold(ifa);
+   refcount_set(>refcnt, 1);
 
/* Add to big hash table */
hash = inet6_addr_hash(addr);
-- 
2.7.4

Re: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations?

[Michal Hocko]

On Tue 04-07-17 14:11:41, Joonsoo Kim wrote:
> On Fri, Jun 30, 2017 at 05:44:16PM +0200, Michal Hocko wrote:
> > On Fri 30-06-17 17:42:24, Michal Hocko wrote:
> > [...]
> > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > > index 16532fa0bb64..894697c1e6f5 100644
> > > --- a/include/linux/mmzone.h
> > > +++ b/include/linux/mmzone.h
> > > @@ -1055,6 +1055,7 @@ static inline struct zoneref 
> > > *first_zones_zonelist(struct zonelist *zonelist,
> > >   !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
> > >  static inline unsigned long early_pfn_to_nid(unsigned long pfn)
> > >  {
> > > + BUILD_BUG_ON(!IS_ENABLED(CONFIG_NUMA));
> > 
> > Err, this should read BUILD_BUG_ON(IS_ENABLED(CONFIG_NUMA)) of course
> 
> Agreed.
> 
> However, AFAIK, ARM can set CONFIG_NUMA but it doesn't have
> CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID and CONFIG_HAVE_MEMBLOCK_NODE_MAP.

$ git grep "config NUMA\|select NUMA" arch/arm
$

Did you mean arch64? If yes this one looks ok
$ git grep "HAVE_MEMBLOCK_NODE_MAP\|HAVE_ARCH_EARLY_PFN_TO_NID" arch/arm64/
arch/arm64/Kconfig: select HAVE_MEMBLOCK_NODE_MAP if NUMA

> If page_ext uses early_pfn_to_nid(), it will cause build error in ARM.

Which would be intentional if it doesn't provide a proper implementation
of the function.
 
> Therefore, I suggest following change.
> CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on proper early_pfn_to_nid().
> So, following code will always work as long as
> CONFIG_DEFERRED_STRUCT_PAGE_INIT works.

I haven't checked all other callers of early_pfn_to_nid yet but I have
run my original patch (with !IS_ENABLED...) just to see whether anybody
actually uses this function from an innvalid context and it hasn't blown
up. So I suspect that all current users simply use the function from the
proper context. So if nobody objects I would just post the patch for
inclusion. If the compilation breaks we can think of a proper
implementation.

> 
> Thanks.
> 
> --->8---
> diff --git a/mm/page_ext.c b/mm/page_ext.c
> index 88ccc044..e3db259 100644
> --- a/mm/page_ext.c
> +++ b/mm/page_ext.c
> @@ -384,6 +384,7 @@ void __init page_ext_init(void)
>  
> for_each_node_state(nid, N_MEMORY) {
> unsigned long start_pfn, end_pfn;
> +   int page_nid;
>  
> start_pfn = node_start_pfn(nid);
> end_pfn = node_end_pfn(nid);
> @@ -405,8 +406,15 @@ void __init page_ext_init(void)
>  *
>  * Take into account DEFERRED_STRUCT_PAGE_INIT.
>  */
> -   if (early_pfn_to_nid(pfn) != nid)
> +#ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT
> +   page_nid = early_pfn_to_nid(pfn);
> +#else
> +   page_nid = pfn_to_nid(pfn);
> +#endif

I cannot say I would be happy about this ifdefery. Especially when there
is no existing user which would need it. 

> +
> +   if (page_nid != nid)
> continue;
> +
> if (init_section_page_ext(pfn, nid))
> goto oom;
> }

-- 
Michal Hocko
SUSE Labs

Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

[zhouxianrong]

i do the test again. after minutes i tell you the result.

On 2017/7/4 14:52, Michal Hocko wrote:

On Tue 04-07-17 09:21:00, zhouxianrong wrote:

the test was done as follows:

1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB


There have been many changes in the compaction proper since than. Do you
see the same problem with the current upstream kernel?


2. every 4s startup one apk, total 100 more apks need to startup
3. after finishing step 2, sample buddyinfo once and get the result


How stable are those results?

Re: [PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies

[Geert Uytterhoeven]

On Tue, Jun 13, 2017 at 12:09 AM, Babu Moger  wrote:
> Found this problem while enabling queued rwlock on SPARC.
> The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
> specific byte in qrwlock structure. Without this parameter,
> we clear the wrong byte.
> Here is the code in include/asm-generic/qrwlock.h
>
> static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
>   {
>  return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
>   }
>
> Also found few more references of this parameter in
> drivers/of/base.c
> drivers/of/fdt.c
> drivers/tty/serial/earlycon.c
> drivers/tty/serial/serial_core.c
>
> Here is our previous discussion.
> https://lkml.org/lkml/2017/5/24/620
>
> Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
> for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
> parisc and sparc). And warn if there are inconsistencies in this definition.
>
> v2 -> v3:
>  Added the choice statement for endianness selection for microblaze.
>  Updated the Makefile for microblaze(Suggested by Arnd Bergmann) to
>  properly compile for the correct format.
>  Updated acks.
>
> v1 -> v2:
>  Updated the commit messages and acks.
>
> Babu Moger (3):
>   arch: Define CPU_BIG_ENDIAN for all fixed big endian archs
>   arch/microblaze: Add choice for endianness and update Makefile
>   include: warn for inconsistent endian config definition
>
>  arch/frv/Kconfig|3 +++
>  arch/h8300/Kconfig  |3 +++
>  arch/m68k/Kconfig   |3 +++
>  arch/microblaze/Kconfig |   16 
>  arch/microblaze/Makefile|2 ++
>  arch/openrisc/Kconfig   |3 +++
>  arch/parisc/Kconfig |3 +++
>  arch/sparc/Kconfig  |3 +++
>  include/linux/byteorder/big_endian.h|4 
>  include/linux/byteorder/little_endian.h |4 
>  10 files changed, 44 insertions(+), 0 deletions(-)

We've just got a new user in c1b0bc2dabfa884d ("usb: typec:
Add support for UCSI interface").
So this series should definitely go in soon.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Peter Zijlstra]

On Mon, Jul 03, 2017 at 05:30:28PM +0200, Marc Gonzalez wrote:

> And at the end of smp8759_config_read:
> 
>   printk("in_atomic_preempt_off = %d\n", in_atomic_preempt_off());

That's confused...

>   stop_machine(do_nothing, NULL, NULL);
>   panic("STOP HERE FOR NOW\n");
> 
> The kernel outputs:
> 
> [1.022725] in_atomic_preempt_off = 0
> [1.026568] BUG: scheduling while atomic: swapper/0/1/0x0002
> [1.032625] 5 locks held by swapper/0/1:
> [1.036575]  #0:  (>mutex){..}, at: [] 
> __driver_attach+0x50/0xd0
> [1.044319]  #1:  (>mutex){..}, at: [] 
> __driver_attach+0x60/0xd0
> [1.052050]  #2:  (pci_lock){+.+...}, at: [] 
> pci_bus_read_config_dword+0x44/0x94

This is a raw_spinlock_t, that disables preemption

> [1.060398]  #3:  (cpu_hotplug.dep_map){++}, at: [] 
> get_online_cpus+0x2c/0xa0
> [1.068843]  #4:  (stop_cpus_mutex){+.+...}, at: [] 
> stop_cpus+0x20/0x48

> [1.076404] Modules linked in:
> [1.079483] Preemption disabled at:[1.082820] [<  (null)>]   (null)
> [1.086165] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.23-1-rc4 #13
> [1.092723] Hardware name: Sigma Tango DT
> [1.096765] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [1.104558] [] (show_stack) from [] 
> (dump_stack+0x98/0xc4)
> [1.111823] [] (dump_stack) from [] 
> (__schedule_bug+0x94/0xec)
> [1.119436] [] (__schedule_bug) from [] 
> (__schedule+0x4a4/0x5f0)
> [1.127220] [] (__schedule) from [] 
> (schedule+0x4c/0xac)


And here you try and schedule with preemption disabled.

> [1.134308] [] (schedule) from [] 
> (schedule_timeout+0x1f4/0x30c)
> [1.142093] [] (schedule_timeout) from [] 
> (wait_for_common+0x8c/0x13c)
> [1.150401] [] (wait_for_common) from [] 
> (wait_for_completion+0x10/0x14)
> [1.158886] [] (wait_for_completion) from [] 
> (__stop_cpus+0x50/0x64)
> [1.167021] [] (__stop_cpus) from [] 
> (stop_cpus+0x30/0x48)
> [1.174282] [] (stop_cpus) from [] 
> (stop_machine+0x84/0x118)
> [1.181719] [] (stop_machine) from [] 
> (smp8759_config_read+0x84/0x90)
> [1.189942] [] (smp8759_config_read) from [] 
> (pci_bus_read_config_dword+0x6c/0x94)
> [1.199301] [] (pci_bus_read_config_dword) from [] 
> (pci_bus_read_dev_vendor_id+0x24/0xe8)
> [1.209270] [] (pci_bus_read_dev_vendor_id) from [] 
> (pci_scan_single_device+0x40/0xb0)
> [1.218977] [] (pci_scan_single_device) from [] 
> (pci_scan_slot+0x58/0x100)
> [1.227636] [] (pci_scan_slot) from [] 
> (pci_scan_child_bus+0x20/0xf8)
> [1.235858] [] (pci_scan_child_bus) from [] 
> (pci_scan_root_bus_msi+0xcc/0xd8)
> [1.244779] [] (pci_scan_root_bus_msi) from [] 
> (pci_scan_root_bus+0x18/0x20)
> [1.253612] [] (pci_scan_root_bus) from [] 
> (pci_host_common_probe+0xc8/0x314)
> [1.262533] [] (pci_host_common_probe) from [] 
> (tango_pcie_probe+0x148/0x350)
> [1.271455] [] (tango_pcie_probe) from [] 
> (platform_drv_probe+0x34/0x6c)

> The panic call stack looks suspicious.
> 
> smp8759_config_read() never calls tango_check_pcie_link().
> 
> (I compile with -fno-optimize-sibling-calls to get more accurate
> call stacks.)
> 
> in_atomic_preempt_off is false before calling stop_machine()

Yes, but that's a pointless statement.

> I suppose I'm doing something wrong, but I'm not sure what yet.

Using stop_machine() is per definition doing it wrong ;-) But see above.

Re: [GIT pull] x86/timers updates for 4.13

[Thomas Gleixner]

On Mon, 3 Jul 2017, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 1:20 AM, Thomas Gleixner  wrote:
> >
> > This update contains:
> >
> >- The final solution for the TSC deadline timer borkage, which is caused
> >  by a hardware problem in the TSC_ADJUST/TSC_DEADLINE_TIMER logic.
> >
> >  The problem is documented now fixed with a microcode update, so we can
> >  remove the workaround and check for the microcode version. If the
> >  microcode is not up to date, then the TSC deadline timer is
> >  enabled. If the borkage is fixed by the proper micro code version,
> >  then the deadline timer can be used. In both cases the restrictions to
> >  the range of the TSC_ADJUST value, which were added as workarounds,
> >  are removed.
> >
> >   - A few simple fixes and updates to the timer related x86 code.
> 
> That deadline timer explanation made no sense.

Indeed. Sorry.

> I edited it to what I think you wanted to say in the commit message.

Yes. Thank you for fixing it up!

 tglx

Re: [PATCH v2] sched/pelt: fix false running accounting

[Peter Zijlstra]

On Sat, Jul 01, 2017 at 07:06:13AM +0200, Vincent Guittot wrote:
> The running state is a subset of runnable state which means that running
> can't be set if runnable (weight) is cleared. There are corner cases
> where the current sched_entity has been already dequeued but cfs_rq->curr
> has not been updated yet and still points to the dequeued sched_entity.
> If ___update_load_avg is called at that time, weight will be 0 and running
> will be set which is not possible.
> 
> This case happens during pick_next_task_fair() when a cfs_rq becomes idles.
> The current sched_entity has been dequeued so se->on_rq is cleared and
> cfs_rq->weight is null. But cfs_rq->curr still points to se (it will be
> cleared when picking the idle thread). Because the cfs_rq becomes idle,
> idle_balance() is called and ends up to call update_blocked_averages()
> with these wrong running and runnable states.
> 
> Add a test in ___update_load_avg to correct the running state in this case.

Cute, however did you find that ?

Re: [PATCH v6 11/18] xen/pvcalls: implement accept command

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Implement the accept command by calling inet_accept. To avoid blocking
> in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
> scheduled on sk_data_ready (for a passive socket, it means that there
> are connections to accept).
> 
> Use the reqcopy field to store the request. Accept the new socket from
> the delayed work function, create a new sock_mapping for it, map
> the indexes page and data ring, and reply to the other end. Allocate an
> ioworker for the socket.
> 
> Only support one outstanding blocking accept request for every socket at
> any time.
> 
> Add a field to sock_mapping to remember the passive socket from which an
> active socket was created.
> 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

Re: [PATCH 4/5] pwm: rockchip: Add atomic updated feature for rk3328

[David.Wu]

Hi Boris,

在 2017/7/4 2:39, Boris Brezillon 写道:

Yet another customization. Don't you think we can extract common parts,
expose them as helpers and then have 3 different pwm_ops (with 3
different ->apply() implementation), one for each IP revision.


Sounds reasonable.I will try to implement 3 different apply().

Re: [PATCH v2] sched/pelt: fix false running accounting

[Vincent Guittot]

On 4 July 2017 at 09:27, Peter Zijlstra  wrote:
> On Sat, Jul 01, 2017 at 07:06:13AM +0200, Vincent Guittot wrote:
>> The running state is a subset of runnable state which means that running
>> can't be set if runnable (weight) is cleared. There are corner cases
>> where the current sched_entity has been already dequeued but cfs_rq->curr
>> has not been updated yet and still points to the dequeued sched_entity.
>> If ___update_load_avg is called at that time, weight will be 0 and running
>> will be set which is not possible.
>>
>> This case happens during pick_next_task_fair() when a cfs_rq becomes idles.
>> The current sched_entity has been dequeued so se->on_rq is cleared and
>> cfs_rq->weight is null. But cfs_rq->curr still points to se (it will be
>> cleared when picking the idle thread). Because the cfs_rq becomes idle,
>> idle_balance() is called and ends up to call update_blocked_averages()
>> with these wrong running and runnable states.
>>
>> Add a test in ___update_load_avg to correct the running state in this case.
>
> Cute, however did you find that ?

In fact, while rebasing and running more tests on my patch "update
scale invariance of PELT" that changes how to scale the load and
utilization, I have seen that sometimes the utilization was increasing
but not the load when CPU was going into idle state because the
stolen_idle time was applied as idle time for load but running time
for utilization. This patch has highlighted the problem.

Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

[zhouxianrong]

every 2s i sample /proc/buddyinfo in the whole test process.

the last about 90 samples were sampled after the test was done.

Node 0, zone  DMA
  4706   2099838266 50  5  3  2  1  2 38
 0395   1261211 57  6  1  0  0  0  0
Node 0, zone  DMA
  4691   2107833265 50  5  3  2  1  2 38
 0395   1260211 57  6  1  0  0  0  0
Node 0, zone  DMA
  1815   1437791266 51  6  2  2  1  2 38
 0244   1275211 57  6  1  0  0  0  0
Node 0, zone  DMA
  1465   1030796267 51  6  2  2  1  2 38
 0246   1279211 57  6  1  0  0  0  0
Node 0, zone  DMA
  1378   1114791260 51  6  2  2  1  2 38
 0183   1282216 54  3  1  0  0  0  0
Node 0, zone  DMA
  2605   2021619260 51  6  2  2  1  2 38
 0307   1330220 54  3  1  0  0  0  0
Node 0, zone  DMA
  2465   2026618260 51  6  2  2  1  2 38
 0312   1330220 54  3  1  0  0  0  0
Node 0, zone  DMA
   758766462224 43  6  2  2  1  2 38
 0148   1082194 50  3  1  0  0  0  0
Node 0, zone  DMA
   912939472224 43  6  2  2  1  2 38
 0174   1086194 50  3  1  0  0  0  0
Node 0, zone  DMA
   502   1049428226 44  6  2  2  1  2 38
 0187   1092198 50  3  1  0  0  0  0
Node 0, zone  DMA
   747   1338671228 46  6  2  2  1  2 38
 0222   1180204 51  3  1  0  0  0  0
Node 0, zone  DMA
   675   1351667226 46  6  2  2  1  2 38
 0220   1180204 52  3  1  0  0  0  0
Node 0, zone  DMA
   865787266220 45  6  2  2  1  2 38
 0116984203 51  3  1  0  0  0  0
Node 0, zone  DMA
  1915   1233351261 47  6  2  2  1  2 38
 0179   1191230 53  3  1  0  0  0  0
Node 0, zone  DMA
  2078   1348402258 46  6  2  2  1  2 38
 0183   1233228 53  3  1  0  0  0  0
Node 0, zone  DMA
  2940   1129457259 46  6  2  2  1  2 38
 0209   1239229 54  3  1  0  0  0  0
Node 0, zone  DMA
  2906   1127457259 46  6  2  2  1  2 38
 0222   1240230 54  3  1  0  0  0  0
Node 0, zone  DMA
  1540   1093475256 46  6  2  2  1  2 38
 0293   1234227 54  3  1  0  0  0  0
Node 0, zone  DMA
  1060   1071487257 46  6  2  2  1  2 38
 0297   1238227 54  3  1  0  0  0  0
Node 0, zone  DMA
  1693869405267 46  6  2  2  1  2 38
 0243   1480230 54  3  1  0  0  0  0
Node 0, zone  DMA
  1720928426269 46  6  2  2  1  2 38
 0260   1485230 54  3  1  0  0  0  0
Node 0, zone  DMA
   546601393269 46  6  2  2  1  2 38
 0193   1314230 54  3  1  0  0  0  0
Node 0, zone  DMA
   583336 28 42 20  3  2  2  2  2 36
 0 15 43  5 20  1  1  0  0  0  0
Node 0, zone  DMA
   592382 27 39 21  3  2  2  2  2 36
 0 17 27  5 21  1  1  0  0  0  0
Node 0, zone  DMA
  3534   1510212 78 35  6  3  3  1  2 32
 0122333 66 28  2  1  0  0  0  0
Node 0, zone  DMA
  3411   1521212 78 35  6  3  3  1  2 32
 0123334 67 28  2  1  0  0  0  0
Node 0, zone  DMA
  1521   1521211 79 35  6  3  3  1  2 32
 0118336 68 28  2  1  0  0  0  0
Node 0, zone  DMA
 3  1  2  0  3  3  1  1  1  3 18
 0  2  

Re: [PATCH] vmalloc: respect the GFP_NOIO and GFP_NOFS flags

[Michal Hocko]

On Mon 03-07-17 18:57:14, Mikulas Patocka wrote:
> 
> 
> On Mon, 3 Jul 2017, Michal Hocko wrote:
> 
> > We can add a warning (or move it from kvmalloc) and hope that the
> > respective maintainers will fix those places properly. The reason I
> > didn't add the warning to vmalloc and kept it in kvmalloc was to catch
> > only new users rather than suddenly splat on existing ones. Note that
> > there are users with panic_on_warn enabled.
> > 
> > Considering how many NOFS users we have in tree I would rather work with
> > maintainers to fix them.
> 
> So - do you want this patch?

no, see below
 
> I still believe that the previous patch that pushes 
> memalloc_noio/nofs_save into __vmalloc is better than this.

It is, but both of them are actually wrong. Why? Because that would be
just a mindless application of the scope where the scope doesn't match
the actual reclaim recursion restricted scope. Really, the right way to
go is to simply talk to the respective maintainers. Find out whether
NOFS context is really needed and if so find the scope (e.g. a lock
which would be needed in the reclaim context) and document it. This is
not a trivial work to do but a) we do not seem to have any bug reports
complaining about these call sites so there is no need to hurry and b)
this will result in a cleaner and easier to maintain code.
-- 
Michal Hocko
SUSE Labs

[PATCH stable-only] mm: fix classzone_idx underflow in shrink_zones()

[Vlastimil Babka]

Hi,

I realize this is against the standard stable policy, but I see no other
way, because the mainline accidental fix is part of 34+ patch reclaim
rework, that would be absurd to try to backport into stable. The fix is
a one-liner though.

The bug affects at least 4.4.y, and likely also older stable trees that
backported commit 7bf52fb891b6, which itself was a fix for 3.19 commit
6b4f7799c6a5. You could revert the 7bf52fb891b6 backport, but then 32bit
with highmem might suffer from OOM or thrashing.

More details in the changelog itself.

8<
>From a1a1e459276298ac98827520e07923aa1219dbe1 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka 
Date: Thu, 22 Jun 2017 16:23:13 +0200
Subject: [PATCH] mm: fix classzone_idx underflow in shrink_zones()

We've got reported a BUG in do_try_to_free_pages():

BUG: unable to handle kernel paging request at 8ff28990
IP: [] do_try_to_free_pages+0x140/0x490
PGD 0
Oops:  [#1] SMP
megaraid_sas sg scsi_mod efivarfs autofs4
Supported: No, Unsupported modules are loaded
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
task: 88ffd0d4c540 ti: 88ffd0e48000 task.ti: 88ffd0e48000
RIP: 0010:[]  [] 
do_try_to_free_pages+0x140/0x490
RSP: 0018:88ffd0e4ba60  EFLAGS: 00010206
RAX: 06fff900 RBX:  RCX: 88f29000
RDX: 0000 RSI: 0003 RDI: 024200c8
RBP: 01320122 R08:  R09: 88ffd0e4bbac
R10:  R11:  R12: 88ffd0e4bae0
R13: 0e00 R14: 88f2a500 R15: 88f2b300
FS:  () GS:88ffe644() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 8ff28990 CR3: 01c0a000 CR4: 003406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Stack:
 0002db570a80 024200c8001e 88f2b300 
 88fd5700 88ffd0d4c540 88ffd0d4c540 000c
  0040 024200c8 88ffd0e4bae0
Call Trace:
 [] try_to_free_pages+0xba/0x170
 [] __alloc_pages_nodemask+0x53f/0xb20
 [] alloc_pages_current+0x7f/0x100
 [] migrate_pages+0x202/0x710
 [] __offline_pages.constprop.23+0x4ba/0x790
 [] memory_subsys_offline+0x43/0x70
 [] device_offline+0x7d/0xa0
 [] acpi_bus_offline+0xa5/0xef
 [] acpi_device_hotplug+0x21b/0x41f
 [] acpi_hotplug_work_fn+0x1a/0x23
 [] process_one_work+0x14e/0x410
 [] worker_thread+0x116/0x490
 [] kthread+0xbd/0xe0
 [] ret_from_fork+0x3f/0x70

This translates to the loop in shrink_zone():

classzone_idx = requested_highidx;
while (!populated_zone(zone->zone_pgdat->node_zones +
classzone_idx))
classzone_idx--;

where no zone is populated, so classzone_idx becomes -1 (in RBX).

Added debugging output reveals that we enter the function with
sc->gfp_mask == GFP_NOFS|__GFP_NOFAIL|__GFP_HARDWALL|__GFP_MOVABLE
requested_highidx = gfp_zone(sc->gfp_mask) == 2 (ZONE_NORMAL)

Inside the for loop, however:
gfp_zone(sc->gfp_mask) == 3 (ZONE_MOVABLE)

This means we have gone through this branch:

if (buffer_heads_over_limit)
sc->gfp_mask |= __GFP_HIGHMEM;

This changes the gfp_zone() result, but requested_highidx remains unchanged.
On nodes where the only populated zone is movable, the inner while loop will
check only lower zones, which are not populated, and underflow classzone_idx.

To sum up, the bug occurs in configurations with ZONE_MOVABLE (such as when
booted with the movable_node parameter) and only in situations when
buffer_heads_over_limit is true, and there's an allocation with __GFP_MOVABLE
and without __GFP_HIGHMEM performing direct reclaim.

This patch makes sure that classzone_idx starts with the correct zone.

Mainline has been affected in versions 4.6 and 4.7, but the culprit commit has
been also included in stable trees.
In mainline, this has been fixed accidentally as part of 34-patch series (plus
follow-up fixes) "Move LRU page reclaim from zones to nodes", which makes the
mainline commit unsuitable for stable backport, unfortunately.

Fixes: 7bf52fb891b6 ("mm: vmscan: reclaim highmem zone if buffer_heads is over 
limit")
Obsoleted-by: b2e18757f2c9 ("mm, vmscan: begin reclaiming pages on a per-node 
basis")
Debugged-by: Michal Hocko 
Signed-off-by: Vlastimil Babka 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: 

---
 mm/vmscan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2539,7 +2539,7 @@ static bool shrink_zones(struct zonelist
if (!populated_zone(zone))
continue;
 
-   classzone_idx = requested_highidx;
+   classzone_idx = gfp_zone(sc->gfp_mask);
while 

[GIT PULL] hsi changes for hsi-4.13

[Sebastian Reichel]

Hi Linus,

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git 
tags/hsi-for-4.13

for you to fetch changes up to 67ddd75771b6b860bc0cebb3b7fd4cbebeda9cd4:

  HSI: core: Use kcalloc() in two functions (2017-06-08 13:21:43 +0200)


HSI changes for the v4.13 series

* misc. cleanups


Markus Elfring (8):
  HSI: nokia-modem: Use devm_kcalloc() in nokia_modem_gpio_probe()
  HSI: nokia-modem: Delete error messages for a failed memory allocation in 
two functions
  HSI: nokia-modem: Add a space character for better code readability in 
nokia_modem_probe()
  HSI: omap_ssi: Use devm_kcalloc() in ssi_add_controller()
  HSI: omap_ssi: Fix a typo in a comment line
  HSI: omap_ssi: Delete an error message for a failed memory allocation in 
ssi_add_controller()
  HSI: Use kcalloc() in hsi_register_board_info()
  HSI: core: Use kcalloc() in two functions

 drivers/hsi/clients/nokia-modem.c   | 15 ++-
 drivers/hsi/controllers/omap_ssi_core.c | 10 --
 drivers/hsi/hsi_boardinfo.c |  2 +-
 drivers/hsi/hsi_core.c  |  7 +++
 4 files changed, 14 insertions(+), 20 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH v5 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

[Jose Abreu]

Hi Hans,


On 03-07-2017 11:33, Hans Verkuil wrote:
> On 07/03/2017 11:53 AM, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 03-07-2017 10:27, Hans Verkuil wrote:
>>> On 06/29/2017 12:46 PM, Jose Abreu wrote:
 This is an initial submission for the Synopsys Designware
 HDMI RX
 Controller Driver. This driver interacts with a phy driver so
 that
 a communication between them is created and a video pipeline is
 configured.

 The controller + phy pipeline can then be integrated into a
 fully
 featured system that can be able to receive video up to 4k@60Hz
 with deep color 48bit RGB, depending on the platform. Although,
 this initial version does not yet handle deep color modes.

 This driver was implemented as a standard V4L2 subdevice and
 its
 main features are:
  - Internal state machine that reconfigures phy until the
  video is not stable
  - JTAG communication with phy
  - Inter-module communication with phy driver
  - Debug write/read ioctls

 Some notes:
  - RX sense controller (cable connection/disconnection)
 must
  be handled by the platform wrapper as this is not
 integrated
  into the controller RTL
  - The same goes for EDID ROM's
  - ZCAL calibration is needed only in FPGA platforms, in
 ASIC
  this is not needed
  - The state machine is not an ideal solution as it
 creates a
  kthread but it is needed because some sources might not be
  very stable at sending the video (i.e. we must react
  accordingly).

 Signed-off-by: Jose Abreu 
 Cc: Carlos Palminha 
 Cc: Mauro Carvalho Chehab 
 Cc: Hans Verkuil 
 Cc: Sylwester Nawrocki 

 Changes from v4:
  - Add flag V4L2_SUBDEV_FL_HAS_DEVNODE (Sylwester)
  - Remove some comments and change some messages to dev_dbg
 (Sylwester)
  - Use v4l2_async_subnotifier_register() (Sylwester)
 Changes from v3:
  - Use v4l2 async API (Sylwester)
  - Do not block waiting for phy
  - Do not use busy waiting delays (Sylwester)
  - Simplify dw_hdmi_power_on (Sylwester)
  - Use clock API (Sylwester)
  - Use compatible string (Sylwester)
  - Minor fixes (Sylwester)
 Changes from v2:
  - Address review comments from Hans regarding CEC
  - Use CEC notifier
  - Enable SCDC
 Changes from v1:
  - Add support for CEC
  - Correct typo errors
  - Correctly detect interlaced video modes
  - Correct VIC parsing
 Changes from RFC:
  - Add support for HDCP 1.4
  - Fixup HDMI_VIC not being parsed (Hans)
  - Send source change signal when powering off (Hans)
  - Add a "wait stable delay"
  - Detect interlaced video modes (Hans)
  - Restrain g/s_register from reading/writing to HDCP regs
 (Hans)
 ---
drivers/media/platform/dwc/Kconfig  |   15 +
drivers/media/platform/dwc/Makefile |1 +
drivers/media/platform/dwc/dw-hdmi-rx.c | 1824
 +++
drivers/media/platform/dwc/dw-hdmi-rx.h |  441 
include/media/dwc/dw-hdmi-rx-pdata.h|   97 ++
5 files changed, 2378 insertions(+)
create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c
create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h
create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h

 diff --git a/drivers/media/platform/dwc/Kconfig
 b/drivers/media/platform/dwc/Kconfig
 index 361d38d..3ddccde 100644
 --- a/drivers/media/platform/dwc/Kconfig
 +++ b/drivers/media/platform/dwc/Kconfig
 @@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405
To compile this driver as a module, choose M here.
 The module
  will be called dw-hdmi-phy-e405.
 +
 +config VIDEO_DWC_HDMI_RX
 +tristate "Synopsys Designware HDMI Receiver driver"
 +depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
 +help
 +  Support for Synopsys Designware HDMI RX controller.
 +
 +  To compile this driver as a module, choose M here. The
 module
 +  will be called dw-hdmi-rx.
 +
 +config VIDEO_DWC_HDMI_RX_CEC
 +bool
 +depends on VIDEO_DWC_HDMI_RX
 +select CEC_CORE
 +select CEC_NOTIFIER
 diff --git a/drivers/media/platform/dwc/Makefile
 b/drivers/media/platform/dwc/Makefile
 index fc3b62c..cd04ca9 100644
 --- a/drivers/media/platform/dwc/Makefile
 +++ b/drivers/media/platform/dwc/Makefile
 @@ -1 +1,2 @@
obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
 +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o
 diff --git 

Re: [PATCH] mm: disallow early_pfn_to_nid on configurations which do not implement it

[Vlastimil Babka]

On 07/04/2017 09:58 AM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> early_pfn_to_nid will return node 0 if both HAVE_ARCH_EARLY_PFN_TO_NID
> and HAVE_MEMBLOCK_NODE_MAP are disabled. It seems we are safe now
> because all architectures which support NUMA define one of them (with an
> exception of alpha which however has CONFIG_NUMA marked as broken) so
> this works as expected. It can get silently and subtly broken too
> easily, though. Make sure we fail the compilation if NUMA is enabled and
> there is no proper implementation for this function. If that ever
> happens we know that either the specific configuration is invalid
> and the fix should either disable NUMA or enable one of the above
> configs.
> 
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

> ---
> Hi,
> I have brought this up earlier [1] because I thought the deferred
> initialization might be broken but then found out that this is not the
> case right now. This is an attempt to prevent any subtly broken users in
> future.
> 
> [1] http://lkml.kernel.org/r/20170630141847.gn22...@dhcp22.suse.cz
> 
>  include/linux/mmzone.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 16532fa0bb64..fc14b8b3f6ce 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1055,6 +1055,7 @@ static inline struct zoneref 
> *first_zones_zonelist(struct zonelist *zonelist,
>   !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
>  static inline unsigned long early_pfn_to_nid(unsigned long pfn)
>  {
> + BUILD_BUG_ON(IS_ENABLED(CONFIG_NUMA));
>   return 0;
>  }
>  #endif
> 

Re: [PATCH 4.4 072/101] arm64: assembler: make adr_l work in modules under KASLR

[Greg Kroah-Hartman]

On Tue, Jul 04, 2017 at 10:24:37AM +0100, Ard Biesheuvel wrote:
> On 3 July 2017 at 14:35, Greg Kroah-Hartman  
> wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ard Biesheuvel 
> >
> >
> > [ Upstream commit 41c066f2c4d436c535616fe182331766c57838f0 ]
> >
> > When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> > modules and the core kernel may exceed 4 GB, putting symbols exported
> > by the core kernel out of the reach of the ordinary adrp/add instruction
> > pairs used to generate relative symbol references. So make the adr_l
> > macro emit a movz/movk sequence instead when executing in module context.
> >
> > While at it, remove the pointless special case for the stack pointer.
> >
> 
> As it turns out, this 'pointless special case' was not so pointless in
> v4.4, and removing it breaks the build.
> 
> Given that the only in-module user of adr_l is the new scalar AES
> code, which is not backported to v4.4, there is really no point in
> backporting this to v4.4.

Yes, I dropped it from the tree about 2 hours ago after the build-bots
reported it killed things :)

thanks,

greg k-h

[PATCH 2/6] Staging: rtl8712 : os_intfs.c: use octal permission representation

[Jaya Durga]

Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not 
preferred.
Consider using octal permissions '0644'.

Signed-off-by: Jaya Durga 
---
 drivers/staging/rtl8712/os_intfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/os_intfs.c 
b/drivers/staging/rtl8712/os_intfs.c
index 8836b31..e698f6e 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -93,7 +93,7 @@
  */
 static int wifi_test;
 
-module_param_string(ifname, ifname, sizeof(ifname), S_IRUGO | S_IWUSR);
+module_param_string(ifname, ifname, sizeof(ifname), 0644);
 module_param(wifi_test, int, 0644);
 module_param(initmac, charp, 0644);
 module_param(video_mode, int, 0644);
-- 
1.9.1

[v2] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

When working with wl18xx the nvs file is used for defining an alternate
mac address and override the default mac address that is stored inside
the wl18xx chip.

The following commits:
c815fde wlcore: spi: Populate config firmware data
d776fc8 wlcore: sdio: Populate config firmware data

Populated the nvs entry for wilink6 and wilink7 only while it is 
still needed for wilink8 as well. 
This broke user space backward compatibility when upgrading from older 
kernels, as the alternate mac address would not be read from the nvs that is 
already present in the file system 
(lib/firmware/ti-connectivity/wl1271-nvs.bin) 
causing mac address change of the wlan interface.

This patch fix this and update the structure field with the same default nvs 
file 
name that has been used before.

Cc: stable 
Signed-off-by: Eyal Reizer 
---
 drivers/net/wireless/ti/wlcore/sdio.c | 1 +
 drivers/net/wireless/ti/wlcore/spi.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2fb3871..f8a1fea 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -230,6 +230,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 static const struct of_device_id wlcore_sdio_of_match_table[] = {
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index fdabb92..62ce54a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -92,6 +92,7 @@ static const struct wilink_family_data wl128x_data = {
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
.cfg_name = "ti-connectivity/wl18xx-conf.bin",
+   .nvs_name = "ti-connectivity/wl1271-nvs.bin",
 };
 
 struct wl12xx_spi_glue {
-- 
2.7.4

Re: [PATCH v6 06/18] xen/pvcalls: handle commands from the frontend

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> When the other end notifies us that there are commands to be read
> (pvcalls_back_event), wake up the backend thread to parse the command.
> 
> The command ring works like most other Xen rings, so use the usual
> ring macros to read and write to it. The functions implementing the
> commands are empty stubs for now.
> 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-back.c | 144 
> -
>  1 file changed, 129 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index e4c2e46..9e00971 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -47,16 +47,135 @@ struct pvcalls_fedata {
>   struct list_head socket_mappings;
>   struct radix_tree_root socketpass_mappings;
>   struct semaphore socket_lock;
> - struct workqueue_struct *wq;
> - struct work_struct register_work;
>  };
>  
> -static void pvcalls_back_work(struct work_struct *work)
> +static int pvcalls_back_socket(struct xenbus_device *dev,
> + struct xen_pvcalls_request *req)
>  {
> + return 0;
> +}
> +
> +static int pvcalls_back_connect(struct xenbus_device *dev,
> + struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_release(struct xenbus_device *dev,
> + struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_bind(struct xenbus_device *dev,
> +  struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_listen(struct xenbus_device *dev,
> +struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_accept(struct xenbus_device *dev,
> +struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_poll(struct xenbus_device *dev,
> +  struct xen_pvcalls_request *req)
> +{
> + return 0;
> +}
> +
> +static int pvcalls_back_handle_cmd(struct xenbus_device *dev,
> +struct xen_pvcalls_request *req)
> +{
> + int ret = 0;
> +
> + switch (req->cmd) {
> + case PVCALLS_SOCKET:
> + ret = pvcalls_back_socket(dev, req);
> + break;
> + case PVCALLS_CONNECT:
> + ret = pvcalls_back_connect(dev, req);
> + break;
> + case PVCALLS_RELEASE:
> + ret = pvcalls_back_release(dev, req);
> + break;
> + case PVCALLS_BIND:
> + ret = pvcalls_back_bind(dev, req);
> + break;
> + case PVCALLS_LISTEN:
> + ret = pvcalls_back_listen(dev, req);
> + break;
> + case PVCALLS_ACCEPT:
> + ret = pvcalls_back_accept(dev, req);
> + break;
> + case PVCALLS_POLL:
> + ret = pvcalls_back_poll(dev, req);
> + break;
> + default:
> + {
> + struct pvcalls_fedata *fedata;
> + struct xen_pvcalls_response *rsp;
> +
> + fedata = dev_get_drvdata(>dev);
> + rsp = RING_GET_RESPONSE(
> + >ring, fedata->ring.rsp_prod_pvt++);
> + rsp->req_id = req->req_id;
> + rsp->cmd = req->cmd;
> + rsp->ret = -ENOTSUPP;
> + break;
> + }
> + }
> + return ret;
> +}
> +
> +static void pvcalls_back_work(struct pvcalls_fedata *fedata)
> +{
> + int notify, notify_all = 0, more = 1;
> + struct xen_pvcalls_request req;
> + struct xenbus_device *dev = fedata->dev;
> +
> + while (more) {
> + while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
> + RING_COPY_REQUEST(>ring,
> +   fedata->ring.req_cons++,
> +   );
> +
> + if (!pvcalls_back_handle_cmd(dev, )) {
> + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
> + >ring, notify);
> + notify_all += notify;
> + }
> + }
> +
> + if (notify_all) {
> + notify_remote_via_irq(fedata->irq);
> + notify_all = 0;
> + }
> +
> + RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
> + }
>  }
>  
>  static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
>  {
> + struct xenbus_device *dev = dev_id;
> + struct pvcalls_fedata *fedata = NULL;
> +
> + if (dev == NULL)
> + return IRQ_HANDLED;
> +
> + fedata = dev_get_drvdata(>dev);
> + if (fedata == NULL)
> + return IRQ_HANDLED;
> +
> + pvcalls_back_work(fedata);
>   return IRQ_HANDLED;
>  }
>  

Re: [PATCH v6 08/18] xen/pvcalls: implement connect command

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> Allocate a socket. Keep track of socket <-> ring mappings with a new data
> structure, called sock_mapping. Implement the connect command by calling
> inet_stream_connect, and mapping the new indexes page and data ring.
> Allocate a workqueue and a work_struct, called ioworker, to perform
> reads and writes to the socket.
> 
> When an active socket is closed (sk_state_change), set in_error to
> -ENOTCONN and notify the other end, as specified by the protocol.
> 
> sk_data_ready and pvcalls_back_ioworker will be implemented later.
> 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-back.c | 174 
> +
>  1 file changed, 174 insertions(+)
> 
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index 53fd908..1bc2620 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -54,6 +54,39 @@ struct pvcalls_fedata {
>   struct semaphore socket_lock;
>  };
>  
> +struct pvcalls_ioworker {
> + struct work_struct register_work;
> + struct workqueue_struct *wq;
> +};
> +
> +struct sock_mapping {
> + struct list_head list;
> + struct pvcalls_fedata *fedata;
> + struct socket *sock;
> + uint64_t id;
> + grant_ref_t ref;
> + struct pvcalls_data_intf *ring;
> + void *bytes;
> + struct pvcalls_data data;
> + uint32_t ring_order;
> + int irq;
> + atomic_t read;
> + atomic_t write;
> + atomic_t io;
> + atomic_t release;
> + void (*saved_data_ready)(struct sock *sk);
> + struct pvcalls_ioworker ioworker;
> +};
> +
> +static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map);
> +static int pvcalls_back_release_active(struct xenbus_device *dev,
> +struct pvcalls_fedata *fedata,
> +struct sock_mapping *map);
> +
> +static void pvcalls_back_ioworker(struct work_struct *work)
> +{
> +}
> +
>  static int pvcalls_back_socket(struct xenbus_device *dev,
>   struct xen_pvcalls_request *req)
>  {
> @@ -82,9 +115,145 @@ static int pvcalls_back_socket(struct xenbus_device *dev,
>   return 0;
>  }
>  
> +static void pvcalls_sk_state_change(struct sock *sock)
> +{
> + struct sock_mapping *map = sock->sk_user_data;
> + struct pvcalls_data_intf *intf;
> +
> + if (map == NULL)
> + return;
> +
> + intf = map->ring;
> + intf->in_error = -ENOTCONN;
> + notify_remote_via_irq(map->irq);
> +}
> +
> +static void pvcalls_sk_data_ready(struct sock *sock)
> +{
> +}
> +
> +static struct sock_mapping *pvcalls_new_active_socket(
> + struct pvcalls_fedata *fedata,
> + uint64_t id,
> + grant_ref_t ref,
> + uint32_t evtchn,
> + struct socket *sock)
> +{
> + int ret;
> + struct sock_mapping *map;
> + void *page;
> +
> + map = kzalloc(sizeof(*map), GFP_KERNEL);
> + if (map == NULL)
> + return NULL;
> +
> + map->fedata = fedata;
> + map->sock = sock;
> + map->id = id;
> + map->ref = ref;
> +
> + ret = xenbus_map_ring_valloc(fedata->dev, , 1, );
> + if (ret < 0)
> + goto out;
> + map->ring = page;
> + map->ring_order = map->ring->ring_order;
> + /* first read the order, then map the data ring */
> + virt_rmb();
> + if (map->ring_order > MAX_RING_ORDER) {
> + pr_warn("%s frontend requested ring_order %u, which is > MAX 
> (%u)\n",
> + __func__, map->ring_order, MAX_RING_ORDER);
> + goto out;
> + }
> + ret = xenbus_map_ring_valloc(fedata->dev, map->ring->ref,
> +  (1 << map->ring_order), );
> + if (ret < 0)
> + goto out;
> + map->bytes = page;
> +
> + ret = bind_interdomain_evtchn_to_irqhandler(fedata->dev->otherend_id,
> + evtchn,
> + pvcalls_back_conn_event,
> + 0,
> + "pvcalls-backend",
> + map);
> + if (ret < 0)
> + goto out;
> + map->irq = ret;
> +
> + map->data.in = map->bytes;
> + map->data.out = map->bytes + XEN_FLEX_RING_SIZE(map->ring_order);
> + 
> + map->ioworker.wq = alloc_workqueue("pvcalls_io", WQ_UNBOUND, 1);
> + if (!map->ioworker.wq)
> + goto out;
> + atomic_set(>io, 1);
> + INIT_WORK(>ioworker.register_work, pvcalls_back_ioworker);
> +
> + down(>socket_lock);
> + list_add_tail(>list, >socket_mappings);
> + up(>socket_lock);
> +
> + write_lock_bh(>sock->sk->sk_callback_lock);
> + map->saved_data_ready = map->sock->sk->sk_data_ready;
> + 

Re: [PATCH v6 15/18] xen/pvcalls: implement the ioworker functions

[Juergen Gross]

On 03/07/17 23:08, Stefano Stabellini wrote:
> We have one ioworker per socket. Each ioworker goes through the list of
> outstanding read/write requests. Once all requests have been dealt with,
> it returns.
> 
> We use one atomic counter per socket for "read" operations and one
> for "write" operations to keep track of the reads/writes to do.
> 
> We also use one atomic counter ("io") per ioworker to keep track of how
> many outstanding requests we have in total assigned to the ioworker. The
> ioworker finishes when there are none.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: Boris Ostrovsky 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-back.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> index 71a42fc..d59c2e4 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -96,8 +96,35 @@ static int pvcalls_back_release_active(struct 
> xenbus_device *dev,
>  struct pvcalls_fedata *fedata,
>  struct sock_mapping *map);
>  
> +static void pvcalls_conn_back_read(void *opaque)
> +{
> +}
> +
> +static int pvcalls_conn_back_write(struct sock_mapping *map)
> +{
> + return 0;
> +}

Any reason for letting this function return int? I haven't spotted any
use of the return value in this or any later patch.


Juergen

Re: [PATCH 4.11 00/84] 4.11.9-stable review

[Greg Kroah-Hartman]

On Mon, Jul 03, 2017 at 12:55:07PM -0700, Guenter Roeck wrote:
> On 07/03/2017 06:34 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.11.9 release.
> > There are 84 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Jul  5 13:33:30 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 143 fail: 2
> Failed builds:
>   arm:allmodconfig
>   arm:omap2plus_defconfig
> 
> Qemu test results:
>   total: 122 pass: 119 fail: 3
> Failed tests:
>   arm:beagle:omap2plus_defconfig:omap3-beagle
>   arm:beaglexm:omap2plus_defconfig:omap3-beagle-xm
>   arm:overo:omap2plus_defconfig:omap3-overo-tobi
> 
> Details are available at http://kerneltests.org/builders.
> 
> The common build error is:
> 
> drivers/hsi/clients/ssi_protocol.c: In function 'ssip_pn_setup':
> drivers/hsi/clients/ssi_protocol.c:1068:5: error: 'struct net_device' has no 
> member named 'destructor'
> 
> Bisect points to commit 1469d4b7e6 ("net: Fix inconsistent teardown and
> release of private net dev state.") as the culprit for the build failures.
> Reverting that patch fixes the problem.

Ah, looks like we need to add commit ed66e50d9587 ("hsi: Fix build
regression due to netdev destructor fix.") to the tree to fix this up,
let me go queue it up now...

thanks,

greg k-h

Re: [GIT PULL] s390 patches for 4.13 merge window

[Stephen Rothwell]

Hi Linus,

On Mon, 3 Jul 2017 15:46:00 -0700 Linus Torvalds 
 wrote:
>
> On Mon, Jul 3, 2017 at 2:01 AM, Martin Schwidefsky
>  wrote:
> >
> > please pull from the 'for-linus' branch of
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git 
> > for-linus  
> 
> So my conflict resolution looks different from the one Stephen posted,
> which may be due to various reasons, ranging from "linux-next has
> other things that conflict" to just "I didn't notice some semantic
> conflict since unlike linux-next I don't build for s390".
> 
> Regardless, you should check my current -git tree just to verify, and
> send me a patch if I screwed something up.

At least part of the difference is the following merge fix patch I have
been carrying.  It is needed due to a build failure.

From: Stephen Rothwell 
Date: Tue, 13 Jun 2017 20:51:32 +1000
Subject: [PATCH] s390: fix up for "blk-mq: switch ->queue_rq return value to
 blk_status_t"

Signed-off-by: Stephen Rothwell 
---
 drivers/s390/block/scm_blk.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 42018a20f2b7..0071febac9e6 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -278,7 +278,7 @@ struct scm_queue {
spinlock_t lock;
 };
 
-static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
+static blk_status_t scm_blk_request(struct blk_mq_hw_ctx *hctx,
   const struct blk_mq_queue_data *qd)
 {
struct scm_device *scmdev = hctx->queue->queuedata;
@@ -290,7 +290,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
spin_lock(>lock);
if (!scm_permit_request(bdev, req)) {
spin_unlock(>lock);
-   return BLK_MQ_RQ_QUEUE_BUSY;
+   return BLK_STS_RESOURCE;
}
 
scmrq = sq->scmrq;
@@ -299,7 +299,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
if (!scmrq) {
SCM_LOG(5, "no request");
spin_unlock(>lock);
-   return BLK_MQ_RQ_QUEUE_BUSY;
+   return BLK_STS_RESOURCE;
}
scm_request_init(bdev, scmrq);
sq->scmrq = scmrq;
@@ -315,7 +315,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
 
sq->scmrq = NULL;
spin_unlock(>lock);
-   return BLK_MQ_RQ_QUEUE_BUSY;
+   return BLK_STS_RESOURCE;
}
blk_mq_start_request(req);
 
@@ -324,7 +324,7 @@ static int scm_blk_request(struct blk_mq_hw_ctx *hctx,
sq->scmrq = NULL;
}
spin_unlock(>lock);
-   return BLK_MQ_RQ_QUEUE_OK;
+   return BLK_STS_OK;
 }
 
 static int scm_blk_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

[PATCH] mm: disallow early_pfn_to_nid on configurations which do not implement it

[Michal Hocko]

From: Michal Hocko 

early_pfn_to_nid will return node 0 if both HAVE_ARCH_EARLY_PFN_TO_NID
and HAVE_MEMBLOCK_NODE_MAP are disabled. It seems we are safe now
because all architectures which support NUMA define one of them (with an
exception of alpha which however has CONFIG_NUMA marked as broken) so
this works as expected. It can get silently and subtly broken too
easily, though. Make sure we fail the compilation if NUMA is enabled and
there is no proper implementation for this function. If that ever
happens we know that either the specific configuration is invalid
and the fix should either disable NUMA or enable one of the above
configs.

Signed-off-by: Michal Hocko 
---
Hi,
I have brought this up earlier [1] because I thought the deferred
initialization might be broken but then found out that this is not the
case right now. This is an attempt to prevent any subtly broken users in
future.

[1] http://lkml.kernel.org/r/20170630141847.gn22...@dhcp22.suse.cz

 include/linux/mmzone.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 16532fa0bb64..fc14b8b3f6ce 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1055,6 +1055,7 @@ static inline struct zoneref *first_zones_zonelist(struct 
zonelist *zonelist,
!defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP)
 static inline unsigned long early_pfn_to_nid(unsigned long pfn)
 {
+   BUILD_BUG_ON(IS_ENABLED(CONFIG_NUMA));
return 0;
 }
 #endif
-- 
2.11.0

Re: perf report: fix off-by-one for non-activation frames

[Milian Wolff]

On Monday, June 19, 2017 8:59:39 PM CEST Arnaldo Carvalho de Melo wrote:
> Em Sat, Jun 17, 2017 at 01:13:11PM +0200, Milian Wolff escreveu:
> > On Samstag, 17. Juni 2017 10:04:02 CEST Jan Kratochvil wrote:
> > > On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote:
> > > > Not sure whether it needs be fixed or not.  If we fix it, srcline and
> > > > address would not match so it can give its own confusion to users.
> > > > Ideally it should display an addressof the instruction before the
> > > > address IMHO.
> > > 
> > > One can figure million ways how it can behave and each one has its pros
> > > and
> > > cons.  I was just describing the current behavior of GDB and LLDB which
> > > people are used to already.
> > 
> > Personally, I agree with Jan that we should mimick existing tool's
> > behavior. I just fear that it's not trivial to do it with the current
> > code base...
> But we agree it is a worthwhile change (have backtraces in perf match
> what gdb, etc show), right?
> 
> If you can, please try to do this, your attempt will help us understand
> more the extent of the changes needed and perhaps someonw can come up
> with simplifications...

Sorry for the (long) delay, but I'm sadly busy on other things right now. I 
have this on my radar and will try to find time to look into it. But it 
probably won't happen before end of July. If this is urgent, maybe someone 
else needs to look into it before me.

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature

Re: [v2] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170703 23:58]:
> When working with wl18xx the nvs file is used for defining an alternate
> mac address and override the default mac address that is stored inside
> the wl18xx chip.
> 
> The following commits:
> c815fde wlcore: spi: Populate config firmware data
> d776fc8 wlcore: sdio: Populate config firmware data
> 
> Populated the nvs entry for wilink6 and wilink7 only while it is 
> still needed for wilink8 as well. 
> This broke user space backward compatibility when upgrading from older 
> kernels, as the alternate mac address would not be read from the nvs that is 
> already present in the file system 
> (lib/firmware/ti-connectivity/wl1271-nvs.bin) 
> causing mac address change of the wlan interface.
> 
> This patch fix this and update the structure field with the same default nvs 
> file 
> name that has been used before.

I think more checks on the nvs file being used are needed to avoid other
nasty issues, see the comments I just made in the earlier version of this
patch.

Regards,

Tony

[PATCH] target: make device_mutex and device_list static

[Colin King]

From: Colin Ian King 

Variables device_mutex and device_list static are local to the source,
so make them static.

Cleans up sparse warnings:
"symbol 'device_list' was not declared. Should it be static?"
"symbol 'device_mutex' was not declared. Should it be static?"

Signed-off-by: Colin Ian King 
---
 drivers/target/target_core_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/target/target_core_device.c 
b/drivers/target/target_core_device.c
index 3ae8fbf01bdf..bbcef3bc66c8 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -49,8 +49,8 @@
 #include "target_core_pr.h"
 #include "target_core_ua.h"
 
-DEFINE_MUTEX(device_mutex);
-LIST_HEAD(device_list);
+static DEFINE_MUTEX(device_mutex);
+static LIST_HEAD(device_list);
 static DEFINE_IDR(devices_idr);
 
 static struct se_hba *lun0_hba;
-- 
2.11.0

Re: [PATCH v4 2/3] arm64: kvm: route synchronous external abort exceptions to el2

[Christoffer Dall]

Hi  Dongjiu,

On Tue, Jul 04, 2017 at 02:30:21PM +0800, gengdongjiu wrote:
> Hi Christoffer,
> 
> On 2017/7/3 16:23, Christoffer Dall wrote:
> > On Tue, Jun 27, 2017 at 08:15:49PM +0800, gengdongjiu wrote:
> >> correct the commit message:
> >>
> >>  In the firmware-first RAS solution, OS receives an synchronous
> >>  external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
> >>  the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
> >>  If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
> >>  otherwise it delegates to the host OS kernel
> > 
> > This commit text has nothing (directly) to do with the content of the
> > patch.  Whether or not seting these bits are used by firmware to emulate
> > injecting an exception or by the CPU raising a an exception is not the
> > core of the issue.
> > 
> > Please describe your change, then provide rationale.
> 
> (1)Below hcr_el2.TEA/TERR two field is introduced by armv8.2, RAS extension.
> 
> TEA, bit [37]
>   Route synchronous External Abort exceptions to EL2. The possible values 
> of this bit are:
>   0 Do not route synchronous External Abort exceptions from Non-secure 
> EL0 and EL1 to EL2.
>   1 Route synchronous External Abort exceptions from Non-secure EL0 and 
> EL1 to EL2, if not routed
>   to EL3.
>   This bit is RES0 if the RAS extension is not implemented.
> TERR, bit [36]
>   Trap Error record accesses. The possible values of this bit are:
>   0 Do not trap accesses to error record registers from Non-secure EL1 to 
> EL2.
>   1 Accesses to the ER* registers from Non-secure EL1 generate a Trap 
> exception to EL2.
>   This bit is RES0 if the RAS extension is not implemented.
> 
> (2) when synchronous External Abort(SEA) OS happen SEA, it trap to EL3 
> firmware.
> then the firmware needs to do by faking an exception entry to  hypervisor 
> EL2; or
> by faking an exception entry to EL1
> so if the hcr_el2.TEA is set, firmware will eret to EL2; otherwise, eret to 
> EL1.
> hcr_el2.TEA is only set for the guest OS.
> not set for the host OS.
> 
> 
> (3) setting hcr_el2.HCR_TERR want to trap the EL1 error record access to EL2.


So again, I was more asking for a new commit message for the next
version of the patch rather than an explanation here.  But I the commit
message should not mention assumptions about how EL3 firmware works, but
try to stay within the semantics laid out by the ARM architecture.

For example:

  ARMv8.2 introduces two new bits, TEA and TERR, which [...].  When RAS
  is available, we set these bits on the HCR_EL2, because we want to
  take external aborts to EL2 in order for [...].



Thanks,
-Christoffer


> 
> 
> > 
> > Thanks,
> > -Christoffer
> > 
> > 
> >>
> >>
> >> On 2017/6/26 20:45, Dongjiu Geng wrote:
> >>> In the firmware-first RAS solution, guest OS receives an synchronous
> >>> external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
> >>> the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
> >>> If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
> >>> otherwise it delegates to the guest OS kernel
> >>>
> >>> Signed-off-by: Dongjiu Geng 
> >>> ---
> >>>  arch/arm64/include/asm/kvm_arm.h | 2 ++
> >>>  arch/arm64/include/asm/kvm_emulate.h | 7 +++
> >>>  2 files changed, 9 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/include/asm/kvm_arm.h 
> >>> b/arch/arm64/include/asm/kvm_arm.h
> >>> index 61d694c..1188272 100644
> >>> --- a/arch/arm64/include/asm/kvm_arm.h
> >>> +++ b/arch/arm64/include/asm/kvm_arm.h
> >>> @@ -23,6 +23,8 @@
> >>>  #include 
> >>>  
> >>>  /* Hyp Configuration Register (HCR) bits */
> >>> +#define HCR_TEA  (UL(1) << 37)
> >>> +#define HCR_TERR (UL(1) << 36)
> >>>  #define HCR_E2H  (UL(1) << 34)
> >>>  #define HCR_ID   (UL(1) << 33)
> >>>  #define HCR_CD   (UL(1) << 32)
> >>> diff --git a/arch/arm64/include/asm/kvm_emulate.h 
> >>> b/arch/arm64/include/asm/kvm_emulate.h
> >>> index f5ea0ba..5f64ab2 100644
> >>> --- a/arch/arm64/include/asm/kvm_emulate.h
> >>> +++ b/arch/arm64/include/asm/kvm_emulate.h
> >>> @@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu 
> >>> *vcpu)
> >>>   vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> >>>   if (is_kernel_in_hyp_mode())
> >>>   vcpu->arch.hcr_el2 |= HCR_E2H;
> >>> + if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
> >>> + /* route synchronous external abort exceptions to EL2 */
> >>> + vcpu->arch.hcr_el2 |= HCR_TEA;
> >>> + /* trap error record accesses */
> >>> + vcpu->arch.hcr_el2 |= HCR_TERR;
> >>> + }
> >>> +
> >>>   if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
> >>>   vcpu->arch.hcr_el2 &= ~HCR_RW;
> >>>  }
> >>>
> >>
> > 
> > .
> > 
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> 

Re: [PATCH] net: ethernet: mediatek: fixed deadlock captured by lockdep

[David Miller]

From: 
Date: Tue, 4 Jul 2017 11:17:36 +0800

> From: Sean Wang 
> 
> Lockdep found an inconsistent lock state when mtk_get_stats64 is called
> in user context while NAPI updates MAC statistics in softirq.
> 
> Use spin_trylock_bh/spin_unlock_bh fix following lockdep warning.
 ...
> Signed-off-by: Sean Wang 

Good catch, applied, thanks.

[GIT PULL] power-supply changes for 4.13

[Sebastian Reichel]

Hi Linus,

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git 
tags/for-v4.13

for you to fetch changes up to bfa953d336cdd713f6968c85ca820ef22333dc35:

  power: supply: sbs-battery: Don't needlessly set CAPACITY_MODE (2017-06-15 
16:52:04 +0200)


power supply and reset changes for the v4.13 series

* New drivers
 - Linear ltc3651 charger driver
 - Motorola CPCAP battery fuel-gauge driver
* New chip/feature support
 - bq27xxx: prepare for chip data setup
 - axp20x_battery: support max charge current setup
* New core features
 - add Apple Brick ID type
 - support "supplied-from" device property for generic ACPI/pdata support
 - support strings for sysfs properties representing enums
 - introduce battery-info (backend is DT only for now)
 - provide reboot-mode header globally
* Misc. fixes


Alexandre Belloni (2):
  power: reset: at91-poweroff: fix clobber list
  power: reset: at91-sama5d2_shdwc: fix clobber list

Andy Shevchenko (1):
  power: supply: twl4030_charger: Use sysfs_match_string() helper

Arvind Yadav (1):
  power: supply: core: constify psy_tcd_ops.

Benson Leung (1):
  power: supply: Add Apple Brick ID power supply type

Bjorn Andersson (1):
  power: reset: reboot-mode: Make include file global

Dan Carpenter (1):
  power: supply: ltc3651-charger: fix some error codes in probe

David Lechner (1):
  power: supply: sysfs: parse string as enum when writing property

Florian Fainelli (2):
  power: reset: Allow selecting POWER_RESET_BRCMSTB on ARM64
  power: reset: Default POWER_RESET_BRCMSTB to BMIPS_GENERIC

H. Nikolaus Schaller (3):
  power: supply: twl4030-charger: remove nonstandard max_current sysfs 
attribute
  power: supply: twl4030-charger: allocate iio by devm_iio_channel_get() 
and fix error path
  power: supply: twl4030-charger: move allocation of iio channel to the 
beginning

Hans de Goede (1):
  power: supply: core: Add support for supplied-from device-property

Julia Lawall (1):
  power: supply: axp20x_usb_power: Drop unnecessary static

Liam Breck (6):
  dt-bindings: power: supply: Add battery.txt with simple-battery binding
  power: supply: core: Add power_supply_battery_info and API
  power: supply: core: Add power_supply_prop_precharge
  dt-bindings: power: supply: bq27xxx: Add monitored-battery documentation
  power: supply: bq27xxx: Add chip data memory read/write support
  power: supply: bq27xxx: Add power_supply_battery_info support

Matt Ranostay (2):
  devicetree: property-units: Add uWh and uAh units
  power: supply: bq27xxx: Add bulk transfer bus methods

Mike Looijmans (2):
  dt-bindings: power: supply: New bindings for ltc3651-charger
  power: supply: Add ltc3651-charger driver

Phil Reid (2):
  power: supply: sbs-battery: remove incorrect le16_to_cpu calls
  power: supply: bq24735: remove incorrect le16_to_cpu calls

Quentin Schulz (2):
  power: supply: axp20x_battery: add support for DT battery
  power: supply: axp20x_battery: add DT support for battery max constant 
charge current

Sebastian Reichel (3):
  Merge branch 'psy-reboot-mode-immutable' into psy-next
  dt-bindings: power: supply: move maxim,max14656.txt to proper location
  dt-bindings: power: supply: move max8903-charger.txt to proper location

Shawn Nematbakhsh (2):
  power: supply: sbs-battery: Prevent CAPACITY_MODE races
  power: supply: sbs-battery: Don't needlessly set CAPACITY_MODE

Tony Lindgren (6):
  power: supply: cpcap-charger: Update charge current table and add comments
  power: supply: cpcap-charger: Fix charger voltages based on ADC values
  dt-bindings: power: supply: cpcap-battery: Add binding
  power: supply: cpcap-battery: Add a battery driver
  dt-bindings: power: supply: cpcap-battery: Add power-supplies property
  power: supply: cpcap-charger: Add missing power_supply_config

 .../ABI/testing/sysfs-class-power-twl4030  |  17 -
 .../devicetree/bindings/power/supply/battery.txt   |  57 ++
 .../devicetree/bindings/power/supply/bq27xxx.txt   |  31 +-
 .../bindings/power/supply/cpcap-battery.txt|  31 +
 .../bindings/power/supply/ltc3651-charger.txt  |  27 +
 .../power/{ => supply}/max8903-charger.txt |   0
 .../supply}/maxim,max14656.txt |   0
 .../devicetree/bindings/property-units.txt |   2 +
 Documentation/power/power_supply_class.txt |  31 +-
 drivers/power/reset/Kconfig|   4 +-
 drivers/power/reset/at91-poweroff.c|   2 +-
 drivers/power/reset/at91-sama5d2_shdwc.c   |   2 +-
 

[PATCH v1 1/1] KVM: trigger uevents when starting or stopping a VM

[Claudio Imbrenda]

This patch adds a few lines to the KVM common code to fire a
KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
carries two environment variables:
KVM_VM_CREATED which indicates how many times a new VM has been created,
KVM_VM_COUNT which indicates how many VMs are currently active.

Specific udev rules can be then set up in userspace to deal with the
creation or destruction of VMs as needed.

Signed-off-by: Claudio Imbrenda 
---
 virt/kvm/kvm_main.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6e3b12c..f67aa59 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -130,6 +130,10 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
 
 static bool largepages_enabled = true;
 
+static void kvm_uevent_notify_change(u64 created, u64 active);
+static u64 kvm_createvm_count;
+static u64 kvm_active_vms;
+
 bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
@@ -627,6 +631,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
 {
int r, i;
struct kvm *kvm = kvm_arch_alloc_vm();
+   u64 activevms, createdvms;
 
if (!kvm)
return ERR_PTR(-ENOMEM);
@@ -686,9 +691,12 @@ static struct kvm *kvm_create_vm(unsigned long type)
 
spin_lock(_lock);
list_add(>vm_list, _list);
+   createdvms = ++kvm_createvm_count;
+   activevms = ++kvm_active_vms;
spin_unlock(_lock);
 
preempt_notifier_inc();
+   kvm_uevent_notify_change(createdvms, activevms);
 
return kvm;
 
@@ -739,11 +747,14 @@ static void kvm_destroy_vm(struct kvm *kvm)
 {
int i;
struct mm_struct *mm = kvm->mm;
+   u64 activevms, createdvms;
 
kvm_destroy_vm_debugfs(kvm);
kvm_arch_sync_events(kvm);
spin_lock(_lock);
list_del(>vm_list);
+   activevms = --kvm_active_vms;
+   createdvms = kvm_createvm_count;
spin_unlock(_lock);
kvm_free_irq_routing(kvm);
for (i = 0; i < KVM_NR_BUSES; i++) {
@@ -767,6 +778,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
preempt_notifier_dec();
hardware_disable_all();
mmdrop(mm);
+   kvm_uevent_notify_change(createdvms, activevms);
 }
 
 void kvm_get_kvm(struct kvm *kvm)
@@ -3864,6 +3876,19 @@ static const struct file_operations *stat_fops[] = {
[KVM_STAT_VM]   = _stat_fops,
 };
 
+static void kvm_uevent_notify_change(u64 created, u64 active)
+{
+   char createvm_buf[40];
+   char activevm_buf[40];
+   char *ptr[3] = {createvm_buf, activevm_buf, NULL};
+
+   if (!kvm_dev.this_device)
+   return;
+   snprintf(createvm_buf, 40, "KVM_VM_CREATED=%llu", created);
+   snprintf(activevm_buf, 40, "KVM_VM_ACTIVE=%llu", active);
+   kobject_uevent_env(_dev.this_device->kobj, KOBJ_CHANGE, ptr);
+}
+
 static int kvm_init_debug(void)
 {
int r = -EEXIST;
-- 
2.7.4

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

[Peter Zijlstra]

On Wed, Jun 28, 2017 at 03:55:07PM -0700, Kyle Huey wrote:

> > Having thought about this some more, I think Vince does make a good
> > point that throwing away samples is liable to break stuff, e.g. that
> > which only relies on (non-sensitive) samples.
> >
> > It still seems wrong to make up data, though.

It is something we do in other places as well though. For example the
printk() %pK thing fakes NULL pointers when kptr_restrict is set.

Faking data gets a wee bit tricky in how much data we need to clear
through, its not only IP, pretty much everything we get from the
interrupt context, like the branch stack and registers is also suspect.

> > Maybe for exclude_kernel && !exclude_user events we can always generate
> > samples from the user regs, rather than the exception regs. That's going
> > to be closer to what the user wants, regardless. I'll take a look
> > tomorrow.
> 
> I'm not very familiar with the kernel internals, but the reason I
> didn't suggest this originally is it seems like it will be difficult
> to determine what the "correct" userspace registers are.  For example,
> what happens if a performance counter is fixed to a given tid, the
> interrupt fires during a context switch from that task to another that
> is not being monitored, and the kernel is far enough along in the
> context switch that the current task struct has been switched out?
> Reporting the new task's registers seems as bad as reporting the
> kernel's registers.  But maybe this is easier than I imagine for
> whatever reason.

If the counter is fixed to a task then its scheduled along with the
task. We'll schedule out the event before doing the actual task switch
and switch in the new event after.

That said, with a per-cpu event the TID sample value is indeed subject
to skid like you describe.

Re: [PATCH v2 00/11] patches for fpga

[Anatolij Gustschin]

Hi Greg,

On Wed, 14 Jun 2017 10:36:24 -0500
Alan Tull at...@kernel.org wrote:

>Hi Greg,
>
>This is a repost of last weeks patches, fixing the warnings.  I've
>also added the Altera CvP driver which has been reviewed on the lists.
>I pushed these to my kernel.org git repo for testing (which I should
>have done in the first place) on Monday and the robot hasn't
>complained.

Is this series queued for merging in 4.13-rc1 ?

thanks,

Anatolij

Re: [PATCH v1 1/1] KVM: trigger uevents when starting or stopping a VM

[Paolo Bonzini]

On 04/07/2017 11:25, Christian Borntraeger wrote:
> On 07/04/2017 11:23 AM, Paolo Bonzini wrote:
>>
>>
>> On 04/07/2017 11:03, Claudio Imbrenda wrote:
>>> This patch adds a few lines to the KVM common code to fire a
>>> KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
>>> carries two environment variables:
>>> KVM_VM_CREATED which indicates how many times a new VM has been created,
>>> KVM_VM_COUNT which indicates how many VMs are currently active.
>>
>> I'm not sure why KVM_VM_CREATED is useful, KVM_VM_COUNT can be a bit
>> more interesting though not much.
> 
> I am certainly interested in an trigger from "kvm was never used" to "kvm was 
> used",
> so having something like KVM_VM_CREATED has a value for me.

Fair enough, that's a good use.  Please add it to the commit message,
however.

Paolo

>> But since we are at it, let's also add a PID.  That one is the really
>> useful one, because it gives you something to look at in debugfs.
>> Another possibility is to add the debugfs directory name directly
>> (KVM_VM_STATS_PATH or something like that).
>>
>> Paolo
>>
>>> Specific udev rules can be then set up in userspace to deal with the
>>> creation or destruction of VMs as needed.
>>>
>>> Signed-off-by: Claudio Imbrenda 
>>> ---
>>>  virt/kvm/kvm_main.c | 25 +
>>>  1 file changed, 25 insertions(+)
>>>
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index 6e3b12c..f67aa59 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -130,6 +130,10 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
>>>  
>>>  static bool largepages_enabled = true;
>>>  
>>> +static void kvm_uevent_notify_change(u64 created, u64 active);
>>> +static u64 kvm_createvm_count;
>>> +static u64 kvm_active_vms;
>>> +
>>>  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
>>>  {
>>> if (pfn_valid(pfn))
>>> @@ -627,6 +631,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
>>>  {
>>> int r, i;
>>> struct kvm *kvm = kvm_arch_alloc_vm();
>>> +   u64 activevms, createdvms;
>>>  
>>> if (!kvm)
>>> return ERR_PTR(-ENOMEM);
>>> @@ -686,9 +691,12 @@ static struct kvm *kvm_create_vm(unsigned long type)
>>>  
>>> spin_lock(_lock);
>>> list_add(>vm_list, _list);
>>> +   createdvms = ++kvm_createvm_count;
>>> +   activevms = ++kvm_active_vms;
>>> spin_unlock(_lock);
>>>  
>>> preempt_notifier_inc();
>>> +   kvm_uevent_notify_change(createdvms, activevms);
>>>  
>>> return kvm;
>>>  
>>> @@ -739,11 +747,14 @@ static void kvm_destroy_vm(struct kvm *kvm)
>>>  {
>>> int i;
>>> struct mm_struct *mm = kvm->mm;
>>> +   u64 activevms, createdvms;
>>>  
>>> kvm_destroy_vm_debugfs(kvm);
>>> kvm_arch_sync_events(kvm);
>>> spin_lock(_lock);
>>> list_del(>vm_list);
>>> +   activevms = --kvm_active_vms;
>>> +   createdvms = kvm_createvm_count;
>>> spin_unlock(_lock);
>>> kvm_free_irq_routing(kvm);
>>> for (i = 0; i < KVM_NR_BUSES; i++) {
>>> @@ -767,6 +778,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
>>> preempt_notifier_dec();
>>> hardware_disable_all();
>>> mmdrop(mm);
>>> +   kvm_uevent_notify_change(createdvms, activevms);
>>>  }
>>>  
>>>  void kvm_get_kvm(struct kvm *kvm)
>>> @@ -3864,6 +3876,19 @@ static const struct file_operations *stat_fops[] = {
>>> [KVM_STAT_VM]   = _stat_fops,
>>>  };
>>>  
>>> +static void kvm_uevent_notify_change(u64 created, u64 active)
>>> +{
>>> +   char createvm_buf[40];
>>> +   char activevm_buf[40];
>>> +   char *ptr[3] = {createvm_buf, activevm_buf, NULL};
>>> +
>>> +   if (!kvm_dev.this_device)
>>> +   return;
>>> +   snprintf(createvm_buf, 40, "KVM_VM_CREATED=%llu", created);
>>> +   snprintf(activevm_buf, 40, "KVM_VM_ACTIVE=%llu", active);
>>> +   kobject_uevent_env(_dev.this_device->kobj, KOBJ_CHANGE, ptr);
>>> +}
>>> +
>>>  static int kvm_init_debug(void)
>>>  {
>>> int r = -EEXIST;
>>>
>>
> 

[patch V2 0/2] mm/memory_hotplug: Cure potential deadlocks vs. cpu hotplug lock

[Thomas Gleixner]

Andrey reported a potential deadlock with the memory hotplug lock and the
cpu hotplug lock.

The following series addresses this by reworking the memory hotplug locking
and fixing up the potential deadlock scenarios.

Applies against Linus head. All preliminaries are merged there already

Thanks,

tglx
---
 include/linux/swap.h |1 
 mm/memory_hotplug.c  |   89 ---
 mm/page_alloc.c  |2 -
 mm/swap.c|   11 --
 4 files changed, 25 insertions(+), 78 deletions(-)

Re: [PATCH] mm: larger stack guard gap, between vmas

[Michal Hocko]

On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings  wrote:
> > >
> > > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> > > Apparently Rust maps its own guard page at the lower limit of the stack
> > > (determined using pthread_getattr_np() and pthread_attr_getstack()).  I
> > > don't think this ever actually worked for the main thread stack, but it
> > > now also blocks expansion as the default stack size of 8 MiB is smaller
> > > than the stack gap of 16 MiB.  Would it make sense to skip over
> > > PROT_NONE mappings when checking whether it's safe to expand?
> 
> This is what my workaround for the older patch was doing, actually. We
> have deployed that as a follow up fix on our older code bases. And this
> has fixed verious issues with Java which was doing the similar thing.

Here is a forward port (on top of the current Linus tree) of my earlier
patch. I have dropped a note about java stack trace because this would
most likely be not the case with the Hugh's patch. The problem is the
same in principle though. Note I didn't get to test this properly yet
but it should be pretty much obvious.
---
>From d9f6faccf2c286ed81fbc860c9b0b7fe23ef0836 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Tue, 4 Jul 2017 11:27:39 +0200
Subject: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the
 stack

"mm: enlarge stack guard gap" has introduced a regression in some rust
and Java environments which are trying to implement their own stack
guard page.  They are punching a new MAP_FIXED mapping inside the
existing stack Vma.

This will confuse expand_{downwards,upwards} into thinking that the stack
expansion would in fact get us too close to an existing non-stack vma
which is a correct behavior wrt. safety. It is a real regression on
the other hand. Let's work around the problem by considering PROT_NONE
mapping as a part of the stack. This is a gros hack but overflowing to
such a mapping would trap anyway an we only can hope that usespace
knows what it is doing and handle it propely.

Fixes: d4d2d35e6ef9 ("mm: larger stack guard gap, between vmas")
Debugged-by: Vlastimil Babka 
Signed-off-by: Michal Hocko 
---
 mm/mmap.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index f60a8bc2869c..2e996cbf4ff3 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2244,7 +2244,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned 
long address)
gap_addr = TASK_SIZE;
 
next = vma->vm_next;
-   if (next && next->vm_start < gap_addr) {
+   if (next && next->vm_start < gap_addr &&
+   (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
if (!(next->vm_flags & VM_GROWSUP))
return -ENOMEM;
/* Check that both stack segments have the same anon_vma? */
@@ -2325,7 +2326,8 @@ int expand_downwards(struct vm_area_struct *vma,
/* Enforce stack_guard_gap */
prev = vma->vm_prev;
/* Check that both stack segments have the same anon_vma? */
-   if (prev && !(prev->vm_flags & VM_GROWSDOWN)) {
+   if (prev && !(prev->vm_flags & VM_GROWSDOWN) &&
+   (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
if (address - prev->vm_end < stack_guard_gap)
return -ENOMEM;
}
-- 
2.11.0

-- 
Michal Hocko
SUSE Labs

[patch V2 1/2] mm: swap: Provide lru_add_drain_all_cpuslocked()

[Thomas Gleixner]

The rework of the cpu hotplug locking unearthed potential deadlocks with
the memory hotplug locking code.

The solution for these is to rework the memory hotplug locking code as well
and take the cpu hotplug lock before the memory hotplug lock in
mem_hotplug_begin(), but this will cause a recursive locking of the cpu
hotplug lock when the memory hotplug code calls lru_add_drain_all().

Split out the inner workings of lru_add_drain_all() into
lru_add_drain_all_cpuslocked() so this function can be invoked from the
memory hotplug code with the cpu hotplug lock held.

Reported-by: Andrey Ryabinin 
Signed-off-by: Thomas Gleixner 
Cc: Michal Hocko 
Cc: linux...@kvack.org
Cc: Andrew Morton 
Cc: Vlastimil Babka 
Cc: Vladimir Davydov 
---
 include/linux/swap.h |1 +
 mm/swap.c|   11 ---
 2 files changed, 9 insertions(+), 3 deletions(-)

--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -277,6 +277,7 @@ extern void mark_page_accessed(struct pa
 extern void lru_add_drain(void);
 extern void lru_add_drain_cpu(int cpu);
 extern void lru_add_drain_all(void);
+extern void lru_add_drain_all_cpuslocked(void);
 extern void rotate_reclaimable_page(struct page *page);
 extern void deactivate_file_page(struct page *page);
 extern void mark_page_lazyfree(struct page *page);
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -687,7 +687,7 @@ static void lru_add_drain_per_cpu(struct
 
 static DEFINE_PER_CPU(struct work_struct, lru_add_drain_work);
 
-void lru_add_drain_all(void)
+void lru_add_drain_all_cpuslocked(void)
 {
static DEFINE_MUTEX(lock);
static struct cpumask has_work;
@@ -701,7 +701,6 @@ void lru_add_drain_all(void)
return;
 
mutex_lock();
-   get_online_cpus();
cpumask_clear(_work);
 
for_each_online_cpu(cpu) {
@@ -721,10 +720,16 @@ void lru_add_drain_all(void)
for_each_cpu(cpu, _work)
flush_work(_cpu(lru_add_drain_work, cpu));
 
-   put_online_cpus();
mutex_unlock();
 }
 
+void lru_add_drain_all(void)
+{
+   get_online_cpus();
+   lru_add_drain_all_cpuslocked();
+   put_online_cpus();
+}
+
 /**
  * release_pages - batched put_page()
  * @pages: array of pages to release

Re: [PATCH] mm: larger stack guard gap, between vmas

[Willy Tarreau]

On Tue, Jul 04, 2017 at 11:35:38AM +0200, Michal Hocko wrote:
> On Tue 04-07-17 10:41:22, Michal Hocko wrote:
> > On Mon 03-07-17 17:05:27, Linus Torvalds wrote:
> > > On Mon, Jul 3, 2017 at 4:55 PM, Ben Hutchings  
> > > wrote:
> > > >
> > > > Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> > > > Apparently Rust maps its own guard page at the lower limit of the stack
> > > > (determined using pthread_getattr_np() and pthread_attr_getstack()).  I
> > > > don't think this ever actually worked for the main thread stack, but it
> > > > now also blocks expansion as the default stack size of 8 MiB is smaller
> > > > than the stack gap of 16 MiB.  Would it make sense to skip over
> > > > PROT_NONE mappings when checking whether it's safe to expand?
> > 
> > This is what my workaround for the older patch was doing, actually. We
> > have deployed that as a follow up fix on our older code bases. And this
> > has fixed verious issues with Java which was doing the similar thing.
> 
> Here is a forward port (on top of the current Linus tree) of my earlier
> patch. I have dropped a note about java stack trace because this would
> most likely be not the case with the Hugh's patch. The problem is the
> same in principle though. Note I didn't get to test this properly yet
> but it should be pretty much obvious.
> ---
> >From d9f6faccf2c286ed81fbc860c9b0b7fe23ef0836 Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Tue, 4 Jul 2017 11:27:39 +0200
> Subject: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the
>  stack
> 
> "mm: enlarge stack guard gap" has introduced a regression in some rust
> and Java environments which are trying to implement their own stack
> guard page.  They are punching a new MAP_FIXED mapping inside the
> existing stack Vma.
> 
> This will confuse expand_{downwards,upwards} into thinking that the stack
> expansion would in fact get us too close to an existing non-stack vma
> which is a correct behavior wrt. safety. It is a real regression on
> the other hand. Let's work around the problem by considering PROT_NONE
> mapping as a part of the stack. This is a gros hack but overflowing to
> such a mapping would trap anyway an we only can hope that usespace
> knows what it is doing and handle it propely.
> 
> Fixes: d4d2d35e6ef9 ("mm: larger stack guard gap, between vmas")
> Debugged-by: Vlastimil Babka 
> Signed-off-by: Michal Hocko 
> ---
>  mm/mmap.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f60a8bc2869c..2e996cbf4ff3 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2244,7 +2244,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned 
> long address)
>   gap_addr = TASK_SIZE;
>  
>   next = vma->vm_next;
> - if (next && next->vm_start < gap_addr) {
> + if (next && next->vm_start < gap_addr &&
> + (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
>   if (!(next->vm_flags & VM_GROWSUP))
>   return -ENOMEM;
>   /* Check that both stack segments have the same anon_vma? */
> @@ -2325,7 +2326,8 @@ int expand_downwards(struct vm_area_struct *vma,
>   /* Enforce stack_guard_gap */
>   prev = vma->vm_prev;
>   /* Check that both stack segments have the same anon_vma? */
> - if (prev && !(prev->vm_flags & VM_GROWSDOWN)) {
> + if (prev && !(prev->vm_flags & VM_GROWSDOWN) &&
> + (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
>   if (address - prev->vm_end < stack_guard_gap)
>   return -ENOMEM;
>   }

But wouldn't this completely disable the check in case such a guard page
is installed, and possibly continue to allow the collision when the stack
allocation is large enough to skip this guard page ? Shouldn't we instead
"skip" such a vma and look for the next one ?

I was thinking about something more like :

prev = vma->vm_prev;
+   /* Don't consider a possible user-space stack guard page */
+   if (prev && !(prev->vm_flags & VM_GROWSDOWN) &&
+   !(prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC)))
+   prev = prev->vm_prev;
+
   /* Check that both stack segments have the same anon_vma? */

Willy

Re: [PATCH] coccinelle: api: detect unnecessary le16_to_cpu

[Andy Shevchenko]

On Tue, Jul 4, 2017 at 12:11 PM, Julia Lawall  wrote:
> Here is a revised version (not a patch because it doesn't support all of
> the various modes) and the results.  It doesn't return anything beyond
> what was mentioned in previous mails.
>
> For the following code:
>
> ret = i2c_smbus_read_word_data(chip->client, reg << 1);
> val[0] = (u16)ret & 0xFF;
> val[1] = (u16)ret >> 8;
>
> do we want to see:
>
> put_unaligned(val,i2c_smbus_read_word_data(chip->client, reg << 1));

If and only if the type of the pointer is a byte type (u8 *, char *,
or alike) _and_ we try to use it as a provider for 16-bit value (2
bytes).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 13/14] qcom: mtd: nand: support for QPIC version 1.5.0

[Archit Taneja]

On 06/29/2017 12:46 PM, Abhishek Sahu wrote:

The current QCOM NAND driver only supports version 1.4.0
QCOM QPIC NAND controller. This patch adds the support for
version 1.5.0 which contains some of the registers at
different offsets. The driver data contains the register offset
field which is being initialized with its crossponding register


s/crossponding/corresponding


offsets array. A new compatible string has been added for
version 1.5.0 in BAM mode which uses version 1.5.0 register
offsets.


Please split into 2 patches.

Thanks,
Archit



Signed-off-by: Abhishek Sahu 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt | 44 ++
  drivers/mtd/nand/qcom_nandc.c  | 54 --
  2 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 87b9a56..11e2da2 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -4,6 +4,8 @@ Required properties:
  - compatible: must be one of the following:
* "qcom,ebi2-nandc" - EBI2 NAND which uses ADM DMA like IPQ8064.
* "qcom,qpic-nandc-v1.4.0" - QPIC NAND v1.4.0 which uses BAM DMA like 
IPQ4019.
+   * "qcom,qpic-nandc-v1.5.0" - QPIC NAND v1.5.0 which uses BAM DMA like 
IPQ8074.
+
  - reg:MMIO address range
  - clocks: must contain core clock and always on clock
  - clock-names:must contain "core" for the core clock and 
"aon" for the
@@ -130,3 +132,45 @@ nand@79b {
};
};
  };
+
+nand@79b {
+   compatible = "qcom,qpic-nandc-v1.5.0";
+   reg = <0x79B 0x1000>;
+
+   clocks = < GCC_QPIC_CLK>,
+   < GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = < 0>,
+   < 1>,
+   < 2>;
+   dma-names = "tx", "rx", "cmd";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nandcs@0 {
+   compatible = "qcom,nandcs";
+   reg = <0>;
+
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "boot-nand";
+   reg = <0 0x58a>;
+   };
+
+   partition@58a {
+   label = "fs-nand";
+   reg = <0x58a 0x400>;
+   };
+   };
+   };
+};
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 24750e6..641e85d 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -430,15 +430,18 @@ struct qcom_nand_host {
   * This data type corresponds to the nand driver data which will be used at
   * driver probe time
   * @ecc_modes - ecc mode for nand
+ * @regs_offsets - contains the register offsets array pointer.
   * @dma_bam_enabled - whether this driver is using bam
   */
  struct qcom_nand_driver_data {
u32 ecc_modes;
+   const u32 *regs_offsets;
bool dma_bam_enabled;
  };
  
  /* Mapping table which contains the actual register offsets */

-static const u32 regs_offsets[] = {
+/* NAND controller Version 1.4.0 mapping table */
+static const u32 regs_offsets_v1_4_0[] = {
[NAND_FLASH_CMD] = 0x00,
[NAND_ADDR0] = 0x04,
[NAND_ADDR1] = 0x08,
@@ -471,6 +474,40 @@ struct qcom_nand_driver_data {
[NAND_READ_LOCATION_3] = 0xf2c,
  };
  
+/* NAND controller Version 1.5.0 mapping table */

+static const u32 regs_offsets_v1_5_0[] = {
+   [NAND_FLASH_CMD] = 0x00,
+   [NAND_ADDR0] = 0x04,
+   [NAND_ADDR1] = 0x08,
+   [NAND_FLASH_CHIP_SELECT] = 0x0c,
+   [NAND_EXEC_CMD] = 0x10,
+   [NAND_FLASH_STATUS] = 0x14,
+   [NAND_BUFFER_STATUS] = 0x18,
+   [NAND_DEV0_CFG0] = 0x20,
+   [NAND_DEV0_CFG1] = 0x24,
+   [NAND_DEV0_ECC_CFG] = 0x28,
+   [NAND_DEV1_ECC_CFG] = 0x2c,
+   [NAND_DEV1_CFG0] = 0x30,
+   [NAND_DEV1_CFG1] = 0x34,
+   [NAND_READ_ID] = 0x40,
+   [NAND_READ_STATUS] = 0x44,
+   [NAND_DEV_CMD0] = 0x70a0,
+   [NAND_DEV_CMD1] = 0x70a4,
+   [NAND_DEV_CMD2] = 0x70a8,
+   [NAND_DEV_CMD_VLD] = 0x70ac,
+   [SFLASHC_BURST_CFG] = 0xe0,
+   [NAND_ERASED_CW_DETECT_CFG] = 0xe8,
+   [NAND_ERASED_CW_DETECT_STATUS] = 0xec,
+   [NAND_EBI2_ECC_BUF_CFG] = 0xf0,
+   [FLASH_BUF_ACC] = 0x100,
+   [NAND_CTRL] = 0xf00,
+   [NAND_VERSION] = 0x4f08,
+   [NAND_READ_LOCATION_0] = 0xf20,
+   [NAND_READ_LOCATION_1] = 0xf24,
+   [NAND_READ_LOCATION_2] = 

Re: [PATCH v3 2/2] acpi/iort: numa: Add numa node mapping for smmuv3 devices

[Lorenzo Pieralisi]

Hi Robert,

On Wed, Jun 28, 2017 at 07:47:50PM +0200, Robert Richter wrote:
> On 15.06.17 14:46:03, Lorenzo Pieralisi wrote:
> > On Thu, Jun 08, 2017 at 10:14:19AM +0530, Ganapatrao Kulkarni wrote:
> > > Add code to parse proximity domain in SMMUv3 IORT table to
> > > set numa node mapping for smmuv3 devices.
> > > 
> > > Signed-off-by: Ganapatrao Kulkarni 
> > > ---
> > >  drivers/acpi/arm64/iort.c | 28 ++--
> > >  1 file changed, 26 insertions(+), 2 deletions(-)
> > 
> > I am happy to take this but I want to know what we shall do with
> > patch 1 and related ACPICA changes first.
> 
> The change is now in acpica:
> 
>  
> https://github.com/acpica/acpica/commit/8cadc4fb500e2aa52241e367c87a0f95d9760c58
> 
> So we could guard the code with an #ifdef until that patch is pulled
> in via acpica tree:
> 
> > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > index bba2b59..e804386 100644
> > > --- a/drivers/acpi/arm64/iort.c
> > > +++ b/drivers/acpi/arm64/iort.c
> > > @@ -882,6 +882,23 @@ static bool __init arm_smmu_v3_is_coherent(struct 
> > > acpi_iort_node *node)
> > >   return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> > >  }
> > >  
> > > +/*
> > > + * set numa proximity domain for smmuv3 device
> > > + */
> > > +static void  __init arm_smmu_v3_set_proximity(struct acpi_iort_node 
> > > *node,
> > > + struct device *dev)
> > > +{
> 
> #ifdef ACPI_IORT_SMMU_V3_PXM_VALID
> 
> > > + struct acpi_iort_smmu_v3 *smmu;
> > > +
> > > + smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
> > > + if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
> > > + set_dev_node(dev, acpi_map_pxm_to_node(smmu->pxm));
> > > + pr_info("SMMUV3[%llx] Mapped to Proximity domain %d\n",
> > > + smmu->base_address,
> > > + smmu->pxm);
> > > + }
> 
> #endif
> 
> > > +}
> > > +
> 
> Could the patch be applied with this change?

Sorry I was away (and the ARM64 tree was not accepting any new code last
week anyway), I will send the patch upstream for 4.14 (with your change
above - or whatever ACPICA guard make it safe - since we will depend on
ACPICA changes merge timing anyway - they won't be merged this cycle).

Bad timing, apologies, I hope it is not a burden to carry it for one
cycle.

Thanks,
Lorenzo

> 
> Thanks,
> 
> -Robert
> 
> > >  static int __init arm_smmu_count_resources(struct acpi_iort_node *node)
> > >  {
> > >   struct acpi_iort_smmu *smmu;
> > > @@ -951,20 +968,24 @@ struct iort_iommu_config {
> > >   int (*iommu_count_resources)(struct acpi_iort_node *node);
> > >   void (*iommu_init_resources)(struct resource *res,
> > >struct acpi_iort_node *node);
> > > + void (*iommu_set_proximity)(struct acpi_iort_node *node,
> > > +  struct device *dev);
> > >  };
> > >  
> > >  static const struct iort_iommu_config iort_arm_smmu_v3_cfg __initconst = 
> > > {
> > >   .name = "arm-smmu-v3",
> > >   .iommu_is_coherent = arm_smmu_v3_is_coherent,
> > >   .iommu_count_resources = arm_smmu_v3_count_resources,
> > > - .iommu_init_resources = arm_smmu_v3_init_resources
> > > + .iommu_init_resources = arm_smmu_v3_init_resources,
> > > + .iommu_set_proximity = arm_smmu_v3_set_proximity
> > >  };
> > >  
> > >  static const struct iort_iommu_config iort_arm_smmu_cfg __initconst = {
> > >   .name = "arm-smmu",
> > >   .iommu_is_coherent = arm_smmu_is_coherent,
> > >   .iommu_count_resources = arm_smmu_count_resources,
> > > - .iommu_init_resources = arm_smmu_init_resources
> > > + .iommu_init_resources = arm_smmu_init_resources,
> > > + .iommu_set_proximity = NULL
> > >  };
> > >  
> > >  static __init
> > > @@ -1002,6 +1023,9 @@ static int __init 
> > > iort_add_smmu_platform_device(struct acpi_iort_node *node)
> > >   if (!pdev)
> > >   return -ENOMEM;
> > >  
> > > + if (ops->iommu_set_proximity)
> > > + ops->iommu_set_proximity(node, >dev);
> > > +
> > >   count = ops->iommu_count_resources(node);
> > >  
> > >   r = kcalloc(count, sizeof(*r), GFP_KERNEL);
> > > -- 
> > > 1.8.1.4
> > > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] net, ipv6: convert ipv6_txoptions.refcnt from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 include/net/ipv6.h   | 7 ---
 net/ipv6/exthdrs.c   | 4 ++--
 net/ipv6/ipv6_sockglue.c | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 3e505bb..6eac5cf 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -203,7 +204,7 @@ extern rwlock_t ip6_ra_lock;
  */
 
 struct ipv6_txoptions {
-   atomic_trefcnt;
+   refcount_t  refcnt;
/* Length of this structure */
int tot_len;
 
@@ -265,7 +266,7 @@ static inline struct ipv6_txoptions *txopt_get(const struct 
ipv6_pinfo *np)
rcu_read_lock();
opt = rcu_dereference(np->opt);
if (opt) {
-   if (!atomic_inc_not_zero(>refcnt))
+   if (!refcount_inc_not_zero(>refcnt))
opt = NULL;
else
opt = rcu_pointer_handoff(opt);
@@ -276,7 +277,7 @@ static inline struct ipv6_txoptions *txopt_get(const struct 
ipv6_pinfo *np)
 
 static inline void txopt_put(struct ipv6_txoptions *opt)
 {
-   if (opt && atomic_dec_and_test(>refcnt))
+   if (opt && refcount_dec_and_test(>refcnt))
kfree_rcu(opt, rcu);
 }
 
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 0460af22..4996d73 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -971,7 +971,7 @@ ipv6_dup_options(struct sock *sk, struct ipv6_txoptions 
*opt)
*((char **)>dst1opt) += dif;
if (opt2->srcrt)
*((char **)>srcrt) += dif;
-   atomic_set(>refcnt, 1);
+   refcount_set(>refcnt, 1);
}
return opt2;
 }
@@ -1056,7 +1056,7 @@ ipv6_renew_options(struct sock *sk, struct ipv6_txoptions 
*opt,
return ERR_PTR(-ENOBUFS);
 
memset(opt2, 0, tot_len);
-   atomic_set(>refcnt, 1);
+   refcount_set(>refcnt, 1);
opt2->tot_len = tot_len;
p = (char *)(opt2 + 1);
 
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index a531ba0..85404e7 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -505,7 +505,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, 
int optname,
break;
 
memset(opt, 0, sizeof(*opt));
-   atomic_set(>refcnt, 1);
+   refcount_set(>refcnt, 1);
opt->tot_len = sizeof(*opt) + optlen;
retv = -EFAULT;
if (copy_from_user(opt+1, optval, optlen))
-- 
2.7.4

[PATCH 6/9] net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 net/ipv6/xfrm6_tunnel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
index d7b731a..4e438bc 100644
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -59,7 +59,7 @@ struct xfrm6_tunnel_spi {
struct hlist_node   list_byspi;
xfrm_address_t  addr;
u32 spi;
-   atomic_trefcnt;
+   refcount_t  refcnt;
struct rcu_head rcu_head;
 };
 
@@ -160,7 +160,7 @@ static u32 __xfrm6_tunnel_alloc_spi(struct net *net, 
xfrm_address_t *saddr)
 
memcpy(>addr, saddr, sizeof(x6spi->addr));
x6spi->spi = spi;
-   atomic_set(>refcnt, 1);
+   refcount_set(>refcnt, 1);
 
hlist_add_head_rcu(>list_byspi, _tn->spi_byspi[index]);
 
@@ -178,7 +178,7 @@ __be32 xfrm6_tunnel_alloc_spi(struct net *net, 
xfrm_address_t *saddr)
spin_lock_bh(_tunnel_spi_lock);
x6spi = __xfrm6_tunnel_spi_lookup(net, saddr);
if (x6spi) {
-   atomic_inc(>refcnt);
+   refcount_inc(>refcnt);
spi = x6spi->spi;
} else
spi = __xfrm6_tunnel_alloc_spi(net, saddr);
@@ -207,7 +207,7 @@ static void xfrm6_tunnel_free_spi(struct net *net, 
xfrm_address_t *saddr)
  list_byaddr)
{
if (xfrm6_addr_equal(>addr, saddr)) {
-   if (atomic_dec_and_test(>refcnt)) {
+   if (refcount_dec_and_test(>refcnt)) {
hlist_del_rcu(>list_byaddr);
hlist_del_rcu(>list_byspi);
call_rcu(>rcu_head, x6spi_destroy_rcu);
-- 
2.7.4

[PATCH 0/9] v2 ipv4/ipv6 refcount conversions

[Elena Reshetova]

Changes in v2:
 * rebase on top of net-next
 * currently by default refcount_t = atomic_t (*) and uses all 
   atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled.
   This is a compromise for the systems that are critical on
   performance (such as net) and cannot accept even slight delay
   on the refcounter operations.

This series, for ipv4/ipv6 network components, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing this we prevent intentional or accidental
underflows or overflows that can led to use-after-free vulnerabilities.

The patches are fully independent and can be cherry-picked separately.
In order to try with refcount functionality enabled in run-time,
CONFIG_REFCOUNT_FULL must be enabled.

NOTE: automatic kernel builder for some reason doesn't like all my
network branches and regularly times out the builds on these branches.
Suggestion for "waiting a day for a good coverage" doesn't work, as
we have seen with generic network conversions. So please wait for the
full report from kernel test rebot before merging further up.
This has been compile-tested in 116 configs, but 71 timed out (including
all s390-related configs again). I am trying to see if they can fix
build coverage for me in meanwhile.

* The respective change is currently merged into -next as
  "locking/refcount: Create unchecked atomic_t implementation".

Elena Reshetova (9):
  net, ipv6: convert ipv6_txoptions.refcnt from atomic_t to refcount_t
  net, ipv6: convert inet6_dev.refcnt from atomic_t to refcount_t
  net, ipv6: convert inet6_ifaddr.refcnt from atomic_t to refcount_t
  net, ipv6: convert ifmcaddr6.mca_refcnt from atomic_t to refcount_t
  net, ipv6: convert ifacaddr6.aca_refcnt from atomic_t to refcount_t
  net, ipv6: convert xfrm6_tunnel_spi.refcnt from atomic_t to refcount_t
  net, ipv6: convert ip6addrlbl_entry.refcnt from atomic_t to refcount_t
  net, ipv4: convert cipso_v4_doi.refcount from atomic_t to refcount_t
  net, ipv4: convert fib_info.fib_clntref from atomic_t to refcount_t

 include/net/addrconf.h   | 14 +++---
 include/net/cipso_ipv4.h |  3 ++-
 include/net/if_inet6.h   |  9 +
 include/net/ip_fib.h |  7 ---
 include/net/ipv6.h   |  7 ---
 net/ipv4/cipso_ipv4.c| 12 ++--
 net/ipv4/fib_semantics.c |  2 +-
 net/ipv4/fib_trie.c  |  2 +-
 net/ipv6/addrconf.c  |  4 ++--
 net/ipv6/addrlabel.c |  9 +
 net/ipv6/anycast.c   |  6 +++---
 net/ipv6/exthdrs.c   |  4 ++--
 net/ipv6/ipv6_sockglue.c |  2 +-
 net/ipv6/mcast.c | 18 +-
 net/ipv6/xfrm6_tunnel.c  |  8 
 15 files changed, 56 insertions(+), 51 deletions(-)

-- 
2.7.4

[PATCH 5/9] net, ipv6: convert ifacaddr6.aca_refcnt from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 include/net/if_inet6.h | 2 +-
 net/ipv6/anycast.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index 4bb52ce..d4088d1 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -147,7 +147,7 @@ struct ifacaddr6 {
struct rt6_info *aca_rt;
struct ifacaddr6*aca_next;
int aca_users;
-   atomic_taca_refcnt;
+   refcount_t  aca_refcnt;
unsigned long   aca_cstamp;
unsigned long   aca_tstamp;
 };
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 514ac25..0bbab8a 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -203,12 +203,12 @@ void ipv6_sock_ac_close(struct sock *sk)
 
 static void aca_get(struct ifacaddr6 *aca)
 {
-   atomic_inc(>aca_refcnt);
+   refcount_inc(>aca_refcnt);
 }
 
 static void aca_put(struct ifacaddr6 *ac)
 {
-   if (atomic_dec_and_test(>aca_refcnt)) {
+   if (refcount_dec_and_test(>aca_refcnt)) {
in6_dev_put(ac->aca_idev);
dst_release(>aca_rt->dst);
kfree(ac);
@@ -232,7 +232,7 @@ static struct ifacaddr6 *aca_alloc(struct rt6_info *rt,
aca->aca_users = 1;
/* aca_tstamp should be updated upon changes */
aca->aca_cstamp = aca->aca_tstamp = jiffies;
-   atomic_set(>aca_refcnt, 1);
+   refcount_set(>aca_refcnt, 1);
 
return aca;
 }
-- 
2.7.4

[PATCH 2/9] net, ipv6: convert inet6_dev.refcnt from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 include/net/addrconf.h | 8 
 include/net/if_inet6.h | 3 ++-
 net/ipv6/addrconf.c| 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index d0889cb..620bd9a 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -316,7 +316,7 @@ static inline struct inet6_dev *in6_dev_get(const struct 
net_device *dev)
rcu_read_lock();
idev = rcu_dereference(dev->ip6_ptr);
if (idev)
-   atomic_inc(>refcnt);
+   refcount_inc(>refcnt);
rcu_read_unlock();
return idev;
 }
@@ -332,18 +332,18 @@ void in6_dev_finish_destroy(struct inet6_dev *idev);
 
 static inline void in6_dev_put(struct inet6_dev *idev)
 {
-   if (atomic_dec_and_test(>refcnt))
+   if (refcount_dec_and_test(>refcnt))
in6_dev_finish_destroy(idev);
 }
 
 static inline void __in6_dev_put(struct inet6_dev *idev)
 {
-   atomic_dec(>refcnt);
+   refcount_dec(>refcnt);
 }
 
 static inline void in6_dev_hold(struct inet6_dev *idev)
 {
-   atomic_inc(>refcnt);
+   refcount_inc(>refcnt);
 }
 
 void inet6_ifa_finish_destroy(struct inet6_ifaddr *ifp);
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index f656f90..e7a17b2 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 /* inet6_dev.if_flags */
 
@@ -187,7 +188,7 @@ struct inet6_dev {
 
struct ifacaddr6*ac_list;
rwlock_tlock;
-   atomic_trefcnt;
+   refcount_t  refcnt;
__u32   if_flags;
int dead;
 
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 114fb64..2365f12 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -426,7 +426,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device 
*dev)
}
 
/* One reference from device. */
-   in6_dev_hold(ndev);
+   refcount_set(>refcnt, 1);
 
if (dev->flags & (IFF_NOARP | IFF_LOOPBACK))
ndev->cnf.accept_dad = -1;
-- 
2.7.4

Re: [PATCH v2 1/2] ACPI: SPCR: Use access width to determine mmio usage

[Greg Kroah-Hartman]

On Mon, Jul 03, 2017 at 11:44:30PM +0200, Rafael J. Wysocki wrote:
> On Mon, Jul 3, 2017 at 11:33 PM, Loc Ho  wrote:
> > The current SPCR code does not check the access width of the mmio, and
> > uses a default of 8bit register accesses.  This prevents devices that
> > only do 16 or 32bit register accesses from working.  By simply checking
> > this field and setting the mmio string appropriately, this issue can be
> > corrected.  To prevent any legacy issues, the code will default to 8bit
> > accesses if the value is anything but 16 or 32.
> >
> > Signed-off-by: Loc Ho 
> > [Re-send as single patch set]
> > Signed-off-by: Jon Mason 
> 
> Greg, Aleksey, any objections here?
> 
> If not, I'll route this through the ACPI tree.

No objections from me for either of these patches:
Acked-by: Greg Kroah-Hartman