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

[Boris Brezillon]

On Sun, 29 Apr 2018 15:01:11 -0400
Marcin Ziemianowicz  wrote:

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

Acked-by: Boris Brezillon 

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

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

[Boris Brezillon]

On Sun, 29 Apr 2018 15:01:11 -0400
Marcin Ziemianowicz  wrote:

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

Acked-by: Boris Brezillon 

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

[PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Wenwen Wang]

In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and msgbuf1,
which are used to save a series of messages, as mentioned in the comment.
According to the value of the variable "size", msgbuf0 is initialized to
various values. In contrast, msgbuf1 is left uninitialized until the
function i2c_transfer() is invoked. However, mgsbuf1 is not always
initialized on all possible execution paths (implementation) of
i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be
uninitialized even after the invocation of the function i2c_transfer(). In
the following execution, the uninitialized msgbuf1 will be used, such as
for security checks. Since uninitialized values can be random and
arbitrary, this will cause undefined behaviors or even check bypass. For
example, it is expected that if the value of "size" is
I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be larger
than I2C_SMBUS_BLOCK_MAX. But, at the end of i2c_smbus_xfer_emulated(), the
value read from msgbuf1 is assigned to data->block[0], which can
potentially lead to invalid block write size, as demonstrated in the error
message.

This patch simply initializes the buffer msgbuf1 with 0 to avoid undefined
behaviors or security issues.

Signed-off-by: Wenwen Wang 
---
 drivers/i2c/i2c-core-smbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b5aec33..0fcca75 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct i2c_adapter 
*adapter, u16 addr,
 * somewhat simpler.
 */
unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
-   unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
+   unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};
int num = read_write == I2C_SMBUS_READ ? 2 : 1;
int i;
u8 partial_pec = 0;
-- 
2.7.4

[PATCH] i2c: core-smbus: fix a potential uninitialization bug

[Wenwen Wang]

In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and msgbuf1,
which are used to save a series of messages, as mentioned in the comment.
According to the value of the variable "size", msgbuf0 is initialized to
various values. In contrast, msgbuf1 is left uninitialized until the
function i2c_transfer() is invoked. However, mgsbuf1 is not always
initialized on all possible execution paths (implementation) of
i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be
uninitialized even after the invocation of the function i2c_transfer(). In
the following execution, the uninitialized msgbuf1 will be used, such as
for security checks. Since uninitialized values can be random and
arbitrary, this will cause undefined behaviors or even check bypass. For
example, it is expected that if the value of "size" is
I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be larger
than I2C_SMBUS_BLOCK_MAX. But, at the end of i2c_smbus_xfer_emulated(), the
value read from msgbuf1 is assigned to data->block[0], which can
potentially lead to invalid block write size, as demonstrated in the error
message.

This patch simply initializes the buffer msgbuf1 with 0 to avoid undefined
behaviors or security issues.

Signed-off-by: Wenwen Wang 
---
 drivers/i2c/i2c-core-smbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b5aec33..0fcca75 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct i2c_adapter 
*adapter, u16 addr,
 * somewhat simpler.
 */
unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
-   unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
+   unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};
int num = read_write == I2C_SMBUS_READ ? 2 : 1;
int i;
u8 partial_pec = 0;
-- 
2.7.4

[PATCH v2 01/10] PCI: Make pci_get_new_domain_nr() static

[Jan Kiszka]

From: Jan Kiszka 

The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.

No functional change intended.

Signed-off-by: Jan Kiszka 
Acked-by: Lorenzo Pieralisi 
---
 drivers/pci/pci.c   | 6 ++
 include/linux/pci.h | 3 ---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a04197ce767d..811d71e7ee05 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5702,15 +5702,14 @@ static void pci_no_domains(void)
 #endif
 }
 
-#ifdef CONFIG_PCI_DOMAINS
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
 static atomic_t __domain_nr = ATOMIC_INIT(-1);
 
-int pci_get_new_domain_nr(void)
+static int pci_get_new_domain_nr(void)
 {
return atomic_inc_return(&__domain_nr);
 }
 
-#ifdef CONFIG_PCI_DOMAINS_GENERIC
 static int of_pci_bus_find_domain_nr(struct device *parent)
 {
static int use_dt_domains = -1;
@@ -5765,7 +5764,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct 
device *parent)
   acpi_pci_bus_find_domain_nr(bus);
 }
 #endif
-#endif
 
 /**
  * pci_ext_cfg_avail - can we access extended PCI config space?
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..963232a6cd2e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
  */
 #ifdef CONFIG_PCI_DOMAINS
 extern int pci_domains_supported;
-int pci_get_new_domain_nr(void);
 #else
 enum { pci_domains_supported = 0 };
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
 #endif /* CONFIG_PCI_DOMAINS */
 
 /*
@@ -1670,7 +1668,6 @@ static inline struct pci_dev 
*pci_get_domain_bus_and_slot(int domain,
 
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
 
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
-- 
2.13.6

[PATCH v2 01/10] PCI: Make pci_get_new_domain_nr() static

[Jan Kiszka]

From: Jan Kiszka 

The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.

No functional change intended.

Signed-off-by: Jan Kiszka 
Acked-by: Lorenzo Pieralisi 
---
 drivers/pci/pci.c   | 6 ++
 include/linux/pci.h | 3 ---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a04197ce767d..811d71e7ee05 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5702,15 +5702,14 @@ static void pci_no_domains(void)
 #endif
 }
 
-#ifdef CONFIG_PCI_DOMAINS
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
 static atomic_t __domain_nr = ATOMIC_INIT(-1);
 
-int pci_get_new_domain_nr(void)
+static int pci_get_new_domain_nr(void)
 {
return atomic_inc_return(&__domain_nr);
 }
 
-#ifdef CONFIG_PCI_DOMAINS_GENERIC
 static int of_pci_bus_find_domain_nr(struct device *parent)
 {
static int use_dt_domains = -1;
@@ -5765,7 +5764,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct 
device *parent)
   acpi_pci_bus_find_domain_nr(bus);
 }
 #endif
-#endif
 
 /**
  * pci_ext_cfg_avail - can we access extended PCI config space?
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..963232a6cd2e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
  */
 #ifdef CONFIG_PCI_DOMAINS
 extern int pci_domains_supported;
-int pci_get_new_domain_nr(void);
 #else
 enum { pci_domains_supported = 0 };
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
 #endif /* CONFIG_PCI_DOMAINS */
 
 /*
@@ -1670,7 +1668,6 @@ static inline struct pci_dev 
*pci_get_domain_bus_and_slot(int domain,
 
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
 
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
-- 
2.13.6

[PATCH v2 00/10] PCI: leak fixes, removable generic PCI host, assorted stuff

[Jan Kiszka]

Changes in v2:
 - patch 1: commit message reworking as suggested by Lorenzo
 - patch 3-6: split-up as suggested by Bjorn
 - patch 8: new
 - patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than
   allowing manual choice, as suggested by Lorenzo

This primarily enables to unbind the generic PCI host controller without
leaving lots of memory leaks behind. A previous proposal patch 5 was
rejected because of those issues [1].

The fixes have been validated in the Jailhouse setup, where we add and
remove a virtual PCI host controller on hypervisor activation/
deactivation, with the help of kmemleak.

Besides that, there is tiny PCI API cleanup at the beginning and
support for manually enabled PCI domains at the end that enables the
Jailhouse scenario.

Jan

[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html


CC: Jingoo Han 
CC: Joao Pinto 
CC: Lorenzo Pieralisi 
CC: Will Deacon 

Jan Kiszka (10):
  PCI: Make pci_get_new_domain_nr() static
  PCI: Fix memory leak of devm_pci_alloc_host_bridge()
  PCI: Factor out __of_pci_get_host_bridge_resources()
  PCI: Add dev parameter to __of_pci_get_host_bridge_resources()
  PCI: Replace pr_*() with dev_*() in
__of_pci_get_host_bridge_resources()
  PCI: Introduce devm_of_pci_get_host_bridge_resources()
  PCI: Convert of_pci_get_host_bridge_resources() users to devm variant
  PCI: Deprecate of_pci_get_host_bridge_resources()
  PCI: Add support for unbinding the generic PCI host controller
  PCI: Enable PCI_DOMAINS along with generic PCI host controller

 drivers/pci/dwc/pcie-designware-host.c |   2 +-
 drivers/pci/host/Kconfig   |   1 +
 drivers/pci/host/pci-aardvark.c|   5 +-
 drivers/pci/host/pci-ftpci100.c|   4 +-
 drivers/pci/host/pci-host-common.c |  13 
 drivers/pci/host/pci-host-generic.c|   1 +
 drivers/pci/host/pci-v3-semi.c |   3 +-
 drivers/pci/host/pci-versatile.c   |   3 +-
 drivers/pci/host/pci-xgene.c   |   3 +-
 drivers/pci/host/pcie-altera.c |   5 +-
 drivers/pci/host/pcie-iproc-platform.c |   4 +-
 drivers/pci/host/pcie-rcar.c   |   5 +-
 drivers/pci/host/pcie-rockchip.c   |   4 +-
 drivers/pci/host/pcie-xilinx-nwl.c |   4 +-
 drivers/pci/host/pcie-xilinx.c |   4 +-
 drivers/pci/of.c   | 105 +
 drivers/pci/pci.c  |   6 +-
 drivers/pci/probe.c|   4 +-
 include/linux/of_pci.h |  42 -
 include/linux/pci-ecam.h   |   1 +
 include/linux/pci.h|   3 -
 21 files changed, 149 insertions(+), 73 deletions(-)

-- 
2.13.6

[PATCH v2 10/10] PCI: Enable PCI_DOMAINS along with generic PCI host controller

[Jan Kiszka]

From: Jan Kiszka 

This controller is often instantiated by hypervisors, and they may add
multiple of them or add them in addition to a physical host controller
like the Jailhouse hypervisor is doing. Therefore allow for multiple
domains so that we can handle them all.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/host/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 0d0177ce436c..3d25b35bb5ab 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -68,6 +68,7 @@ config PCI_HOST_GENERIC
depends on (ARM || ARM64) && OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
+   select PCI_DOMAINS
help
  Say Y here if you want to support a simple generic PCI host
  controller, such as the one emulated by kvmtool.
-- 
2.13.6

[PATCH v2 00/10] PCI: leak fixes, removable generic PCI host, assorted stuff

[Jan Kiszka]

Changes in v2:
 - patch 1: commit message reworking as suggested by Lorenzo
 - patch 3-6: split-up as suggested by Bjorn
 - patch 8: new
 - patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than
   allowing manual choice, as suggested by Lorenzo

This primarily enables to unbind the generic PCI host controller without
leaving lots of memory leaks behind. A previous proposal patch 5 was
rejected because of those issues [1].

The fixes have been validated in the Jailhouse setup, where we add and
remove a virtual PCI host controller on hypervisor activation/
deactivation, with the help of kmemleak.

Besides that, there is tiny PCI API cleanup at the beginning and
support for manually enabled PCI domains at the end that enables the
Jailhouse scenario.

Jan

[1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html


CC: Jingoo Han 
CC: Joao Pinto 
CC: Lorenzo Pieralisi 
CC: Will Deacon 

Jan Kiszka (10):
  PCI: Make pci_get_new_domain_nr() static
  PCI: Fix memory leak of devm_pci_alloc_host_bridge()
  PCI: Factor out __of_pci_get_host_bridge_resources()
  PCI: Add dev parameter to __of_pci_get_host_bridge_resources()
  PCI: Replace pr_*() with dev_*() in
__of_pci_get_host_bridge_resources()
  PCI: Introduce devm_of_pci_get_host_bridge_resources()
  PCI: Convert of_pci_get_host_bridge_resources() users to devm variant
  PCI: Deprecate of_pci_get_host_bridge_resources()
  PCI: Add support for unbinding the generic PCI host controller
  PCI: Enable PCI_DOMAINS along with generic PCI host controller

 drivers/pci/dwc/pcie-designware-host.c |   2 +-
 drivers/pci/host/Kconfig   |   1 +
 drivers/pci/host/pci-aardvark.c|   5 +-
 drivers/pci/host/pci-ftpci100.c|   4 +-
 drivers/pci/host/pci-host-common.c |  13 
 drivers/pci/host/pci-host-generic.c|   1 +
 drivers/pci/host/pci-v3-semi.c |   3 +-
 drivers/pci/host/pci-versatile.c   |   3 +-
 drivers/pci/host/pci-xgene.c   |   3 +-
 drivers/pci/host/pcie-altera.c |   5 +-
 drivers/pci/host/pcie-iproc-platform.c |   4 +-
 drivers/pci/host/pcie-rcar.c   |   5 +-
 drivers/pci/host/pcie-rockchip.c   |   4 +-
 drivers/pci/host/pcie-xilinx-nwl.c |   4 +-
 drivers/pci/host/pcie-xilinx.c |   4 +-
 drivers/pci/of.c   | 105 +
 drivers/pci/pci.c  |   6 +-
 drivers/pci/probe.c|   4 +-
 include/linux/of_pci.h |  42 -
 include/linux/pci-ecam.h   |   1 +
 include/linux/pci.h|   3 -
 21 files changed, 149 insertions(+), 73 deletions(-)

-- 
2.13.6

[PATCH v2 10/10] PCI: Enable PCI_DOMAINS along with generic PCI host controller

[Jan Kiszka]

From: Jan Kiszka 

This controller is often instantiated by hypervisors, and they may add
multiple of them or add them in addition to a physical host controller
like the Jailhouse hypervisor is doing. Therefore allow for multiple
domains so that we can handle them all.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/host/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 0d0177ce436c..3d25b35bb5ab 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -68,6 +68,7 @@ config PCI_HOST_GENERIC
depends on (ARM || ARM64) && OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
+   select PCI_DOMAINS
help
  Say Y here if you want to support a simple generic PCI host
  controller, such as the one emulated by kvmtool.
-- 
2.13.6

[PATCH v2 05/10] PCI: Replace pr_*() with dev_*() in __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

Now that we have a device reference, make use of it for printing. And as
long as dev can still be NULL, we will still get some reasonable output
nevertheless.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index bfa282b538d5..8f6cbf13e18d 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -266,15 +266,15 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
if (!bus_range)
return -ENOMEM;
 
-   pr_info("host bridge %pOF ranges:\n", dev_node);
+   dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
 
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
-   pr_info("  No bus range found for %pOF, using %pR\n",
-   dev_node, bus_range);
+   dev_info(dev, "  No bus range found for %pOF, using %pR\n",
+dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -286,7 +286,7 @@ static int __of_pci_get_host_bridge_resources(struct device 
*dev,
if (err)
goto parse_failed;
 
-   pr_debug("Parsing ranges property...\n");
+   dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(, ) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
@@ -295,9 +295,9 @@ static int __of_pci_get_host_bridge_resources(struct device 
*dev,
snprintf(range_type, 4, "MEM");
else
snprintf(range_type, 4, "err");
-   pr_info("  %s %#010llx..%#010llx -> %#010llx\n", range_type,
-   range.cpu_addr, range.cpu_addr + range.size - 1,
-   range.pci_addr);
+   dev_info(dev, "  %s %#010llx..%#010llx -> %#010llx\n",
+range_type, range.cpu_addr,
+range.cpu_addr + range.size - 1, range.pci_addr);
 
/*
 * If we failed translation or got a zero-sized region
@@ -324,14 +324,16 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
 
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
-   pr_err("I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
+   dev_err(dev,
+   "I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
-   pr_warn("More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
-   dev_node);
+   dev_warn(dev,
+"More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
+dev_node);
*io_base = range.cpu_addr;
}
 
-- 
2.13.6

[PATCH v2 05/10] PCI: Replace pr_*() with dev_*() in __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

Now that we have a device reference, make use of it for printing. And as
long as dev can still be NULL, we will still get some reasonable output
nevertheless.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index bfa282b538d5..8f6cbf13e18d 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -266,15 +266,15 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
if (!bus_range)
return -ENOMEM;
 
-   pr_info("host bridge %pOF ranges:\n", dev_node);
+   dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
 
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
-   pr_info("  No bus range found for %pOF, using %pR\n",
-   dev_node, bus_range);
+   dev_info(dev, "  No bus range found for %pOF, using %pR\n",
+dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -286,7 +286,7 @@ static int __of_pci_get_host_bridge_resources(struct device 
*dev,
if (err)
goto parse_failed;
 
-   pr_debug("Parsing ranges property...\n");
+   dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(, ) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
@@ -295,9 +295,9 @@ static int __of_pci_get_host_bridge_resources(struct device 
*dev,
snprintf(range_type, 4, "MEM");
else
snprintf(range_type, 4, "err");
-   pr_info("  %s %#010llx..%#010llx -> %#010llx\n", range_type,
-   range.cpu_addr, range.cpu_addr + range.size - 1,
-   range.pci_addr);
+   dev_info(dev, "  %s %#010llx..%#010llx -> %#010llx\n",
+range_type, range.cpu_addr,
+range.cpu_addr + range.size - 1, range.pci_addr);
 
/*
 * If we failed translation or got a zero-sized region
@@ -324,14 +324,16 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
 
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
-   pr_err("I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
+   dev_err(dev,
+   "I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
-   pr_warn("More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
-   dev_node);
+   dev_warn(dev,
+"More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
+dev_node);
*io_base = range.cpu_addr;
}
 
-- 
2.13.6

[PATCH v2 08/10] PCI: Deprecate of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

There are no in-tree users remaining, all are converted to the managed
variant. And it is unlikely that any out-of-tree user got the resource
management right as well. So deprecate the interface and push users to
the managed version instead.

To avoid raising a warning when exporting a deprecated symbol, wrap the
API with an inline and export an internal name.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 23 ++-
 include/linux/of_pci.h | 36 
 2 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 5a88d46a41b7..ccf8c7544e10 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -351,33 +351,14 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
return err;
 }
 
-/**
- * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
- * @dev_node: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
  bus_max, resources, io_base);
 }
-EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+EXPORT_SYMBOL_GPL(__of_pci_get_host_bridge_resources_deprecated);
 
 /**
  * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 08b8f02426a5..c6408bd6f862 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,26 +71,54 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin)
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
 int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
 #else
-static inline int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
return -EINVAL;
 }
+#endif
 
-static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ *
+ * Note: This function is deprecated and will eventually be removed. Use
+ * devm_of_pci_get_host_bridge_resources() instead.
+ */
+static inline int __deprecated of_pci_get_host_bridge_resources(
+   struct device_node *dev_node,
unsigned char busno, unsigned 

[PATCH v2 08/10] PCI: Deprecate of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

There are no in-tree users remaining, all are converted to the managed
variant. And it is unlikely that any out-of-tree user got the resource
management right as well. So deprecate the interface and push users to
the managed version instead.

To avoid raising a warning when exporting a deprecated symbol, wrap the
API with an inline and export an internal name.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 23 ++-
 include/linux/of_pci.h | 36 
 2 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 5a88d46a41b7..ccf8c7544e10 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -351,33 +351,14 @@ static int __of_pci_get_host_bridge_resources(struct 
device *dev,
return err;
 }
 
-/**
- * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
- * @dev_node: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
  bus_max, resources, io_base);
 }
-EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+EXPORT_SYMBOL_GPL(__of_pci_get_host_bridge_resources_deprecated);
 
 /**
  * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 08b8f02426a5..c6408bd6f862 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,26 +71,54 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin)
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
 int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
 #else
-static inline int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
return -EINVAL;
 }
+#endif
 
-static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ *
+ * Note: This function is deprecated and will eventually be removed. Use
+ * devm_of_pci_get_host_bridge_resources() instead.
+ */
+static inline int __deprecated of_pci_get_host_bridge_resources(
+   struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct 

[PATCH v2 04/10] PCI: Add dev parameter to __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

When non-NULL, use the new dev parameter of
__of_pci_get_host_bridge_resources() to allocate the resource data
structures via devm_kzalloc. That allows to release them automatically
during device destruction.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 375de447a58e..bfa282b538d5 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,7 +243,7 @@ void of_pci_check_probe_only(void)
 EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
 
 #if defined(CONFIG_OF_ADDRESS)
-static int __of_pci_get_host_bridge_resources(
+static int __of_pci_get_host_bridge_resources(struct device *dev,
struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
@@ -259,7 +259,10 @@ static int __of_pci_get_host_bridge_resources(
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
 
-   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+   if (dev)
+   bus_range = devm_kzalloc(dev,sizeof(*bus_range), GFP_KERNEL);
+   else
+   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
 
@@ -303,7 +306,11 @@ static int __of_pci_get_host_bridge_resources(
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
 
-   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (dev)
+   res = devm_kzalloc(dev, sizeof(struct resource),
+  GFP_KERNEL);
+   else
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto parse_failed;
@@ -365,7 +372,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
-   return __of_pci_get_host_bridge_resources(dev_node, busno,
+   return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
  bus_max, resources, io_base);
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
-- 
2.13.6

[PATCH v2 06/10] PCI: Introduce devm_of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

of_pci_get_host_bridge_resources() allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, introduce a
managed version of that service. This differs API-wise only in taking a
reference to the associated device, rather than to the device tree node.

As of_pci_get_host_bridge_resources() is an exported interface, we
cannot simply drop it at this point. After converting all in-tree users
to the new API, we will phase out the unmanaged one.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 28 
 include/linux/of_pci.h | 10 ++
 2 files changed, 38 insertions(+)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 8f6cbf13e18d..f16b343d3b85 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -378,6 +378,34 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
  bus_max, resources, io_base);
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
+ *  bridge resources from DT
+ * @dev: host bridge device
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base)
+{
+   return __of_pci_get_host_bridge_resources(dev, dev->of_node, busno,
+ bus_max, resources, io_base);
+}
+EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
+
 #endif /* CONFIG_OF_ADDRESS */
 
 /**
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 74eec1943ad2..08b8f02426a5 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -74,6 +74,9 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, 
u8 pin)
 int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base);
 #else
 static inline int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
unsigned char busno, unsigned char bus_max,
@@ -81,6 +84,13 @@ static inline int of_pci_get_host_bridge_resources(struct 
device_node *dev_node,
 {
return -EINVAL;
 }
+
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base)
+{
+   return -EINVAL;
+}
 #endif
 
 #endif
-- 
2.13.6

[PATCH v2 04/10] PCI: Add dev parameter to __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

When non-NULL, use the new dev parameter of
__of_pci_get_host_bridge_resources() to allocate the resource data
structures via devm_kzalloc. That allows to release them automatically
during device destruction.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 375de447a58e..bfa282b538d5 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,7 +243,7 @@ void of_pci_check_probe_only(void)
 EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
 
 #if defined(CONFIG_OF_ADDRESS)
-static int __of_pci_get_host_bridge_resources(
+static int __of_pci_get_host_bridge_resources(struct device *dev,
struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
@@ -259,7 +259,10 @@ static int __of_pci_get_host_bridge_resources(
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
 
-   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+   if (dev)
+   bus_range = devm_kzalloc(dev,sizeof(*bus_range), GFP_KERNEL);
+   else
+   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
 
@@ -303,7 +306,11 @@ static int __of_pci_get_host_bridge_resources(
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
 
-   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (dev)
+   res = devm_kzalloc(dev, sizeof(struct resource),
+  GFP_KERNEL);
+   else
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto parse_failed;
@@ -365,7 +372,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
-   return __of_pci_get_host_bridge_resources(dev_node, busno,
+   return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
  bus_max, resources, io_base);
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
-- 
2.13.6

[PATCH v2 06/10] PCI: Introduce devm_of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

of_pci_get_host_bridge_resources() allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, introduce a
managed version of that service. This differs API-wise only in taking a
reference to the associated device, rather than to the device tree node.

As of_pci_get_host_bridge_resources() is an exported interface, we
cannot simply drop it at this point. After converting all in-tree users
to the new API, we will phase out the unmanaged one.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 28 
 include/linux/of_pci.h | 10 ++
 2 files changed, 38 insertions(+)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 8f6cbf13e18d..f16b343d3b85 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -378,6 +378,34 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
  bus_max, resources, io_base);
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
+ *  bridge resources from DT
+ * @dev: host bridge device
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base)
+{
+   return __of_pci_get_host_bridge_resources(dev, dev->of_node, busno,
+ bus_max, resources, io_base);
+}
+EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
+
 #endif /* CONFIG_OF_ADDRESS */
 
 /**
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 74eec1943ad2..08b8f02426a5 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -74,6 +74,9 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, 
u8 pin)
 int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base);
 #else
 static inline int of_pci_get_host_bridge_resources(struct device_node 
*dev_node,
unsigned char busno, unsigned char bus_max,
@@ -81,6 +84,13 @@ static inline int of_pci_get_host_bridge_resources(struct 
device_node *dev_node,
 {
return -EINVAL;
 }
+
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+   unsigned char busno, unsigned char bus_max,
+   struct list_head *resources, resource_size_t *io_base)
+{
+   return -EINVAL;
+}
 #endif
 
 #endif
-- 
2.13.6

[PATCH v2 03/10] PCI: Factor out __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

This will be needed for sharing the core logic between current
of_pci_get_host_bridge_resources() and upcoming
devm_of_pci_get_host_bridge_resources().

Already rename the dev parameter to dev_node in order to free the
namespace for a real device parameter.

No functional changes.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 63 --
 include/linux/of_pci.h |  4 ++--
 2 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..375de447a58e 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,26 +243,8 @@ void of_pci_check_probe_only(void)
 EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
 
 #if defined(CONFIG_OF_ADDRESS)
-/**
- * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+static int __of_pci_get_host_bridge_resources(
+   struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
@@ -281,15 +263,15 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (!bus_range)
return -ENOMEM;
 
-   pr_info("host bridge %pOF ranges:\n", dev);
+   pr_info("host bridge %pOF ranges:\n", dev_node);
 
-   err = of_pci_parse_bus_range(dev, bus_range);
+   err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info("  No bus range found for %pOF, using %pR\n",
-   dev, bus_range);
+   dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +279,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
pci_add_resource(resources, bus_range);
 
/* Check for ranges property */
-   err = of_pci_range_parser_init(, dev);
+   err = of_pci_range_parser_init(, dev_node);
if (err)
goto parse_failed;
 
@@ -327,7 +309,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
goto parse_failed;
}
 
-   err = of_pci_range_to_resource(, dev, res);
+   err = of_pci_range_to_resource(, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +318,13 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
-   dev);
+   dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
-   dev);
+   dev_node);
*io_base = range.cpu_addr;
}
 
@@ -359,6 +341,33 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
pci_free_resource_list(resources);
return err;
 }
+
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be 

[PATCH v2 09/10] PCI: Add support for unbinding the generic PCI host controller

[Jan Kiszka]

From: Jan Kiszka 

Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.

CC: Will Deacon 
CC: Lorenzo Pieralisi 
Signed-off-by: Jan Kiszka 
---
 drivers/pci/host/pci-host-common.c  | 13 +
 drivers/pci/host/pci-host-generic.c |  1 +
 include/linux/pci-ecam.h|  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/pci/host/pci-host-common.c 
b/drivers/pci/host/pci-host-common.c
index 5d028f53fdcd..d8f10451f273 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -101,5 +101,18 @@ int pci_host_common_probe(struct platform_device *pdev,
return ret;
}
 
+   platform_set_drvdata(pdev, bridge->bus);
+   return 0;
+}
+
+int pci_host_common_remove(struct platform_device *pdev)
+{
+   struct pci_bus *bus = platform_get_drvdata(pdev);
+
+   pci_lock_rescan_remove();
+   pci_stop_root_bus(bus);
+   pci_remove_root_bus(bus);
+   pci_unlock_rescan_remove();
+
return 0;
 }
diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 45319ee3b484..dea3ec7592a2 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -95,5 +95,6 @@ static struct platform_driver gen_pci_driver = {
.suppress_bind_attrs = true,
},
.probe = gen_pci_probe,
+   .remove = pci_host_common_remove,
 };
 builtin_platform_driver(gen_pci_driver);
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index baadad1aabbc..29efa09d686b 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,5 +62,6 @@ extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM 
X-Gene PCIe v2.x */
 /* for DT-based PCI controllers that support ECAM */
 int pci_host_common_probe(struct platform_device *pdev,
  struct pci_ecam_ops *ops);
+int pci_host_common_remove(struct platform_device *pdev);
 #endif
 #endif
-- 
2.13.6

[PATCH v2 03/10] PCI: Factor out __of_pci_get_host_bridge_resources()

[Jan Kiszka]

From: Jan Kiszka 

This will be needed for sharing the core logic between current
of_pci_get_host_bridge_resources() and upcoming
devm_of_pci_get_host_bridge_resources().

Already rename the dev parameter to dev_node in order to free the
namespace for a real device parameter.

No functional changes.

Signed-off-by: Jan Kiszka 
---
 drivers/pci/of.c   | 63 --
 include/linux/of_pci.h |  4 ++--
 2 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..375de447a58e 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,26 +243,8 @@ void of_pci_check_probe_only(void)
 EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
 
 #if defined(CONFIG_OF_ADDRESS)
-/**
- * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+static int __of_pci_get_host_bridge_resources(
+   struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
 {
@@ -281,15 +263,15 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (!bus_range)
return -ENOMEM;
 
-   pr_info("host bridge %pOF ranges:\n", dev);
+   pr_info("host bridge %pOF ranges:\n", dev_node);
 
-   err = of_pci_parse_bus_range(dev, bus_range);
+   err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info("  No bus range found for %pOF, using %pR\n",
-   dev, bus_range);
+   dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +279,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
pci_add_resource(resources, bus_range);
 
/* Check for ranges property */
-   err = of_pci_range_parser_init(, dev);
+   err = of_pci_range_parser_init(, dev_node);
if (err)
goto parse_failed;
 
@@ -327,7 +309,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
goto parse_failed;
}
 
-   err = of_pci_range_to_resource(, dev, res);
+   err = of_pci_range_to_resource(, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +318,13 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please 
provide an io_base pointer to save CPU base address\n",
-   dev);
+   dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted 
for %pOF. CPU base address for old range lost!\n",
-   dev);
+   dev_node);
*io_base = range.cpu_addr;
}
 
@@ -359,6 +341,33 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
pci_free_resource_list(resources);
return err;
 }
+
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a 

[PATCH v2 09/10] PCI: Add support for unbinding the generic PCI host controller

[Jan Kiszka]

From: Jan Kiszka 

Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.

CC: Will Deacon 
CC: Lorenzo Pieralisi 
Signed-off-by: Jan Kiszka 
---
 drivers/pci/host/pci-host-common.c  | 13 +
 drivers/pci/host/pci-host-generic.c |  1 +
 include/linux/pci-ecam.h|  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/pci/host/pci-host-common.c 
b/drivers/pci/host/pci-host-common.c
index 5d028f53fdcd..d8f10451f273 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -101,5 +101,18 @@ int pci_host_common_probe(struct platform_device *pdev,
return ret;
}
 
+   platform_set_drvdata(pdev, bridge->bus);
+   return 0;
+}
+
+int pci_host_common_remove(struct platform_device *pdev)
+{
+   struct pci_bus *bus = platform_get_drvdata(pdev);
+
+   pci_lock_rescan_remove();
+   pci_stop_root_bus(bus);
+   pci_remove_root_bus(bus);
+   pci_unlock_rescan_remove();
+
return 0;
 }
diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 45319ee3b484..dea3ec7592a2 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -95,5 +95,6 @@ static struct platform_driver gen_pci_driver = {
.suppress_bind_attrs = true,
},
.probe = gen_pci_probe,
+   .remove = pci_host_common_remove,
 };
 builtin_platform_driver(gen_pci_driver);
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index baadad1aabbc..29efa09d686b 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,5 +62,6 @@ extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM 
X-Gene PCIe v2.x */
 /* for DT-based PCI controllers that support ECAM */
 int pci_host_common_probe(struct platform_device *pdev,
  struct pci_ecam_ops *ops);
+int pci_host_common_remove(struct platform_device *pdev);
 #endif
 #endif
-- 
2.13.6

Re: [PATCH 3/4] rculist: add list_for_each_entry_from_rcu()

[Josh Triplett]

On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote:
> list_for_each_entry_from_rcu() is an RCU version of
> list_for_each_entry_from().  It walks a linked list under rcu
> protection, from a given start point.
> 
> It is similar to list_for_each_entry_continue_rcu() but starts *at*
> the given position rather than *after* it.
> 
> Naturally, the start point must be known to be in the list.

I'd suggest giving an explicit advisory comment to clarify and suggest
correct usage:

"This would typically require either that you obtained the node from a
previous walk of the list in the same RCU read-side critical section, or
that you held some sort of non-RCU reference (such as a reference count)
to keep the node alive *and* in the list."

(Feel free to wordsmith the exact wording, but something like that seems
like it would help people understand how to use this correctly, and make
it less likely that they'd use it incorrectly.)

[PATCH v2 02/10] PCI: Fix memory leak of devm_pci_alloc_host_bridge()

[Jan Kiszka]

From: Jan Kiszka 

devm_pci_release_host_bridge_dev() failed to release the resource list.

Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka 
---
 drivers/pci/probe.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..eccf204c9160 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -526,12 +526,14 @@ static void devm_pci_release_host_bridge_dev(struct 
device *dev)
 
if (bridge->release_fn)
bridge->release_fn(bridge);
+
+   pci_free_resource_list(>windows);
 }
 
 static void pci_release_host_bridge_dev(struct device *dev)
 {
devm_pci_release_host_bridge_dev(dev);
-   pci_free_host_bridge(to_pci_host_bridge(dev));
+   kfree(to_pci_host_bridge(dev));
 }
 
 struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
-- 
2.13.6

Re: [PATCH 3/4] rculist: add list_for_each_entry_from_rcu()

[Josh Triplett]

On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote:
> list_for_each_entry_from_rcu() is an RCU version of
> list_for_each_entry_from().  It walks a linked list under rcu
> protection, from a given start point.
> 
> It is similar to list_for_each_entry_continue_rcu() but starts *at*
> the given position rather than *after* it.
> 
> Naturally, the start point must be known to be in the list.

I'd suggest giving an explicit advisory comment to clarify and suggest
correct usage:

"This would typically require either that you obtained the node from a
previous walk of the list in the same RCU read-side critical section, or
that you held some sort of non-RCU reference (such as a reference count)
to keep the node alive *and* in the list."

(Feel free to wordsmith the exact wording, but something like that seems
like it would help people understand how to use this correctly, and make
it less likely that they'd use it incorrectly.)

[PATCH v2 02/10] PCI: Fix memory leak of devm_pci_alloc_host_bridge()

[Jan Kiszka]

From: Jan Kiszka 

devm_pci_release_host_bridge_dev() failed to release the resource list.

Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka 
---
 drivers/pci/probe.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..eccf204c9160 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -526,12 +526,14 @@ static void devm_pci_release_host_bridge_dev(struct 
device *dev)
 
if (bridge->release_fn)
bridge->release_fn(bridge);
+
+   pci_free_resource_list(>windows);
 }
 
 static void pci_release_host_bridge_dev(struct device *dev)
 {
devm_pci_release_host_bridge_dev(dev);
-   pci_free_host_bridge(to_pci_host_bridge(dev));
+   kfree(to_pci_host_bridge(dev));
 }
 
 struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
-- 
2.13.6

[PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

[Jan Kiszka]

From: Jan Kiszka 

Straightforward for all of them, no more leaks afterwards.

CC: Jingoo Han 
CC: Joao Pinto 
CC: Lorenzo Pieralisi 
Signed-off-by: Jan Kiszka 
Acked-by: Jingoo Han 
---
 drivers/pci/dwc/pcie-designware-host.c | 2 +-
 drivers/pci/host/pci-aardvark.c| 5 ++---
 drivers/pci/host/pci-ftpci100.c| 4 ++--
 drivers/pci/host/pci-v3-semi.c | 3 ++-
 drivers/pci/host/pci-versatile.c   | 3 +--
 drivers/pci/host/pci-xgene.c   | 3 ++-
 drivers/pci/host/pcie-altera.c | 5 ++---
 drivers/pci/host/pcie-iproc-platform.c | 4 ++--
 drivers/pci/host/pcie-rcar.c   | 5 ++---
 drivers/pci/host/pcie-rockchip.c   | 4 ++--
 drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
 drivers/pci/host/pcie-xilinx.c | 4 ++--
 drivers/pci/of.c   | 4 ++--
 13 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..a8f6ab54b4c0 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
>windows, >io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..1e048dd806dc 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ static int advk_pcie_parse_request_of_pci_ranges(struct 
advk_pcie *pcie)
 {
int err, res_valid = 0;
struct device *dev = >pdev->dev;
-   struct device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
 
INIT_LIST_HEAD(>resources);
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
-  );
+   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   >resources, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..87748eaeaaed 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
 
-   ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
-  , _base);
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   , _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..167bf6f6b378 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , _base);
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+   _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ff2cd12b3978 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct 
device *dev,
 struct list_head *res)
 {
int err, mem = 1, res_valid = 0;
-   struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, );
+   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..7b3ed6e34b6c 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, , );
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+   );
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pcie-altera.c 

[PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

[Jan Kiszka]

From: Jan Kiszka 

Straightforward for all of them, no more leaks afterwards.

CC: Jingoo Han 
CC: Joao Pinto 
CC: Lorenzo Pieralisi 
Signed-off-by: Jan Kiszka 
Acked-by: Jingoo Han 
---
 drivers/pci/dwc/pcie-designware-host.c | 2 +-
 drivers/pci/host/pci-aardvark.c| 5 ++---
 drivers/pci/host/pci-ftpci100.c| 4 ++--
 drivers/pci/host/pci-v3-semi.c | 3 ++-
 drivers/pci/host/pci-versatile.c   | 3 +--
 drivers/pci/host/pci-xgene.c   | 3 ++-
 drivers/pci/host/pcie-altera.c | 5 ++---
 drivers/pci/host/pcie-iproc-platform.c | 4 ++--
 drivers/pci/host/pcie-rcar.c   | 5 ++---
 drivers/pci/host/pcie-rockchip.c   | 4 ++--
 drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
 drivers/pci/host/pcie-xilinx.c | 4 ++--
 drivers/pci/of.c   | 4 ++--
 13 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..a8f6ab54b4c0 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
>windows, >io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..1e048dd806dc 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ static int advk_pcie_parse_request_of_pci_ranges(struct 
advk_pcie *pcie)
 {
int err, res_valid = 0;
struct device *dev = >pdev->dev;
-   struct device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
 
INIT_LIST_HEAD(>resources);
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
-  );
+   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   >resources, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..87748eaeaaed 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
 
-   ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
-  , _base);
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+   , _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..167bf6f6b378 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
 
-   ret = of_pci_get_host_bridge_resources(np, 0, 0xff, , _base);
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+   _base);
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ff2cd12b3978 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct 
device *dev,
 struct list_head *res)
 {
int err, mem = 1, res_valid = 0;
-   struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
 
-   err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, );
+   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, );
if (err)
return err;
 
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..7b3ed6e34b6c 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, , );
+   ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, ,
+   );
if (ret)
return ret;
 
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index a6af62e0256d..49410c7ba0cc 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -488,11 

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[Lee Jones]

On Fri, 27 Apr 2018, John Garry wrote:
> On 26/04/2018 15:23, John Garry wrote:
> > On 26/04/2018 15:08, Mika Westerberg wrote:
> > > On Thu, Apr 26, 2018 at 02:49:49PM +0100, John Garry wrote:
> > > > diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> > > > index 2d4611e..b04425b 100644
> > > > --- a/drivers/bus/hisi_lpc.c
> > > > +++ b/drivers/bus/hisi_lpc.c
> > > > @@ -18,6 +18,8 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include "../tty/serial/8250/8250.h"
> > > > 
> > > >  #define DRV_NAME "hisi-lpc"
> > > > 
> > > > @@ -345,6 +347,7 @@ static void hisi_lpc_comm_outs(void *hostdata,
> > > > unsigned
> > > > long pio,
> > > >  #define MFD_CHILD_NAME_LEN (ACPI_ID_LEN +
> > > > sizeof(MFD_CHILD_NAME_PREFIX) -
> > > > 1)
> > > > 
> > > >  struct hisi_lpc_mfd_cell {
> > > > +struct plat_serial8250_port serial8250_port;
> > > >  struct mfd_cell_acpi_match acpi_match;
> > > >  char name[MFD_CHILD_NAME_LEN];
> > > >  char pnpid[ACPI_ID_LEN];
> > > > @@ -513,10 +516,31 @@ static int hisi_lpc_acpi_probe(struct device
> > > > *hostdev)
> > > >  dev_warn(>dev, "set resource fail (%d)\n", ret);
> > > >  return ret;
> > > >  }
> > > > +if (!strcmp(acpi_device_hid(child), "HISI1031")) {
> > > 
> > 
> > Hi Mika,
> > 
> > > Hmm, there is a way in struct mfd_cell to match child devices using _HID
> > > so is there something preventing you from using that?
> > 
> > Not that I know about. Can you describe this method? I guess I also
> > don't need to set the mfd_cell pnpid either for this special case device.
> > 
> 
> So we using the mfd_cell to match child devices using _HID. At a glance, I
> don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
> 
> Anyway we don't use static tables as we need to update the resources of the
> cell dynamically. However I do look at a driver like intel_quark_i2c_gpio.c,
> and this dynamically modifies the value of global mfd_cell array here:
> https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
> 
> I know the cell array is only used at probe time, but this did not look to
> be good standard practice to me.

Lots of drivers do this to supply dynamic data.  If there is no other
sane way of providing such data, it's fine to do.  Although each
situation should be dealt with on a case-by-case basis.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices

[Lee Jones]

On Fri, 27 Apr 2018, John Garry wrote:
> On 26/04/2018 15:23, John Garry wrote:
> > On 26/04/2018 15:08, Mika Westerberg wrote:
> > > On Thu, Apr 26, 2018 at 02:49:49PM +0100, John Garry wrote:
> > > > diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> > > > index 2d4611e..b04425b 100644
> > > > --- a/drivers/bus/hisi_lpc.c
> > > > +++ b/drivers/bus/hisi_lpc.c
> > > > @@ -18,6 +18,8 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include "../tty/serial/8250/8250.h"
> > > > 
> > > >  #define DRV_NAME "hisi-lpc"
> > > > 
> > > > @@ -345,6 +347,7 @@ static void hisi_lpc_comm_outs(void *hostdata,
> > > > unsigned
> > > > long pio,
> > > >  #define MFD_CHILD_NAME_LEN (ACPI_ID_LEN +
> > > > sizeof(MFD_CHILD_NAME_PREFIX) -
> > > > 1)
> > > > 
> > > >  struct hisi_lpc_mfd_cell {
> > > > +struct plat_serial8250_port serial8250_port;
> > > >  struct mfd_cell_acpi_match acpi_match;
> > > >  char name[MFD_CHILD_NAME_LEN];
> > > >  char pnpid[ACPI_ID_LEN];
> > > > @@ -513,10 +516,31 @@ static int hisi_lpc_acpi_probe(struct device
> > > > *hostdev)
> > > >  dev_warn(>dev, "set resource fail (%d)\n", ret);
> > > >  return ret;
> > > >  }
> > > > +if (!strcmp(acpi_device_hid(child), "HISI1031")) {
> > > 
> > 
> > Hi Mika,
> > 
> > > Hmm, there is a way in struct mfd_cell to match child devices using _HID
> > > so is there something preventing you from using that?
> > 
> > Not that I know about. Can you describe this method? I guess I also
> > don't need to set the mfd_cell pnpid either for this special case device.
> > 
> 
> So we using the mfd_cell to match child devices using _HID. At a glance, I
> don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
> 
> Anyway we don't use static tables as we need to update the resources of the
> cell dynamically. However I do look at a driver like intel_quark_i2c_gpio.c,
> and this dynamically modifies the value of global mfd_cell array here:
> https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
> 
> I know the cell array is only used at probe time, but this did not look to
> be good standard practice to me.

Lots of drivers do this to supply dynamic data.  If there is no other
sane way of providing such data, it's fine to do.  Although each
situation should be dealt with on a case-by-case basis.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

linux-next: Tree for Apr 30

[Stephen Rothwell]

Hi all,

Changes since 20180426:

The qcom tree lost its build failure.

The clk-samsung tree lost its build failure.

The net-next tree gained a conflict against the net tree.

The ipsec-next tree gained a conflict against the net-next tree.

The rpmsg tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3135
 3014 files changed, 121018 insertions(+), 56873 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (6da6c0db5316 Linux v4.17-rc3)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (6d08b06e67cd Linux 4.17-rc2)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting 
atomic_ll_sc.o)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec 
related build break)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1d39fd1bedbd Merge branch 'sfc-more-ARFS-fixes')
Merging bpf/master (815425567dea bpf: fix uninitialized variable in bpf tools)
Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.)
Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip 
synchronize_rcu if transaction log is empty)
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (af8a41cccf8f rtlwifi: cleanup 8723be ant_sel 
definition)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (dc5640f294e4 IB/core: Fix deleting default GIDs when 
changing mac adddress)
Merging sound-current/for-linus (52759c096351 ALSA: dice: fix kernel NULL 
pointer dereference due to invalid calculation for array index)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (b93815d0f37e firmware: some 
documentation fixes)
Merging tty.current/tty-linus (bcdd0ca8cb87 tty: Use __GFP_NOFAIL for 
tty_ldisc_get())
Merging usb.current/usb-linus (573a09487375 Merge tag 'usb-serial-4.17-rc3' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for 
larger configuration descriptors)
Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use 
jtag quirk for Arrow USB Blaster)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (b00e2fd10429 staging: wilc1000: fix NULL 
pointer exception in host_int_parse_assoc_resp_info())
Merging char-misc.current/char-misc-linus 

linux-next: Tree for Apr 30

[Stephen Rothwell]

Hi all,

Changes since 20180426:

The qcom tree lost its build failure.

The clk-samsung tree lost its build failure.

The net-next tree gained a conflict against the net tree.

The ipsec-next tree gained a conflict against the net-next tree.

The rpmsg tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3135
 3014 files changed, 121018 insertions(+), 56873 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (6da6c0db5316 Linux v4.17-rc3)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (6d08b06e67cd Linux 4.17-rc2)
Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4)
Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed 
and the shell $(( )) operator)
Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting 
atomic_ll_sc.o)
Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" 
comment)
Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec 
related build break)
Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1d39fd1bedbd Merge branch 'sfc-more-ARFS-fixes')
Merging bpf/master (815425567dea bpf: fix uninitialized variable in bpf tools)
Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.)
Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip 
synchronize_rcu if transaction log is empty)
Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for 
kmemleak_not_leak())
Merging wireless-drivers/master (af8a41cccf8f rtlwifi: cleanup 8723be ant_sel 
definition)
Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external 
authentication failure)
Merging rdma-fixes/for-rc (dc5640f294e4 IB/core: Fix deleting default GIDs when 
changing mac adddress)
Merging sound-current/for-linus (52759c096351 ALSA: dice: fix kernel NULL 
pointer dereference due to invalid calculation for array index)
Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to 
pcie_print_link_status() messages)
Merging driver-core.current/driver-core-linus (b93815d0f37e firmware: some 
documentation fixes)
Merging tty.current/tty-linus (bcdd0ca8cb87 tty: Use __GFP_NOFAIL for 
tty_ldisc_get())
Merging usb.current/usb-linus (573a09487375 Merge tag 'usb-serial-4.17-rc3' of 
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for 
larger configuration descriptors)
Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use 
jtag quirk for Arrow USB Blaster)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1)
Merging staging.current/staging-linus (b00e2fd10429 staging: wilc1000: fix NULL 
pointer exception in host_int_parse_assoc_resp_info())
Merging char-misc.current/char-misc-linus 

Re: [RFD] x86: The future of MPX

[Dave Hansen]

On 04/28/2018 09:44 AM, Linus Torvalds wrote:
> On Sat, Apr 28, 2018 at 9:36 AM Linus Torvalds <
> torva...@linux-foundation.org> wrote:
> 
>> They need to be run as root.
> Side note: don't get me wrong. If the MPX stuff isn't supported by gcc,
> then there is little point in us supporting it in the kernel either.

The loss of the GCC support is definitely a bummer.

There are no objections from me against removing it from future kernels.
 I think it will be pretty straightforward, just leaving the prctl()
numbers as placeholders.

Re: [RFD] x86: The future of MPX

[Dave Hansen]

On 04/28/2018 09:44 AM, Linus Torvalds wrote:
> On Sat, Apr 28, 2018 at 9:36 AM Linus Torvalds <
> torva...@linux-foundation.org> wrote:
> 
>> They need to be run as root.
> Side note: don't get me wrong. If the MPX stuff isn't supported by gcc,
> then there is little point in us supporting it in the kernel either.

The loss of the GCC support is definitely a bummer.

There are no objections from me against removing it from future kernels.
 I think it will be pretty straightforward, just leaving the prctl()
numbers as placeholders.

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

On Sun, Apr 29, 2018 at 08:11:07PM -0400, Theodore Y. Ts'o wrote:
>
> What your patch does is assume that there is a full bit of uncertainty
> that can be obtained from the information gathered from each
> interrupt.  I *might* be willing to assume that to be valid on x86
> systems that have a high resolution cycle counter.  But on ARM
> platforms, especially during system bootup when the user isn't typing
> anything and SSD's and flash storage tend to have very predictable
> timing patterns?  Not a bet I'd be willing to take.  Even with a cycle
> counter, there's a reason why we assumed that we need to mix in timing
> results from 64 interrupts or one second's worth before we would give
> a single bit's worth of entropy credit.
> 
>   - Ted

What about abusing high-resolution timers to get entropy? Since hrtimers can't
make guarantees down to the nanosecond, there's always a skew between the
requested expiry time and the actual expiry time.

Please see the attached patch and let me know just how horrible it is.

Sultan

>From b0d21c38558c661531d4cb46816fbb36b874a169 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf 
Date: Sun, 29 Apr 2018 21:28:08 -0700
Subject: [PATCH] random: use high-res timers to generate entropy until crng
 init is done

---
 drivers/char/random.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index d9e38523b383..af2d60bbcec3 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -286,6 +286,7 @@
 #define OUTPUT_POOL_WORDS  (1 << (OUTPUT_POOL_SHIFT-5))
 #define SEC_XFER_SIZE  512
 #define EXTRACT_SIZE   10
+#define ENTROPY_GEN_INTVL_NS   (1 * NSEC_PER_MSEC)
 
 
 #define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
@@ -408,6 +409,8 @@ static struct fasync_struct *fasync;
 static DEFINE_SPINLOCK(random_ready_list_lock);
 static LIST_HEAD(random_ready_list);
 
+static struct hrtimer entropy_gen_hrtimer;
+
 struct crng_state {
__u32   state[16];
unsigned long   init_time;
@@ -2287,3 +2290,47 @@ void add_hwgenerator_randomness(const char *buffer, 
size_t count,
credit_entropy_bits(poolp, entropy);
 }
 EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+
+/*
+ * Generate entropy on init using high-res timers. Although high-res timers
+ * provide nanosecond precision, they don't actually honor requests to the
+ * nanosecond. The skew between the expected time difference in nanoseconds and
+ * the actual time difference can be used as a way to generate entropy on boot
+ * for machines that lack sufficient boot-time entropy.
+ */
+static enum hrtimer_restart entropy_timer_cb(struct hrtimer *timer)
+{
+   static u64 prev_ns;
+   u64 curr_ns, delta;
+
+   if (crng_ready())
+   return HRTIMER_NORESTART;
+
+   curr_ns = ktime_get_mono_fast_ns();
+   delta = curr_ns - prev_ns;
+
+   add_interrupt_randomness(delta);
+
+   /* Use the hrtimer skew to make the next interval more unpredictable */
+   if (likely(prev_ns))
+   hrtimer_add_expires_ns(timer, delta);
+   else
+   hrtimer_add_expires_ns(timer, ENTROPY_GEN_INTVL_NS);
+
+   prev_ns = curr_ns;
+   return HRTIMER_RESTART;
+}
+
+static int entropy_gen_hrtimer_init(void)
+{
+   if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS))
+   return 0;
+
+   hrtimer_init(_gen_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+
+   entropy_gen_hrtimer.function = entropy_timer_cb;
+   hrtimer_start(_gen_hrtimer, ns_to_ktime(ENTROPY_GEN_INTVL_NS),
+   HRTIMER_MODE_REL);
+   return 0;
+}
+core_initcall(entropy_gen_hrtimer_init);
-- 
2.14.1

Re: Linux messages full of `random: get_random_u32 called from`

[Sultan Alsawaf]

On Sun, Apr 29, 2018 at 08:11:07PM -0400, Theodore Y. Ts'o wrote:
>
> What your patch does is assume that there is a full bit of uncertainty
> that can be obtained from the information gathered from each
> interrupt.  I *might* be willing to assume that to be valid on x86
> systems that have a high resolution cycle counter.  But on ARM
> platforms, especially during system bootup when the user isn't typing
> anything and SSD's and flash storage tend to have very predictable
> timing patterns?  Not a bet I'd be willing to take.  Even with a cycle
> counter, there's a reason why we assumed that we need to mix in timing
> results from 64 interrupts or one second's worth before we would give
> a single bit's worth of entropy credit.
> 
>   - Ted

What about abusing high-resolution timers to get entropy? Since hrtimers can't
make guarantees down to the nanosecond, there's always a skew between the
requested expiry time and the actual expiry time.

Please see the attached patch and let me know just how horrible it is.

Sultan

>From b0d21c38558c661531d4cb46816fbb36b874a169 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf 
Date: Sun, 29 Apr 2018 21:28:08 -0700
Subject: [PATCH] random: use high-res timers to generate entropy until crng
 init is done

---
 drivers/char/random.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index d9e38523b383..af2d60bbcec3 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -286,6 +286,7 @@
 #define OUTPUT_POOL_WORDS  (1 << (OUTPUT_POOL_SHIFT-5))
 #define SEC_XFER_SIZE  512
 #define EXTRACT_SIZE   10
+#define ENTROPY_GEN_INTVL_NS   (1 * NSEC_PER_MSEC)
 
 
 #define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
@@ -408,6 +409,8 @@ static struct fasync_struct *fasync;
 static DEFINE_SPINLOCK(random_ready_list_lock);
 static LIST_HEAD(random_ready_list);
 
+static struct hrtimer entropy_gen_hrtimer;
+
 struct crng_state {
__u32   state[16];
unsigned long   init_time;
@@ -2287,3 +2290,47 @@ void add_hwgenerator_randomness(const char *buffer, 
size_t count,
credit_entropy_bits(poolp, entropy);
 }
 EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+
+/*
+ * Generate entropy on init using high-res timers. Although high-res timers
+ * provide nanosecond precision, they don't actually honor requests to the
+ * nanosecond. The skew between the expected time difference in nanoseconds and
+ * the actual time difference can be used as a way to generate entropy on boot
+ * for machines that lack sufficient boot-time entropy.
+ */
+static enum hrtimer_restart entropy_timer_cb(struct hrtimer *timer)
+{
+   static u64 prev_ns;
+   u64 curr_ns, delta;
+
+   if (crng_ready())
+   return HRTIMER_NORESTART;
+
+   curr_ns = ktime_get_mono_fast_ns();
+   delta = curr_ns - prev_ns;
+
+   add_interrupt_randomness(delta);
+
+   /* Use the hrtimer skew to make the next interval more unpredictable */
+   if (likely(prev_ns))
+   hrtimer_add_expires_ns(timer, delta);
+   else
+   hrtimer_add_expires_ns(timer, ENTROPY_GEN_INTVL_NS);
+
+   prev_ns = curr_ns;
+   return HRTIMER_RESTART;
+}
+
+static int entropy_gen_hrtimer_init(void)
+{
+   if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS))
+   return 0;
+
+   hrtimer_init(_gen_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+
+   entropy_gen_hrtimer.function = entropy_timer_cb;
+   hrtimer_start(_gen_hrtimer, ns_to_ktime(ENTROPY_GEN_INTVL_NS),
+   HRTIMER_MODE_REL);
+   return 0;
+}
+core_initcall(entropy_gen_hrtimer_init);
-- 
2.14.1

[PATCH 4/4] NFS: Avoid quadratic search when freeing delegations.

[NeilBrown]

There are three places that walk all delegation for an nfs_client and
restart whenever they find something interesting - potentially
resulting in a quadratic search:  If there are 10,000 uninteresting
delegations followed by 10,000 interesting one, then the code
skips over 100,000,000 delegations, which can take a noticeable amount
of time.

Of these nfs_delegation_reap_unclaimed() and
nfs_reap_expired_delegations() are only called during unusual events:
a server reboots or reports expired delegations, probably due to a
network partition.  Optimizing these is not particularly important.

The third, nfs_client_return_marked_delegations(), is called
periodically via nfs_expire_unreferenced_delegations().  It could
cause periodic problems on a busy server.

New delegations are added to the end of the list, so if there are
10,000 open files with delegations, and 10,000 more recently opened files
that received delegations but are now closed, then
nfs_client_return_marked_delegations() can take seconds to skip over
the 10,000 open files 10,000 times.  That is a waste of time.

The avoid this waste a place-holder (an inode) is kept when locks are
dropped, so that the place can usually be found again after taking
rcu_readlock().  This place holder ensure that we find the right
starting point in the list of nfs_servers, and makes is probable that
we find the right starting point in the list of delegations.
We might need to occasionally restart at the head of that list.

It might be possible that the place_holder inode could lose its
delegation separately, and then get a new one using the same (freed
and then reallocated) 'struct nfs_delegation'.  Were this to happen,
the new delegation would be at the end of the list and we would miss
returning some other delegations.  This would have the effect of
unnecessarily delaying the return of some unused delegations until the
next time this function is called - typically 90 seconds later.  As
this is not a correctness issue and is vanishingly unlikely to happen,
it does not seem worth addressing.

Signed-off-by: NeilBrown 
---
 fs/nfs/delegation.c |   57 +++
 1 file changed, 53 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 76ab1374f589..cfec852c8bad 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -483,28 +483,73 @@ static bool nfs_delegation_need_return(struct 
nfs_delegation *delegation)
 int nfs_client_return_marked_delegations(struct nfs_client *clp)
 {
struct nfs_delegation *delegation;
+   struct nfs_delegation *prev;
struct nfs_server *server;
struct inode *inode;
+   struct inode *place_holder = NULL;
+   struct nfs_delegation *place_holder_deleg = NULL;
int err = 0;
 
 restart:
+   /*
+* To avoid quadratic looping we hold a reference
+* to an inode place_holder.  Each time we restart, we
+* list nfs_servers from the server of that inode, and
+* delegation in the server from the delegations of that
+* inode.
+* prev is an RCU-protected pointer to a delegation which
+* wasn't marked for return and might be a good choice for
+* the next place_holder.
+*/
rcu_read_lock();
-   list_for_each_entry_rcu(server, >cl_superblocks, client_link) {
-   list_for_each_entry_rcu(delegation, >delegations,
-   super_list) {
-   if (!nfs_delegation_need_return(delegation))
+   prev = NULL;
+   if (place_holder)
+   server = NFS_SERVER(place_holder);
+   else
+   server = list_entry_rcu(clp->cl_superblocks.next,
+   struct nfs_server, client_link);
+   list_for_each_entry_from_rcu(server, >cl_superblocks, client_link) 
{
+   delegation = NULL;
+   if (place_holder && server == NFS_SERVER(place_holder))
+   delegation = 
rcu_dereference(NFS_I(place_holder)->delegation);
+   if (!delegation || delegation != place_holder_deleg)
+   delegation = list_entry_rcu(server->delegations.next,
+   struct nfs_delegation, 
super_list);
+   list_for_each_entry_from_rcu(delegation, >delegations, 
super_list) {
+   struct inode *to_put = NULL;
+
+   if (!nfs_delegation_need_return(delegation)) {
+   prev = delegation;
continue;
+   }
if (!nfs_sb_active(server->super))
break;
+
+   if (prev) {
+   struct inode *tmp;
+
+   tmp = nfs_delegation_grab_inode(prev);
+   if (tmp) {
+   

[PATCH 4/4] NFS: Avoid quadratic search when freeing delegations.

[NeilBrown]

There are three places that walk all delegation for an nfs_client and
restart whenever they find something interesting - potentially
resulting in a quadratic search:  If there are 10,000 uninteresting
delegations followed by 10,000 interesting one, then the code
skips over 100,000,000 delegations, which can take a noticeable amount
of time.

Of these nfs_delegation_reap_unclaimed() and
nfs_reap_expired_delegations() are only called during unusual events:
a server reboots or reports expired delegations, probably due to a
network partition.  Optimizing these is not particularly important.

The third, nfs_client_return_marked_delegations(), is called
periodically via nfs_expire_unreferenced_delegations().  It could
cause periodic problems on a busy server.

New delegations are added to the end of the list, so if there are
10,000 open files with delegations, and 10,000 more recently opened files
that received delegations but are now closed, then
nfs_client_return_marked_delegations() can take seconds to skip over
the 10,000 open files 10,000 times.  That is a waste of time.

The avoid this waste a place-holder (an inode) is kept when locks are
dropped, so that the place can usually be found again after taking
rcu_readlock().  This place holder ensure that we find the right
starting point in the list of nfs_servers, and makes is probable that
we find the right starting point in the list of delegations.
We might need to occasionally restart at the head of that list.

It might be possible that the place_holder inode could lose its
delegation separately, and then get a new one using the same (freed
and then reallocated) 'struct nfs_delegation'.  Were this to happen,
the new delegation would be at the end of the list and we would miss
returning some other delegations.  This would have the effect of
unnecessarily delaying the return of some unused delegations until the
next time this function is called - typically 90 seconds later.  As
this is not a correctness issue and is vanishingly unlikely to happen,
it does not seem worth addressing.

Signed-off-by: NeilBrown 
---
 fs/nfs/delegation.c |   57 +++
 1 file changed, 53 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 76ab1374f589..cfec852c8bad 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -483,28 +483,73 @@ static bool nfs_delegation_need_return(struct 
nfs_delegation *delegation)
 int nfs_client_return_marked_delegations(struct nfs_client *clp)
 {
struct nfs_delegation *delegation;
+   struct nfs_delegation *prev;
struct nfs_server *server;
struct inode *inode;
+   struct inode *place_holder = NULL;
+   struct nfs_delegation *place_holder_deleg = NULL;
int err = 0;
 
 restart:
+   /*
+* To avoid quadratic looping we hold a reference
+* to an inode place_holder.  Each time we restart, we
+* list nfs_servers from the server of that inode, and
+* delegation in the server from the delegations of that
+* inode.
+* prev is an RCU-protected pointer to a delegation which
+* wasn't marked for return and might be a good choice for
+* the next place_holder.
+*/
rcu_read_lock();
-   list_for_each_entry_rcu(server, >cl_superblocks, client_link) {
-   list_for_each_entry_rcu(delegation, >delegations,
-   super_list) {
-   if (!nfs_delegation_need_return(delegation))
+   prev = NULL;
+   if (place_holder)
+   server = NFS_SERVER(place_holder);
+   else
+   server = list_entry_rcu(clp->cl_superblocks.next,
+   struct nfs_server, client_link);
+   list_for_each_entry_from_rcu(server, >cl_superblocks, client_link) 
{
+   delegation = NULL;
+   if (place_holder && server == NFS_SERVER(place_holder))
+   delegation = 
rcu_dereference(NFS_I(place_holder)->delegation);
+   if (!delegation || delegation != place_holder_deleg)
+   delegation = list_entry_rcu(server->delegations.next,
+   struct nfs_delegation, 
super_list);
+   list_for_each_entry_from_rcu(delegation, >delegations, 
super_list) {
+   struct inode *to_put = NULL;
+
+   if (!nfs_delegation_need_return(delegation)) {
+   prev = delegation;
continue;
+   }
if (!nfs_sb_active(server->super))
break;
+
+   if (prev) {
+   struct inode *tmp;
+
+   tmp = nfs_delegation_grab_inode(prev);
+   if (tmp) {
+   

[PATCH 3/4] rculist: add list_for_each_entry_from_rcu()

[NeilBrown]

list_for_each_entry_from_rcu() is an RCU version of
list_for_each_entry_from().  It walks a linked list under rcu
protection, from a given start point.

It is similar to list_for_each_entry_continue_rcu() but starts *at*
the given position rather than *after* it.

Naturally, the start point must be known to be in the list.

Signed-off-by: NeilBrown 
---
 include/linux/rculist.h |   13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 127f534fec94..36df6ccbc874 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -403,6 +403,19 @@ static inline void list_splice_tail_init_rcu(struct 
list_head *list,
 >member != (head);\
 pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
 
+/**
+ * list_for_each_entry_from_rcu - iterate over a list from current point
+ * @pos:   the type * to use as a loop cursor.
+ * @head:  the head for your list.
+ * @member:the name of the list_node within the struct.
+ *
+ * Iterate over the tail of a list starting from a given position,
+ * which must have been in the list when the RCU read lock was taken.
+ */
+#define list_for_each_entry_from_rcu(pos, head, member)
\
+   for (; &(pos)->member != (head);
\
+   pos = list_entry_rcu(pos->member.next, typeof(*(pos)), member))
+
 /**
  * hlist_del_rcu - deletes entry from hash list without re-initialization
  * @n: the element to delete from the hash list.

[PATCH 3/4] rculist: add list_for_each_entry_from_rcu()

[NeilBrown]

list_for_each_entry_from_rcu() is an RCU version of
list_for_each_entry_from().  It walks a linked list under rcu
protection, from a given start point.

It is similar to list_for_each_entry_continue_rcu() but starts *at*
the given position rather than *after* it.

Naturally, the start point must be known to be in the list.

Signed-off-by: NeilBrown 
---
 include/linux/rculist.h |   13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 127f534fec94..36df6ccbc874 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -403,6 +403,19 @@ static inline void list_splice_tail_init_rcu(struct 
list_head *list,
 >member != (head);\
 pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
 
+/**
+ * list_for_each_entry_from_rcu - iterate over a list from current point
+ * @pos:   the type * to use as a loop cursor.
+ * @head:  the head for your list.
+ * @member:the name of the list_node within the struct.
+ *
+ * Iterate over the tail of a list starting from a given position,
+ * which must have been in the list when the RCU read lock was taken.
+ */
+#define list_for_each_entry_from_rcu(pos, head, member)
\
+   for (; &(pos)->member != (head);
\
+   pos = list_entry_rcu(pos->member.next, typeof(*(pos)), member))
+
 /**
  * hlist_del_rcu - deletes entry from hash list without re-initialization
  * @n: the element to delete from the hash list.

[PATCH 2/4] NFS: use cond_resched() when restarting walk of delegation list.

[NeilBrown]

In three places we walk the list of delegations for an nfs_client
until an interesting one is found, then we act of that delegation
and restart the walk.

New delegations are added to the end of a list and the interesting
delegations are usually old, so in many case we won't repeat
a long walk over and over again, but it is possible - particularly if
the first server in the list has a large number of uninteresting
delegations.

In each cache the work done on interesting delegations will often
complete without sleeping, so this could loop many times without
giving up the CPU.

So add a cond_resched() at an appropriate point to avoid hogging the
CPU for too long.

Signed-off-by: NeilBrown 
---
 fs/nfs/delegation.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index af32365894c8..76ab1374f589 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -508,6 +508,7 @@ int nfs_client_return_marked_delegations(struct nfs_client 
*clp)
err = nfs_end_delegation_return(inode, delegation, 0);
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
if (!err)
goto restart;
set_bit(NFS4CLNT_DELEGRETURN, >cl_state);
@@ -904,6 +905,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp)
}
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
goto restart;
}
}
@@ -1020,6 +1022,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp)
}
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
goto restart;
}
}

[PATCH 1/4] NFS: slight optimization for walking list for delegations

[NeilBrown]

There are 3 places where we walk the list of delegations
for an nfs_client.
In each case there are two nested loops, one for nfs_servers
and one for nfs_delegations.

When we find an interesting delegation we try to get an active
reference to the server.  If that fails, it is pointless to
continue to look at the other delegation for the server as
we will never be able to get an active reference.
So instead of continuing in the inner loop, break out
and continue in the outer loop.
---
 fs/nfs/delegation.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 1819d0d0ba4b..af32365894c8 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -495,7 +495,7 @@ int nfs_client_return_marked_delegations(struct nfs_client 
*clp)
if (!nfs_delegation_need_return(delegation))
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -887,7 +887,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp)
>flags) == 0)
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -995,7 +995,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp)
>flags) == 0)
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();

[PATCH 0/4 V2] Avoid quadratic search when freeing delegations

[NeilBrown]

Following review from Mathieu (thanks) I've made some revisions
and split this into four patches.  The RCU change is now in patch 3
by itself.
I've also revised the description in the main (final) patch quite
a bit.

Thanks,
NeilBrown


---

NeilBrown (4):
  NFS: slight optimization for walking list for delegations
  NFS: use cond_resched() when restarting walk of delegation list.
  rculist: add list_for_each_entry_from_rcu()
  NFS: Avoid quadratic search when freeing delegations.


 fs/nfs/delegation.c |   66 ++-
 include/linux/rculist.h |   13 +
 2 files changed, 72 insertions(+), 7 deletions(-)

--
Signature

[PATCH 2/4] NFS: use cond_resched() when restarting walk of delegation list.

[NeilBrown]

In three places we walk the list of delegations for an nfs_client
until an interesting one is found, then we act of that delegation
and restart the walk.

New delegations are added to the end of a list and the interesting
delegations are usually old, so in many case we won't repeat
a long walk over and over again, but it is possible - particularly if
the first server in the list has a large number of uninteresting
delegations.

In each cache the work done on interesting delegations will often
complete without sleeping, so this could loop many times without
giving up the CPU.

So add a cond_resched() at an appropriate point to avoid hogging the
CPU for too long.

Signed-off-by: NeilBrown 
---
 fs/nfs/delegation.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index af32365894c8..76ab1374f589 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -508,6 +508,7 @@ int nfs_client_return_marked_delegations(struct nfs_client 
*clp)
err = nfs_end_delegation_return(inode, delegation, 0);
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
if (!err)
goto restart;
set_bit(NFS4CLNT_DELEGRETURN, >cl_state);
@@ -904,6 +905,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp)
}
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
goto restart;
}
}
@@ -1020,6 +1022,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp)
}
iput(inode);
nfs_sb_deactive(server->super);
+   cond_resched();
goto restart;
}
}

[PATCH 1/4] NFS: slight optimization for walking list for delegations

[NeilBrown]

There are 3 places where we walk the list of delegations
for an nfs_client.
In each case there are two nested loops, one for nfs_servers
and one for nfs_delegations.

When we find an interesting delegation we try to get an active
reference to the server.  If that fails, it is pointless to
continue to look at the other delegation for the server as
we will never be able to get an active reference.
So instead of continuing in the inner loop, break out
and continue in the outer loop.
---
 fs/nfs/delegation.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 1819d0d0ba4b..af32365894c8 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -495,7 +495,7 @@ int nfs_client_return_marked_delegations(struct nfs_client 
*clp)
if (!nfs_delegation_need_return(delegation))
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -887,7 +887,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp)
>flags) == 0)
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -995,7 +995,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp)
>flags) == 0)
continue;
if (!nfs_sb_active(server->super))
-   continue;
+   break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();

[PATCH 0/4 V2] Avoid quadratic search when freeing delegations

[NeilBrown]

Following review from Mathieu (thanks) I've made some revisions
and split this into four patches.  The RCU change is now in patch 3
by itself.
I've also revised the description in the main (final) patch quite
a bit.

Thanks,
NeilBrown


---

NeilBrown (4):
  NFS: slight optimization for walking list for delegations
  NFS: use cond_resched() when restarting walk of delegation list.
  rculist: add list_for_each_entry_from_rcu()
  NFS: Avoid quadratic search when freeing delegations.


 fs/nfs/delegation.c |   66 ++-
 include/linux/rculist.h |   13 +
 2 files changed, 72 insertions(+), 7 deletions(-)

--
Signature

Re: [PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[Chandan Vn]

Please ignore this mail. I missed replying to the thread.
I have resubmitted over the proper thread.

On Mon, 30 Apr 2018, 09:44 CHANDAN VN,  wrote:
>
> INITRD reserved area entry is not removed from memblock
> even though initrd reserved area is freed. After freeing
> the memory it is released from memblock. The same can be
> checked from /sys/kernel/debug/memblock/reserved.
>
> The patch makes sure that the initrd entry is removed from
> memblock when keepinitrd is not enabled.
>
> The patch only affects accounting and debugging. This does not
> fix any memory leak.
>
> Signed-off-by: CHANDAN VN 
> ---
>  arch/arm64/mm/init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9f3c47a..1b18b47 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -646,8 +646,10 @@ void free_initmem(void)
>
>  void __init free_initrd_mem(unsigned long start, unsigned long end)
>  {
> -   if (!keep_initrd)
> +   if (!keep_initrd) {
> free_reserved_area((void *)start, (void *)end, 0, "initrd");
> +   memblock_free(__virt_to_phys(start), end - start);
> +   }
>  }
>
>  static int __init keepinitrd_setup(char *__unused)
> --
> 1.9.1
>

Re: [PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[Chandan Vn]

Please ignore this mail. I missed replying to the thread.
I have resubmitted over the proper thread.

On Mon, 30 Apr 2018, 09:44 CHANDAN VN,  wrote:
>
> INITRD reserved area entry is not removed from memblock
> even though initrd reserved area is freed. After freeing
> the memory it is released from memblock. The same can be
> checked from /sys/kernel/debug/memblock/reserved.
>
> The patch makes sure that the initrd entry is removed from
> memblock when keepinitrd is not enabled.
>
> The patch only affects accounting and debugging. This does not
> fix any memory leak.
>
> Signed-off-by: CHANDAN VN 
> ---
>  arch/arm64/mm/init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9f3c47a..1b18b47 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -646,8 +646,10 @@ void free_initmem(void)
>
>  void __init free_initrd_mem(unsigned long start, unsigned long end)
>  {
> -   if (!keep_initrd)
> +   if (!keep_initrd) {
> free_reserved_area((void *)start, (void *)end, 0, "initrd");
> +   memblock_free(__virt_to_phys(start), end - start);
> +   }
>  }
>
>  static int __init keepinitrd_setup(char *__unused)
> --
> 1.9.1
>

[PATCH] iio: humidity: hts221: Fix sensor reads after resume

[Shrirang Bagul]

CTRL1 register (ODR & BDU settings) gets reset after system comes back
from suspend, causing subsequent reads from the sensor to fail.

This patch restores the CTRL1 register after resume.

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git iio-fixes-for-4.14b

Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
address this issue.

Cc: sta...@vger.kernel.org
Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul 
---
 drivers/iio/humidity/hts221_core.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 32524a8dc66f..fed2da64fa3b 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
struct hts221_hw *hw = iio_priv(iio_dev);
int err = 0;
 
-   if (hw->enabled)
-   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
-HTS221_ENABLE_MASK, true);
+   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK, 1);
+   if (err < 0)
+   goto fail_err;
 
-   return err;
+   err = hts221_update_odr(hw, hw->odr);
+
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.14.1

[PATCH] iio: humidity: hts221: Fix sensor reads after resume

[Shrirang Bagul]

CTRL1 register (ODR & BDU settings) gets reset after system comes back
from suspend, causing subsequent reads from the sensor to fail.

This patch restores the CTRL1 register after resume.

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git iio-fixes-for-4.14b

Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
address this issue.

Cc: sta...@vger.kernel.org
Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul 
---
 drivers/iio/humidity/hts221_core.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/humidity/hts221_core.c 
b/drivers/iio/humidity/hts221_core.c
index 32524a8dc66f..fed2da64fa3b 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device 
*dev)
struct hts221_hw *hw = iio_priv(iio_dev);
int err = 0;
 
-   if (hw->enabled)
-   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
-HTS221_ENABLE_MASK, true);
+   err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK, 1);
+   if (err < 0)
+   goto fail_err;
 
-   return err;
+   err = hts221_update_odr(hw, hw->odr);
+
+fail_err:
+   return err < 0 ? err : 0;
 }
 
 const struct dev_pm_ops hts221_pm_ops = {
-- 
2.14.1

[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[CHANDAN VN]

INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.

The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.

The patch only affects accounting and debugging. This does not
fix any memory leak.

Signed-off-by: CHANDAN VN 
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
 
 void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   memblock_free(__virt_to_phys(start), end - start);
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
1.9.1

[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[CHANDAN VN]

INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.

The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.

The patch only affects accounting and debugging. This does not
fix any memory leak.

Signed-off-by: CHANDAN VN 
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
 
 void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   memblock_free(__virt_to_phys(start), end - start);
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
1.9.1

[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[CHANDAN VN]

INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.

The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.

The patch only affects accounting and debugging. This does not
fix any memory leak.

Signed-off-by: CHANDAN VN 
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
 
 void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   memblock_free(__virt_to_phys(start), end - start);
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
1.9.1

[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock

[CHANDAN VN]

INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.

The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.

The patch only affects accounting and debugging. This does not
fix any memory leak.

Signed-off-by: CHANDAN VN 
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
 
 void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   memblock_free(__virt_to_phys(start), end - start);
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
1.9.1

Re: [PATCH 3/3] genalloc: selftest

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850
config: um-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

>> lib/test_genalloc.c:18:10: fatal error: linux/test_genalloc.h: No such file 
>> or directory
#include 
 ^~~
   compilation terminated.

vim +18 lib/test_genalloc.c

17  
  > 18  #include 
19  
20  

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


.config.gz
Description: application/gzip

Re: [PATCH 3/3] genalloc: selftest

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850
config: um-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

>> lib/test_genalloc.c:18:10: fatal error: linux/test_genalloc.h: No such file 
>> or directory
#include 
 ^~~
   compilation terminated.

vim +18 lib/test_genalloc.c

17  
  > 18  #include 
19  
20  

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


.config.gz
Description: application/gzip

RE: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, April 27, 2018 10:46 PM
> To: Nipun Gupta 
> Cc: robin.mur...@arm.com; will.dea...@arm.com; mark.rutl...@arm.com;
> catalin.mari...@arm.com; h...@lst.de; gre...@linuxfoundation.org;
> j...@8bytes.org; m.szyprow...@samsung.com; shawn...@kernel.org;
> frowand.l...@gmail.com; bhelg...@google.com; iommu@lists.linux-
> foundation.org; linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Laurentiu Tudor ; Leo Li
> 
> Subject: Re: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On Fri, Apr 27, 2018 at 03:57:02PM +0530, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This
> > patch moves the of_pci_map_rid to generic location, so that it
> > can be used by other busses too.
> >
> > 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
> > functional change done in the API.
> >
> > Signed-off-by: Nipun Gupta 
> > ---
> >  drivers/iommu/of_iommu.c   |   6 +--
> >  drivers/of/address.c   | 102
> +
> >  drivers/of/irq.c   |   7 ++--
> >  drivers/pci/of.c   | 101 
> > 
> >  include/linux/of_address.h |  11 +
> >  include/linux/of_pci.h |  10 -
> >  6 files changed, 120 insertions(+), 117 deletions(-)
> 
> of/address.c isn't really the best fit either, though I don't have a
> better suggestion.
> 
> I'm guessing this breaks on Sparc which doesn't build of/address.c.
> I guess move it to base.c and of.h if that is the case.

Sure, that makes sense. Thank you for the suggestion !!
I'll spin off new version with this change.

Regards,
Nipun

> 
> Rob

RE: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, April 27, 2018 10:46 PM
> To: Nipun Gupta 
> Cc: robin.mur...@arm.com; will.dea...@arm.com; mark.rutl...@arm.com;
> catalin.mari...@arm.com; h...@lst.de; gre...@linuxfoundation.org;
> j...@8bytes.org; m.szyprow...@samsung.com; shawn...@kernel.org;
> frowand.l...@gmail.com; bhelg...@google.com; iommu@lists.linux-
> foundation.org; linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux-
> p...@vger.kernel.org; Bharat Bhushan ;
> stuyo...@gmail.com; Laurentiu Tudor ; Leo Li
> 
> Subject: Re: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On Fri, Apr 27, 2018 at 03:57:02PM +0530, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This
> > patch moves the of_pci_map_rid to generic location, so that it
> > can be used by other busses too.
> >
> > 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
> > functional change done in the API.
> >
> > Signed-off-by: Nipun Gupta 
> > ---
> >  drivers/iommu/of_iommu.c   |   6 +--
> >  drivers/of/address.c   | 102
> +
> >  drivers/of/irq.c   |   7 ++--
> >  drivers/pci/of.c   | 101 
> > 
> >  include/linux/of_address.h |  11 +
> >  include/linux/of_pci.h |  10 -
> >  6 files changed, 120 insertions(+), 117 deletions(-)
> 
> of/address.c isn't really the best fit either, though I don't have a
> better suggestion.
> 
> I'm guessing this breaks on Sparc which doesn't build of/address.c.
> I guess move it to base.c and of.h if that is the case.

Sure, that makes sense. Thank you for the suggestion !!
I'll spin off new version with this change.

Regards,
Nipun

> 
> Rob

[PATCH] random: remove unused argument from add_interrupt_randomness()

[Sultan Alsawaf]

>From cdc2a03f93fdec88ad040a212605e20ab97c3e19 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf 
Date: Sun, 29 Apr 2018 20:04:35 -0700
Subject: [PATCH] random: remove unused argument from add_interrupt_randomness()

The irq_flags parameter is not used. Remove it.

Signed-off-by: Sultan Alsawaf 
---
 drivers/char/random.c  | 4 ++--
 drivers/hv/vmbus_drv.c | 2 +-
 include/linux/random.h | 2 +-
 kernel/irq/handle.c| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38729baed6ee..d9e38523b383 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -131,7 +131,7 @@
  * void add_device_randomness(const void *buf, unsigned int size);
  * void add_input_randomness(unsigned int type, unsigned int code,
  *unsigned int value);
- * void add_interrupt_randomness(int irq, int irq_flags);
+ * void add_interrupt_randomness(int irq);
  * void add_disk_randomness(struct gendisk *disk);
  *
  * add_device_randomness() is for adding data to the random pool that
@@ -1164,7 +1164,7 @@ static __u32 get_reg(struct fast_pool *f, struct pt_regs 
*regs)
return *ptr;
 }
 
-void add_interrupt_randomness(int irq, int irq_flags)
+void add_interrupt_randomness(int irq)
 {
struct entropy_store*r;
struct fast_pool*fast_pool = this_cpu_ptr(_randomness);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc65c4d79c1f..777096d560cb 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1016,7 +1016,7 @@ static void vmbus_isr(void)
tasklet_schedule(_cpu->msg_dpc);
}
 
-   add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0);
+   add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR);
 }
 
 
diff --git a/include/linux/random.h b/include/linux/random.h
index 4024f7d9c77d..b71f87dbf7cd 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -32,7 +32,7 @@ static inline void add_latent_entropy(void) {}
 
 extern void add_input_randomness(unsigned int type, unsigned int code,
 unsigned int value) __latent_entropy;
-extern void add_interrupt_randomness(int irq, int irq_flags) __latent_entropy;
+extern void add_interrupt_randomness(int irq) __latent_entropy;
 
 extern void get_random_bytes(void *buf, int nbytes);
 extern int wait_for_random_bytes(void);
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 79f987b942b8..1bc4dcc489d0 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -186,7 +186,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
 
retval = __handle_irq_event_percpu(desc, );
 
-   add_interrupt_randomness(desc->irq_data.irq, flags);
+   add_interrupt_randomness(desc->irq_data.irq);
 
if (!noirqdebug)
note_interrupt(desc, retval);
-- 
2.14.1

[PATCH] random: remove unused argument from add_interrupt_randomness()

[Sultan Alsawaf]

>From cdc2a03f93fdec88ad040a212605e20ab97c3e19 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf 
Date: Sun, 29 Apr 2018 20:04:35 -0700
Subject: [PATCH] random: remove unused argument from add_interrupt_randomness()

The irq_flags parameter is not used. Remove it.

Signed-off-by: Sultan Alsawaf 
---
 drivers/char/random.c  | 4 ++--
 drivers/hv/vmbus_drv.c | 2 +-
 include/linux/random.h | 2 +-
 kernel/irq/handle.c| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38729baed6ee..d9e38523b383 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -131,7 +131,7 @@
  * void add_device_randomness(const void *buf, unsigned int size);
  * void add_input_randomness(unsigned int type, unsigned int code,
  *unsigned int value);
- * void add_interrupt_randomness(int irq, int irq_flags);
+ * void add_interrupt_randomness(int irq);
  * void add_disk_randomness(struct gendisk *disk);
  *
  * add_device_randomness() is for adding data to the random pool that
@@ -1164,7 +1164,7 @@ static __u32 get_reg(struct fast_pool *f, struct pt_regs 
*regs)
return *ptr;
 }
 
-void add_interrupt_randomness(int irq, int irq_flags)
+void add_interrupt_randomness(int irq)
 {
struct entropy_store*r;
struct fast_pool*fast_pool = this_cpu_ptr(_randomness);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc65c4d79c1f..777096d560cb 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1016,7 +1016,7 @@ static void vmbus_isr(void)
tasklet_schedule(_cpu->msg_dpc);
}
 
-   add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0);
+   add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR);
 }
 
 
diff --git a/include/linux/random.h b/include/linux/random.h
index 4024f7d9c77d..b71f87dbf7cd 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -32,7 +32,7 @@ static inline void add_latent_entropy(void) {}
 
 extern void add_input_randomness(unsigned int type, unsigned int code,
 unsigned int value) __latent_entropy;
-extern void add_interrupt_randomness(int irq, int irq_flags) __latent_entropy;
+extern void add_interrupt_randomness(int irq) __latent_entropy;
 
 extern void get_random_bytes(void *buf, int nbytes);
 extern int wait_for_random_bytes(void);
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 79f987b942b8..1bc4dcc489d0 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -186,7 +186,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
 
retval = __handle_irq_event_percpu(desc, );
 
-   add_interrupt_randomness(desc->irq_data.irq, flags);
+   add_interrupt_randomness(desc->irq_data.irq);
 
if (!noirqdebug)
note_interrupt(desc, retval);
-- 
2.14.1

Re: [RFC net-next 0/5] Support for PHY test modes

[David Miller]

From: Florian Fainelli 
Date: Fri, 27 Apr 2018 17:32:30 -0700

> This patch series adds support for specifying PHY test modes through
> ethtool and paves the ground for adding support for more complex
> test modes that might require data to be exchanged between user and
> kernel space.
> 
> As an example, patches are included to add support for the IEEE
> electrical test modes for 100BaseT2 and 1000BaseT. Those do not
> require data to be passed back and forth.
> 
> I believe the infrastructure to be usable enough to add support for
> other things like:
> 
> - cable diagnostics
> - pattern generator/waveform generator with specific pattern being
>   indicated for instance
> 
> Questions for Andrew, and others:
> 
> - there could be room for adding additional ETH_TEST_FL_* values in order to
>   help determine how the test should be running
> - some of these tests can be disruptive to connectivity, the minimum we could
>   do is stop the PHY state machine and restart it when "normal" is used to 
> exit
>   those test modes
> 
> Comments welcome!

Generally, no objection to providing this in the general manner you
have implemented it via ethtool.

I think in order to answer the disruptive question, you need to give
some information about what kind of context this stuff would be
used in, and if in those contexts what the user expectations are
or might be.

Are these test modes something that usually would be initiated with
the interface down?

Re: [RFC net-next 0/5] Support for PHY test modes

[David Miller]

From: Florian Fainelli 
Date: Fri, 27 Apr 2018 17:32:30 -0700

> This patch series adds support for specifying PHY test modes through
> ethtool and paves the ground for adding support for more complex
> test modes that might require data to be exchanged between user and
> kernel space.
> 
> As an example, patches are included to add support for the IEEE
> electrical test modes for 100BaseT2 and 1000BaseT. Those do not
> require data to be passed back and forth.
> 
> I believe the infrastructure to be usable enough to add support for
> other things like:
> 
> - cable diagnostics
> - pattern generator/waveform generator with specific pattern being
>   indicated for instance
> 
> Questions for Andrew, and others:
> 
> - there could be room for adding additional ETH_TEST_FL_* values in order to
>   help determine how the test should be running
> - some of these tests can be disruptive to connectivity, the minimum we could
>   do is stop the PHY state machine and restart it when "normal" is used to 
> exit
>   those test modes
> 
> Comments welcome!

Generally, no objection to providing this in the general manner you
have implemented it via ethtool.

I think in order to answer the disruptive question, you need to give
some information about what kind of context this stuff would be
used in, and if in those contexts what the user expectations are
or might be.

Are these test modes something that usually would be initiated with
the interface down?

fscache kasan splat on v4.17-rc3

[Dave Jones]

[   46.333213] 
==
[   46.336298] BUG: KASAN: slab-out-of-bounds in 
fscache_alloc_cookie+0x129/0x310
[   46.338208] Read of size 4 at addr 8803ea90261c by task mount.nfs/839

[   46.342780] CPU: 2 PID: 839 Comm: mount.nfs Not tainted 
4.17.0-rc3-backup-debug+ #1
[   46.342783] Hardware name: ASUS All Series/Z97-DELUXE, BIOS 2602 08/18/2015
[   46.342784] Call Trace:
[   46.342790]  dump_stack+0x74/0xbb
[   46.342795]  print_address_description+0x9b/0x2b0
[   46.342797]  kasan_report+0x258/0x380
[   46.355407]  ? fscache_alloc_cookie+0x129/0x310
[   46.355410]  fscache_alloc_cookie+0x129/0x310
[   46.355413]  __fscache_acquire_cookie+0xd2/0x570
[   46.355417]  nfs_fscache_get_client_cookie+0x206/0x220
[   46.355419]  ? nfs_readpage_from_fscache_complete+0xa0/0xa0
[   46.355422]  ? rcu_read_lock_sched_held+0x8a/0xa0
[   46.355426]  ? memcpy+0x34/0x50
[   46.355428]  nfs_alloc_client+0x1d9/0x1f0
[   46.371854]  nfs4_alloc_client+0x22/0x420
[   46.371857]  nfs_get_client+0x47d/0x8f0
[   46.371860]  ? pcpu_alloc+0x599/0xaf0
[   46.371862]  nfs4_set_client+0x155/0x1e0
[   46.371865]  ? nfs4_check_serverowner_major_id+0x50/0x50
[   46.371867]  nfs4_create_server+0x261/0x4e0
[   46.371870]  ? nfs4_set_ds_client+0x200/0x200
[   46.371872]  ? alloc_vfsmnt+0xa6/0x360
[   46.371875]  ? __lockdep_init_map+0xaa/0x290
[   46.371878]  nfs4_remote_mount+0x31/0x60
[   46.371880]  mount_fs+0x2f/0xd0
[   46.371884]  vfs_kern_mount+0x68/0x200
[   46.396948]  nfs_do_root_mount+0x7f/0xc0
[   46.396952]  ? do_raw_spin_unlock+0xa2/0x130
[   46.396954]  nfs4_try_mount+0x7f/0x110
[   46.396957]  nfs_fs_mount+0xca5/0x1450
[   46.396960]  ? pcpu_alloc+0x599/0xaf0
[   46.396962]  ? nfs_remount+0x8a0/0x8a0
[   46.396964]  ? mark_held_locks+0x1c/0xb0
[   46.396967]  ? __raw_spin_lock_init+0x1c/0x70
[   46.412631]  ? trace_hardirqs_on_caller+0x187/0x260
[   46.412633]  ? nfs_clone_super+0x150/0x150
[   46.412635]  ? nfs_destroy_inode+0x20/0x20
[   46.412637]  ? __lockdep_init_map+0xaa/0x290
[   46.412639]  ? __lockdep_init_map+0xaa/0x290
[   46.412641]  ? mount_fs+0x2f/0xd0
[   46.412642]  mount_fs+0x2f/0xd0
[   46.412645]  vfs_kern_mount+0x68/0x200
[   46.412648]  ? do_raw_read_unlock+0x28/0x50
[   46.412651]  do_mount+0x2ac/0x14f0
[   46.412653]  ? copy_mount_string+0x20/0x20
[   46.431590]  ? copy_mount_options+0xe6/0x1b0
[   46.431592]  ? copy_mount_options+0x100/0x1b0
[   46.431594]  ? copy_mount_options+0xe6/0x1b0
[   46.431596]  ksys_mount+0x7e/0xd0
[   46.431599]  __x64_sys_mount+0x62/0x70
[   46.431601]  do_syscall_64+0xc7/0x8a0
[   46.431603]  ? syscall_return_slowpath+0x3c0/0x3c0
[   46.431605]  ? mark_held_locks+0x1c/0xb0
[   46.431609]  ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[   46.431611]  ? trace_hardirqs_off_caller+0xc2/0x110
[   46.431613]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   46.431615]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   46.431617] RIP: 0033:0x7f546ceb97fa
[   46.431619] RSP: 002b:7ffdf1c9d078 EFLAGS: 0206 ORIG_RAX: 
00a5
[   46.431622] RAX: ffda RBX:  RCX: 7f546ceb97fa
[   46.431623] RDX: 55decf202b20 RSI: 55decf202b40 RDI: 55decf204850
[   46.431625] RBP: 7ffdf1c9d1d0 R08: 55decf206680 R09: 62353a303036343a
[   46.431626] R10: 0c00 R11: 0206 R12: 7ffdf1c9d1d0
[   46.431627] R13: 55decf205870 R14: 001c R15: 7ffdf1c9d0e0

[   46.431631] Allocated by task 839:
[   46.431634]  kasan_kmalloc+0xa0/0xd0
[   46.431636]  __kmalloc+0x156/0x350
[   46.431639]  fscache_alloc_cookie+0x2e4/0x310
[   46.431640]  __fscache_acquire_cookie+0xd2/0x570
[   46.431643]  nfs_fscache_get_client_cookie+0x206/0x220
[   46.431645]  nfs_alloc_client+0x1d9/0x1f0
[   46.431648]  nfs4_alloc_client+0x22/0x420
[   46.431650]  nfs_get_client+0x47d/0x8f0
[   46.431652]  nfs4_set_client+0x155/0x1e0
[   46.431653]  nfs4_create_server+0x261/0x4e0
[   46.431655]  nfs4_remote_mount+0x31/0x60
[   46.431657]  mount_fs+0x2f/0xd0
[   46.431659]  vfs_kern_mount+0x68/0x200
[   46.431662]  nfs_do_root_mount+0x7f/0xc0
[   46.484441]  nfs4_try_mount+0x7f/0x110
[   46.484443]  nfs_fs_mount+0xca5/0x1450
[   46.484445]  mount_fs+0x2f/0xd0
[   46.484447]  vfs_kern_mount+0x68/0x200
[   46.484449]  do_mount+0x2ac/0x14f0
[   46.484451]  ksys_mount+0x7e/0xd0
[   46.484452]  __x64_sys_mount+0x62/0x70
[   46.484455]  do_syscall_64+0xc7/0x8a0
[   46.484458]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

[   46.484461] Freed by task 407:
[   46.499159]  __kasan_slab_free+0x11d/0x160
[   46.499161]  kfree+0xe5/0x320
[   46.499163]  kobject_uevent_env+0x1ab/0x760
[   46.499165]  kobject_synth_uevent+0x470/0x4e0
[   46.499168]  uevent_store+0x1c/0x40
[   46.499171]  kernfs_fop_write+0x196/0x230
[   46.499174]  __vfs_write+0xc5/0x310
[   46.499175]  vfs_write+0xfb/0x250
[   46.499177]  ksys_write+0xa7/0x130
[   46.499180]  do_syscall_64+0xc7/0x8a0
[   46.512915]  

fscache kasan splat on v4.17-rc3

[Dave Jones]

[   46.333213] 
==
[   46.336298] BUG: KASAN: slab-out-of-bounds in 
fscache_alloc_cookie+0x129/0x310
[   46.338208] Read of size 4 at addr 8803ea90261c by task mount.nfs/839

[   46.342780] CPU: 2 PID: 839 Comm: mount.nfs Not tainted 
4.17.0-rc3-backup-debug+ #1
[   46.342783] Hardware name: ASUS All Series/Z97-DELUXE, BIOS 2602 08/18/2015
[   46.342784] Call Trace:
[   46.342790]  dump_stack+0x74/0xbb
[   46.342795]  print_address_description+0x9b/0x2b0
[   46.342797]  kasan_report+0x258/0x380
[   46.355407]  ? fscache_alloc_cookie+0x129/0x310
[   46.355410]  fscache_alloc_cookie+0x129/0x310
[   46.355413]  __fscache_acquire_cookie+0xd2/0x570
[   46.355417]  nfs_fscache_get_client_cookie+0x206/0x220
[   46.355419]  ? nfs_readpage_from_fscache_complete+0xa0/0xa0
[   46.355422]  ? rcu_read_lock_sched_held+0x8a/0xa0
[   46.355426]  ? memcpy+0x34/0x50
[   46.355428]  nfs_alloc_client+0x1d9/0x1f0
[   46.371854]  nfs4_alloc_client+0x22/0x420
[   46.371857]  nfs_get_client+0x47d/0x8f0
[   46.371860]  ? pcpu_alloc+0x599/0xaf0
[   46.371862]  nfs4_set_client+0x155/0x1e0
[   46.371865]  ? nfs4_check_serverowner_major_id+0x50/0x50
[   46.371867]  nfs4_create_server+0x261/0x4e0
[   46.371870]  ? nfs4_set_ds_client+0x200/0x200
[   46.371872]  ? alloc_vfsmnt+0xa6/0x360
[   46.371875]  ? __lockdep_init_map+0xaa/0x290
[   46.371878]  nfs4_remote_mount+0x31/0x60
[   46.371880]  mount_fs+0x2f/0xd0
[   46.371884]  vfs_kern_mount+0x68/0x200
[   46.396948]  nfs_do_root_mount+0x7f/0xc0
[   46.396952]  ? do_raw_spin_unlock+0xa2/0x130
[   46.396954]  nfs4_try_mount+0x7f/0x110
[   46.396957]  nfs_fs_mount+0xca5/0x1450
[   46.396960]  ? pcpu_alloc+0x599/0xaf0
[   46.396962]  ? nfs_remount+0x8a0/0x8a0
[   46.396964]  ? mark_held_locks+0x1c/0xb0
[   46.396967]  ? __raw_spin_lock_init+0x1c/0x70
[   46.412631]  ? trace_hardirqs_on_caller+0x187/0x260
[   46.412633]  ? nfs_clone_super+0x150/0x150
[   46.412635]  ? nfs_destroy_inode+0x20/0x20
[   46.412637]  ? __lockdep_init_map+0xaa/0x290
[   46.412639]  ? __lockdep_init_map+0xaa/0x290
[   46.412641]  ? mount_fs+0x2f/0xd0
[   46.412642]  mount_fs+0x2f/0xd0
[   46.412645]  vfs_kern_mount+0x68/0x200
[   46.412648]  ? do_raw_read_unlock+0x28/0x50
[   46.412651]  do_mount+0x2ac/0x14f0
[   46.412653]  ? copy_mount_string+0x20/0x20
[   46.431590]  ? copy_mount_options+0xe6/0x1b0
[   46.431592]  ? copy_mount_options+0x100/0x1b0
[   46.431594]  ? copy_mount_options+0xe6/0x1b0
[   46.431596]  ksys_mount+0x7e/0xd0
[   46.431599]  __x64_sys_mount+0x62/0x70
[   46.431601]  do_syscall_64+0xc7/0x8a0
[   46.431603]  ? syscall_return_slowpath+0x3c0/0x3c0
[   46.431605]  ? mark_held_locks+0x1c/0xb0
[   46.431609]  ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[   46.431611]  ? trace_hardirqs_off_caller+0xc2/0x110
[   46.431613]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[   46.431615]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   46.431617] RIP: 0033:0x7f546ceb97fa
[   46.431619] RSP: 002b:7ffdf1c9d078 EFLAGS: 0206 ORIG_RAX: 
00a5
[   46.431622] RAX: ffda RBX:  RCX: 7f546ceb97fa
[   46.431623] RDX: 55decf202b20 RSI: 55decf202b40 RDI: 55decf204850
[   46.431625] RBP: 7ffdf1c9d1d0 R08: 55decf206680 R09: 62353a303036343a
[   46.431626] R10: 0c00 R11: 0206 R12: 7ffdf1c9d1d0
[   46.431627] R13: 55decf205870 R14: 001c R15: 7ffdf1c9d0e0

[   46.431631] Allocated by task 839:
[   46.431634]  kasan_kmalloc+0xa0/0xd0
[   46.431636]  __kmalloc+0x156/0x350
[   46.431639]  fscache_alloc_cookie+0x2e4/0x310
[   46.431640]  __fscache_acquire_cookie+0xd2/0x570
[   46.431643]  nfs_fscache_get_client_cookie+0x206/0x220
[   46.431645]  nfs_alloc_client+0x1d9/0x1f0
[   46.431648]  nfs4_alloc_client+0x22/0x420
[   46.431650]  nfs_get_client+0x47d/0x8f0
[   46.431652]  nfs4_set_client+0x155/0x1e0
[   46.431653]  nfs4_create_server+0x261/0x4e0
[   46.431655]  nfs4_remote_mount+0x31/0x60
[   46.431657]  mount_fs+0x2f/0xd0
[   46.431659]  vfs_kern_mount+0x68/0x200
[   46.431662]  nfs_do_root_mount+0x7f/0xc0
[   46.484441]  nfs4_try_mount+0x7f/0x110
[   46.484443]  nfs_fs_mount+0xca5/0x1450
[   46.484445]  mount_fs+0x2f/0xd0
[   46.484447]  vfs_kern_mount+0x68/0x200
[   46.484449]  do_mount+0x2ac/0x14f0
[   46.484451]  ksys_mount+0x7e/0xd0
[   46.484452]  __x64_sys_mount+0x62/0x70
[   46.484455]  do_syscall_64+0xc7/0x8a0
[   46.484458]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

[   46.484461] Freed by task 407:
[   46.499159]  __kasan_slab_free+0x11d/0x160
[   46.499161]  kfree+0xe5/0x320
[   46.499163]  kobject_uevent_env+0x1ab/0x760
[   46.499165]  kobject_synth_uevent+0x470/0x4e0
[   46.499168]  uevent_store+0x1c/0x40
[   46.499171]  kernfs_fop_write+0x196/0x230
[   46.499174]  __vfs_write+0xc5/0x310
[   46.499175]  vfs_write+0xfb/0x250
[   46.499177]  ksys_write+0xa7/0x130
[   46.499180]  do_syscall_64+0xc7/0x8a0
[   46.512915]  

Re: [PATCH] net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"

[David Miller]

From: Colin King 
Date: Fri, 27 Apr 2018 20:09:25 +0100

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in netdev_warn warning message
> 
> Signed-off-by: Colin Ian King 

Applied, thank you.

Re: [PATCH] net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"

[David Miller]

From: Colin King 
Date: Fri, 27 Apr 2018 20:09:25 +0100

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in netdev_warn warning message
> 
> Signed-off-by: Colin Ian King 

Applied, thank you.

[PATCH] KVM: X86: Limit timer frequency with more smaller interval

[Wanpeng Li]

From: Wanpeng Li 

Anthoine reported:
 The period used by Windows change over time but it can be 1 milliseconds
 or less. I saw the limit_periodic_timer_frequency print so 500
 microseconds is sometimes reached.

This patchs limits timer frequency with more smaller interval 200ms(5000Hz) 
to leave some headroom as Paolo suggested since Windows 10 changed the 
scheduler tick limit from 1024 Hz to 2048 Hz.

Reported-by: Anthoine Bourgeois 
Suggested-by: Paolo Bonzini  
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Anthoine Bourgeois 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 51ecd38..dc47073 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -114,7 +114,7 @@ module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR);
 static bool __read_mostly report_ignored_msrs = true;
 module_param(report_ignored_msrs, bool, S_IRUGO | S_IWUSR);
 
-unsigned int min_timer_period_us = 500;
+unsigned int min_timer_period_us = 200;
 module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR);
 
 static bool __read_mostly kvmclock_periodic_sync = true;
-- 
2.7.4

[PATCH] KVM: X86: Limit timer frequency with more smaller interval

[Wanpeng Li]

From: Wanpeng Li 

Anthoine reported:
 The period used by Windows change over time but it can be 1 milliseconds
 or less. I saw the limit_periodic_timer_frequency print so 500
 microseconds is sometimes reached.

This patchs limits timer frequency with more smaller interval 200ms(5000Hz) 
to leave some headroom as Paolo suggested since Windows 10 changed the 
scheduler tick limit from 1024 Hz to 2048 Hz.

Reported-by: Anthoine Bourgeois 
Suggested-by: Paolo Bonzini  
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Anthoine Bourgeois 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 51ecd38..dc47073 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -114,7 +114,7 @@ module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR);
 static bool __read_mostly report_ignored_msrs = true;
 module_param(report_ignored_msrs, bool, S_IRUGO | S_IWUSR);
 
-unsigned int min_timer_period_us = 500;
+unsigned int min_timer_period_us = 200;
 module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR);
 
 static bool __read_mostly kvmclock_periodic_sync = true;
-- 
2.7.4

Re: [PATCH] NFS: Avoid quadratic search when freeing delegations.

[NeilBrown]

On Fri, Apr 27 2018, Mathieu Desnoyers wrote:

> - On Apr 27, 2018, at 1:29 AM, NeilBrown ne...@suse.com wrote:
>
>> If an NFS client has 10,000 delegations which are between 90 and 180 seconds
>> old,
>> and 10,000 which are between 180 and 270 seconds old, with none of them still
>> in use, it is likely that the old ones are at the end of the list.
>> The first 10,000 will not be marked to be returned, the last 10,000 will.
>> 
>> To return these, the code starts at the front of the list and finds the
>> first delegation needing to be returned (testing 10,000 on the way).
>> Then it drops rcu_readlock(), returns the delegation and starts again,
>> and does this 10,000 times.
>> 
>> As delegation return is async, it may never block, so these 10,000
>> delegation will be returned without stopping for a breath.  The soft-lock
>> detector will notice and complain.
>> 
>> This patch makes 3 changes.
>> 
>> 1/ cond_resched() is added so that the soft-lockup detector doesn't notice.
>> 2/ A place-holder (an inode) is kept when locks are dropped, so that
>>   the place can usually be found again after taking rcu_readlock().
>>   This means we don't need to skip over 10,000 entries 10,000 times,
>>   100 million pointless operations - which could eaisly be a larger
>>   number.
>> 3/ If nfs_sb_active() fails, break out of the loop - there is no point
>>   in continuing.
>> 
>> The patch also add list_for_each_entry_from_rcu() to rculist.h in
>> order to achieve 2/.
>> 
>> Signed-off-by: NeilBrown 
>> ---
>> 
>> Hi,
>> I'm hoping one of the RCU reviewers will provide an Acked-by for the
>> rculist.h change.
>> 
>> If you'ld like 3 patches instead of just one, please let me know.  But
>> they all see to fit well together.

Thanks for your review!

>
> I think the RCU list API changes should sit in their own patch.

I guess I can split it into a separate patch if you like.  Hopefully it
can still go in through the NFS tree so we need to sync separate trees.


>
>> 
>> thanks,
>> NeilBrown
>> 
>> 
>> fs/nfs/delegation.c | 57 
>> -
>> include/linux/rculist.h | 10 +
>> 2 files changed, 62 insertions(+), 5 deletions(-)
>> 
>> diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
>> index 1819d0d0ba4b..c3d9e21ab440 100644
>> --- a/fs/nfs/delegation.c
>> +++ b/fs/nfs/delegation.c
>> @@ -483,19 +483,56 @@ static bool nfs_delegation_need_return(struct
>> nfs_delegation *delegation)
>> int nfs_client_return_marked_delegations(struct nfs_client *clp)
>> {
>>  struct nfs_delegation *delegation;
>> +struct nfs_delegation *prev;
>>  struct nfs_server *server;
>>  struct inode *inode;
>> +struct inode *place_holder = NULL;
>>  int err = 0;
>> 
>> restart:
>> +/*
>> + * To avoid quadratic looping we hold an reference
>
> an reference -> a reference

Fixed, thanks.

>
>> + * to an inode place_holder.  Each time we restart, we
>> + * list nfs_servers from the server of that inode, and
>> + * delegation in the server from the delegations of that
>> + * inode.
>> + * prev is an RCU-protected pointer to a delegation which
>> + * wasn't marked for return and might be a good choice for
>> + * the next place_holder.
>> + */
>>  rcu_read_lock();
>> -list_for_each_entry_rcu(server, >cl_superblocks, client_link) {
>> -list_for_each_entry_rcu(delegation, >delegations,
>> -super_list) {
>> -if (!nfs_delegation_need_return(delegation))
>> +prev = NULL;
>> +if (place_holder)
>> +server = NFS_SERVER(place_holder);
>> +else
>> +server = list_entry_rcu(clp->cl_superblocks.next,
>> +struct nfs_server, client_link);
>> +list_for_each_entry_from_rcu(server, >cl_superblocks, client_link) 
>> {
>
> Unless I'm missing something, you should define the delegation variable within
> this scope.

I could, yes.  But that was true before the patch as well.  I don't
really want to change things that I don't need to change.
This is really a style issue.  If Trond or Anna prefer the variable in
the most local scope, I'll move it.

>
>> +delegation = NULL;
>> +if (place_holder && server == NFS_SERVER(place_holder))
>> +delegation = 
>> rcu_dereference(NFS_I(place_holder)->delegation);
>> +if (!delegation)
>> +delegation = list_entry_rcu(server->delegations.next,
>> +struct nfs_delegation, 
>> super_list);
>
> AFAIU, what makes this work is that you expect grabbing the inode
> reference will ensure the entry is not removed from the RCU list until
> the iput().
>

There are two lists, a per "struct nfs_client" list of "struct
nfs_server", and a per "struct nfs_server" list of "struct
nfs_delegation".

I expect that grabbing the 

Re: [PATCH] NFS: Avoid quadratic search when freeing delegations.

[NeilBrown]

On Fri, Apr 27 2018, Mathieu Desnoyers wrote:

> - On Apr 27, 2018, at 1:29 AM, NeilBrown ne...@suse.com wrote:
>
>> If an NFS client has 10,000 delegations which are between 90 and 180 seconds
>> old,
>> and 10,000 which are between 180 and 270 seconds old, with none of them still
>> in use, it is likely that the old ones are at the end of the list.
>> The first 10,000 will not be marked to be returned, the last 10,000 will.
>> 
>> To return these, the code starts at the front of the list and finds the
>> first delegation needing to be returned (testing 10,000 on the way).
>> Then it drops rcu_readlock(), returns the delegation and starts again,
>> and does this 10,000 times.
>> 
>> As delegation return is async, it may never block, so these 10,000
>> delegation will be returned without stopping for a breath.  The soft-lock
>> detector will notice and complain.
>> 
>> This patch makes 3 changes.
>> 
>> 1/ cond_resched() is added so that the soft-lockup detector doesn't notice.
>> 2/ A place-holder (an inode) is kept when locks are dropped, so that
>>   the place can usually be found again after taking rcu_readlock().
>>   This means we don't need to skip over 10,000 entries 10,000 times,
>>   100 million pointless operations - which could eaisly be a larger
>>   number.
>> 3/ If nfs_sb_active() fails, break out of the loop - there is no point
>>   in continuing.
>> 
>> The patch also add list_for_each_entry_from_rcu() to rculist.h in
>> order to achieve 2/.
>> 
>> Signed-off-by: NeilBrown 
>> ---
>> 
>> Hi,
>> I'm hoping one of the RCU reviewers will provide an Acked-by for the
>> rculist.h change.
>> 
>> If you'ld like 3 patches instead of just one, please let me know.  But
>> they all see to fit well together.

Thanks for your review!

>
> I think the RCU list API changes should sit in their own patch.

I guess I can split it into a separate patch if you like.  Hopefully it
can still go in through the NFS tree so we need to sync separate trees.


>
>> 
>> thanks,
>> NeilBrown
>> 
>> 
>> fs/nfs/delegation.c | 57 
>> -
>> include/linux/rculist.h | 10 +
>> 2 files changed, 62 insertions(+), 5 deletions(-)
>> 
>> diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
>> index 1819d0d0ba4b..c3d9e21ab440 100644
>> --- a/fs/nfs/delegation.c
>> +++ b/fs/nfs/delegation.c
>> @@ -483,19 +483,56 @@ static bool nfs_delegation_need_return(struct
>> nfs_delegation *delegation)
>> int nfs_client_return_marked_delegations(struct nfs_client *clp)
>> {
>>  struct nfs_delegation *delegation;
>> +struct nfs_delegation *prev;
>>  struct nfs_server *server;
>>  struct inode *inode;
>> +struct inode *place_holder = NULL;
>>  int err = 0;
>> 
>> restart:
>> +/*
>> + * To avoid quadratic looping we hold an reference
>
> an reference -> a reference

Fixed, thanks.

>
>> + * to an inode place_holder.  Each time we restart, we
>> + * list nfs_servers from the server of that inode, and
>> + * delegation in the server from the delegations of that
>> + * inode.
>> + * prev is an RCU-protected pointer to a delegation which
>> + * wasn't marked for return and might be a good choice for
>> + * the next place_holder.
>> + */
>>  rcu_read_lock();
>> -list_for_each_entry_rcu(server, >cl_superblocks, client_link) {
>> -list_for_each_entry_rcu(delegation, >delegations,
>> -super_list) {
>> -if (!nfs_delegation_need_return(delegation))
>> +prev = NULL;
>> +if (place_holder)
>> +server = NFS_SERVER(place_holder);
>> +else
>> +server = list_entry_rcu(clp->cl_superblocks.next,
>> +struct nfs_server, client_link);
>> +list_for_each_entry_from_rcu(server, >cl_superblocks, client_link) 
>> {
>
> Unless I'm missing something, you should define the delegation variable within
> this scope.

I could, yes.  But that was true before the patch as well.  I don't
really want to change things that I don't need to change.
This is really a style issue.  If Trond or Anna prefer the variable in
the most local scope, I'll move it.

>
>> +delegation = NULL;
>> +if (place_holder && server == NFS_SERVER(place_holder))
>> +delegation = 
>> rcu_dereference(NFS_I(place_holder)->delegation);
>> +if (!delegation)
>> +delegation = list_entry_rcu(server->delegations.next,
>> +struct nfs_delegation, 
>> super_list);
>
> AFAIU, what makes this work is that you expect grabbing the inode
> reference will ensure the entry is not removed from the RCU list until
> the iput().
>

There are two lists, a per "struct nfs_client" list of "struct
nfs_server", and a per "struct nfs_server" list of "struct
nfs_delegation".

I expect that grabbing the inode will stop 

Re: [PATCH 3/3] genalloc: selftest

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> init/main.c:94:10: fatal error: linux/test_genalloc.h: No such file or 
>> directory
#include 
 ^~~
   compilation terminated.

vim +94 init/main.c

13  
14  #include 
15  #include 
16  #include 
17  #include 
18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
23  #include 
24  #include 
25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  #include 
35  #include 
36  #include 
37  #include 
38  #include 
39  #include 
40  #include 
41  #include 
42  #include 
43  #include 
44  #include 
45  #include 
46  #include 
47  #include 
48  #include 
49  #include 
50  #include 
51  #include 
52  #include 
53  #include 
54  #include 
55  #include 
56  #include 
57  #include 
58  #include 
59  #include 
60  #include 
61  #include 
62  #include 
63  #include 
64  #include 
65  #include 
66  #include 
67  #include 
68  #include 
69  #include 
70  #include 
71  #include 
72  #include 
73  #include 
74  #include 
75  #include 
76  #include 
77  #include 
78  #include 
79  #include 
80  #include 
81  #include 
82  #include 
83  #include 
84  #include 
85  #include 
86  #include 
87  #include 
88  #include 
89  #include 
90  #include 
91  #include 
92  #include 
93  #include 
  > 94  #include 
95  

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


.config.gz
Description: application/gzip

Re: [PATCH 3/3] genalloc: selftest

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850
config: i386-tinyconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> init/main.c:94:10: fatal error: linux/test_genalloc.h: No such file or 
>> directory
#include 
 ^~~
   compilation terminated.

vim +94 init/main.c

13  
14  #include 
15  #include 
16  #include 
17  #include 
18  #include 
19  #include 
20  #include 
21  #include 
22  #include 
23  #include 
24  #include 
25  #include 
26  #include 
27  #include 
28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  #include 
35  #include 
36  #include 
37  #include 
38  #include 
39  #include 
40  #include 
41  #include 
42  #include 
43  #include 
44  #include 
45  #include 
46  #include 
47  #include 
48  #include 
49  #include 
50  #include 
51  #include 
52  #include 
53  #include 
54  #include 
55  #include 
56  #include 
57  #include 
58  #include 
59  #include 
60  #include 
61  #include 
62  #include 
63  #include 
64  #include 
65  #include 
66  #include 
67  #include 
68  #include 
69  #include 
70  #include 
71  #include 
72  #include 
73  #include 
74  #include 
75  #include 
76  #include 
77  #include 
78  #include 
79  #include 
80  #include 
81  #include 
82  #include 
83  #include 
84  #include 
85  #include 
86  #include 
87  #include 
88  #include 
89  #include 
90  #include 
91  #include 
92  #include 
93  #include 
  > 94  #include 
95  

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


.config.gz
Description: application/gzip

Re: [PATCH v6 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Ryder Lee]

On Fri, 2018-04-20 at 13:25 +0800, Honghui Zhang (张洪辉) wrote:
> From: Honghui Zhang 
> 
> Two fixups for mediatek's host bridge:
> The first patch fixup class type and vendor ID for MT7622.
> The second patch fixup the IRQ handle routine by using irq_chip solution
> to avoid IRQ reentry which may exist for both MT2712 and MT7622.
> 
> Change since v5:
>  - Make the comments consistend with the code modification in the first patch.
>  - Using writew to performing a 16-bit write.
>  - Using irq_chip solution to fix the IRQ issue.
> 
> The v5 patchset could be found in:
>  https://patchwork.kernel.org/patch/10133303
>  https://patchwork.kernel.org/patch/10133305
> 
> Change since v4:
>  - Only setup vendor ID for MT7622, igorning the device ID since mediatek's
>host bridge driver does not cares about the device ID.
> 
> Change since v3:
>  - Setup the class type and vendor ID at the beginning of startup instead
>of in a quirk.
>  - Add mediatek's vendor ID, it could be found in:
>https://pcisig.com/membership/member-companies?combine==4
> 
> Change since v2:
>  - Move the initialize of the iterate before the loop to fix an
>INTx IRQ issue in the first patch
> 
> Change since v1:
>  - Add the second patch.
>  - Make the first patch's commit message more standard.
> Honghui Zhang (2):
>   PCI: mediatek: Set up vendor ID and class type for MT7622
>   PCI: mediatek: Using chained IRQ to setup IRQ handle
> 
>  drivers/pci/host/pcie-mediatek.c | 220 
> +++
>  include/linux/pci_ids.h  |   2 +
>  2 files changed, 133 insertions(+), 89 deletions(-)


Acked-by: Ryder Lee  for the series.

Thanks

Re: [PATCH v6 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Ryder Lee]

On Fri, 2018-04-20 at 13:25 +0800, Honghui Zhang (张洪辉) wrote:
> From: Honghui Zhang 
> 
> Two fixups for mediatek's host bridge:
> The first patch fixup class type and vendor ID for MT7622.
> The second patch fixup the IRQ handle routine by using irq_chip solution
> to avoid IRQ reentry which may exist for both MT2712 and MT7622.
> 
> Change since v5:
>  - Make the comments consistend with the code modification in the first patch.
>  - Using writew to performing a 16-bit write.
>  - Using irq_chip solution to fix the IRQ issue.
> 
> The v5 patchset could be found in:
>  https://patchwork.kernel.org/patch/10133303
>  https://patchwork.kernel.org/patch/10133305
> 
> Change since v4:
>  - Only setup vendor ID for MT7622, igorning the device ID since mediatek's
>host bridge driver does not cares about the device ID.
> 
> Change since v3:
>  - Setup the class type and vendor ID at the beginning of startup instead
>of in a quirk.
>  - Add mediatek's vendor ID, it could be found in:
>https://pcisig.com/membership/member-companies?combine==4
> 
> Change since v2:
>  - Move the initialize of the iterate before the loop to fix an
>INTx IRQ issue in the first patch
> 
> Change since v1:
>  - Add the second patch.
>  - Make the first patch's commit message more standard.
> Honghui Zhang (2):
>   PCI: mediatek: Set up vendor ID and class type for MT7622
>   PCI: mediatek: Using chained IRQ to setup IRQ handle
> 
>  drivers/pci/host/pcie-mediatek.c | 220 
> +++
>  include/linux/pci_ids.h  |   2 +
>  2 files changed, 133 insertions(+), 89 deletions(-)


Acked-by: Ryder Lee  for the series.

Thanks

[PATCH resend] VFS: simplify seq_file iteration code and interface

[NeilBrown]

Just resending after 2 weeks silence, in case it fell through a crack.
Thanks,
NeilBrown

("git am -c" understands this line)
--8<-

The documentation for seq_file suggests that it is necessary to be
able to move the iterator to a given offset, however that is not the
case.  If the iterator is stored in the private data and is stable
from one read() syscall to the next, it is only necessary to support
first/next interactions.  Implementing this in a client is a little
clumsy.
- if ->start() is given a pos of zero, it should go to start of
  sequence.
- if ->start() is given the name pos that was given to the most recent
  next() or start(), it should restore the iterator to state just
  before that last call
- if ->start is given another number, it should set the iterator one
  beyond the start just before the last ->start or ->next call.


Also, the documentation says that the implementation can interpret the
pos however it likes (other than zero meaning start), but seq_file
increments the pos sometimes which does impose on the implementation.

This patch simplifies the interface for first/next iteration and
simplifies the code, while maintaining complete backward
compatability.  Now:

- if ->start() is given a pos of zero, it should return an iterator
  placed at the start of the sequence
- if ->start() is given a non-zero pos, it should return the iterator
  in the same state it was after the last ->start or ->next.

This is particularly useful for interators which walk the multiple
chains in a hash table, e.g. using rhashtable_walk*. See
fs/gfs2/glock.c and drivers/staging/lustre/lustre/llite/vvp_dev.c

A large part of achieving this is to *always* call ->next after ->show
has successfully stored all of an entry in the buffer.  Never just
increment the index instead.
Also:
 - always pass >index to ->start() and ->next(), never a temp
   variable
 - don't clear ->from when ->count is zero, as ->from is dead when
->count is zero.


Some ->next functions do not increment *pos when they return NULL.
To maintain compatability with this, we still need to increment
m->index in one place, if ->next didn't increment it.
Note that such ->next functions are buggy and should be fixed.
A simple demonstration is
   dd if=/proc/swaps bs=1000 skip=1
Choose any block size larger than the size of /proc/swaps.
This will always show the whole last line of /proc/swaps.

This patch doesn't work around buggy next() functions for this case.

Signed-off-by: NeilBrown 
---
 Documentation/filesystems/seq_file.txt | 63 ++
 fs/seq_file.c  | 53 +++-
 2 files changed, 62 insertions(+), 54 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt 
b/Documentation/filesystems/seq_file.txt
index 9de4303201e1..d412b236a9d6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -66,23 +66,39 @@ kernel 3.10. Current versions require the following update
 
 The iterator interface
 
-Modules implementing a virtual file with seq_file must implement a simple
-iterator object that allows stepping through the data of interest.
-Iterators must be able to move to a specific position - like the file they
-implement - but the interpretation of that position is up to the iterator
-itself. A seq_file implementation that is formatting firewall rules, for
-example, could interpret position N as the Nth rule in the chain.
-Positioning can thus be done in whatever way makes the most sense for the
-generator of the data, which need not be aware of how a position translates
-to an offset in the virtual file. The one obvious exception is that a
-position of zero should indicate the beginning of the file.
+Modules implementing a virtual file with seq_file must implement an
+iterator object that allows stepping through the data of interest
+during a "session" (roughly one read() system call).  If the iterator
+is able to move to a specific position - like the file they implement,
+though with freedom to map the position number to a sequence location
+in whatever way is convenient - the iterator need only exist
+transiently during a session.  If the iterator cannot easily find a
+numerical position but works well with a first/next interface, the
+iterator can be stored in the private data area and continue from one
+session to the next.
+
+A seq_file implementation that is formatting firewall rules from a
+table, for example, could provide a simple iterator that interprets
+position N as the Nth rule in the chain.  A seq_file implementation
+that presents the content of a, potentially volatile, linked list
+might record a pointer into that list, providing that can be done
+without risk of the current location being removed.
+
+Positioning can thus be done in whatever way makes the most sense for
+the generator of the data, which need not be aware of how a position
+translates to 

[PATCH resend] VFS: simplify seq_file iteration code and interface

[NeilBrown]

Just resending after 2 weeks silence, in case it fell through a crack.
Thanks,
NeilBrown

("git am -c" understands this line)
--8<-

The documentation for seq_file suggests that it is necessary to be
able to move the iterator to a given offset, however that is not the
case.  If the iterator is stored in the private data and is stable
from one read() syscall to the next, it is only necessary to support
first/next interactions.  Implementing this in a client is a little
clumsy.
- if ->start() is given a pos of zero, it should go to start of
  sequence.
- if ->start() is given the name pos that was given to the most recent
  next() or start(), it should restore the iterator to state just
  before that last call
- if ->start is given another number, it should set the iterator one
  beyond the start just before the last ->start or ->next call.


Also, the documentation says that the implementation can interpret the
pos however it likes (other than zero meaning start), but seq_file
increments the pos sometimes which does impose on the implementation.

This patch simplifies the interface for first/next iteration and
simplifies the code, while maintaining complete backward
compatability.  Now:

- if ->start() is given a pos of zero, it should return an iterator
  placed at the start of the sequence
- if ->start() is given a non-zero pos, it should return the iterator
  in the same state it was after the last ->start or ->next.

This is particularly useful for interators which walk the multiple
chains in a hash table, e.g. using rhashtable_walk*. See
fs/gfs2/glock.c and drivers/staging/lustre/lustre/llite/vvp_dev.c

A large part of achieving this is to *always* call ->next after ->show
has successfully stored all of an entry in the buffer.  Never just
increment the index instead.
Also:
 - always pass >index to ->start() and ->next(), never a temp
   variable
 - don't clear ->from when ->count is zero, as ->from is dead when
->count is zero.


Some ->next functions do not increment *pos when they return NULL.
To maintain compatability with this, we still need to increment
m->index in one place, if ->next didn't increment it.
Note that such ->next functions are buggy and should be fixed.
A simple demonstration is
   dd if=/proc/swaps bs=1000 skip=1
Choose any block size larger than the size of /proc/swaps.
This will always show the whole last line of /proc/swaps.

This patch doesn't work around buggy next() functions for this case.

Signed-off-by: NeilBrown 
---
 Documentation/filesystems/seq_file.txt | 63 ++
 fs/seq_file.c  | 53 +++-
 2 files changed, 62 insertions(+), 54 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt 
b/Documentation/filesystems/seq_file.txt
index 9de4303201e1..d412b236a9d6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -66,23 +66,39 @@ kernel 3.10. Current versions require the following update
 
 The iterator interface
 
-Modules implementing a virtual file with seq_file must implement a simple
-iterator object that allows stepping through the data of interest.
-Iterators must be able to move to a specific position - like the file they
-implement - but the interpretation of that position is up to the iterator
-itself. A seq_file implementation that is formatting firewall rules, for
-example, could interpret position N as the Nth rule in the chain.
-Positioning can thus be done in whatever way makes the most sense for the
-generator of the data, which need not be aware of how a position translates
-to an offset in the virtual file. The one obvious exception is that a
-position of zero should indicate the beginning of the file.
+Modules implementing a virtual file with seq_file must implement an
+iterator object that allows stepping through the data of interest
+during a "session" (roughly one read() system call).  If the iterator
+is able to move to a specific position - like the file they implement,
+though with freedom to map the position number to a sequence location
+in whatever way is convenient - the iterator need only exist
+transiently during a session.  If the iterator cannot easily find a
+numerical position but works well with a first/next interface, the
+iterator can be stored in the private data area and continue from one
+session to the next.
+
+A seq_file implementation that is formatting firewall rules from a
+table, for example, could provide a simple iterator that interprets
+position N as the Nth rule in the chain.  A seq_file implementation
+that presents the content of a, potentially volatile, linked list
+might record a pointer into that list, providing that can be done
+without risk of the current location being removed.
+
+Positioning can thus be done in whatever way makes the most sense for
+the generator of the data, which need not be aware of how a position
+translates to an offset in the 

Re: [PATCH] vhost: make msg padding explicit

[David Miller]

From: "Michael S. Tsirkin" 
Date: Fri, 27 Apr 2018 19:02:05 +0300

> There's a 32 bit hole just after type. It's best to
> give it a name, this way compiler is forced to initialize
> it with rest of the structure.
> 
> Reported-by: Kevin Easton 
> Signed-off-by: Michael S. Tsirkin 

Who applied this, me? :-)

Re: [PATCH] vhost: make msg padding explicit

[David Miller]

From: "Michael S. Tsirkin" 
Date: Fri, 27 Apr 2018 19:02:05 +0300

> There's a 32 bit hole just after type. It's best to
> give it a name, this way compiler is forced to initialize
> it with rest of the structure.
> 
> Reported-by: Kevin Easton 
> Signed-off-by: Michael S. Tsirkin 

Who applied this, me? :-)

Re: [PATCH v4 net-next 0/2] tcp: mmap: rework zerocopy receive

[David Miller]

From: Eric Dumazet 
Date: Fri, 27 Apr 2018 08:58:07 -0700

> syzbot reported a lockdep issue caused by tcp mmap() support.
> 
> I implemented Andy Lutomirski nice suggestions to resolve the
> issue and increase scalability as well.
> 
> First patch is adding a new getsockopt() operation and changes mmap()
> behavior.
> 
> Second patch changes tcp_mmap reference program.
> 
> v4: tcp mmap() support depends on CONFIG_MMU, as kbuild bot told us.
> 
> v3: change TCP_ZEROCOPY_RECEIVE to be a getsockopt() option
> instead of setsockopt(), feedback from Ka-Cheon Poon
> 
> v2: Added a missing page align of zc->length in tcp_zerocopy_receive()
> Properly clear zc->recv_skip_hint in case user request was completed.

Looks great, series applied, thanks Eric.

Re: linux-next: manual merge of the usb tree with the usb.current tree

[Stephen Rothwell]

Hi all,

On Mon, 23 Apr 2018 13:04:44 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the usb tree got a conflict in:
> 
>   drivers/usb/core/hcd.c
> 
> between commit:
> 
>   63cb03f5c11e ("usb: core: split usb_phy_roothub_{init,alloc}")
> 
> from the usb.current tree and commit:
> 
>   bc40f5341741 ("USB: core: hcd: drop support for legacy phys")
> 
> from the usb tree.
> 
> I fixed it up (see below - though I am not sure what happens to the
> phy_roothub allocation when usb_phy_roothub_init fails) and can carry
> the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/usb/core/hcd.c
> index 0a42c5df3c0f,ac5bcf449d7d..
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@@ -2742,35 -2740,11 +2743,15 @@@ int usb_add_hcd(struct usb_hcd *hcd
>   int retval;
>   struct usb_device *rhdev;
>   
> - if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->skip_phy_initialization) {
> - struct usb_phy *phy = usb_get_phy_dev(hcd->self.sysdev, 0);
> - 
> - if (IS_ERR(phy)) {
> - retval = PTR_ERR(phy);
> - if (retval == -EPROBE_DEFER)
> - return retval;
> - } else {
> - retval = usb_phy_init(phy);
> - if (retval) {
> - usb_put_phy(phy);
> - return retval;
> - }
> - hcd->usb_phy = phy;
> - hcd->remove_phy = 1;
> - }
> - }
> - 
>   if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
>  -hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
>  +hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
> - if (IS_ERR(hcd->phy_roothub)) {
> - retval = PTR_ERR(hcd->phy_roothub);
> - goto err_phy_roothub_alloc;
> - }
> + if (IS_ERR(hcd->phy_roothub))
> + return PTR_ERR(hcd->phy_roothub);
>   
>  +retval = usb_phy_roothub_init(hcd->phy_roothub);
>  +if (retval)
> - goto err_phy_roothub_alloc;
> ++return retval;
>  +
>   retval = usb_phy_roothub_power_on(hcd->phy_roothub);
>   if (retval)
>   goto err_usb_phy_roothub_power_on;

This is now a conflict between the battery tree (since it merged the
usb tree) and Linus' tree (since it merged the usb.current tree).

-- 
Cheers,
Stephen Rothwell


pgpylkKm1dsNZ.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 net-next 0/2] tcp: mmap: rework zerocopy receive

[David Miller]

From: Eric Dumazet 
Date: Fri, 27 Apr 2018 08:58:07 -0700

> syzbot reported a lockdep issue caused by tcp mmap() support.
> 
> I implemented Andy Lutomirski nice suggestions to resolve the
> issue and increase scalability as well.
> 
> First patch is adding a new getsockopt() operation and changes mmap()
> behavior.
> 
> Second patch changes tcp_mmap reference program.
> 
> v4: tcp mmap() support depends on CONFIG_MMU, as kbuild bot told us.
> 
> v3: change TCP_ZEROCOPY_RECEIVE to be a getsockopt() option
> instead of setsockopt(), feedback from Ka-Cheon Poon
> 
> v2: Added a missing page align of zc->length in tcp_zerocopy_receive()
> Properly clear zc->recv_skip_hint in case user request was completed.

Looks great, series applied, thanks Eric.

Re: linux-next: manual merge of the usb tree with the usb.current tree

[Stephen Rothwell]

Hi all,

On Mon, 23 Apr 2018 13:04:44 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the usb tree got a conflict in:
> 
>   drivers/usb/core/hcd.c
> 
> between commit:
> 
>   63cb03f5c11e ("usb: core: split usb_phy_roothub_{init,alloc}")
> 
> from the usb.current tree and commit:
> 
>   bc40f5341741 ("USB: core: hcd: drop support for legacy phys")
> 
> from the usb tree.
> 
> I fixed it up (see below - though I am not sure what happens to the
> phy_roothub allocation when usb_phy_roothub_init fails) and can carry
> the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/usb/core/hcd.c
> index 0a42c5df3c0f,ac5bcf449d7d..
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@@ -2742,35 -2740,11 +2743,15 @@@ int usb_add_hcd(struct usb_hcd *hcd
>   int retval;
>   struct usb_device *rhdev;
>   
> - if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->skip_phy_initialization) {
> - struct usb_phy *phy = usb_get_phy_dev(hcd->self.sysdev, 0);
> - 
> - if (IS_ERR(phy)) {
> - retval = PTR_ERR(phy);
> - if (retval == -EPROBE_DEFER)
> - return retval;
> - } else {
> - retval = usb_phy_init(phy);
> - if (retval) {
> - usb_put_phy(phy);
> - return retval;
> - }
> - hcd->usb_phy = phy;
> - hcd->remove_phy = 1;
> - }
> - }
> - 
>   if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
>  -hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
>  +hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
> - if (IS_ERR(hcd->phy_roothub)) {
> - retval = PTR_ERR(hcd->phy_roothub);
> - goto err_phy_roothub_alloc;
> - }
> + if (IS_ERR(hcd->phy_roothub))
> + return PTR_ERR(hcd->phy_roothub);
>   
>  +retval = usb_phy_roothub_init(hcd->phy_roothub);
>  +if (retval)
> - goto err_phy_roothub_alloc;
> ++return retval;
>  +
>   retval = usb_phy_roothub_power_on(hcd->phy_roothub);
>   if (retval)
>   goto err_usb_phy_roothub_power_on;

This is now a conflict between the battery tree (since it merged the
usb tree) and Linus' tree (since it merged the usb.current tree).

-- 
Cheers,
Stephen Rothwell


pgpylkKm1dsNZ.pgp
Description: OpenPGP digital signature

[PATCH] ethtool: fix a potential missing-check bug

[Wenwen Wang]

In ethtool_get_rxnfc(), the object "info" is firstly copied from
user-space. If the FLOW_RSS flag is set in the member field flow_type of
"info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
user-space because FLOW_RSS is newer and has new definition, as mentioned
in the comment. However, given that the user data resides in user-space, a
malicious user can race to change the data after the first copy. By doing
so, the user can inject inconsistent data. For example, in the second
copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
In the following execution, "info" will be used in the function
ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
information leakage since ops->get_rxnfc() will prepare various types of
data according to flow_type, and the prepared data will be eventually
copied to user-space. This inconsistent data may also cause undefined
behaviors based on how ops->get_rxnfc() is implemented.

This patch re-verifies the flow_type field of "info" after the second copy.
If the value is not as expected, an error code will be returned.

Signed-off-by: Wenwen Wang 
---
 net/core/ethtool.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 03416e6..a121034 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct 
net_device *dev,
info_size = sizeof(info);
if (copy_from_user(, useraddr, info_size))
return -EFAULT;
+   if (!(info.flow_type & FLOW_RSS))
+   return -EINVAL;
}
 
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
-- 
2.7.4

[PATCH] ethtool: fix a potential missing-check bug

[Wenwen Wang]

In ethtool_get_rxnfc(), the object "info" is firstly copied from
user-space. If the FLOW_RSS flag is set in the member field flow_type of
"info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
user-space because FLOW_RSS is newer and has new definition, as mentioned
in the comment. However, given that the user data resides in user-space, a
malicious user can race to change the data after the first copy. By doing
so, the user can inject inconsistent data. For example, in the second
copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
In the following execution, "info" will be used in the function
ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
information leakage since ops->get_rxnfc() will prepare various types of
data according to flow_type, and the prepared data will be eventually
copied to user-space. This inconsistent data may also cause undefined
behaviors based on how ops->get_rxnfc() is implemented.

This patch re-verifies the flow_type field of "info" after the second copy.
If the value is not as expected, an error code will be returned.

Signed-off-by: Wenwen Wang 
---
 net/core/ethtool.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 03416e6..a121034 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct 
net_device *dev,
info_size = sizeof(info);
if (copy_from_user(, useraddr, info_size))
return -EFAULT;
+   if (!(info.flow_type & FLOW_RSS))
+   return -EINVAL;
}
 
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
-- 
2.7.4

Re: [PATCH net-next 0/3] net: dsa: mv88e6xxx: remove Global 2 setup

[David Miller]

From: Vivien Didelot 
Date: Thu, 26 Apr 2018 21:56:43 -0400

> Parts of the mv88e6xxx driver still write arbitrary registers of
> different banks at setup time, which is misleading especially when
> supporting multiple device models.
> 
> This patchset moves two features setup into the top lovel
> mv88e6xxx_setup function and kills the old Global 2 register bank setup
> function. It brings no functional changes.

Series applied, thanks Vivien.

Re: [PATCH net-next 0/3] net: dsa: mv88e6xxx: remove Global 2 setup

[David Miller]

From: Vivien Didelot 
Date: Thu, 26 Apr 2018 21:56:43 -0400

> Parts of the mv88e6xxx driver still write arbitrary registers of
> different banks at setup time, which is misleading especially when
> supporting multiple device models.
> 
> This patchset moves two features setup into the top lovel
> mv88e6xxx_setup function and kills the old Global 2 register bank setup
> function. It brings no functional changes.

Series applied, thanks Vivien.

WARNING in md_ioctl

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
c61a56ababa404961fa769a2b24229f18e461961 (Sun Apr 29 17:06:05 2018 +)
Merge branch 'x86-urgent-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=1e46a0864c1a6e9bd3d8


C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5771999158730752
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6399853584187392
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6389218171420672
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=4617060493481910265

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e46a0864c1a6e9bd...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
md: md0 stopped.
md: md0 stopped.
WARNING: CPU: 1 PID: 4511 at drivers/md/md.c:7188 md_ioctl+0x3427/0x6360  
drivers/md/md.c:7188

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 4511 Comm: syz-executor107 Not tainted 4.17.0-rc2+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 panic+0x22f/0x4de kernel/panic.c:184
 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
 report_bug+0x252/0x2d0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:md_ioctl+0x3427/0x6360 drivers/md/md.c:7188
RSP: 0018:8801ad9b7400 EFLAGS: 00010293
RAX: 8801acf7a540 RBX: 0932 RCX: 8565f354
RDX:  RSI: 85661c37 RDI: 0007
RBP: 8801ad9b79c0 R08: 8801acf7a540 R09: ed0039894699
R10: 8801ad9b73f0 R11: 8801cc4a34cf R12: 0932
R13: 8801cc4a3328 R14: 8801ad9b7998 R15: 0001
 __blkdev_driver_ioctl block/ioctl.c:303 [inline]
 blkdev_ioctl+0x9b6/0x2020 block/ioctl.c:601
 block_ioctl+0xee/0x130 fs/block_dev.c:1877
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445a59
RSP: 002b:7f00dd147da8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 00445a59
RDX: 2080 RSI: 0932 RDI: 0003
RBP: 006dac3c R08: 7f00dd148700 R09: 
R10: 7f00dd148700 R11: 0246 R12: 006dac38
R13: 30646d2f7665642f R14: 7f00dd1489c0 R15: 0003
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

WARNING in md_ioctl

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
c61a56ababa404961fa769a2b24229f18e461961 (Sun Apr 29 17:06:05 2018 +)
Merge branch 'x86-urgent-for-linus' of  
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=1e46a0864c1a6e9bd3d8


C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5771999158730752
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=6399853584187392
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6389218171420672
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=4617060493481910265

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e46a0864c1a6e9bd...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
md: md0 stopped.
md: md0 stopped.
WARNING: CPU: 1 PID: 4511 at drivers/md/md.c:7188 md_ioctl+0x3427/0x6360  
drivers/md/md.c:7188

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 4511 Comm: syz-executor107 Not tainted 4.17.0-rc2+ #24
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 panic+0x22f/0x4de kernel/panic.c:184
 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
 report_bug+0x252/0x2d0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:md_ioctl+0x3427/0x6360 drivers/md/md.c:7188
RSP: 0018:8801ad9b7400 EFLAGS: 00010293
RAX: 8801acf7a540 RBX: 0932 RCX: 8565f354
RDX:  RSI: 85661c37 RDI: 0007
RBP: 8801ad9b79c0 R08: 8801acf7a540 R09: ed0039894699
R10: 8801ad9b73f0 R11: 8801cc4a34cf R12: 0932
R13: 8801cc4a3328 R14: 8801ad9b7998 R15: 0001
 __blkdev_driver_ioctl block/ioctl.c:303 [inline]
 blkdev_ioctl+0x9b6/0x2020 block/ioctl.c:601
 block_ioctl+0xee/0x130 fs/block_dev.c:1877
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 __do_sys_ioctl fs/ioctl.c:708 [inline]
 __se_sys_ioctl fs/ioctl.c:706 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445a59
RSP: 002b:7f00dd147da8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 00445a59
RDX: 2080 RSI: 0932 RDI: 0003
RBP: 006dac3c R08: 7f00dd148700 R09: 
R10: 7f00dd148700 R11: 0246 R12: 006dac38
R13: 30646d2f7665642f R14: 7f00dd1489c0 R15: 0003
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

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

[Stephen Rothwell]

Hi all,

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

  net/ipv4/ip_output.c

between commit:

  bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")

from the net-next tree and commit:

  cd027a5433d6 ("udp: enable UDP checksum offload for ESP")

from the ipsec-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc net/ipv4/ip_output.c
index f2338e40c37d,a2dfb5a9ba76..
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -909,8 -906,8 +909,8 @@@ static int __ip_append_data(struct soc
if (transhdrlen &&
length + fragheaderlen <= mtu &&
rt->dst.dev->features & (NETIF_F_HW_CSUM | NETIF_F_IP_CSUM) &&
 -  !(flags & MSG_MORE) &&
 +  (!(flags & MSG_MORE) || cork->gso_size) &&
-   !exthdrlen)
+   (!exthdrlen || (rt->dst.dev->features & NETIF_F_HW_ESP_TX_CSUM)))
csummode = CHECKSUM_PARTIAL;
  
cork->length += length;


pgpB0ugoU7JD2.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

  net/ipv4/ip_output.c

between commit:

  bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")

from the net-next tree and commit:

  cd027a5433d6 ("udp: enable UDP checksum offload for ESP")

from the ipsec-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc net/ipv4/ip_output.c
index f2338e40c37d,a2dfb5a9ba76..
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -909,8 -906,8 +909,8 @@@ static int __ip_append_data(struct soc
if (transhdrlen &&
length + fragheaderlen <= mtu &&
rt->dst.dev->features & (NETIF_F_HW_CSUM | NETIF_F_IP_CSUM) &&
 -  !(flags & MSG_MORE) &&
 +  (!(flags & MSG_MORE) || cork->gso_size) &&
-   !exthdrlen)
+   (!exthdrlen || (rt->dst.dev->features & NETIF_F_HW_ESP_TX_CSUM)))
csummode = CHECKSUM_PARTIAL;
  
cork->length += length;


pgpB0ugoU7JD2.pgp
Description: OpenPGP digital signature

Re: Linux messages full of `random: get_random_u32 called from`

[Laura Abbott]

On 04/29/2018 03:05 PM, Theodore Y. Ts'o wrote:

What would be useful is if people gave reports that listed exactly
what laptop and distributions they are using.  Just "a high spec x86
laptop" isn't terribly useful, because*my*  brand-new Dell XPS 13
running Debian testing is working just fine.  The year, model, make,
and CPU type plus what distribution (and distro version number) you
are running is useful, so I can assess how wide spread the unhappiness
is going to be, and what mitigation steps make sense.


I'm pretty sure Fedora is hitting this in our VMs. I just spent some
time debugging an issue of a boot delay with someone from the
infrastructure team where it would take upwards of 2 minutes to boot.
If someone holds down a key, it boots in 4 seconds. There's a qemu
reproducer at https://bugzilla.redhat.com/show_bug.cgi?id=1572916#c3
I suggested a cat on the keyboard as a workaround.

Independently, we also got a report of a boot hang in GCE with 4.16.4
where as 4.16.3 works which corresponds to the previous report of a
stable regression. This was just via IRC so I didn't have time to
dig into this.

Thanks,
Laura

Re: Linux messages full of `random: get_random_u32 called from`

[Laura Abbott]

On 04/29/2018 03:05 PM, Theodore Y. Ts'o wrote:

What would be useful is if people gave reports that listed exactly
what laptop and distributions they are using.  Just "a high spec x86
laptop" isn't terribly useful, because*my*  brand-new Dell XPS 13
running Debian testing is working just fine.  The year, model, make,
and CPU type plus what distribution (and distro version number) you
are running is useful, so I can assess how wide spread the unhappiness
is going to be, and what mitigation steps make sense.


I'm pretty sure Fedora is hitting this in our VMs. I just spent some
time debugging an issue of a boot delay with someone from the
infrastructure team where it would take upwards of 2 minutes to boot.
If someone holds down a key, it boots in 4 seconds. There's a qemu
reproducer at https://bugzilla.redhat.com/show_bug.cgi?id=1572916#c3
I suggested a cat on the keyboard as a workaround.

Independently, we also got a report of a boot hang in GCE with 4.16.4
where as 4.16.3 works which corresponds to the previous report of a
stable regression. This was just via IRC so I didn't have time to
dig into this.

Thanks,
Laura

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote:
>  > Why do we continue to print this stuff out when crng_init=1 though ?
> 
> answering my own question, I think.. This is a tristate, and we need it
> to be >1 to be quiet, which doesn't happen until..
> 
>  > [  165.806247] random: crng init done
> 
> this point.

Right.  What happens is that we divert the first 64 bits of entropy
credits directly into the crng state, without initializing the
input_pool.  So when we hit crng_init=1, the crng has only 64 bits of
entropy (conservatively speaking); furthermore, since we aren't doing
catastrophic reseeding, if something is continuously reading from
/dev/urandom or get_random_bytes() during that time, then the attacker
could be able to detremine which one of the 32 states the entropy pool
was when the entropy count was 5, and then 5 bits later, poll the
output of the pool again, and guess which of the 32 states the pool
was in, etc., and effectively keep up with the entropy as it trickles
in.

This is the reasoning behind catastrophic reseeding; we wait until we
have 128 bits of entropy in the input pool, and then we reseed the
pool all at once.

Why do we have the crng_init=1 state?  Because it provides some basic
protection for super-early users of the entropy pool.  It's
essentially a bandaid, and we could improve the time to get to fully
initialize by about 33% if we left the pool totally unititalized and
only focused on filling the input pool.  But given that on many
distributions, ssh still insists on initializing long-term public keys
at first boot from /dev/urandom, instead of *waiting* until the first
time someone attempts to ssh into box, or waiting until getrandom(2)
doesn't block --- without hanging the boot --- we have the crng_init=1
hack essentially as a palliative.

I view this as working around broken user space.  But userspace has
been broken for a long time, and users tend to blame the kernel, not
userspace

- Ted

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote:
>  > Why do we continue to print this stuff out when crng_init=1 though ?
> 
> answering my own question, I think.. This is a tristate, and we need it
> to be >1 to be quiet, which doesn't happen until..
> 
>  > [  165.806247] random: crng init done
> 
> this point.

Right.  What happens is that we divert the first 64 bits of entropy
credits directly into the crng state, without initializing the
input_pool.  So when we hit crng_init=1, the crng has only 64 bits of
entropy (conservatively speaking); furthermore, since we aren't doing
catastrophic reseeding, if something is continuously reading from
/dev/urandom or get_random_bytes() during that time, then the attacker
could be able to detremine which one of the 32 states the entropy pool
was when the entropy count was 5, and then 5 bits later, poll the
output of the pool again, and guess which of the 32 states the pool
was in, etc., and effectively keep up with the entropy as it trickles
in.

This is the reasoning behind catastrophic reseeding; we wait until we
have 128 bits of entropy in the input pool, and then we reseed the
pool all at once.

Why do we have the crng_init=1 state?  Because it provides some basic
protection for super-early users of the entropy pool.  It's
essentially a bandaid, and we could improve the time to get to fully
initialize by about 33% if we left the pool totally unititalized and
only focused on filling the input pool.  But given that on many
distributions, ssh still insists on initializing long-term public keys
at first boot from /dev/urandom, instead of *waiting* until the first
time someone attempts to ssh into box, or waiting until getrandom(2)
doesn't block --- without hanging the boot --- we have the crng_init=1
hack essentially as a palliative.

I view this as working around broken user space.  But userspace has
been broken for a long time, and users tend to blame the kernel, not
userspace

- Ted

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote:
> On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote:
> > > -   if ((fast_pool->count < 64) &&
> > > -   !time_after(now, fast_pool->last + HZ))
> > > -   return;
> > > -
> > 
> > I suspect you still want the rate-limiting in place. But if you _do_
> > want to cheat like this, you could instead just modify the condition
> > to only relax the rate limiting when !crng_init().
> 
> Good idea. Attached a new patch that's less intrusive. It still fixes my 
> issue,
> of course.

What your patch does is assume that there is a full bit of uncertainty
that can be obtained from the information gathered from each
interrupt.  I *might* be willing to assume that to be valid on x86
systems that have a high resolution cycle counter.  But on ARM
platforms, especially during system bootup when the user isn't typing
anything and SSD's and flash storage tend to have very predictable
timing patterns?  Not a bet I'd be willing to take.  Even with a cycle
counter, there's a reason why we assumed that we need to mix in timing
results from 64 interrupts or one second's worth before we would give
a single bit's worth of entropy credit.

- Ted

Re: Linux messages full of `random: get_random_u32 called from`

[Theodore Y. Ts'o]

On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote:
> On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote:
> > > -   if ((fast_pool->count < 64) &&
> > > -   !time_after(now, fast_pool->last + HZ))
> > > -   return;
> > > -
> > 
> > I suspect you still want the rate-limiting in place. But if you _do_
> > want to cheat like this, you could instead just modify the condition
> > to only relax the rate limiting when !crng_init().
> 
> Good idea. Attached a new patch that's less intrusive. It still fixes my 
> issue,
> of course.

What your patch does is assume that there is a full bit of uncertainty
that can be obtained from the information gathered from each
interrupt.  I *might* be willing to assume that to be valid on x86
systems that have a high resolution cycle counter.  But on ARM
platforms, especially during system bootup when the user isn't typing
anything and SSD's and flash storage tend to have very predictable
timing patterns?  Not a bet I'd be willing to take.  Even with a cycle
counter, there's a reason why we assumed that we need to mix in timing
results from 64 interrupts or one second's worth before we would give
a single bit's worth of entropy credit.

- Ted

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

[Stephen Rothwell]

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  9faedd643fd9 ("selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED")

from the net tree and commit:

  a160725780e3 ("selftests: udp gso")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/net/Makefile
index daf5effec3f0,df9102ec7b7a..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,12 -5,14 +5,15 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh 
rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
 -TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
++TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 +TEST_GEN_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
+ TEST_GEN_PROGS += udpgso udpgso_bench_tx udpgso_bench_rx
  
  include ../lib.mk
  


pgpQAJbgTlv5e.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi all,

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

  tools/testing/selftests/net/Makefile

between commit:

  9faedd643fd9 ("selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED")

from the net tree and commit:

  a160725780e3 ("selftests: udp gso")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/net/Makefile
index daf5effec3f0,df9102ec7b7a..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,12 -5,14 +5,15 @@@ CFLAGS =  -Wall -Wl,--no-as-needed -O2 
  CFLAGS += -I../../../../usr/include/
  
  TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh 
rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
 -TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
++TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
 +TEST_GEN_PROGS_EXTENDED := in_netns.sh
  TEST_GEN_FILES =  socket
  TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap
  TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
  TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
+ TEST_GEN_PROGS += udpgso udpgso_bench_tx udpgso_bench_rx
  
  include ../lib.mk
  


pgpQAJbgTlv5e.pgp
Description: OpenPGP digital signature

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote:
> On 29 April 2018 at 07:26, Greg Kroah-Hartman
>  wrote:
> > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> >> Due to some maintainers *preferring* BSD-compatible license for DTS
> >> files [0], I was writing mine using ISC. I had no very special reason
> >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> >> ISC as I read about its "removal of language deemed unnecessary".
> >>
> >> I took a moment to look at the new SPDX thing and noticed that:
> >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
> >
> > Yeah, bad example, we should fix that text up.  Care to send a patch? :)
> 
> Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
> which also doesn't exist.
> 
> As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
> these should be referenced.

See the patch set that Thomas has posted to hopefully resolve these
issues.  I think they are all now taken care of with that series.

> >> 2) License file LICENSES/other/ISC doesn't exist
> >> 3) ISC is listed as an *example* under the "Not recommended licenses"
> >
> > Yes, please don't use it if at all possible.
> >
> >> First of all, as ISC is used by some files in the Linux kernel, I
> >> think it's worth adding to the LICENSE/*/ISC.
> >
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> As said, I read about its "removal of language deemed unnecessary". I
> assumed that the simpler license text the better.

Simple up to a point, having loads of different licenses is a mess, as
you are finding out :)

> >> Secondly, it isn't 100% clear to me if ISC is preferred or not
> >> recommended. File license-rules.rst suggests the later by listing it
> >> as an example for "Not recommended". It's just an example though, so
> >> I'm not 100% sure without seeing it in either: "preferred" or "other"
> >> directories. Also if anyone finds it "Not recommended", can we get a
> >> short explanation why is it so, please?
> >
> > The license is functionally equalivant to BSD-2, so why would you want
> > to add more complexity here and have two licenses that are the same be
> > "recommended"?
> 
> I don't insist on it, I'm trying to figure out what's the best for the
> Linux community.
> 
> On the other hand I could ask why do we want more complexity by having
> MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
> the only minor differences are that:
> 1) MIT clearly allows sublicensing
> 2) BSD 2-Clause clearly requires distributing *binaries* with
> copyrights + license text

I think you will find more dual-licensed MIT code in the tree already
than ISC, right?

And really, in the end, the odds of someone taking this code _out_ of
the tree and using it only under a non-GPLv2 license is slim, to none,
so it's best to just stick with the common licenses, as long as they
match what you wish the code to abide by.  As you want to follow what
MIT says, then just use that and all should be good, right?

thanks,

greg k-h

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote:
> On 29 April 2018 at 07:26, Greg Kroah-Hartman
>  wrote:
> > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> >> Due to some maintainers *preferring* BSD-compatible license for DTS
> >> files [0], I was writing mine using ISC. I had no very special reason
> >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> >> ISC as I read about its "removal of language deemed unnecessary".
> >>
> >> I took a moment to look at the new SPDX thing and noticed that:
> >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example
> >
> > Yeah, bad example, we should fix that text up.  Care to send a patch? :)
> 
> Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib
> which also doesn't exist.
> 
> As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of
> these should be referenced.

See the patch set that Thomas has posted to hopefully resolve these
issues.  I think they are all now taken care of with that series.

> >> 2) License file LICENSES/other/ISC doesn't exist
> >> 3) ISC is listed as an *example* under the "Not recommended licenses"
> >
> > Yes, please don't use it if at all possible.
> >
> >> First of all, as ISC is used by some files in the Linux kernel, I
> >> think it's worth adding to the LICENSE/*/ISC.
> >
> > I see it is only used in a very small number of dts files.  Why not just
> > use BSD-2-Clause instead?  What do you find in ISC that is not available
> > to you with just BSD?
> 
> As said, I read about its "removal of language deemed unnecessary". I
> assumed that the simpler license text the better.

Simple up to a point, having loads of different licenses is a mess, as
you are finding out :)

> >> Secondly, it isn't 100% clear to me if ISC is preferred or not
> >> recommended. File license-rules.rst suggests the later by listing it
> >> as an example for "Not recommended". It's just an example though, so
> >> I'm not 100% sure without seeing it in either: "preferred" or "other"
> >> directories. Also if anyone finds it "Not recommended", can we get a
> >> short explanation why is it so, please?
> >
> > The license is functionally equalivant to BSD-2, so why would you want
> > to add more complexity here and have two licenses that are the same be
> > "recommended"?
> 
> I don't insist on it, I'm trying to figure out what's the best for the
> Linux community.
> 
> On the other hand I could ask why do we want more complexity by having
> MIT license. It's very similar to the BSD-2-Clause after all. AFAIK
> the only minor differences are that:
> 1) MIT clearly allows sublicensing
> 2) BSD 2-Clause clearly requires distributing *binaries* with
> copyrights + license text

I think you will find more dual-licensed MIT code in the tree already
than ISC, right?

And really, in the end, the odds of someone taking this code _out_ of
the tree and using it only under a non-GPLv2 license is slim, to none,
so it's best to just stick with the common licenses, as long as they
match what you wish the code to abide by.  As you want to follow what
MIT says, then just use that and all should be good, right?

thanks,

greg k-h