Re: [PATCH v2] drivers: Update drv260x driver

[Dmitry Torokhov]

Hi Jingkui,

On Fri, Dec 09, 2016 at 01:45:26PM -0800, Jingkui Wang wrote:
> Update driver drv260x to use generic device properties
> Remove platform data and corresponding header file

Please next time come up with more descriptive subject than "drivers:
Update drv260x driver": when scanning commit messages person shoudl be
able to gauge whether the change is interesting or not.

> -static int drv260x_parse_dt(struct device *dev,
> +static int drv260x_read_device_property(struct device *dev,
>   struct drv260x_data *haptics)
>  {
> - struct device_node *np = dev->of_node;
>   unsigned int voltage;
>   int error;
>  
> - error = of_property_read_u32(np, "mode", >mode);
> + error = device_property_read_u32(dev, "mode", >mode);
>   if (error) {
>   dev_err(dev, "%s: No entry for mode\n", __func__);
>   return error;
>   }
>  
> - error = of_property_read_u32(np, "library-sel", >library);
> + error = device_property_read_u32(dev, "library-sel", >library);
>   if (error) {
>   dev_err(dev, "%s: No entry for library selection\n",
>   __func__);
>   return error;
>   }

Now that platform code is gone there it makes no sense separating
reading properties from validating the settings. Does the following
version look OK to you (it needs a patch introducing temporary in
probe() function, you'll find it attached)?

Thanks.

-- 
Dmitry


Input: drv260x - use generic device properties

From: Jingkui Wang 

Update driver drv260x to use generic device properties so that it can be
used on non-DT systems. We also remove platform data as generic device
properties work on static board code as well.

Signed-off-by: Jingkui Wang 
Patchwork-Id: 9469075
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/drv260x.c|   80 ++-
 include/linux/platform_data/drv260x-pdata.h |   28 -
 2 files changed, 19 insertions(+), 89 deletions(-)
 delete mode 100644 include/linux/platform_data/drv260x-pdata.h

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 18c266c..11664d7 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -27,7 +25,6 @@
 #include 
 
 #include 
-#include 
 
 #define DRV260X_STATUS 0x0
 #define DRV260X_MODE   0x1
@@ -468,54 +465,12 @@ static const struct regmap_config drv260x_regmap_config = 
{
.cache_type = REGCACHE_NONE,
 };
 
-#ifdef CONFIG_OF
-static int drv260x_parse_dt(struct device *dev,
-   struct drv260x_data *haptics)
-{
-   struct device_node *np = dev->of_node;
-   unsigned int voltage;
-   int error;
-
-   error = of_property_read_u32(np, "mode", >mode);
-   if (error) {
-   dev_err(dev, "%s: No entry for mode\n", __func__);
-   return error;
-   }
-
-   error = of_property_read_u32(np, "library-sel", >library);
-   if (error) {
-   dev_err(dev, "%s: No entry for library selection\n",
-   __func__);
-   return error;
-   }
-
-   error = of_property_read_u32(np, "vib-rated-mv", );
-   if (!error)
-   haptics->rated_voltage = drv260x_calculate_voltage(voltage);
-
-
-   error = of_property_read_u32(np, "vib-overdrive-mv", );
-   if (!error)
-   haptics->overdrive_voltage = drv260x_calculate_voltage(voltage);
-
-   return 0;
-}
-#else
-static inline int drv260x_parse_dt(struct device *dev,
-  struct drv260x_data *haptics)
-{
-   dev_err(dev, "no platform data defined\n");
-
-   return -EINVAL;
-}
-#endif
-
 static int drv260x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   const struct drv260x_platform_data *pdata = 
dev_get_platdata(>dev);
struct device *dev = >dev;
struct drv260x_data *haptics;
+   u32 voltage;
int error;
 
haptics = devm_kzalloc(dev, sizeof(*haptics), GFP_KERNEL);
@@ -525,29 +480,24 @@ static int drv260x_probe(struct i2c_client *client,
haptics->overdrive_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
 
-   if (pdata) {
-   haptics->mode = pdata->mode;
-   haptics->library = pdata->library_selection;
-   if (pdata->vib_overdrive_voltage)
-   haptics->overdrive_voltage = 
drv260x_calculate_voltage(pdata->vib_overdrive_voltage);
-   if (pdata->vib_rated_voltage)
-   haptics->rated_voltage = 
drv260x_calculate_voltage(pdata->vib_rated_voltage);
-   } else if (client->dev.of_node) {
-   error = 

Re: [PATCH v2] drivers: Update drv260x driver

[Dmitry Torokhov]

Hi Jingkui,

On Fri, Dec 09, 2016 at 01:45:26PM -0800, Jingkui Wang wrote:
> Update driver drv260x to use generic device properties
> Remove platform data and corresponding header file

Please next time come up with more descriptive subject than "drivers:
Update drv260x driver": when scanning commit messages person shoudl be
able to gauge whether the change is interesting or not.

> -static int drv260x_parse_dt(struct device *dev,
> +static int drv260x_read_device_property(struct device *dev,
>   struct drv260x_data *haptics)
>  {
> - struct device_node *np = dev->of_node;
>   unsigned int voltage;
>   int error;
>  
> - error = of_property_read_u32(np, "mode", >mode);
> + error = device_property_read_u32(dev, "mode", >mode);
>   if (error) {
>   dev_err(dev, "%s: No entry for mode\n", __func__);
>   return error;
>   }
>  
> - error = of_property_read_u32(np, "library-sel", >library);
> + error = device_property_read_u32(dev, "library-sel", >library);
>   if (error) {
>   dev_err(dev, "%s: No entry for library selection\n",
>   __func__);
>   return error;
>   }

Now that platform code is gone there it makes no sense separating
reading properties from validating the settings. Does the following
version look OK to you (it needs a patch introducing temporary in
probe() function, you'll find it attached)?

Thanks.

-- 
Dmitry


Input: drv260x - use generic device properties

From: Jingkui Wang 

Update driver drv260x to use generic device properties so that it can be
used on non-DT systems. We also remove platform data as generic device
properties work on static board code as well.

Signed-off-by: Jingkui Wang 
Patchwork-Id: 9469075
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/drv260x.c|   80 ++-
 include/linux/platform_data/drv260x-pdata.h |   28 -
 2 files changed, 19 insertions(+), 89 deletions(-)
 delete mode 100644 include/linux/platform_data/drv260x-pdata.h

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 18c266c..11664d7 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -27,7 +25,6 @@
 #include 
 
 #include 
-#include 
 
 #define DRV260X_STATUS 0x0
 #define DRV260X_MODE   0x1
@@ -468,54 +465,12 @@ static const struct regmap_config drv260x_regmap_config = 
{
.cache_type = REGCACHE_NONE,
 };
 
-#ifdef CONFIG_OF
-static int drv260x_parse_dt(struct device *dev,
-   struct drv260x_data *haptics)
-{
-   struct device_node *np = dev->of_node;
-   unsigned int voltage;
-   int error;
-
-   error = of_property_read_u32(np, "mode", >mode);
-   if (error) {
-   dev_err(dev, "%s: No entry for mode\n", __func__);
-   return error;
-   }
-
-   error = of_property_read_u32(np, "library-sel", >library);
-   if (error) {
-   dev_err(dev, "%s: No entry for library selection\n",
-   __func__);
-   return error;
-   }
-
-   error = of_property_read_u32(np, "vib-rated-mv", );
-   if (!error)
-   haptics->rated_voltage = drv260x_calculate_voltage(voltage);
-
-
-   error = of_property_read_u32(np, "vib-overdrive-mv", );
-   if (!error)
-   haptics->overdrive_voltage = drv260x_calculate_voltage(voltage);
-
-   return 0;
-}
-#else
-static inline int drv260x_parse_dt(struct device *dev,
-  struct drv260x_data *haptics)
-{
-   dev_err(dev, "no platform data defined\n");
-
-   return -EINVAL;
-}
-#endif
-
 static int drv260x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   const struct drv260x_platform_data *pdata = 
dev_get_platdata(>dev);
struct device *dev = >dev;
struct drv260x_data *haptics;
+   u32 voltage;
int error;
 
haptics = devm_kzalloc(dev, sizeof(*haptics), GFP_KERNEL);
@@ -525,29 +480,24 @@ static int drv260x_probe(struct i2c_client *client,
haptics->overdrive_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
 
-   if (pdata) {
-   haptics->mode = pdata->mode;
-   haptics->library = pdata->library_selection;
-   if (pdata->vib_overdrive_voltage)
-   haptics->overdrive_voltage = 
drv260x_calculate_voltage(pdata->vib_overdrive_voltage);
-   if (pdata->vib_rated_voltage)
-   haptics->rated_voltage = 
drv260x_calculate_voltage(pdata->vib_rated_voltage);
-   } else if (client->dev.of_node) {
-   error = drv260x_parse_dt(>dev, haptics);
-   if (error)
-   

Re: Misalignment, MIPS, and ip_hdr(skb)->version

[Greg KH]

On Sat, Dec 10, 2016 at 11:18:14PM +0100, Dan Lüdtke wrote:
> 
> > On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor  wrote:
> > 
> > On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> >> Your custom protocol should be designed in a way you get an aligned ip
> >> header. Most protocols of the IETF follow this mantra and it is always
> >> possible to e.g. pad options so you end up on aligned boundaries for the
> >> next header.
> > 
> > fwiw, i'm not convinced that "most protocols of the IETF follow this
> > mantra".  we've had multiple discussions in different protocol groups
> > about shaving or bloating by a few bytes here or there in different
> > protocols, and i don't think anyone has brought up memory alignment as
> > an argument in any of the discussions i've followed.
> > 
> 
> If the trade-off is between 1 padding byte and 2 byte alignment versus
> 3 padding bytes and 4 byte alignment I would definitely opt for 3
> padding bytes. I know how that waste feels like to a protocol
> designer, but I think it is worth it. Maybe the padding/reserved will
> be useful some day for an additional feature.

Note, if you do do this (hint, I think it is a good idea), require that
these reserved/pad fields always set to 0 for now, so that no one puts
garbage in them and then if you later want to use them, it will be a
mess.

thanks,

greg k-h

Re: Misalignment, MIPS, and ip_hdr(skb)->version

[Greg KH]

On Sat, Dec 10, 2016 at 11:18:14PM +0100, Dan Lüdtke wrote:
> 
> > On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor  wrote:
> > 
> > On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> >> Your custom protocol should be designed in a way you get an aligned ip
> >> header. Most protocols of the IETF follow this mantra and it is always
> >> possible to e.g. pad options so you end up on aligned boundaries for the
> >> next header.
> > 
> > fwiw, i'm not convinced that "most protocols of the IETF follow this
> > mantra".  we've had multiple discussions in different protocol groups
> > about shaving or bloating by a few bytes here or there in different
> > protocols, and i don't think anyone has brought up memory alignment as
> > an argument in any of the discussions i've followed.
> > 
> 
> If the trade-off is between 1 padding byte and 2 byte alignment versus
> 3 padding bytes and 4 byte alignment I would definitely opt for 3
> padding bytes. I know how that waste feels like to a protocol
> designer, but I think it is worth it. Maybe the padding/reserved will
> be useful some day for an additional feature.

Note, if you do do this (hint, I think it is a good idea), require that
these reserved/pad fields always set to 0 for now, so that no one puts
garbage in them and then if you later want to use them, it will be a
mess.

thanks,

greg k-h

Re: [PATCH] Revert "tty: serial: 8250: add CON_CONSDEV to flags"

[Greg Kroah-Hartman]

On Sun, Dec 11, 2016 at 10:05:49AM +0800, Herbert Xu wrote:
> This commit needs to be reverted because it prevents people from
> using the serial console as a secondary console with input being
> directed to tty0.
> 
> IOW, if you boot with console=ttyS0 console=tty0 then all kernels
> prior to this commit will produce output on both ttyS0 and tty0
> but input will only be taken from tty0.  With this patch the serial
> console will always be the primary console instead of tty0,
> potentially preventing people from getting into their machines in
> emergency situations.
> 
> Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
> Signed-off-by: Herbert Xu 
> 
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 240a361..e8819aa 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -675,7 +675,7 @@ static int univ8250_console_match(struct console *co, 
> char *name, int idx,
>   .device = uart_console_device,
>   .setup  = univ8250_console_setup,
>   .match  = univ8250_console_match,
> - .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
> + .flags  = CON_PRINTBUFFER | CON_ANYTIME,
>   .index  = -1,
>   .data   = _reg,
>  };

Ok, this is the second time this has been reported.  Matthew seems to be
ignoring my email about this, so I guess I'll just revert the patch, as
it's obviously causing problems...

thanks,

greg k-h

Re: [PATCH] Revert "tty: serial: 8250: add CON_CONSDEV to flags"

[Greg Kroah-Hartman]

On Sun, Dec 11, 2016 at 10:05:49AM +0800, Herbert Xu wrote:
> This commit needs to be reverted because it prevents people from
> using the serial console as a secondary console with input being
> directed to tty0.
> 
> IOW, if you boot with console=ttyS0 console=tty0 then all kernels
> prior to this commit will produce output on both ttyS0 and tty0
> but input will only be taken from tty0.  With this patch the serial
> console will always be the primary console instead of tty0,
> potentially preventing people from getting into their machines in
> emergency situations.
> 
> Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
> Signed-off-by: Herbert Xu 
> 
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 240a361..e8819aa 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -675,7 +675,7 @@ static int univ8250_console_match(struct console *co, 
> char *name, int idx,
>   .device = uart_console_device,
>   .setup  = univ8250_console_setup,
>   .match  = univ8250_console_match,
> - .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
> + .flags  = CON_PRINTBUFFER | CON_ANYTIME,
>   .index  = -1,
>   .data   = _reg,
>  };

Ok, this is the second time this has been reported.  Matthew seems to be
ignoring my email about this, so I guess I'll just revert the patch, as
it's obviously causing problems...

thanks,

greg k-h

Re: [PATCH v2 2/2] USB: OHCI: pxa27x:fix code warnig and errors

[Greg Kroah-Hartman]

On Sat, Dec 10, 2016 at 11:08:45PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl following errors:
> WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ...
> then dev_err(dev, ... then pr_err(...  to printk(KERN_ERR ...
> ERROR: space prohibited after that open parenthesis '('
> ERROR: space prohibited before that close parenthesis ')'
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> changelog V1->V2:
> Have fixed the printk warning.
>  drivers/usb/host/ohci-pxa27x.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index c73e1ae..350e384 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -138,12 +138,15 @@ struct pxa27x_ohci {
>   * PMM_PERPORT_MODE -- PMM per port switching mode
>   * Ports are powered individually.
>   */
> -static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci, int mode)
> +static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci,
> + struct device *dev)

Eeek, no!

Stop and look at what you did here.  Why would you want to include 2
struct device pointers in a function, when they really point to the same
thing?  That makes no sense at all.

I appreciate general code cleanups, but please, get some experience in C
and how the kernel handles the driver model before trying to make
changes like this.  You can't just blindly make coding style changes and
expect them to be correct without that knowledge.

If you want to make coding style fixes, please practice on the
drivers/staging/ area.  The maintainer of that code is much more
forgiving and not grumpy when stuff like this happens...

thanks,

greg k-h

Re: [PATCH v2 2/2] USB: OHCI: pxa27x:fix code warnig and errors

[Greg Kroah-Hartman]

On Sat, Dec 10, 2016 at 11:08:45PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl following errors:
> WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ...
> then dev_err(dev, ... then pr_err(...  to printk(KERN_ERR ...
> ERROR: space prohibited after that open parenthesis '('
> ERROR: space prohibited before that close parenthesis ')'
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> changelog V1->V2:
> Have fixed the printk warning.
>  drivers/usb/host/ohci-pxa27x.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index c73e1ae..350e384 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -138,12 +138,15 @@ struct pxa27x_ohci {
>   * PMM_PERPORT_MODE -- PMM per port switching mode
>   * Ports are powered individually.
>   */
> -static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci, int mode)
> +static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci,
> + struct device *dev)

Eeek, no!

Stop and look at what you did here.  Why would you want to include 2
struct device pointers in a function, when they really point to the same
thing?  That makes no sense at all.

I appreciate general code cleanups, but please, get some experience in C
and how the kernel handles the driver model before trying to make
changes like this.  You can't just blindly make coding style changes and
expect them to be correct without that knowledge.

If you want to make coding style fixes, please practice on the
drivers/staging/ area.  The maintainer of that code is much more
forgiving and not grumpy when stuff like this happens...

thanks,

greg k-h

Re: [PATCH v2 1/2] USB: OHCI: pxa27x:fix code warnings

[Greg Kroah-Hartman]

On Sat, Dec 10, 2016 at 11:08:44PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl following warning:
> WARNING: Block comments use * on subsequent lines
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> changelog V1->V2:
> no changes.

That's foolish, you should have made changes, because your subject is
still totally wrong, as I pointed out before on your other patches...

greg k-h

Re: [PATCH v2 1/2] USB: OHCI: pxa27x:fix code warnings

[Greg Kroah-Hartman]

On Sat, Dec 10, 2016 at 11:08:44PM +, csmanjuvi...@gmail.com wrote:
> From: Manjunath Goudar 
> 
> This patch will fix the checkpatch.pl following warning:
> WARNING: Block comments use * on subsequent lines
> 
> Signed-off-by: Manjunath Goudar 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> changelog V1->V2:
> no changes.

That's foolish, you should have made changes, because your subject is
still totally wrong, as I pointed out before on your other patches...

greg k-h

[PATCH] Input: drv260x - fix initializing overdrive voltage

[Dmitry Torokhov]

We were accidentally initializing haptics->rated_voltage twice, and did not
initialize overdrive voltage.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/drv260x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 2adfd86c..9789d4f 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -521,7 +521,7 @@ static int drv260x_probe(struct i2c_client *client,
if (!haptics)
return -ENOMEM;
 
-   haptics->rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
+   haptics->overdrive_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
 
if (pdata) {
-- 
2.8.0.rc3.226.g39d4020


-- 
Dmitry

[PATCH] Input: drv260x - fix initializing overdrive voltage

[Dmitry Torokhov]

We were accidentally initializing haptics->rated_voltage twice, and did not
initialize overdrive voltage.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/drv260x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 2adfd86c..9789d4f 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -521,7 +521,7 @@ static int drv260x_probe(struct i2c_client *client,
if (!haptics)
return -ENOMEM;
 
-   haptics->rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
+   haptics->overdrive_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
 
if (pdata) {
-- 
2.8.0.rc3.226.g39d4020


-- 
Dmitry

kvm: use-after-free in process_srcu

[Dmitry Vyukov]

Hello,

I am getting the following use-after-free reports while running
syzkaller fuzzer.
On commit 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7).
Unfortunately it is not reproducible, but all reports look sane and
very similar, so I would assume that it is some hard to trigger race.
In all cases the use-after-free offset within struct kvm is 344 bytes.
This points to srcu field, which starts at 208 with size 360 (I have
some debug configs enabled).


BUG: KASAN: use-after-free in process_srcu+0x27a/0x280 at addr 88005e29a418
Read of size 8 by task kworker/3:1/1496
CPU: 3 PID: 1496 Comm: kworker/3:1 Not tainted 4.9.0-rc8+ #78
Hardware name: Google Google/Google, BIOS Google 01/01/2011
Workqueue: events_power_efficient process_srcu
 88006b1df3a0 8348fb59 0003 11000d63be07
 ed000d63bdff 41b58ab3 8957cf20 8348f86b
 8800668dc440 8816c000 11000d63be18 dc00
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:163
 [< inline >] print_address_description mm/kasan/report.c:201
 [< inline >] kasan_report_error mm/kasan/report.c:285
 [] kasan_report+0x1a1/0x440 mm/kasan/report.c:305
 [] __asan_report_load8_noabort+0x19/0x20
mm/kasan/report.c:331
 [< inline >] rcu_batch_empty kernel/rcu/srcu.c:64
 [< inline >] rcu_batch_dequeue kernel/rcu/srcu.c:75
 [< inline >] srcu_invoke_callbacks kernel/rcu/srcu.c:624
 [] process_srcu+0x27a/0x280 kernel/rcu/srcu.c:672
 [] process_one_work+0xb40/0x1ba0 kernel/workqueue.c:2096
 [] worker_thread+0x214/0x18a0 kernel/workqueue.c:2230
 [] kthread+0x328/0x3e0 kernel/kthread.c:209
 [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
Object at 88005e29a2c0, in cache kmalloc-16384 size: 16384
Allocated:
PID = 13066
 [  376.024345] [] save_stack_trace+0x1b/0x20
arch/x86/kernel/stacktrace.c:57
 [  376.024345] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  376.024345] [< inline >] set_track mm/kasan/kasan.c:507
 [  376.024345] [] kasan_kmalloc+0xad/0xe0
mm/kasan/kasan.c:598
 [  376.024345] []
kmem_cache_alloc_trace+0x12c/0x710 mm/slab.c:3635
 [  376.024345] [< inline >] kvm_arch_alloc_vm include/linux/slab.h:490
 [  376.024345] [< inline >] kvm_create_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:610
 [  376.024345] [< inline >] kvm_dev_ioctl_create_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:3164
 [  376.024345] [] kvm_dev_ioctl+0x1b5/0x1100
arch/x86/kvm/../../../virt/kvm/kvm_main.c:3208
 [  376.024345] [< inline >] vfs_ioctl fs/ioctl.c:43
 [  376.024345] [] do_vfs_ioctl+0x1c4/0x1630 fs/ioctl.c:679
 [  376.024345] [< inline >] SYSC_ioctl fs/ioctl.c:694
 [  376.024345] [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685
 [  376.024345] [] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 13064
 [  376.024345] [] save_stack_trace+0x1b/0x20
arch/x86/kernel/stacktrace.c:57
 [  376.024345] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  376.024345] [< inline >] set_track mm/kasan/kasan.c:507
 [  376.024345] [] kasan_slab_free+0x72/0xc0
mm/kasan/kasan.c:571
 [  376.024345] [< inline >] __cache_free mm/slab.c:3511
 [  376.024345] [] kfree+0xc8/0x2a0 mm/slab.c:3828
 [  376.024345] [< inline >] kvm_arch_free_vm
include/linux/kvm_host.h:774
 [  376.024345] [< inline >] kvm_destroy_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:739
 [  376.024345] [] kvm_put_kvm+0x489/0x5f0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:754
 [  376.024345] [] kvm_vm_release+0x47/0x60
arch/x86/kvm/../../../virt/kvm/kvm_main.c:765
 [  376.024345] [] __fput+0x34e/0x910 fs/file_table.c:208
 [  376.024345] [] fput+0x1a/0x20 fs/file_table.c:244
 [  376.024345] [] task_work_run+0x1a0/0x280
kernel/task_work.c:116
 [  376.024345] [< inline >] exit_task_work include/linux/task_work.h:21
 [  376.024345] [] do_exit+0x1842/0x2650 kernel/exit.c:828
 [  376.024345] [] do_group_exit+0x14e/0x420 kernel/exit.c:932
 [  376.024345] [] get_signal+0x663/0x1880
kernel/signal.c:2307
 [  376.024345] [] do_signal+0xc5/0x2190
arch/x86/kernel/signal.c:807
 [  376.024345] [] exit_to_usermode_loop+0x1ea/0x2d0
arch/x86/entry/common.c:156
 [  376.024345] [< inline >] prepare_exit_to_usermode
arch/x86/entry/common.c:190
 [  376.024345] []
syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259
 [  376.024345] [] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
 88005e29a300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88005e29a380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>88005e29a400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
 88005e29a480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88005e29a500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==

kvm: use-after-free in process_srcu

[Dmitry Vyukov]

Hello,

I am getting the following use-after-free reports while running
syzkaller fuzzer.
On commit 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7).
Unfortunately it is not reproducible, but all reports look sane and
very similar, so I would assume that it is some hard to trigger race.
In all cases the use-after-free offset within struct kvm is 344 bytes.
This points to srcu field, which starts at 208 with size 360 (I have
some debug configs enabled).


BUG: KASAN: use-after-free in process_srcu+0x27a/0x280 at addr 88005e29a418
Read of size 8 by task kworker/3:1/1496
CPU: 3 PID: 1496 Comm: kworker/3:1 Not tainted 4.9.0-rc8+ #78
Hardware name: Google Google/Google, BIOS Google 01/01/2011
Workqueue: events_power_efficient process_srcu
 88006b1df3a0 8348fb59 0003 11000d63be07
 ed000d63bdff 41b58ab3 8957cf20 8348f86b
 8800668dc440 8816c000 11000d63be18 dc00
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:163
 [< inline >] print_address_description mm/kasan/report.c:201
 [< inline >] kasan_report_error mm/kasan/report.c:285
 [] kasan_report+0x1a1/0x440 mm/kasan/report.c:305
 [] __asan_report_load8_noabort+0x19/0x20
mm/kasan/report.c:331
 [< inline >] rcu_batch_empty kernel/rcu/srcu.c:64
 [< inline >] rcu_batch_dequeue kernel/rcu/srcu.c:75
 [< inline >] srcu_invoke_callbacks kernel/rcu/srcu.c:624
 [] process_srcu+0x27a/0x280 kernel/rcu/srcu.c:672
 [] process_one_work+0xb40/0x1ba0 kernel/workqueue.c:2096
 [] worker_thread+0x214/0x18a0 kernel/workqueue.c:2230
 [] kthread+0x328/0x3e0 kernel/kthread.c:209
 [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
Object at 88005e29a2c0, in cache kmalloc-16384 size: 16384
Allocated:
PID = 13066
 [  376.024345] [] save_stack_trace+0x1b/0x20
arch/x86/kernel/stacktrace.c:57
 [  376.024345] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  376.024345] [< inline >] set_track mm/kasan/kasan.c:507
 [  376.024345] [] kasan_kmalloc+0xad/0xe0
mm/kasan/kasan.c:598
 [  376.024345] []
kmem_cache_alloc_trace+0x12c/0x710 mm/slab.c:3635
 [  376.024345] [< inline >] kvm_arch_alloc_vm include/linux/slab.h:490
 [  376.024345] [< inline >] kvm_create_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:610
 [  376.024345] [< inline >] kvm_dev_ioctl_create_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:3164
 [  376.024345] [] kvm_dev_ioctl+0x1b5/0x1100
arch/x86/kvm/../../../virt/kvm/kvm_main.c:3208
 [  376.024345] [< inline >] vfs_ioctl fs/ioctl.c:43
 [  376.024345] [] do_vfs_ioctl+0x1c4/0x1630 fs/ioctl.c:679
 [  376.024345] [< inline >] SYSC_ioctl fs/ioctl.c:694
 [  376.024345] [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685
 [  376.024345] [] entry_SYSCALL_64_fastpath+0x23/0xc6
Freed:
PID = 13064
 [  376.024345] [] save_stack_trace+0x1b/0x20
arch/x86/kernel/stacktrace.c:57
 [  376.024345] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
 [  376.024345] [< inline >] set_track mm/kasan/kasan.c:507
 [  376.024345] [] kasan_slab_free+0x72/0xc0
mm/kasan/kasan.c:571
 [  376.024345] [< inline >] __cache_free mm/slab.c:3511
 [  376.024345] [] kfree+0xc8/0x2a0 mm/slab.c:3828
 [  376.024345] [< inline >] kvm_arch_free_vm
include/linux/kvm_host.h:774
 [  376.024345] [< inline >] kvm_destroy_vm
arch/x86/kvm/../../../virt/kvm/kvm_main.c:739
 [  376.024345] [] kvm_put_kvm+0x489/0x5f0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:754
 [  376.024345] [] kvm_vm_release+0x47/0x60
arch/x86/kvm/../../../virt/kvm/kvm_main.c:765
 [  376.024345] [] __fput+0x34e/0x910 fs/file_table.c:208
 [  376.024345] [] fput+0x1a/0x20 fs/file_table.c:244
 [  376.024345] [] task_work_run+0x1a0/0x280
kernel/task_work.c:116
 [  376.024345] [< inline >] exit_task_work include/linux/task_work.h:21
 [  376.024345] [] do_exit+0x1842/0x2650 kernel/exit.c:828
 [  376.024345] [] do_group_exit+0x14e/0x420 kernel/exit.c:932
 [  376.024345] [] get_signal+0x663/0x1880
kernel/signal.c:2307
 [  376.024345] [] do_signal+0xc5/0x2190
arch/x86/kernel/signal.c:807
 [  376.024345] [] exit_to_usermode_loop+0x1ea/0x2d0
arch/x86/entry/common.c:156
 [  376.024345] [< inline >] prepare_exit_to_usermode
arch/x86/entry/common.c:190
 [  376.024345] []
syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259
 [  376.024345] [] entry_SYSCALL_64_fastpath+0xc4/0xc6
Memory state around the buggy address:
 88005e29a300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88005e29a380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>88005e29a400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
 88005e29a480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 88005e29a500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==

[PATCH 7/8] dax: add / remove dax devices after provisioning

[Dan Williams]

Create a new device-dax seed when incrementing the size of the existing
seed from zero.

Destroy a device-dax instance when its size changes from non-zero to
zero.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  195 +++--
 1 file changed, 128 insertions(+), 67 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 9b641c079e52..b130eff91b83 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,7 @@ static struct vfsmount *dax_mnt;
 static struct kmem_cache *dax_cache __read_mostly;
 static struct super_block *dax_superblock __read_mostly;
 MODULE_PARM_DESC(nr_dax, "max number of device-dax instances");
+static ASYNC_DOMAIN_EXCLUSIVE(dax_dev_async);
 
 /**
  * struct dax_region - mapping infrastructure for dax devices
@@ -329,6 +331,7 @@ static void dax_region_free(struct kref *kref)
"%s: child count not zero\n",
dev_name(dax_region->dev));
kfree(dax_region);
+   module_put(THIS_MODULE);
 }
 
 void dax_region_put(struct dax_region *dax_region)
@@ -377,15 +380,22 @@ struct dax_region *alloc_dax_region(struct device 
*parent, int region_id,
dax_region->align = align;
dax_region->dev = parent;
dax_region->base = addr;
-   if (sysfs_create_groups(>kobj, dax_region_attribute_groups)) {
-   kfree(dax_region);
-   return NULL;;
-   }
+   if (!try_module_get(THIS_MODULE))
+   goto err_module;
+
+   if (sysfs_create_groups(>kobj, dax_region_attribute_groups))
+   goto err_groups;
 
kref_get(_region->kref);
if (devm_add_action_or_reset(parent, dax_region_unregister, dax_region))
return NULL;
return dax_region;
+
+err_groups:
+   module_put(THIS_MODULE);
+err_module:
+   kfree(dax_region);
+   return NULL;
 }
 EXPORT_SYMBOL_GPL(alloc_dax_region);
 
@@ -402,6 +412,9 @@ static unsigned long long dax_dev_size(struct dax_dev 
*dax_dev)
 
WARN_ON_ONCE(!mutex_is_locked(_region->lock));
 
+   if (!dax_dev->alive)
+   return 0;
+
for (i = 0; i < dax_dev->num_resources; i++)
size += resource_size(dax_dev->res[i]);
 
@@ -415,6 +428,9 @@ static ssize_t size_show(struct device *dev,
struct dax_dev *dax_dev = to_dax_dev(dev);
struct dax_region *dax_region = dax_dev->region;
 
+   /* flush previous size operations */
+   async_synchronize_full_domain(_dev_async);
+
mutex_lock(_region->lock);
size = dax_dev_size(dax_dev);
mutex_unlock(_region->lock);
@@ -494,6 +510,89 @@ static int dax_dev_adjust_resource(struct dax_dev *dax_dev,
return rc;
 }
 
+static void clear_dax_dev_radix(struct dax_dev *dax_dev)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   struct radix_tree_iter iter;
+   void **slot;
+
+   rcu_read_lock();
+   radix_tree_for_each_slot(slot, >page_tree, , 0) {
+   struct resource *res;
+   unsigned long pgoff;
+   unsigned order;
+
+   res = radix_tree_deref_slot(slot);
+   if (unlikely(!res))
+   continue;
+   if (radix_tree_deref_retry(res)) {
+   slot = radix_tree_iter_retry();
+   continue;
+   }
+
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+   }
+   rcu_read_unlock();
+
+   synchronize_rcu();
+}
+
+static void unregister_dax_dev(void *dev)
+{
+   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
+   struct cdev *cdev = _dev->cdev;
+   int i;
+
+   dev_dbg(dev, "%s\n", __func__);
+
+   /*
+* Note, rcu is not protecting the liveness of dax_dev, rcu is
+* ensuring that any fault handlers that might have seen
+* dax_dev->alive == true, have completed.  Any fault handlers
+* that start after synchronize_rcu() has started will abort
+* upon seeing dax_dev->alive == false.
+*/
+   dax_dev->alive = false;
+   synchronize_rcu();
+   unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
+
+   mutex_lock(_region->lock);
+   clear_dax_dev_radix(dax_dev);
+   for (i = 0; i < dax_dev->num_resources; i++)
+   __release_region(_region->res, dax_dev->res[i]->start,
+   resource_size(dax_dev->res[i]));
+   if (dax_region->seed == dev)
+   dax_region->seed = NULL;
+   mutex_unlock(_region->lock);
+   atomic_dec(_region->child_count);
+
+   cdev_del(cdev);
+   device_unregister(dev);
+}
+
+static 

[PATCH 3/8] dax: register seed device

[Dan Williams]

Towards adding support for sub-dividing device-dax regions, add a seed
device.  Similar to libnvdimm a 'seed' device is un-configured device
that is enabled after setting configuration parameters.  After a given
seed device is enabled another is created and this process repeats until
no more seed devices can be activated due to dax_available_size being
exhausted.

For now, this simply registers a seed instance after the first dax
device instance is established.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index da2962b6f8de..c9ba011e333b 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -40,8 +40,10 @@ MODULE_PARM_DESC(nr_dax, "max number of device-dax 
instances");
  * @kref: to pin while other agents have a need to do lookups
  * @lock: synchronize changes / consistent-access to the resource tree (@res)
  * @dev: parent device backing this region
+ * @seed: next device for dynamic allocation / configuration
  * @align: allocation and mapping alignment for child dax devices
  * @res: physical address range of the region
+ * @child_count: number of registered dax device instances
  * @pfn_flags: identify whether the pfns are paged back or not
  */
 struct dax_region {
@@ -51,8 +53,10 @@ struct dax_region {
struct kref kref;
struct mutex lock;
struct device *dev;
+   struct device *seed;
unsigned int align;
struct resource res;
+   atomic_t child_count;
unsigned long pfn_flags;
 };
 
@@ -161,10 +165,31 @@ static ssize_t align_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(align);
 
+static ssize_t seed_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region) {
+   mutex_lock(_region->lock);
+   if (dax_region->seed)
+   rc = sprintf(buf, "%s\n", dev_name(dax_region->seed));
+   mutex_unlock(_region->lock);
+   }
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(seed);
+
 static struct attribute *dax_region_attributes[] = {
_attr_available_size.attr,
_attr_region_size.attr,
_attr_align.attr,
+   _attr_seed.attr,
_attr_id.attr,
NULL,
 };
@@ -295,6 +320,9 @@ static void dax_region_free(struct kref *kref)
struct dax_region *dax_region;
 
dax_region = container_of(kref, struct dax_region, kref);
+   WARN(atomic_read(_region->child_count),
+   "%s: child count not zero\n",
+   dev_name(dax_region->dev));
kfree(dax_region);
 }
 
@@ -691,7 +719,10 @@ static void unregister_dax_dev(void *dev)
for (i = 0; i < dax_dev->num_resources; i++)
__release_region(_region->res, dax_dev->res[i]->start,
resource_size(dax_dev->res[i]));
+   if (dax_region->seed == dev)
+   dax_region->seed = NULL;
mutex_unlock(_region->lock);
+   atomic_dec(_region->child_count);
 
cdev_del(cdev);
device_unregister(dev);
@@ -796,6 +827,16 @@ struct dax_dev *devm_create_dax_dev(struct dax_region 
*dax_region,
if (rc)
return ERR_PTR(rc);
 
+   if (atomic_inc_return(_region->child_count) == 1) {
+   struct dax_dev *seed;
+
+   seed = devm_create_dax_dev(dax_region, NULL, 0);
+   if (IS_ERR(seed))
+   dev_warn(parent, "failed to create region seed\n");
+   else
+   dax_region->seed = >dev;
+   }
+
return dax_dev;
 
  err_cdev:

[PATCH 7/8] dax: add / remove dax devices after provisioning

[Dan Williams]

Create a new device-dax seed when incrementing the size of the existing
seed from zero.

Destroy a device-dax instance when its size changes from non-zero to
zero.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  195 +++--
 1 file changed, 128 insertions(+), 67 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 9b641c079e52..b130eff91b83 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,7 @@ static struct vfsmount *dax_mnt;
 static struct kmem_cache *dax_cache __read_mostly;
 static struct super_block *dax_superblock __read_mostly;
 MODULE_PARM_DESC(nr_dax, "max number of device-dax instances");
+static ASYNC_DOMAIN_EXCLUSIVE(dax_dev_async);
 
 /**
  * struct dax_region - mapping infrastructure for dax devices
@@ -329,6 +331,7 @@ static void dax_region_free(struct kref *kref)
"%s: child count not zero\n",
dev_name(dax_region->dev));
kfree(dax_region);
+   module_put(THIS_MODULE);
 }
 
 void dax_region_put(struct dax_region *dax_region)
@@ -377,15 +380,22 @@ struct dax_region *alloc_dax_region(struct device 
*parent, int region_id,
dax_region->align = align;
dax_region->dev = parent;
dax_region->base = addr;
-   if (sysfs_create_groups(>kobj, dax_region_attribute_groups)) {
-   kfree(dax_region);
-   return NULL;;
-   }
+   if (!try_module_get(THIS_MODULE))
+   goto err_module;
+
+   if (sysfs_create_groups(>kobj, dax_region_attribute_groups))
+   goto err_groups;
 
kref_get(_region->kref);
if (devm_add_action_or_reset(parent, dax_region_unregister, dax_region))
return NULL;
return dax_region;
+
+err_groups:
+   module_put(THIS_MODULE);
+err_module:
+   kfree(dax_region);
+   return NULL;
 }
 EXPORT_SYMBOL_GPL(alloc_dax_region);
 
@@ -402,6 +412,9 @@ static unsigned long long dax_dev_size(struct dax_dev 
*dax_dev)
 
WARN_ON_ONCE(!mutex_is_locked(_region->lock));
 
+   if (!dax_dev->alive)
+   return 0;
+
for (i = 0; i < dax_dev->num_resources; i++)
size += resource_size(dax_dev->res[i]);
 
@@ -415,6 +428,9 @@ static ssize_t size_show(struct device *dev,
struct dax_dev *dax_dev = to_dax_dev(dev);
struct dax_region *dax_region = dax_dev->region;
 
+   /* flush previous size operations */
+   async_synchronize_full_domain(_dev_async);
+
mutex_lock(_region->lock);
size = dax_dev_size(dax_dev);
mutex_unlock(_region->lock);
@@ -494,6 +510,89 @@ static int dax_dev_adjust_resource(struct dax_dev *dax_dev,
return rc;
 }
 
+static void clear_dax_dev_radix(struct dax_dev *dax_dev)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   struct radix_tree_iter iter;
+   void **slot;
+
+   rcu_read_lock();
+   radix_tree_for_each_slot(slot, >page_tree, , 0) {
+   struct resource *res;
+   unsigned long pgoff;
+   unsigned order;
+
+   res = radix_tree_deref_slot(slot);
+   if (unlikely(!res))
+   continue;
+   if (radix_tree_deref_retry(res)) {
+   slot = radix_tree_iter_retry();
+   continue;
+   }
+
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+   }
+   rcu_read_unlock();
+
+   synchronize_rcu();
+}
+
+static void unregister_dax_dev(void *dev)
+{
+   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
+   struct cdev *cdev = _dev->cdev;
+   int i;
+
+   dev_dbg(dev, "%s\n", __func__);
+
+   /*
+* Note, rcu is not protecting the liveness of dax_dev, rcu is
+* ensuring that any fault handlers that might have seen
+* dax_dev->alive == true, have completed.  Any fault handlers
+* that start after synchronize_rcu() has started will abort
+* upon seeing dax_dev->alive == false.
+*/
+   dax_dev->alive = false;
+   synchronize_rcu();
+   unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
+
+   mutex_lock(_region->lock);
+   clear_dax_dev_radix(dax_dev);
+   for (i = 0; i < dax_dev->num_resources; i++)
+   __release_region(_region->res, dax_dev->res[i]->start,
+   resource_size(dax_dev->res[i]));
+   if (dax_region->seed == dev)
+   dax_region->seed = NULL;
+   mutex_unlock(_region->lock);
+   atomic_dec(_region->child_count);
+
+   cdev_del(cdev);
+   device_unregister(dev);
+}
+
+static void 

[PATCH 3/8] dax: register seed device

[Dan Williams]

Towards adding support for sub-dividing device-dax regions, add a seed
device.  Similar to libnvdimm a 'seed' device is un-configured device
that is enabled after setting configuration parameters.  After a given
seed device is enabled another is created and this process repeats until
no more seed devices can be activated due to dax_available_size being
exhausted.

For now, this simply registers a seed instance after the first dax
device instance is established.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index da2962b6f8de..c9ba011e333b 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -40,8 +40,10 @@ MODULE_PARM_DESC(nr_dax, "max number of device-dax 
instances");
  * @kref: to pin while other agents have a need to do lookups
  * @lock: synchronize changes / consistent-access to the resource tree (@res)
  * @dev: parent device backing this region
+ * @seed: next device for dynamic allocation / configuration
  * @align: allocation and mapping alignment for child dax devices
  * @res: physical address range of the region
+ * @child_count: number of registered dax device instances
  * @pfn_flags: identify whether the pfns are paged back or not
  */
 struct dax_region {
@@ -51,8 +53,10 @@ struct dax_region {
struct kref kref;
struct mutex lock;
struct device *dev;
+   struct device *seed;
unsigned int align;
struct resource res;
+   atomic_t child_count;
unsigned long pfn_flags;
 };
 
@@ -161,10 +165,31 @@ static ssize_t align_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(align);
 
+static ssize_t seed_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region) {
+   mutex_lock(_region->lock);
+   if (dax_region->seed)
+   rc = sprintf(buf, "%s\n", dev_name(dax_region->seed));
+   mutex_unlock(_region->lock);
+   }
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(seed);
+
 static struct attribute *dax_region_attributes[] = {
_attr_available_size.attr,
_attr_region_size.attr,
_attr_align.attr,
+   _attr_seed.attr,
_attr_id.attr,
NULL,
 };
@@ -295,6 +320,9 @@ static void dax_region_free(struct kref *kref)
struct dax_region *dax_region;
 
dax_region = container_of(kref, struct dax_region, kref);
+   WARN(atomic_read(_region->child_count),
+   "%s: child count not zero\n",
+   dev_name(dax_region->dev));
kfree(dax_region);
 }
 
@@ -691,7 +719,10 @@ static void unregister_dax_dev(void *dev)
for (i = 0; i < dax_dev->num_resources; i++)
__release_region(_region->res, dax_dev->res[i]->start,
resource_size(dax_dev->res[i]));
+   if (dax_region->seed == dev)
+   dax_region->seed = NULL;
mutex_unlock(_region->lock);
+   atomic_dec(_region->child_count);
 
cdev_del(cdev);
device_unregister(dev);
@@ -796,6 +827,16 @@ struct dax_dev *devm_create_dax_dev(struct dax_region 
*dax_region,
if (rc)
return ERR_PTR(rc);
 
+   if (atomic_inc_return(_region->child_count) == 1) {
+   struct dax_dev *seed;
+
+   seed = devm_create_dax_dev(dax_region, NULL, 0);
+   if (IS_ERR(seed))
+   dev_warn(parent, "failed to create region seed\n");
+   else
+   dax_region->seed = >dev;
+   }
+
return dax_dev;
 
  err_cdev:

[PATCH 8/8] dax: add debug for region available_size

[Dan Williams]

Add dynamic debug statements to dump the per-dax-dev resource
allocations and device offsets.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index b130eff91b83..d1641e69a088 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -97,8 +97,11 @@ static unsigned long long dax_region_avail_size(
WARN_ON_ONCE(!mutex_is_locked(_region->lock));
 
size = resource_size(_region->res);
-   for_each_dax_region_resource(dax_region, res)
+   for_each_dax_region_resource(dax_region, res) {
+   dev_dbg(dax_region->dev, "%s: %pr offset: %lx\n",
+   res->name, res, res->desc);
size -= resource_size(res);
+   }
 
return size;
 }
@@ -372,6 +375,7 @@ struct dax_region *alloc_dax_region(struct device *parent, 
int region_id,
dax_region->res.name = dev_name(parent);
dax_region->res.start = res->start;
dax_region->res.end = res->end;
+   dax_region->res.flags = IORESOURCE_MEM;
dax_region->pfn_flags = pfn_flags;
mutex_init(_region->lock);
kref_init(_region->kref);

[PATCH 6/8] dax: sub-division support

[Dan Williams]

Device-DAX is a mechanism to establish mappings of performance / feature
differentiated memory with strict fault behavior guarantees. With
sub-division support a platform owner can provision sub-allocations of a
dax-region into separate devices. The provisioning mechanism follows the
same scheme as the libnvdimm sub-system in that a 'seed' device is
created at initialization time that can be resized from zero to become
enabled. Note that a later patch handles creating a new seed when the
current one is "planted" (enabled).

Unlike the nvdimm sub-system there is no on media labelling scheme
associated with this partitioning. Provisioning decisions are ephemeral
/ not automatically restored after reboot. While the initial use case of
device-dax is persistent memory other uses case may be volatile, so the
device-dax core is unable to assume the underlying memory is pmem.  The
task of recalling a partitioning scheme or permissions on the device(s)
is left to userspace.

For persistent allocations, naming, and permissions automatically
recalled by the kernel, use filesystem-DAX. For a userspace helper
library and utility for manipulating device-dax instances see libdaxctl
and the daxctl utility here: https://github.com/pmem/ndctl

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  351 +++--
 1 file changed, 312 insertions(+), 39 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 5b65eaff6ace..9b641c079e52 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -63,6 +63,7 @@ struct dax_region {
 /**
  * struct dax_dev - subdivision of a dax region
  * @region - parent region
+ * @resize_lock - for resource size reductions
  * @dev - device backing the character device
  * @cdev - core chardev data
  * @alive - !alive + rcu grace period == no new mappings can be established
@@ -72,6 +73,7 @@ struct dax_region {
  */
 struct dax_dev {
struct dax_region *region;
+   rwlock_t resize_lock;
struct inode *inode;
struct device dev;
struct cdev cdev;
@@ -419,7 +421,302 @@ static ssize_t size_show(struct device *dev,
 
return sprintf(buf, "%llu\n", size);
 }
-static DEVICE_ATTR_RO(size);
+
+/*
+ * Reuse the unused ->desc attribute of a dax_dev resource to store the
+ * relative pgoff of the resource within the device.
+ */
+static unsigned long to_dev_pgoff(struct resource *res)
+{
+   return res->desc;
+}
+
+static void set_dev_pgoff(struct resource *res, unsigned long dev_pgoff)
+{
+   res->desc = dev_pgoff;
+}
+
+static unsigned order_at(struct resource *res, unsigned long pgoff)
+{
+   unsigned long dev_pgoff = to_dev_pgoff(res) + pgoff;
+   unsigned long nr_pages = PHYS_PFN(resource_size(res));
+   unsigned order_max, order_pgoff;
+
+   if (nr_pages == pgoff)
+   return UINT_MAX;
+
+   /*
+* What is the largest power-of-2 range available from this
+* resource pgoff to the end of the resource range, considering
+* the alignment of the current dev_pgoff?
+*/
+   order_pgoff = ilog2(nr_pages | dev_pgoff);
+   order_max = ilog2(nr_pages - pgoff);
+   return min(order_max, order_pgoff);
+}
+
+#define foreach_order_pgoff(res, order, pgoff) \
+   for (pgoff = 0, order = order_at((res), pgoff); order < UINT_MAX; \
+   pgoff += 1UL << order, order = order_at(res, pgoff))
+
+static int dax_dev_adjust_resource(struct dax_dev *dax_dev,
+   struct resource *res, resource_size_t size)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   unsigned long pgoff;
+   int rc = 0, order;
+
+   /*
+* Take the lock to prevent false negative lookups while we
+* adjust both the resource and radix entries. Note that the
+* false *positive* lookups that are allowed by not locking when
+* deleting full resources are permissible because we will end
+* up invalidating those mappings before completing the resize.
+*/
+   write_lock(_dev->resize_lock);
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+
+   adjust_resource(res, res->start, size);
+
+   foreach_order_pgoff(res, order, pgoff) {
+   rc = __radix_tree_insert(>page_tree,
+   to_dev_pgoff(res) + pgoff, order, res);
+   if (rc) {
+   dev_WARN(_dev->dev,
+   "error: %d adjusting size\n", rc);
+   break;
+   }
+   }
+   write_unlock(_dev->resize_lock);
+
+   return rc;
+}
+
+static int dax_dev_shrink(struct dax_region *dax_region,
+   struct dax_dev *dax_dev, unsigned long long size)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   resource_size_t dev_size 

[PATCH 5/8] dax: refactor locking out of size calculation routines

[Dan Williams]

In preparation for other callers of these routines make the locking the
responsibility of the caller.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index d878a56cf3e3..5b65eaff6ace 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -90,11 +90,11 @@ static unsigned long long dax_region_avail_size(
unsigned long long size;
struct resource *res;
 
-   mutex_lock(_region->lock);
+   WARN_ON_ONCE(!mutex_is_locked(_region->lock));
+
size = resource_size(_region->res);
for_each_dax_region_resource(dax_region, res)
size -= resource_size(res);
-   mutex_unlock(_region->lock);
 
return size;
 }
@@ -107,8 +107,11 @@ static ssize_t available_size_show(struct device *dev,
 
device_lock(dev);
dax_region = dev_get_drvdata(dev);
-   if (dax_region)
+   if (dax_region) {
+   mutex_lock(_region->lock);
rc = sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));
+   mutex_unlock(_region->lock);
+   }
device_unlock(dev);
 
return rc;
@@ -389,16 +392,31 @@ static struct dax_dev *to_dax_dev(struct device *dev)
return container_of(dev, struct dax_dev, dev);
 }
 
-static ssize_t size_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static unsigned long long dax_dev_size(struct dax_dev *dax_dev)
 {
-   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
unsigned long long size = 0;
int i;
 
+   WARN_ON_ONCE(!mutex_is_locked(_region->lock));
+
for (i = 0; i < dax_dev->num_resources; i++)
size += resource_size(dax_dev->res[i]);
 
+   return size;
+}
+
+static ssize_t size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   unsigned long long size;
+   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
+
+   mutex_lock(_region->lock);
+   size = dax_dev_size(dax_dev);
+   mutex_unlock(_region->lock);
+
return sprintf(buf, "%llu\n", size);
 }
 static DEVICE_ATTR_RO(size);

[PATCH 4/8] dax: use multi-order radix for resource lookup

[Dan Williams]

Before we add support for multiple discontiguous extents in a device-dax
region, convert the file-offset to physical-address lookup to use the
multi-order radix tree.

Signed-off-by: Dan Williams 
---
 drivers/dax/Kconfig |1 
 drivers/dax/dax.c   |  120 ---
 2 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index 3e2ab3b14eea..f01d1b353b8e 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -2,6 +2,7 @@ menuconfig DEV_DAX
tristate "DAX: direct access to differentiated memory"
default m if NVDIMM_DAX
depends on TRANSPARENT_HUGEPAGE
+   select RADIX_TREE_MULTIORDER
help
  Support raw access to differentiated (persistence, bandwidth,
  latency...) memory via an mmap(2) capable character
diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index c9ba011e333b..d878a56cf3e3 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -458,28 +458,34 @@ static int check_vma(struct dax_dev *dax_dev, struct 
vm_area_struct *vma,
return 0;
 }
 
+/*
+ * Reuse the unused ->desc attribute of a dax_dev resource to store the
+ * relative pgoff of the resource within the device.
+ */
+static unsigned long to_dev_pgoff(struct resource *res)
+{
+   return res->desc;
+}
+
+static void set_dev_pgoff(struct resource *res, unsigned long dev_pgoff)
+{
+   res->desc = dev_pgoff;
+}
+
 static phys_addr_t pgoff_to_phys(struct dax_dev *dax_dev, pgoff_t pgoff,
unsigned long size)
 {
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   phys_addr_t res_offset;
struct resource *res;
-   phys_addr_t phys;
-   int i;
-
-   for (i = 0; i < dax_dev->num_resources; i++) {
-   res = dax_dev->res[i];
-   phys = pgoff * PAGE_SIZE + res->start;
-   if (phys >= res->start && phys <= res->end)
-   break;
-   pgoff -= PHYS_PFN(resource_size(res));
-   }
-
-   if (i < dax_dev->num_resources) {
-   res = dax_dev->res[i];
-   if (phys + size - 1 <= res->end)
-   return phys;
-   }
 
-   return -1;
+   res = radix_tree_lookup(>page_tree, pgoff);
+   if (!res)
+   return -1;
+   res_offset = PFN_PHYS(pgoff - to_dev_pgoff(res));
+   if (res_offset + size >= resource_size(res))
+   return -1;
+   return res->start + res_offset;
 }
 
 static int __dax_dev_fault(struct dax_dev *dax_dev, struct vm_area_struct *vma,
@@ -682,6 +688,58 @@ static const struct file_operations dax_fops = {
.mmap = dax_mmap,
 };
 
+static unsigned order_at(struct resource *res, unsigned long pgoff)
+{
+   unsigned long dev_pgoff = to_dev_pgoff(res) + pgoff;
+   unsigned long nr_pages = PHYS_PFN(resource_size(res));
+   unsigned order_max, order_pgoff;
+
+   if (nr_pages == pgoff)
+   return UINT_MAX;
+
+   /*
+* What is the largest power-of-2 range available from this
+* resource pgoff to the end of the resource range, considering
+* the alignment of the current dev_pgoff?
+*/
+   order_pgoff = ilog2(nr_pages | dev_pgoff);
+   order_max = ilog2(nr_pages - pgoff);
+   return min(order_max, order_pgoff);
+}
+
+#define foreach_order_pgoff(res, order, pgoff) \
+   for (pgoff = 0, order = order_at((res), pgoff); order < UINT_MAX; \
+   pgoff += 1UL << order, order = order_at(res, pgoff))
+
+static void clear_dax_dev_radix(struct dax_dev *dax_dev)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   struct radix_tree_iter iter;
+   void **slot;
+
+   rcu_read_lock();
+   radix_tree_for_each_slot(slot, >page_tree, , 0) {
+   struct resource *res;
+   unsigned long pgoff;
+   unsigned order;
+
+   res = radix_tree_deref_slot(slot);
+   if (unlikely(!res))
+   continue;
+   if (radix_tree_deref_retry(res)) {
+   slot = radix_tree_iter_retry();
+   continue;
+   }
+
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+   }
+   rcu_read_unlock();
+
+   synchronize_rcu();
+}
+
 static void dax_dev_release(struct device *dev)
 {
struct dax_dev *dax_dev = to_dax_dev(dev);
@@ -716,6 +774,7 @@ static void unregister_dax_dev(void *dev)
unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
 
mutex_lock(_region->lock);
+   clear_dax_dev_radix(dax_dev);
for (i = 0; i < dax_dev->num_resources; i++)
__release_region(_region->res, dax_dev->res[i]->start,

[PATCH 8/8] dax: add debug for region available_size

[Dan Williams]

Add dynamic debug statements to dump the per-dax-dev resource
allocations and device offsets.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index b130eff91b83..d1641e69a088 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -97,8 +97,11 @@ static unsigned long long dax_region_avail_size(
WARN_ON_ONCE(!mutex_is_locked(_region->lock));
 
size = resource_size(_region->res);
-   for_each_dax_region_resource(dax_region, res)
+   for_each_dax_region_resource(dax_region, res) {
+   dev_dbg(dax_region->dev, "%s: %pr offset: %lx\n",
+   res->name, res, res->desc);
size -= resource_size(res);
+   }
 
return size;
 }
@@ -372,6 +375,7 @@ struct dax_region *alloc_dax_region(struct device *parent, 
int region_id,
dax_region->res.name = dev_name(parent);
dax_region->res.start = res->start;
dax_region->res.end = res->end;
+   dax_region->res.flags = IORESOURCE_MEM;
dax_region->pfn_flags = pfn_flags;
mutex_init(_region->lock);
kref_init(_region->kref);

[PATCH 6/8] dax: sub-division support

[Dan Williams]

Device-DAX is a mechanism to establish mappings of performance / feature
differentiated memory with strict fault behavior guarantees. With
sub-division support a platform owner can provision sub-allocations of a
dax-region into separate devices. The provisioning mechanism follows the
same scheme as the libnvdimm sub-system in that a 'seed' device is
created at initialization time that can be resized from zero to become
enabled. Note that a later patch handles creating a new seed when the
current one is "planted" (enabled).

Unlike the nvdimm sub-system there is no on media labelling scheme
associated with this partitioning. Provisioning decisions are ephemeral
/ not automatically restored after reboot. While the initial use case of
device-dax is persistent memory other uses case may be volatile, so the
device-dax core is unable to assume the underlying memory is pmem.  The
task of recalling a partitioning scheme or permissions on the device(s)
is left to userspace.

For persistent allocations, naming, and permissions automatically
recalled by the kernel, use filesystem-DAX. For a userspace helper
library and utility for manipulating device-dax instances see libdaxctl
and the daxctl utility here: https://github.com/pmem/ndctl

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  351 +++--
 1 file changed, 312 insertions(+), 39 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 5b65eaff6ace..9b641c079e52 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -63,6 +63,7 @@ struct dax_region {
 /**
  * struct dax_dev - subdivision of a dax region
  * @region - parent region
+ * @resize_lock - for resource size reductions
  * @dev - device backing the character device
  * @cdev - core chardev data
  * @alive - !alive + rcu grace period == no new mappings can be established
@@ -72,6 +73,7 @@ struct dax_region {
  */
 struct dax_dev {
struct dax_region *region;
+   rwlock_t resize_lock;
struct inode *inode;
struct device dev;
struct cdev cdev;
@@ -419,7 +421,302 @@ static ssize_t size_show(struct device *dev,
 
return sprintf(buf, "%llu\n", size);
 }
-static DEVICE_ATTR_RO(size);
+
+/*
+ * Reuse the unused ->desc attribute of a dax_dev resource to store the
+ * relative pgoff of the resource within the device.
+ */
+static unsigned long to_dev_pgoff(struct resource *res)
+{
+   return res->desc;
+}
+
+static void set_dev_pgoff(struct resource *res, unsigned long dev_pgoff)
+{
+   res->desc = dev_pgoff;
+}
+
+static unsigned order_at(struct resource *res, unsigned long pgoff)
+{
+   unsigned long dev_pgoff = to_dev_pgoff(res) + pgoff;
+   unsigned long nr_pages = PHYS_PFN(resource_size(res));
+   unsigned order_max, order_pgoff;
+
+   if (nr_pages == pgoff)
+   return UINT_MAX;
+
+   /*
+* What is the largest power-of-2 range available from this
+* resource pgoff to the end of the resource range, considering
+* the alignment of the current dev_pgoff?
+*/
+   order_pgoff = ilog2(nr_pages | dev_pgoff);
+   order_max = ilog2(nr_pages - pgoff);
+   return min(order_max, order_pgoff);
+}
+
+#define foreach_order_pgoff(res, order, pgoff) \
+   for (pgoff = 0, order = order_at((res), pgoff); order < UINT_MAX; \
+   pgoff += 1UL << order, order = order_at(res, pgoff))
+
+static int dax_dev_adjust_resource(struct dax_dev *dax_dev,
+   struct resource *res, resource_size_t size)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   unsigned long pgoff;
+   int rc = 0, order;
+
+   /*
+* Take the lock to prevent false negative lookups while we
+* adjust both the resource and radix entries. Note that the
+* false *positive* lookups that are allowed by not locking when
+* deleting full resources are permissible because we will end
+* up invalidating those mappings before completing the resize.
+*/
+   write_lock(_dev->resize_lock);
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+
+   adjust_resource(res, res->start, size);
+
+   foreach_order_pgoff(res, order, pgoff) {
+   rc = __radix_tree_insert(>page_tree,
+   to_dev_pgoff(res) + pgoff, order, res);
+   if (rc) {
+   dev_WARN(_dev->dev,
+   "error: %d adjusting size\n", rc);
+   break;
+   }
+   }
+   write_unlock(_dev->resize_lock);
+
+   return rc;
+}
+
+static int dax_dev_shrink(struct dax_region *dax_region,
+   struct dax_dev *dax_dev, unsigned long long size)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   resource_size_t dev_size = dax_dev_size(dax_dev);
+ 

[PATCH 5/8] dax: refactor locking out of size calculation routines

[Dan Williams]

In preparation for other callers of these routines make the locking the
responsibility of the caller.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index d878a56cf3e3..5b65eaff6ace 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -90,11 +90,11 @@ static unsigned long long dax_region_avail_size(
unsigned long long size;
struct resource *res;
 
-   mutex_lock(_region->lock);
+   WARN_ON_ONCE(!mutex_is_locked(_region->lock));
+
size = resource_size(_region->res);
for_each_dax_region_resource(dax_region, res)
size -= resource_size(res);
-   mutex_unlock(_region->lock);
 
return size;
 }
@@ -107,8 +107,11 @@ static ssize_t available_size_show(struct device *dev,
 
device_lock(dev);
dax_region = dev_get_drvdata(dev);
-   if (dax_region)
+   if (dax_region) {
+   mutex_lock(_region->lock);
rc = sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));
+   mutex_unlock(_region->lock);
+   }
device_unlock(dev);
 
return rc;
@@ -389,16 +392,31 @@ static struct dax_dev *to_dax_dev(struct device *dev)
return container_of(dev, struct dax_dev, dev);
 }
 
-static ssize_t size_show(struct device *dev,
-   struct device_attribute *attr, char *buf)
+static unsigned long long dax_dev_size(struct dax_dev *dax_dev)
 {
-   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
unsigned long long size = 0;
int i;
 
+   WARN_ON_ONCE(!mutex_is_locked(_region->lock));
+
for (i = 0; i < dax_dev->num_resources; i++)
size += resource_size(dax_dev->res[i]);
 
+   return size;
+}
+
+static ssize_t size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   unsigned long long size;
+   struct dax_dev *dax_dev = to_dax_dev(dev);
+   struct dax_region *dax_region = dax_dev->region;
+
+   mutex_lock(_region->lock);
+   size = dax_dev_size(dax_dev);
+   mutex_unlock(_region->lock);
+
return sprintf(buf, "%llu\n", size);
 }
 static DEVICE_ATTR_RO(size);

[PATCH 4/8] dax: use multi-order radix for resource lookup

[Dan Williams]

Before we add support for multiple discontiguous extents in a device-dax
region, convert the file-offset to physical-address lookup to use the
multi-order radix tree.

Signed-off-by: Dan Williams 
---
 drivers/dax/Kconfig |1 
 drivers/dax/dax.c   |  120 ---
 2 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index 3e2ab3b14eea..f01d1b353b8e 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -2,6 +2,7 @@ menuconfig DEV_DAX
tristate "DAX: direct access to differentiated memory"
default m if NVDIMM_DAX
depends on TRANSPARENT_HUGEPAGE
+   select RADIX_TREE_MULTIORDER
help
  Support raw access to differentiated (persistence, bandwidth,
  latency...) memory via an mmap(2) capable character
diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index c9ba011e333b..d878a56cf3e3 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -458,28 +458,34 @@ static int check_vma(struct dax_dev *dax_dev, struct 
vm_area_struct *vma,
return 0;
 }
 
+/*
+ * Reuse the unused ->desc attribute of a dax_dev resource to store the
+ * relative pgoff of the resource within the device.
+ */
+static unsigned long to_dev_pgoff(struct resource *res)
+{
+   return res->desc;
+}
+
+static void set_dev_pgoff(struct resource *res, unsigned long dev_pgoff)
+{
+   res->desc = dev_pgoff;
+}
+
 static phys_addr_t pgoff_to_phys(struct dax_dev *dax_dev, pgoff_t pgoff,
unsigned long size)
 {
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   phys_addr_t res_offset;
struct resource *res;
-   phys_addr_t phys;
-   int i;
-
-   for (i = 0; i < dax_dev->num_resources; i++) {
-   res = dax_dev->res[i];
-   phys = pgoff * PAGE_SIZE + res->start;
-   if (phys >= res->start && phys <= res->end)
-   break;
-   pgoff -= PHYS_PFN(resource_size(res));
-   }
-
-   if (i < dax_dev->num_resources) {
-   res = dax_dev->res[i];
-   if (phys + size - 1 <= res->end)
-   return phys;
-   }
 
-   return -1;
+   res = radix_tree_lookup(>page_tree, pgoff);
+   if (!res)
+   return -1;
+   res_offset = PFN_PHYS(pgoff - to_dev_pgoff(res));
+   if (res_offset + size >= resource_size(res))
+   return -1;
+   return res->start + res_offset;
 }
 
 static int __dax_dev_fault(struct dax_dev *dax_dev, struct vm_area_struct *vma,
@@ -682,6 +688,58 @@ static const struct file_operations dax_fops = {
.mmap = dax_mmap,
 };
 
+static unsigned order_at(struct resource *res, unsigned long pgoff)
+{
+   unsigned long dev_pgoff = to_dev_pgoff(res) + pgoff;
+   unsigned long nr_pages = PHYS_PFN(resource_size(res));
+   unsigned order_max, order_pgoff;
+
+   if (nr_pages == pgoff)
+   return UINT_MAX;
+
+   /*
+* What is the largest power-of-2 range available from this
+* resource pgoff to the end of the resource range, considering
+* the alignment of the current dev_pgoff?
+*/
+   order_pgoff = ilog2(nr_pages | dev_pgoff);
+   order_max = ilog2(nr_pages - pgoff);
+   return min(order_max, order_pgoff);
+}
+
+#define foreach_order_pgoff(res, order, pgoff) \
+   for (pgoff = 0, order = order_at((res), pgoff); order < UINT_MAX; \
+   pgoff += 1UL << order, order = order_at(res, pgoff))
+
+static void clear_dax_dev_radix(struct dax_dev *dax_dev)
+{
+   struct address_space *mapping = dax_dev->inode->i_mapping;
+   struct radix_tree_iter iter;
+   void **slot;
+
+   rcu_read_lock();
+   radix_tree_for_each_slot(slot, >page_tree, , 0) {
+   struct resource *res;
+   unsigned long pgoff;
+   unsigned order;
+
+   res = radix_tree_deref_slot(slot);
+   if (unlikely(!res))
+   continue;
+   if (radix_tree_deref_retry(res)) {
+   slot = radix_tree_iter_retry();
+   continue;
+   }
+
+   foreach_order_pgoff(res, order, pgoff)
+   radix_tree_delete(>page_tree,
+   to_dev_pgoff(res) + pgoff);
+   }
+   rcu_read_unlock();
+
+   synchronize_rcu();
+}
+
 static void dax_dev_release(struct device *dev)
 {
struct dax_dev *dax_dev = to_dax_dev(dev);
@@ -716,6 +774,7 @@ static void unregister_dax_dev(void *dev)
unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
 
mutex_lock(_region->lock);
+   clear_dax_dev_radix(dax_dev);
for (i = 0; i < dax_dev->num_resources; i++)
__release_region(_region->res, dax_dev->res[i]->start,
resource_size(dax_dev->res[i]));
@@ -734,6 +793,7 

[PATCH 2/8] dax: add region 'id', 'size', and 'align' attributes

[Dan Williams]

While this information is available by looking at the nvdimm parent
device that may not always be the case when/if we add support for other
memory regions. Tooling should not depend on walking a given ancestor
topology that is not guaranteed by the device's class. For example, a
device-dax instance will always have a dax_region parent, but it may not
always have a libnvdimm "dax" device as a grandparent.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index cc7c4aa4bcc2..da2962b6f8de 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -111,8 +111,61 @@ static ssize_t available_size_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(available_size);
 
+static ssize_t id_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%d\n", dax_region->id);
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(id);
+
+static ssize_t region_size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%llu\n", (unsigned long long)
+   resource_size(_region->res));
+   device_unlock(dev);
+
+   return rc;
+}
+static struct device_attribute dev_attr_region_size = __ATTR(size, 0444,
+   region_size_show, NULL);
+
+static ssize_t align_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%u\n", dax_region->align);
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(align);
+
 static struct attribute *dax_region_attributes[] = {
_attr_available_size.attr,
+   _attr_region_size.attr,
+   _attr_align.attr,
+   _attr_id.attr,
NULL,
 };
 

[PATCH 2/8] dax: add region 'id', 'size', and 'align' attributes

[Dan Williams]

While this information is available by looking at the nvdimm parent
device that may not always be the case when/if we add support for other
memory regions. Tooling should not depend on walking a given ancestor
topology that is not guaranteed by the device's class. For example, a
device-dax instance will always have a dax_region parent, but it may not
always have a libnvdimm "dax" device as a grandparent.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |   53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index cc7c4aa4bcc2..da2962b6f8de 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -111,8 +111,61 @@ static ssize_t available_size_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(available_size);
 
+static ssize_t id_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%d\n", dax_region->id);
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(id);
+
+static ssize_t region_size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%llu\n", (unsigned long long)
+   resource_size(_region->res));
+   device_unlock(dev);
+
+   return rc;
+}
+static struct device_attribute dev_attr_region_size = __ATTR(size, 0444,
+   region_size_show, NULL);
+
+static ssize_t align_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%u\n", dax_region->align);
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(align);
+
 static struct attribute *dax_region_attributes[] = {
_attr_available_size.attr,
+   _attr_region_size.attr,
+   _attr_align.attr,
+   _attr_id.attr,
NULL,
 };
 

[PATCH 1/8] dax: add region-available-size attribute

[Dan Williams]

In preparation for a facility that enables dax regions to be
sub-divided, introduce a 'dax/available_size' attribute.  This attribute
appears under the parent device that registered the device-dax region,
and it assumes that the device-dax-core owns the driver-data for that
device.

'dax/available_size' adjusts dynamically as dax-device instances are
registered and unregistered.

As a side effect of using __request_region() to reserve capacity from
the dax_region we now track pointers to those returned resources rather
than duplicating the passed in resource array.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  135 -
 1 file changed, 123 insertions(+), 12 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 3d94ff20fdca..cc7c4aa4bcc2 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -38,6 +38,7 @@ MODULE_PARM_DESC(nr_dax, "max number of device-dax 
instances");
  * @id: kernel-wide unique region for a memory range
  * @base: linear address corresponding to @res
  * @kref: to pin while other agents have a need to do lookups
+ * @lock: synchronize changes / consistent-access to the resource tree (@res)
  * @dev: parent device backing this region
  * @align: allocation and mapping alignment for child dax devices
  * @res: physical address range of the region
@@ -48,6 +49,7 @@ struct dax_region {
struct ida ida;
void *base;
struct kref kref;
+   struct mutex lock;
struct device *dev;
unsigned int align;
struct resource res;
@@ -72,7 +74,56 @@ struct dax_dev {
bool alive;
int id;
int num_resources;
-   struct resource res[0];
+   struct resource **res;
+};
+
+#define for_each_dax_region_resource(dax_region, res) \
+   for (res = (dax_region)->res.child; res; res = res->sibling)
+
+static unsigned long long dax_region_avail_size(
+   struct dax_region *dax_region)
+{
+   unsigned long long size;
+   struct resource *res;
+
+   mutex_lock(_region->lock);
+   size = resource_size(_region->res);
+   for_each_dax_region_resource(dax_region, res)
+   size -= resource_size(res);
+   mutex_unlock(_region->lock);
+
+   return size;
+}
+
+static ssize_t available_size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(available_size);
+
+static struct attribute *dax_region_attributes[] = {
+   _attr_available_size.attr,
+   NULL,
+};
+
+static const struct attribute_group dax_region_attribute_group = {
+   .name = "dax_region",
+   .attrs = dax_region_attributes,
+};
+
+static const struct attribute_group *dax_region_attribute_groups[] = {
+   _region_attribute_group,
+   NULL,
 };
 
 static struct inode *dax_alloc_inode(struct super_block *sb)
@@ -200,12 +251,27 @@ void dax_region_put(struct dax_region *dax_region)
 }
 EXPORT_SYMBOL_GPL(dax_region_put);
 
+
+static void dax_region_unregister(void *region)
+{
+   struct dax_region *dax_region = region;
+
+   sysfs_remove_groups(_region->dev->kobj,
+   dax_region_attribute_groups);
+   dax_region_put(dax_region);
+}
+
 struct dax_region *alloc_dax_region(struct device *parent, int region_id,
struct resource *res, unsigned int align, void *addr,
unsigned long pfn_flags)
 {
struct dax_region *dax_region;
 
+   if (dev_get_drvdata(parent)) {
+   dev_WARN(parent, "dax core found drvdata already in use\n");
+   return NULL;
+   }
+
if (!IS_ALIGNED(res->start, align)
|| !IS_ALIGNED(resource_size(res), align))
return NULL;
@@ -213,16 +279,26 @@ struct dax_region *alloc_dax_region(struct device 
*parent, int region_id,
dax_region = kzalloc(sizeof(*dax_region), GFP_KERNEL);
if (!dax_region)
return NULL;
-
-   memcpy(_region->res, res, sizeof(*res));
+   dev_set_drvdata(parent, dax_region);
+   dax_region->res.name = dev_name(parent);
+   dax_region->res.start = res->start;
+   dax_region->res.end = res->end;
dax_region->pfn_flags = pfn_flags;
+   mutex_init(_region->lock);
kref_init(_region->kref);
dax_region->id = region_id;
ida_init(_region->ida);
dax_region->align = align;
dax_region->dev = parent;
dax_region->base = addr;
+   if (sysfs_create_groups(>kobj, dax_region_attribute_groups)) {
+   kfree(dax_region);
+   return NULL;;
+   }
 
+   kref_get(_region->kref);

[PATCH 0/8] device-dax: sub-division support

[Dan Williams]

>From [PATCH 6/8] dax: sub-division support:

Device-DAX is a mechanism to establish mappings of performance / feature
differentiated memory with strict fault behavior guarantees.  With
sub-division support a platform owner can provision sub-allocations of a
dax-region into separate devices. The provisioning mechanism follows the
same scheme as the libnvdimm sub-system in that a 'seed' device is
created at initialization time that can be resized from zero to become
enabled.

Unlike the nvdimm sub-system there is no on media labelling scheme
associated with this partitioning. Provisioning decisions are ephemeral
/ not automatically restored after reboot. While the initial use case of
device-dax is persistent memory other uses case may be volatile, so the
device-dax core is unable to assume the underlying memory is pmem.  The
task of recalling a partitioning scheme or permissions on the device(s)
is left to userspace.

For persistent allocations, naming, and permissions automatically
recalled by the kernel, use filesystem-DAX. For a userspace helper
library and utility for manipulating device-dax instances see libdaxctl
and the daxctl utility here: https://github.com/pmem/ndctl

---

Dan Williams (8):
  dax: add region-available-size attribute
  dax: add region 'id', 'size', and 'align' attributes
  dax: register seed device
  dax: use multi-order radix for resource lookup
  dax: refactor locking out of size calculation routines
  dax: sub-division support
  dax: add / remove dax devices after provisioning
  dax: add debug for region available_size


 drivers/dax/Kconfig |1 
 drivers/dax/dax.c   |  747 ---
 2 files changed, 698 insertions(+), 50 deletions(-)

[PATCH 1/8] dax: add region-available-size attribute

[Dan Williams]

In preparation for a facility that enables dax regions to be
sub-divided, introduce a 'dax/available_size' attribute.  This attribute
appears under the parent device that registered the device-dax region,
and it assumes that the device-dax-core owns the driver-data for that
device.

'dax/available_size' adjusts dynamically as dax-device instances are
registered and unregistered.

As a side effect of using __request_region() to reserve capacity from
the dax_region we now track pointers to those returned resources rather
than duplicating the passed in resource array.

Signed-off-by: Dan Williams 
---
 drivers/dax/dax.c |  135 -
 1 file changed, 123 insertions(+), 12 deletions(-)

diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index 3d94ff20fdca..cc7c4aa4bcc2 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -38,6 +38,7 @@ MODULE_PARM_DESC(nr_dax, "max number of device-dax 
instances");
  * @id: kernel-wide unique region for a memory range
  * @base: linear address corresponding to @res
  * @kref: to pin while other agents have a need to do lookups
+ * @lock: synchronize changes / consistent-access to the resource tree (@res)
  * @dev: parent device backing this region
  * @align: allocation and mapping alignment for child dax devices
  * @res: physical address range of the region
@@ -48,6 +49,7 @@ struct dax_region {
struct ida ida;
void *base;
struct kref kref;
+   struct mutex lock;
struct device *dev;
unsigned int align;
struct resource res;
@@ -72,7 +74,56 @@ struct dax_dev {
bool alive;
int id;
int num_resources;
-   struct resource res[0];
+   struct resource **res;
+};
+
+#define for_each_dax_region_resource(dax_region, res) \
+   for (res = (dax_region)->res.child; res; res = res->sibling)
+
+static unsigned long long dax_region_avail_size(
+   struct dax_region *dax_region)
+{
+   unsigned long long size;
+   struct resource *res;
+
+   mutex_lock(_region->lock);
+   size = resource_size(_region->res);
+   for_each_dax_region_resource(dax_region, res)
+   size -= resource_size(res);
+   mutex_unlock(_region->lock);
+
+   return size;
+}
+
+static ssize_t available_size_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct dax_region *dax_region;
+   ssize_t rc = -ENXIO;
+
+   device_lock(dev);
+   dax_region = dev_get_drvdata(dev);
+   if (dax_region)
+   rc = sprintf(buf, "%llu\n", dax_region_avail_size(dax_region));
+   device_unlock(dev);
+
+   return rc;
+}
+static DEVICE_ATTR_RO(available_size);
+
+static struct attribute *dax_region_attributes[] = {
+   _attr_available_size.attr,
+   NULL,
+};
+
+static const struct attribute_group dax_region_attribute_group = {
+   .name = "dax_region",
+   .attrs = dax_region_attributes,
+};
+
+static const struct attribute_group *dax_region_attribute_groups[] = {
+   _region_attribute_group,
+   NULL,
 };
 
 static struct inode *dax_alloc_inode(struct super_block *sb)
@@ -200,12 +251,27 @@ void dax_region_put(struct dax_region *dax_region)
 }
 EXPORT_SYMBOL_GPL(dax_region_put);
 
+
+static void dax_region_unregister(void *region)
+{
+   struct dax_region *dax_region = region;
+
+   sysfs_remove_groups(_region->dev->kobj,
+   dax_region_attribute_groups);
+   dax_region_put(dax_region);
+}
+
 struct dax_region *alloc_dax_region(struct device *parent, int region_id,
struct resource *res, unsigned int align, void *addr,
unsigned long pfn_flags)
 {
struct dax_region *dax_region;
 
+   if (dev_get_drvdata(parent)) {
+   dev_WARN(parent, "dax core found drvdata already in use\n");
+   return NULL;
+   }
+
if (!IS_ALIGNED(res->start, align)
|| !IS_ALIGNED(resource_size(res), align))
return NULL;
@@ -213,16 +279,26 @@ struct dax_region *alloc_dax_region(struct device 
*parent, int region_id,
dax_region = kzalloc(sizeof(*dax_region), GFP_KERNEL);
if (!dax_region)
return NULL;
-
-   memcpy(_region->res, res, sizeof(*res));
+   dev_set_drvdata(parent, dax_region);
+   dax_region->res.name = dev_name(parent);
+   dax_region->res.start = res->start;
+   dax_region->res.end = res->end;
dax_region->pfn_flags = pfn_flags;
+   mutex_init(_region->lock);
kref_init(_region->kref);
dax_region->id = region_id;
ida_init(_region->ida);
dax_region->align = align;
dax_region->dev = parent;
dax_region->base = addr;
+   if (sysfs_create_groups(>kobj, dax_region_attribute_groups)) {
+   kfree(dax_region);
+   return NULL;;
+   }
 
+   kref_get(_region->kref);
+   if 

[PATCH 0/8] device-dax: sub-division support

[Dan Williams]

>From [PATCH 6/8] dax: sub-division support:

Device-DAX is a mechanism to establish mappings of performance / feature
differentiated memory with strict fault behavior guarantees.  With
sub-division support a platform owner can provision sub-allocations of a
dax-region into separate devices. The provisioning mechanism follows the
same scheme as the libnvdimm sub-system in that a 'seed' device is
created at initialization time that can be resized from zero to become
enabled.

Unlike the nvdimm sub-system there is no on media labelling scheme
associated with this partitioning. Provisioning decisions are ephemeral
/ not automatically restored after reboot. While the initial use case of
device-dax is persistent memory other uses case may be volatile, so the
device-dax core is unable to assume the underlying memory is pmem.  The
task of recalling a partitioning scheme or permissions on the device(s)
is left to userspace.

For persistent allocations, naming, and permissions automatically
recalled by the kernel, use filesystem-DAX. For a userspace helper
library and utility for manipulating device-dax instances see libdaxctl
and the daxctl utility here: https://github.com/pmem/ndctl

---

Dan Williams (8):
  dax: add region-available-size attribute
  dax: add region 'id', 'size', and 'align' attributes
  dax: register seed device
  dax: use multi-order radix for resource lookup
  dax: refactor locking out of size calculation routines
  dax: sub-division support
  dax: add / remove dax devices after provisioning
  dax: add debug for region available_size


 drivers/dax/Kconfig |1 
 drivers/dax/dax.c   |  747 ---
 2 files changed, 698 insertions(+), 50 deletions(-)

Re: [PATCH v5 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs

[kbuild test robot]

Hi Joshua,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc8]
[cannot apply to next-20161209]
[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/Joshua-Clayton/lib-add-bitrev8x4/20161208-070638
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from drivers/fpga/cyclone-ps-spi.c:13:0:
   drivers/fpga/cyclone-ps-spi.c: In function 'rev_buf':
>> include/linux/bitrev.h:12:21: error: implicit declaration of function 
>> '__arch_bitrev8x4' [-Werror=implicit-function-declaration]
#define __bitrev8x4 __arch_bitrev8x4
^
   include/linux/bitrev.h:101:2: note: in expansion of macro '__bitrev8x4'
 __bitrev8x4(__x);\
 ^~~
   drivers/fpga/cyclone-ps-spi.c:84:11: note: in expansion of macro 'bitrev8x4'
  *fw32 = bitrev8x4(*fw32);
  ^
   In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
   drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
   include/linux/kernel.h:739:16: warning: comparison of distinct pointer types 
lacks a cast
 (void) ( == );   \
   ^
   include/linux/kernel.h:742:2: note: in expansion of macro '__min'
 __min(typeof(x), typeof(y),   \
 ^
   drivers/fpga/cyclone-ps-spi.c:98:19: note: in expansion of macro 'min'
  size_t stride = min(fw_data_end - fw_data, SZ_4K);
  ^~~
   cc1: some warnings being treated as errors

vim +/__arch_bitrev8x4 +12 include/linux/bitrev.h

556d2f05 Yalin Wang 2014-11-03   6  #ifdef CONFIG_HAVE_ARCH_BITREVERSE
556d2f05 Yalin Wang 2014-11-03   7  #include 
556d2f05 Yalin Wang 2014-11-03   8  
556d2f05 Yalin Wang 2014-11-03   9  #define __bitrev32 __arch_bitrev32
556d2f05 Yalin Wang 2014-11-03  10  #define __bitrev16 __arch_bitrev16
556d2f05 Yalin Wang 2014-11-03  11  #define __bitrev8 __arch_bitrev8
533d0eab Joshua Clayton 2016-12-07 @12  #define __bitrev8x4 __arch_bitrev8x4
a5cfc1ec Akinobu Mita   2006-12-08  13  
556d2f05 Yalin Wang 2014-11-03  14  #else
556d2f05 Yalin Wang 2014-11-03  15  extern u8 const byte_rev_table[256];

:: The code at line 12 was first introduced by commit
:: 533d0eabff8f37edfdec7fdf6e705fdecb297daa lib: add bitrev8x4()

:: TO: Joshua Clayton 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [PATCH v5 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs

[kbuild test robot]

Hi Joshua,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc8]
[cannot apply to next-20161209]
[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/Joshua-Clayton/lib-add-bitrev8x4/20161208-070638
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   In file included from drivers/fpga/cyclone-ps-spi.c:13:0:
   drivers/fpga/cyclone-ps-spi.c: In function 'rev_buf':
>> include/linux/bitrev.h:12:21: error: implicit declaration of function 
>> '__arch_bitrev8x4' [-Werror=implicit-function-declaration]
#define __bitrev8x4 __arch_bitrev8x4
^
   include/linux/bitrev.h:101:2: note: in expansion of macro '__bitrev8x4'
 __bitrev8x4(__x);\
 ^~~
   drivers/fpga/cyclone-ps-spi.c:84:11: note: in expansion of macro 'bitrev8x4'
  *fw32 = bitrev8x4(*fw32);
  ^
   In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
   drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
   include/linux/kernel.h:739:16: warning: comparison of distinct pointer types 
lacks a cast
 (void) ( == );   \
   ^
   include/linux/kernel.h:742:2: note: in expansion of macro '__min'
 __min(typeof(x), typeof(y),   \
 ^
   drivers/fpga/cyclone-ps-spi.c:98:19: note: in expansion of macro 'min'
  size_t stride = min(fw_data_end - fw_data, SZ_4K);
  ^~~
   cc1: some warnings being treated as errors

vim +/__arch_bitrev8x4 +12 include/linux/bitrev.h

556d2f05 Yalin Wang 2014-11-03   6  #ifdef CONFIG_HAVE_ARCH_BITREVERSE
556d2f05 Yalin Wang 2014-11-03   7  #include 
556d2f05 Yalin Wang 2014-11-03   8  
556d2f05 Yalin Wang 2014-11-03   9  #define __bitrev32 __arch_bitrev32
556d2f05 Yalin Wang 2014-11-03  10  #define __bitrev16 __arch_bitrev16
556d2f05 Yalin Wang 2014-11-03  11  #define __bitrev8 __arch_bitrev8
533d0eab Joshua Clayton 2016-12-07 @12  #define __bitrev8x4 __arch_bitrev8x4
a5cfc1ec Akinobu Mita   2006-12-08  13  
556d2f05 Yalin Wang 2014-11-03  14  #else
556d2f05 Yalin Wang 2014-11-03  15  extern u8 const byte_rev_table[256];

:: The code at line 12 was first introduced by commit
:: 533d0eabff8f37edfdec7fdf6e705fdecb297daa lib: add bitrev8x4()

:: TO: Joshua Clayton 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

[PATCH v7 2/2] tpm: add securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

Unlike the device driver support for TPM 1.2, the TPM 2.0 does
not support the securityfs pseudo files for displaying the
firmware event log.

This patch enables support for providing the TPM 2.0 event log in
binary form. TPM 2.0 event log supports a crypto agile format that
records multiple digests, which is different from TPM 1.2. This
patch enables the tpm_bios_log_setup for TPM 2.0  and adds the
event log parser which understand the TPM 2.0 crypto agile format.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_eventlog.h|  70 +++
 4 files changed, 295 insertions(+), 15 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a05b1eb..3d386a8 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -3,7 +3,7 @@
 #
 obj-$(CONFIG_TCG_TPM) += tpm.o
 tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o tpm-chip.o tpm2-cmd.o \
-   tpm_eventlog.o
+   tpm1_eventlog.o tpm2_eventlog.o
 tpm-$(CONFIG_ACPI) += tpm_ppi.o tpm_acpi.o
 tpm-$(CONFIG_OF) += tpm_of.o
 obj-$(CONFIG_TCG_TIS_CORE) += tpm_tis_core.o
diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm1_eventlog.c
similarity index 95%
rename from drivers/char/tpm/tpm_eventlog.c
rename to drivers/char/tpm/tpm1_eventlog.c
index 11bb113..9a8605e 100644
--- a/drivers/char/tpm/tpm_eventlog.c
+++ b/drivers/char/tpm/tpm1_eventlog.c
@@ -390,9 +390,6 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
unsigned int cnt;
int rc = 0;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   return 0;
-
rc = tpm_read_log(chip);
if (rc)
return rc;
@@ -407,7 +404,13 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
cnt++;
 
chip->bin_log_seqops.chip = chip;
-   chip->bin_log_seqops.seqops = _binary_b_measurements_seqops;
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+   else
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+
 
chip->bios_dir[cnt] =
securityfs_create_file("binary_bios_measurements",
@@ -418,17 +421,21 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
goto err;
cnt++;
 
-   chip->ascii_log_seqops.chip = chip;
-   chip->ascii_log_seqops.seqops = _ascii_b_measurements_seqops;
+   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
 
-   chip->bios_dir[cnt] =
-   securityfs_create_file("ascii_bios_measurements",
-  0440, chip->bios_dir[0],
-  (void *)>ascii_log_seqops,
-  _bios_measurements_ops);
-   if (IS_ERR(chip->bios_dir[cnt]))
-   goto err;
-   cnt++;
+   chip->ascii_log_seqops.chip = chip;
+   chip->ascii_log_seqops.seqops =
+   _ascii_b_measurements_seqops;
+
+   chip->bios_dir[cnt] =
+   securityfs_create_file("ascii_bios_measurements",
+  0440, chip->bios_dir[0],
+  (void *)>ascii_log_seqops,
+  _bios_measurements_ops);
+   if (IS_ERR(chip->bios_dir[cnt]))
+   goto err;
+   cnt++;
+   }
 
return 0;
 
diff --git a/drivers/char/tpm/tpm2_eventlog.c b/drivers/char/tpm/tpm2_eventlog.c
new file mode 100644
index 000..63690d3
--- /dev/null
+++ b/drivers/char/tpm/tpm2_eventlog.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2016 IBM Corporation
+ *
+ * Authors:
+ *  Nayna Jain 
+ *
+ * Access to TPM 2.0 event log as written by Firmware.
+ * It assumes that writer of event log has followed TCG Specification
+ * for Family "2.0" and written the event data in little endian.
+ * With that, it doesn't need any endian conversion for structure
+ * content.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tpm.h"
+#include "tpm_eventlog.h"
+
+static int calc_tpm2_event_size(struct tcg_pcr_event2 *event,
+   struct tcg_pcr_event *event_header)
+{
+   struct tcg_efi_specid_event *efispecid;
+   struct tcg_event_field *event_field;
+   

[PATCH v7 0/2] securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

The TPM device driver defines ascii and binary methods for
displaying the TPM 1.2 event log via securityfs files, which are
needed for validating a TPM quote. The device driver for TPM 2.0
does not have similar support for displaying the TPM 2.0
event log. This patch set adds the support for displaying
TPM 2.0 event log in binary format.

The parsing mechanism to display the TPM 2.0 event log in binary
format is implemented as defined in the TPM 2.0 TCG specification[1].
If the firmware event log support exists and is successfully read,
the securityfs file is created to provide the event log in binary
format for both the OF device tree and ACPI.

   - Patch 1 adds the device tree bindings support for Physical TPM.
   - Patch 2 adds the support for creating securityfs files and for
 displaying the TPM 2.0 crypto agile event log in binary format.

[1] TCG EFI Protocol Specification, Family "2.0" - Section 5 "Event
Log Structure"

Changelog History

v7:
- Rebased to the Jarkko's latest master branch (b2505f6 tpm/vtpm:
  fix kdoc warnings)
- Included Jarkko's feedbacks on version v6.
- Cleaned up #defines in tpm2_eventlog.c
  - renamed HASH_COUNT to TPM2_ACTIVE_PCR_BANKS
  - deleted MAX_DIGEST_SIZE, used SHA384_DIGEST_SIZE directly from 
  
  - deleted MAX_TPM_LOG_MSG. Redefined event[MAX_TPM_LOG_MSG]
  as event[0].

v6:

- Rebased to the Jarkko's latest master branch (e717b5c:tpm: vtpm_proxy: 
  conditionally call tpm_chip_unregister)
- Retained securityfs setup functions in tpm_eventlog.c
- Renamed tpm_eventlog.c to tpm1_eventlog.c
- Fixed tpm_read_log_of() for NULL check and memcpy function.

v5:

- Upstreamed cleanup and fixes as different patchset
- Rebased to the Jarkko's latest master branch (e5be084 tpm: vtpm_proxy:
  Do not access host's event log)
- Patch "tpm: enhance read_log_of() to support Physical TPM event log
  - New Patch.
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log"
  - Moved the changes in read_log_of() to a different patch
  - TPM 2.0 event log data types are declared in tpm_eventlog.h, tpm2.h
  is removed.
  - Included other feedbacks also from Jarkko on aligment and extra
line

v4:

- Includes feedbacks from Jarkko and Jason.
- Patch "tpm: define a generic open() method for ascii & bios
measurements".
  - Fix indentation issue.
- Patch "tpm: replace the dynamically allocated bios_dir as
  struct dentry array".
  - Continue to use bios_dir_count variable to use is_bad() checks and
to maintain correct order for securityfs_remove() during teardown.
  - Reset chip->bios_dir_count in teardown() function.
- Patch "tpm: validate the eventlog access before tpm_bios_log_setup".
  - Retain TPM2 check which was removed in previous patch.
  - Add tpm_bios_log_setup failure handling.
  - Remove use of private data from v3 version of patch. Add a
  new member to struct tpm_chip to achieve the same purpose.
- Patch "tpm: redefine the read_log method to check for ACPI/OF 
properties sequentially".
  - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to this
patch from patch 3.
  - Replace -1 error code with -ENODEV.
- Patch "tpm: replace the of_find_node_by_name() with dev of_node
property".
  - Uses chip->dev.parent->of_node.
  - Created separate patch for cleanup of pr_err messages.
- Patch "tpm: remove printk error messages".
  - New Patch.
- Patch "tpm: add the securityfs file support for TPM 2.0 eventlog".
  - Parses event digests using event alg_id rather than event log header
alg_id.
  - Uses of_property_match_string to differentiate tpm/vtpm compatible

v3:

- Includes the review feedbacks as suggested by Jason.
- Split of patches into one patch per idea.
- Generic open() method for ascii/bios measurements.
- Replacement of of **bios_dir with *bios_dir[3].
- Verifying readlog() is successful before creating securityfs entries.
- Generic readlog() to check for ACPI/OF in sequence.
- read_log_of() method now uses of_node propertry rather than
calling find_device_by_name.
- read_log differentiates vtpm/tpm using its compatible property.
- Cleans pr_err with dev_dbg.
- Commit msgs subject line prefixed with tpm.

v2:

- Fixes issues as given in feedback by Jason.
- Adds documentation for device tree.

Nayna Jain (2):
  tpm: enhance read_log_of() to support Physical TPM event log
  tpm: add securityfs support for TPM 2.0 firmware event log

 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_eventlog.h|  70 +++
 drivers/char/tpm/tpm_of.c  |  27 ++-
 5 files changed, 318 insertions(+), 19 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

-- 
2.5.0

[PATCH v7 1/2] tpm: enhance read_log_of() to support Physical TPM event log

[Nayna Jain]

Physical TPMs use Open Firmware Device Tree bindings that are similar
to the IBM Power virtual TPM to support event log. However, these
properties store the values in different endianness for Physical
and Virtual TPM.

This patch fixes the endianness issue by doing appropriate conversion
based on Physical or Virtual TPM.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/tpm_of.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 7dee42d7..de57d4a 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -27,6 +27,8 @@ int tpm_read_log_of(struct tpm_chip *chip)
const u32 *sizep;
const u64 *basep;
struct tpm_bios_log *log;
+   u32 size;
+   u64 base;
 
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -41,18 +43,35 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (sizep == NULL || basep == NULL)
return -EIO;
 
-   if (*sizep == 0) {
+   /*
+* For both vtpm/tpm, firmware has log addr and log size in big
+* endian format. But in case of vtpm, there is a method called
+* sml-handover which is run during kernel init even before
+* device tree is setup. This sml-handover function takes care
+* of endianness and writes to sml-base and sml-size in little
+* endian format. For this reason, vtpm doesn't need conversion
+* but physical tpm needs the conversion.
+*/
+   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
+   size = be32_to_cpup(sizep);
+   base = be64_to_cpup(basep);
+   } else {
+   size = *sizep;
+   base = *basep;
+   }
+
+   if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
return -EIO;
}
 
-   log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
+   log->bios_event_log = kmalloc(size, GFP_KERNEL);
if (!log->bios_event_log)
return -ENOMEM;
 
-   log->bios_event_log_end = log->bios_event_log + *sizep;
+   log->bios_event_log_end = log->bios_event_log + size;
 
-   memcpy(log->bios_event_log, __va(*basep), *sizep);
+   memcpy(log->bios_event_log, __va(base), size);
 
return 0;
 }
-- 
2.5.0

[PATCH v7 0/2] securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

The TPM device driver defines ascii and binary methods for
displaying the TPM 1.2 event log via securityfs files, which are
needed for validating a TPM quote. The device driver for TPM 2.0
does not have similar support for displaying the TPM 2.0
event log. This patch set adds the support for displaying
TPM 2.0 event log in binary format.

The parsing mechanism to display the TPM 2.0 event log in binary
format is implemented as defined in the TPM 2.0 TCG specification[1].
If the firmware event log support exists and is successfully read,
the securityfs file is created to provide the event log in binary
format for both the OF device tree and ACPI.

   - Patch 1 adds the device tree bindings support for Physical TPM.
   - Patch 2 adds the support for creating securityfs files and for
 displaying the TPM 2.0 crypto agile event log in binary format.

[1] TCG EFI Protocol Specification, Family "2.0" - Section 5 "Event
Log Structure"

Changelog History

v7:
- Rebased to the Jarkko's latest master branch (b2505f6 tpm/vtpm:
  fix kdoc warnings)
- Included Jarkko's feedbacks on version v6.
- Cleaned up #defines in tpm2_eventlog.c
  - renamed HASH_COUNT to TPM2_ACTIVE_PCR_BANKS
  - deleted MAX_DIGEST_SIZE, used SHA384_DIGEST_SIZE directly from 
  
  - deleted MAX_TPM_LOG_MSG. Redefined event[MAX_TPM_LOG_MSG]
  as event[0].

v6:

- Rebased to the Jarkko's latest master branch (e717b5c:tpm: vtpm_proxy: 
  conditionally call tpm_chip_unregister)
- Retained securityfs setup functions in tpm_eventlog.c
- Renamed tpm_eventlog.c to tpm1_eventlog.c
- Fixed tpm_read_log_of() for NULL check and memcpy function.

v5:

- Upstreamed cleanup and fixes as different patchset
- Rebased to the Jarkko's latest master branch (e5be084 tpm: vtpm_proxy:
  Do not access host's event log)
- Patch "tpm: enhance read_log_of() to support Physical TPM event log
  - New Patch.
- Patch "tpm: add securityfs support for TPM 2.0 firmware event log"
  - Moved the changes in read_log_of() to a different patch
  - TPM 2.0 event log data types are declared in tpm_eventlog.h, tpm2.h
  is removed.
  - Included other feedbacks also from Jarkko on aligment and extra
line

v4:

- Includes feedbacks from Jarkko and Jason.
- Patch "tpm: define a generic open() method for ascii & bios
measurements".
  - Fix indentation issue.
- Patch "tpm: replace the dynamically allocated bios_dir as
  struct dentry array".
  - Continue to use bios_dir_count variable to use is_bad() checks and
to maintain correct order for securityfs_remove() during teardown.
  - Reset chip->bios_dir_count in teardown() function.
- Patch "tpm: validate the eventlog access before tpm_bios_log_setup".
  - Retain TPM2 check which was removed in previous patch.
  - Add tpm_bios_log_setup failure handling.
  - Remove use of private data from v3 version of patch. Add a
  new member to struct tpm_chip to achieve the same purpose.
- Patch "tpm: redefine the read_log method to check for ACPI/OF 
properties sequentially".
  - Move replacement of CONFIG_TCG_IBMVTPM with CONFIG_OF to this
patch from patch 3.
  - Replace -1 error code with -ENODEV.
- Patch "tpm: replace the of_find_node_by_name() with dev of_node
property".
  - Uses chip->dev.parent->of_node.
  - Created separate patch for cleanup of pr_err messages.
- Patch "tpm: remove printk error messages".
  - New Patch.
- Patch "tpm: add the securityfs file support for TPM 2.0 eventlog".
  - Parses event digests using event alg_id rather than event log header
alg_id.
  - Uses of_property_match_string to differentiate tpm/vtpm compatible

v3:

- Includes the review feedbacks as suggested by Jason.
- Split of patches into one patch per idea.
- Generic open() method for ascii/bios measurements.
- Replacement of of **bios_dir with *bios_dir[3].
- Verifying readlog() is successful before creating securityfs entries.
- Generic readlog() to check for ACPI/OF in sequence.
- read_log_of() method now uses of_node propertry rather than
calling find_device_by_name.
- read_log differentiates vtpm/tpm using its compatible property.
- Cleans pr_err with dev_dbg.
- Commit msgs subject line prefixed with tpm.

v2:

- Fixes issues as given in feedback by Jason.
- Adds documentation for device tree.

Nayna Jain (2):
  tpm: enhance read_log_of() to support Physical TPM event log
  tpm: add securityfs support for TPM 2.0 firmware event log

 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_eventlog.h|  70 +++
 drivers/char/tpm/tpm_of.c  |  27 ++-
 5 files changed, 318 insertions(+), 19 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

-- 
2.5.0

[PATCH v7 1/2] tpm: enhance read_log_of() to support Physical TPM event log

[Nayna Jain]

Physical TPMs use Open Firmware Device Tree bindings that are similar
to the IBM Power virtual TPM to support event log. However, these
properties store the values in different endianness for Physical
and Virtual TPM.

This patch fixes the endianness issue by doing appropriate conversion
based on Physical or Virtual TPM.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/tpm_of.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm_of.c b/drivers/char/tpm/tpm_of.c
index 7dee42d7..de57d4a 100644
--- a/drivers/char/tpm/tpm_of.c
+++ b/drivers/char/tpm/tpm_of.c
@@ -27,6 +27,8 @@ int tpm_read_log_of(struct tpm_chip *chip)
const u32 *sizep;
const u64 *basep;
struct tpm_bios_log *log;
+   u32 size;
+   u64 base;
 
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -41,18 +43,35 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (sizep == NULL || basep == NULL)
return -EIO;
 
-   if (*sizep == 0) {
+   /*
+* For both vtpm/tpm, firmware has log addr and log size in big
+* endian format. But in case of vtpm, there is a method called
+* sml-handover which is run during kernel init even before
+* device tree is setup. This sml-handover function takes care
+* of endianness and writes to sml-base and sml-size in little
+* endian format. For this reason, vtpm doesn't need conversion
+* but physical tpm needs the conversion.
+*/
+   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0) {
+   size = be32_to_cpup(sizep);
+   base = be64_to_cpup(basep);
+   } else {
+   size = *sizep;
+   base = *basep;
+   }
+
+   if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
return -EIO;
}
 
-   log->bios_event_log = kmalloc(*sizep, GFP_KERNEL);
+   log->bios_event_log = kmalloc(size, GFP_KERNEL);
if (!log->bios_event_log)
return -ENOMEM;
 
-   log->bios_event_log_end = log->bios_event_log + *sizep;
+   log->bios_event_log_end = log->bios_event_log + size;
 
-   memcpy(log->bios_event_log, __va(*basep), *sizep);
+   memcpy(log->bios_event_log, __va(base), size);
 
return 0;
 }
-- 
2.5.0

[PATCH v7 2/2] tpm: add securityfs support for TPM 2.0 firmware event log

[Nayna Jain]

Unlike the device driver support for TPM 1.2, the TPM 2.0 does
not support the securityfs pseudo files for displaying the
firmware event log.

This patch enables support for providing the TPM 2.0 event log in
binary form. TPM 2.0 event log supports a crypto agile format that
records multiple digests, which is different from TPM 1.2. This
patch enables the tpm_bios_log_setup for TPM 2.0  and adds the
event log parser which understand the TPM 2.0 crypto agile format.

Signed-off-by: Nayna Jain 
---
 drivers/char/tpm/Makefile  |   2 +-
 .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c}   |  35 ++--
 drivers/char/tpm/tpm2_eventlog.c   | 203 +
 drivers/char/tpm/tpm_eventlog.h|  70 +++
 4 files changed, 295 insertions(+), 15 deletions(-)
 rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
 create mode 100644 drivers/char/tpm/tpm2_eventlog.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index a05b1eb..3d386a8 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -3,7 +3,7 @@
 #
 obj-$(CONFIG_TCG_TPM) += tpm.o
 tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o tpm-chip.o tpm2-cmd.o \
-   tpm_eventlog.o
+   tpm1_eventlog.o tpm2_eventlog.o
 tpm-$(CONFIG_ACPI) += tpm_ppi.o tpm_acpi.o
 tpm-$(CONFIG_OF) += tpm_of.o
 obj-$(CONFIG_TCG_TIS_CORE) += tpm_tis_core.o
diff --git a/drivers/char/tpm/tpm_eventlog.c b/drivers/char/tpm/tpm1_eventlog.c
similarity index 95%
rename from drivers/char/tpm/tpm_eventlog.c
rename to drivers/char/tpm/tpm1_eventlog.c
index 11bb113..9a8605e 100644
--- a/drivers/char/tpm/tpm_eventlog.c
+++ b/drivers/char/tpm/tpm1_eventlog.c
@@ -390,9 +390,6 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
unsigned int cnt;
int rc = 0;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   return 0;
-
rc = tpm_read_log(chip);
if (rc)
return rc;
@@ -407,7 +404,13 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
cnt++;
 
chip->bin_log_seqops.chip = chip;
-   chip->bin_log_seqops.seqops = _binary_b_measurements_seqops;
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+   else
+   chip->bin_log_seqops.seqops =
+   _binary_b_measurements_seqops;
+
 
chip->bios_dir[cnt] =
securityfs_create_file("binary_bios_measurements",
@@ -418,17 +421,21 @@ int tpm_bios_log_setup(struct tpm_chip *chip)
goto err;
cnt++;
 
-   chip->ascii_log_seqops.chip = chip;
-   chip->ascii_log_seqops.seqops = _ascii_b_measurements_seqops;
+   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
 
-   chip->bios_dir[cnt] =
-   securityfs_create_file("ascii_bios_measurements",
-  0440, chip->bios_dir[0],
-  (void *)>ascii_log_seqops,
-  _bios_measurements_ops);
-   if (IS_ERR(chip->bios_dir[cnt]))
-   goto err;
-   cnt++;
+   chip->ascii_log_seqops.chip = chip;
+   chip->ascii_log_seqops.seqops =
+   _ascii_b_measurements_seqops;
+
+   chip->bios_dir[cnt] =
+   securityfs_create_file("ascii_bios_measurements",
+  0440, chip->bios_dir[0],
+  (void *)>ascii_log_seqops,
+  _bios_measurements_ops);
+   if (IS_ERR(chip->bios_dir[cnt]))
+   goto err;
+   cnt++;
+   }
 
return 0;
 
diff --git a/drivers/char/tpm/tpm2_eventlog.c b/drivers/char/tpm/tpm2_eventlog.c
new file mode 100644
index 000..63690d3
--- /dev/null
+++ b/drivers/char/tpm/tpm2_eventlog.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2016 IBM Corporation
+ *
+ * Authors:
+ *  Nayna Jain 
+ *
+ * Access to TPM 2.0 event log as written by Firmware.
+ * It assumes that writer of event log has followed TCG Specification
+ * for Family "2.0" and written the event data in little endian.
+ * With that, it doesn't need any endian conversion for structure
+ * content.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tpm.h"
+#include "tpm_eventlog.h"
+
+static int calc_tpm2_event_size(struct tcg_pcr_event2 *event,
+   struct tcg_pcr_event *event_header)
+{
+   struct tcg_efi_specid_event *efispecid;
+   struct tcg_event_field *event_field;
+   void *marker;
+   void *marker_start;
+   int 

Re: [PATCH v2] net: ethernet: ti: netcp: add support of cpts

[David Miller]

From: Grygorii Strashko 
Date: Thu, 8 Dec 2016 16:21:56 -0600

> From: WingMan Kwok 
> 
> This patch adds support of the cpts device found in the
> gbe and 10gbe ethernet switches on the keystone 2 SoCs
> (66AK2E/L/Hx, 66AK2Gx).
> 
> Cc: Richard Cochran 
> Signed-off-by: WingMan Kwok 
> Signed-off-by: Grygorii Strashko 
> ---
> changes in v2:
>  - dropped bindings changes
> 
> link on v1:
>  https://lkml.org/lkml/2016/11/28/781

Applied.

Re: [PATCH v2] net: ethernet: ti: netcp: add support of cpts

[David Miller]

From: Grygorii Strashko 
Date: Thu, 8 Dec 2016 16:21:56 -0600

> From: WingMan Kwok 
> 
> This patch adds support of the cpts device found in the
> gbe and 10gbe ethernet switches on the keystone 2 SoCs
> (66AK2E/L/Hx, 66AK2Gx).
> 
> Cc: Richard Cochran 
> Signed-off-by: WingMan Kwok 
> Signed-off-by: Grygorii Strashko 
> ---
> changes in v2:
>  - dropped bindings changes
> 
> link on v1:
>  https://lkml.org/lkml/2016/11/28/781

Applied.

ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!

[kbuild test robot]

Hi Junjie,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 14155cafeadda946376260e2ad5d39a0528a332f btrfs: assign error values to 
the correct bio structs
date:   8 weeks ago
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 14155cafeadda946376260e2ad5d39a0528a332f
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   ERROR: "devm_gpiod_get_optional" [net/rfkill/rfkill-gpio.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/tps62360-regulator.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/regulator/pwm-regulator.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/max8973-regulator.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/max8952.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/lp872x.ko] undefined!
   ERROR: "devm_gpio_request" [drivers/pps/clients/pps-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/sbs-battery.ko] 
undefined!
   ERROR: "devm_gpio_request" [drivers/power/supply/max8903_charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_index" [drivers/power/supply/bq25890_charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24735-charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24257_charger.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/st21nfca/st21nfca_i2c.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/st-nci/st-nci_i2c.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/nxp-nci/nxp-nci_i2c.ko] 
undefined!
   ERROR: "devm_gpio_free" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/nfc/fdp/fdp_i2c.ko] undefined!
   ERROR: "devm_gpio_request" [drivers/net/phy/mdio-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/net/phy/at803x.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/net/dsa/mv88e6xxx/mv88e6xxx.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-lt3593.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/leds/leds-lp8860.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-lp55xx-common.ko] 
undefined!
   ERROR: "devm_gpiod_get" [drivers/leds/leds-ktd2692.ko] undefined!
   ERROR: "devm_get_gpiod_from_child" [drivers/leds/leds-gpio.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/proximity/sx9500.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/pressure/hp03.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/iio/pressure/bmp280.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/iio/magnetometer/ak8975.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/iio/dac/ad5592r-base.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/accel/mma9551.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/extcon/extcon-usb-gpio.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/extcon/extcon-max3355.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-gpio.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/bluetooth/hci_uart.ko] undefined!
>> ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] 
>> undefined!

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


.config.gz
Description: application/gzip

ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined!

[kbuild test robot]

Hi Junjie,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 14155cafeadda946376260e2ad5d39a0528a332f btrfs: assign error values to 
the correct bio structs
date:   8 weeks ago
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 14155cafeadda946376260e2ad5d39a0528a332f
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   ERROR: "devm_gpiod_get_optional" [net/rfkill/rfkill-gpio.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/tps62360-regulator.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/regulator/pwm-regulator.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/max8973-regulator.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/max8952.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/regulator/lp872x.ko] undefined!
   ERROR: "devm_gpio_request" [drivers/pps/clients/pps-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/sbs-battery.ko] 
undefined!
   ERROR: "devm_gpio_request" [drivers/power/supply/max8903_charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_index" [drivers/power/supply/bq25890_charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24735-charger.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24257_charger.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/st21nfca/st21nfca_i2c.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/st-nci/st-nci_i2c.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/nxp-nci/nxp-nci_i2c.ko] 
undefined!
   ERROR: "devm_gpio_free" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/nfc/fdp/fdp_i2c.ko] undefined!
   ERROR: "devm_gpio_request" [drivers/net/phy/mdio-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/net/phy/at803x.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/net/dsa/mv88e6xxx/mv88e6xxx.ko] 
undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-lt3593.ko] undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/leds/leds-lp8860.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-lp55xx-common.ko] 
undefined!
   ERROR: "devm_gpiod_get" [drivers/leds/leds-ktd2692.ko] undefined!
   ERROR: "devm_get_gpiod_from_child" [drivers/leds/leds-gpio.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/leds/leds-gpio.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/proximity/sx9500.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/pressure/hp03.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/iio/pressure/bmp280.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/iio/magnetometer/ak8975.ko] 
undefined!
   ERROR: "devm_gpiod_get_optional" [drivers/iio/dac/ad5592r-base.ko] undefined!
   ERROR: "devm_gpiod_get_index" [drivers/iio/accel/mma9551.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/extcon/extcon-usb-gpio.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/extcon/extcon-max3355.ko] undefined!
   ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-gpio.ko] undefined!
   ERROR: "devm_gpiod_get" [drivers/bluetooth/hci_uart.ko] undefined!
>> ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] 
>> undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH net-next 3/3] net: l2tp: ppp: change PPPOL2TP_MSG_* => L2TP_MSG_*

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:59 +

> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: [PATCH net-next 3/3] net: l2tp: ppp: change PPPOL2TP_MSG_* => L2TP_MSG_*

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:59 +

> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: [PATCH net-next 2/3] net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:58 +

> PPPOL2TP_MSG_* and L2TP_MSG_* are duplicates, and are being used
> interchangeably in the kernel, so let's standardize on L2TP_MSG_*
> internally, and keep PPPOL2TP_MSG_* defined in UAPI for compatibility.
> 
> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: [PATCH net-next 1/3] net: l2tp: export debug flags to UAPI

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:57 +

> Move the L2TP_MSG_* definitions to UAPI, as it is part of
> the netlink API.
> 
> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: [PATCH net-next 2/3] net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_*

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:58 +

> PPPOL2TP_MSG_* and L2TP_MSG_* are duplicates, and are being used
> interchangeably in the kernel, so let's standardize on L2TP_MSG_*
> internally, and keep PPPOL2TP_MSG_* defined in UAPI for compatibility.
> 
> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: [PATCH net-next 1/3] net: l2tp: export debug flags to UAPI

[David Miller]

From: Asbjoern Sloth Toennesen 
Date: Sun, 11 Dec 2016 00:18:57 +

> Move the L2TP_MSG_* definitions to UAPI, as it is part of
> the netlink API.
> 
> Signed-off-by: Asbjoern Sloth Toennesen 

Applied.

Re: Remove private tx queue locks

[David Miller]

From: Lino Sanfilippo 
Date: Fri,  9 Dec 2016 00:55:41 +0100

> this patch series removes unnecessary private locks in the sxgbe and the
> stmmac driver.
> 
> v2:
> - adjust commit message

Series applied to net-next, thanks.

Re: Remove private tx queue locks

[David Miller]

From: Lino Sanfilippo 
Date: Fri,  9 Dec 2016 00:55:41 +0100

> this patch series removes unnecessary private locks in the sxgbe and the
> stmmac driver.
> 
> v2:
> - adjust commit message

Series applied to net-next, thanks.

arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction

[kbuild test robot]

Hi Pete,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for 
Diamond 233L - Rev C processor variant
date:   3 years, 10 months ago
config: xtensa-generic_kc705_defconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d0b73b488c55df905ea8faaad079f8535629ed26
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +41 arch/xtensa/include/asm/initialize_mmu.h

c622b29d Max Filippov 2012-11-19  25  
c622b29d Max Filippov 2012-11-19  26  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  27  
c622b29d Max Filippov 2012-11-19  28  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  29  
c622b29d Max Filippov 2012-11-19  30.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  31  
c622b29d Max Filippov 2012-11-19  32  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  33  /*
c622b29d Max Filippov 2012-11-19  34   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  35   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  36   */
c622b29d Max Filippov 2012-11-19  37  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  38movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  39 * RCW otherwise
c622b29d Max Filippov 2012-11-19  40 */
c622b29d Max Filippov 2012-11-19 @41  #else
c622b29d Max Filippov 2012-11-19  42movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  43 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  44 */
c622b29d Max Filippov 2012-11-19  45  #endif
c622b29d Max Filippov 2012-11-19  46wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  47  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  48 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  49 */

:: The code at line 41 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: application/gzip

arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction

[kbuild test robot]

Hi Pete,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for 
Diamond 233L - Rev C processor variant
date:   3 years, 10 months ago
config: xtensa-generic_kc705_defconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d0b73b488c55df905ea8faaad079f8535629ed26
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +41 arch/xtensa/include/asm/initialize_mmu.h

c622b29d Max Filippov 2012-11-19  25  
c622b29d Max Filippov 2012-11-19  26  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  27  
c622b29d Max Filippov 2012-11-19  28  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  29  
c622b29d Max Filippov 2012-11-19  30.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  31  
c622b29d Max Filippov 2012-11-19  32  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  33  /*
c622b29d Max Filippov 2012-11-19  34   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  35   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  36   */
c622b29d Max Filippov 2012-11-19  37  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  38movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  39 * RCW otherwise
c622b29d Max Filippov 2012-11-19  40 */
c622b29d Max Filippov 2012-11-19 @41  #else
c622b29d Max Filippov 2012-11-19  42movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  43 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  44 */
c622b29d Max Filippov 2012-11-19  45  #endif
c622b29d Max Filippov 2012-11-19  46wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  47  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  48 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  49 */

:: The code at line 41 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: application/gzip

Re: [PATCH] x86/smpboot: Make logical package management more robust

[Boris Ostrovsky]

On 12/10/2016 02:13 PM, Thomas Gleixner wrote:

On Sat, 10 Dec 2016, Thomas Gleixner wrote:

On Fri, 9 Dec 2016, Boris Ostrovsky wrote:

On 12/09/2016 06:02 PM, Boris Ostrovsky wrote:

On 12/09/2016 05:06 PM, Thomas Gleixner wrote:

On Thu, 8 Dec 2016, Thomas Gleixner wrote:

Boris, can you please verify if that makes the
topology_update_package_map() call which you placed into the Xen cpu
starting code obsolete ?


Will do. I did test your patch but without removing
topology_update_package_map() call. It complained about package IDs
being wrong, but that's expected until I fix Xen part.


Ignore my statement about earlier testing --- it was all on single-node
machines.

Something is broken with multi-node on Intel, but failure modes are different.
Prior to this patch build_sched_domain() reports an error and pretty soon we
crash in scheduler (don't remember off the top of my head). With patch applied
I crash mush later, when one of the drivers does kmalloc_node(..,
cpu_to_node(cpu)) and cpu_to_node() returns 1, which should never happen
("x86: Booted up 1 node, 32 CPUs" is reported, for example).


Hmm. But the cpu_to_node() association is unrelated to the logical package
management.


Just came to my mind after hitting send. We had the whole persistent cpuid
to nodeid association work merged in 4.9. So that might be related.



Yes, that's exactly the reason.

It uses _PXM to set nodeID and _PXM is exposed to dom0 (which is a 
privileged PV guest).


Re: you previous message: after I "fix" the problem above,  I see
pr_info("Max logical packages: %u\n", __max_logical_packages);
but no
pr_warn(CPU %u Converting physical %u to logical package %u\n", ...)

with or without topology_update_package_map() in 
arch/x86/xen/smp.c:cpu_bringup()



-boris

Re: [PATCH] x86/smpboot: Make logical package management more robust

[Boris Ostrovsky]

On 12/10/2016 02:13 PM, Thomas Gleixner wrote:

On Sat, 10 Dec 2016, Thomas Gleixner wrote:

On Fri, 9 Dec 2016, Boris Ostrovsky wrote:

On 12/09/2016 06:02 PM, Boris Ostrovsky wrote:

On 12/09/2016 05:06 PM, Thomas Gleixner wrote:

On Thu, 8 Dec 2016, Thomas Gleixner wrote:

Boris, can you please verify if that makes the
topology_update_package_map() call which you placed into the Xen cpu
starting code obsolete ?


Will do. I did test your patch but without removing
topology_update_package_map() call. It complained about package IDs
being wrong, but that's expected until I fix Xen part.


Ignore my statement about earlier testing --- it was all on single-node
machines.

Something is broken with multi-node on Intel, but failure modes are different.
Prior to this patch build_sched_domain() reports an error and pretty soon we
crash in scheduler (don't remember off the top of my head). With patch applied
I crash mush later, when one of the drivers does kmalloc_node(..,
cpu_to_node(cpu)) and cpu_to_node() returns 1, which should never happen
("x86: Booted up 1 node, 32 CPUs" is reported, for example).


Hmm. But the cpu_to_node() association is unrelated to the logical package
management.


Just came to my mind after hitting send. We had the whole persistent cpuid
to nodeid association work merged in 4.9. So that might be related.



Yes, that's exactly the reason.

It uses _PXM to set nodeID and _PXM is exposed to dom0 (which is a 
privileged PV guest).


Re: you previous message: after I "fix" the problem above,  I see
pr_info("Max logical packages: %u\n", __max_logical_packages);
but no
pr_warn(CPU %u Converting physical %u to logical package %u\n", ...)

with or without topology_update_package_map() in 
arch/x86/xen/smp.c:cpu_bringup()



-boris

Re: [PATCH net 0/3] net: bridge: fast ageing on topology change

[David Miller]

From: Vivien Didelot 
Date: Sat, 10 Dec 2016 13:44:26 -0500

> 802.1D [1] specifies that the bridges in a network must use a short
> value to age out dynamic entries in the Filtering Database for a period,
> once a topology change has been communicated by the root bridge.
> 
> This patchset fixes this for the in-kernel STP implementation.
 ...

Series applied.

Re: [PATCH net 0/3] net: bridge: fast ageing on topology change

[David Miller]

From: Vivien Didelot 
Date: Sat, 10 Dec 2016 13:44:26 -0500

> 802.1D [1] specifies that the bridges in a network must use a short
> value to age out dynamic entries in the Filtering Database for a period,
> once a topology change has been communicated by the root bridge.
> 
> This patchset fixes this for the in-kernel STP implementation.
 ...

Series applied.

Re: [PATCH 09/10] vsock/virtio: fix src/dst cid format

[Michael S. Tsirkin]

On Wed, Dec 07, 2016 at 12:31:56PM +0800, Jason Wang wrote:
> 
> 
> On 2016年12月06日 23:41, Michael S. Tsirkin wrote:
> > These fields are 64 bit, using le32_to_cpu and friends
> > on these will not do the right thing.
> > Fix this up.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >   net/vmw_vsock/virtio_transport_common.c | 14 +++---
> >   1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net/vmw_vsock/virtio_transport_common.c 
> > b/net/vmw_vsock/virtio_transport_common.c
> > index 6120384..22e99c4 100644
> > --- a/net/vmw_vsock/virtio_transport_common.c
> > +++ b/net/vmw_vsock/virtio_transport_common.c
> > @@ -606,9 +606,9 @@ static int virtio_transport_reset_no_sock(struct 
> > virtio_vsock_pkt *pkt)
> > return 0;
> > pkt = virtio_transport_alloc_pkt(, 0,
> > -le32_to_cpu(pkt->hdr.dst_cid),
> > +le64_to_cpu(pkt->hdr.dst_cid),
> >  le32_to_cpu(pkt->hdr.dst_port),
> > -le32_to_cpu(pkt->hdr.src_cid),
> > +le64_to_cpu(pkt->hdr.src_cid),
> >  le32_to_cpu(pkt->hdr.src_port));
> 
> Looking at sockaddr_vm, svm_cid is "unsigned int", do we really want 64 bit
> here?

Can't change the protocol at this point.


> > if (!pkt)
> > return -ENOMEM;
> > @@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
> > struct virtio_vsock_pkt_info info = {
> > .op = VIRTIO_VSOCK_OP_RESPONSE,
> > .type = VIRTIO_VSOCK_TYPE_STREAM,
> > -   .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
> > +   .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
> > .remote_port = le32_to_cpu(pkt->hdr.src_port),
> > .reply = true,
> > };
> > @@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct 
> > virtio_vsock_pkt *pkt)
> > child->sk_state = SS_CONNECTED;
> > vchild = vsock_sk(child);
> > -   vsock_addr_init(>local_addr, le32_to_cpu(pkt->hdr.dst_cid),
> > +   vsock_addr_init(>local_addr, le64_to_cpu(pkt->hdr.dst_cid),
> > le32_to_cpu(pkt->hdr.dst_port));
> > -   vsock_addr_init(>remote_addr, le32_to_cpu(pkt->hdr.src_cid),
> > +   vsock_addr_init(>remote_addr, le64_to_cpu(pkt->hdr.src_cid),
> > le32_to_cpu(pkt->hdr.src_port));
> > vsock_insert_connected(vchild);
> > @@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct virtio_vsock_pkt 
> > *pkt)
> > struct sock *sk;
> > bool space_available;
> > -   vsock_addr_init(, le32_to_cpu(pkt->hdr.src_cid),
> > +   vsock_addr_init(, le64_to_cpu(pkt->hdr.src_cid),
> > le32_to_cpu(pkt->hdr.src_port));
> > -   vsock_addr_init(, le32_to_cpu(pkt->hdr.dst_cid),
> > +   vsock_addr_init(, le64_to_cpu(pkt->hdr.dst_cid),
> > le32_to_cpu(pkt->hdr.dst_port));
> > trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,

Re: [PATCH 09/10] vsock/virtio: fix src/dst cid format

[Michael S. Tsirkin]

On Wed, Dec 07, 2016 at 12:31:56PM +0800, Jason Wang wrote:
> 
> 
> On 2016年12月06日 23:41, Michael S. Tsirkin wrote:
> > These fields are 64 bit, using le32_to_cpu and friends
> > on these will not do the right thing.
> > Fix this up.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >   net/vmw_vsock/virtio_transport_common.c | 14 +++---
> >   1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net/vmw_vsock/virtio_transport_common.c 
> > b/net/vmw_vsock/virtio_transport_common.c
> > index 6120384..22e99c4 100644
> > --- a/net/vmw_vsock/virtio_transport_common.c
> > +++ b/net/vmw_vsock/virtio_transport_common.c
> > @@ -606,9 +606,9 @@ static int virtio_transport_reset_no_sock(struct 
> > virtio_vsock_pkt *pkt)
> > return 0;
> > pkt = virtio_transport_alloc_pkt(, 0,
> > -le32_to_cpu(pkt->hdr.dst_cid),
> > +le64_to_cpu(pkt->hdr.dst_cid),
> >  le32_to_cpu(pkt->hdr.dst_port),
> > -le32_to_cpu(pkt->hdr.src_cid),
> > +le64_to_cpu(pkt->hdr.src_cid),
> >  le32_to_cpu(pkt->hdr.src_port));
> 
> Looking at sockaddr_vm, svm_cid is "unsigned int", do we really want 64 bit
> here?

Can't change the protocol at this point.


> > if (!pkt)
> > return -ENOMEM;
> > @@ -823,7 +823,7 @@ virtio_transport_send_response(struct vsock_sock *vsk,
> > struct virtio_vsock_pkt_info info = {
> > .op = VIRTIO_VSOCK_OP_RESPONSE,
> > .type = VIRTIO_VSOCK_TYPE_STREAM,
> > -   .remote_cid = le32_to_cpu(pkt->hdr.src_cid),
> > +   .remote_cid = le64_to_cpu(pkt->hdr.src_cid),
> > .remote_port = le32_to_cpu(pkt->hdr.src_port),
> > .reply = true,
> > };
> > @@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock *sk, struct 
> > virtio_vsock_pkt *pkt)
> > child->sk_state = SS_CONNECTED;
> > vchild = vsock_sk(child);
> > -   vsock_addr_init(>local_addr, le32_to_cpu(pkt->hdr.dst_cid),
> > +   vsock_addr_init(>local_addr, le64_to_cpu(pkt->hdr.dst_cid),
> > le32_to_cpu(pkt->hdr.dst_port));
> > -   vsock_addr_init(>remote_addr, le32_to_cpu(pkt->hdr.src_cid),
> > +   vsock_addr_init(>remote_addr, le64_to_cpu(pkt->hdr.src_cid),
> > le32_to_cpu(pkt->hdr.src_port));
> > vsock_insert_connected(vchild);
> > @@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct virtio_vsock_pkt 
> > *pkt)
> > struct sock *sk;
> > bool space_available;
> > -   vsock_addr_init(, le32_to_cpu(pkt->hdr.src_cid),
> > +   vsock_addr_init(, le64_to_cpu(pkt->hdr.src_cid),
> > le32_to_cpu(pkt->hdr.src_port));
> > -   vsock_addr_init(, le32_to_cpu(pkt->hdr.dst_cid),
> > +   vsock_addr_init(, le64_to_cpu(pkt->hdr.dst_cid),
> > le32_to_cpu(pkt->hdr.dst_port));
> > trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,

[PATCH v3 2/2] staging: iio: ad7606: move out of staging

[Eva Rachel Retuya]

Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the
corresponding Makefile and Kconfig associated with the change.

Signed-off-by: Eva Rachel Retuya 
---
 drivers/iio/adc/Kconfig| 34 ++
 drivers/iio/adc/Makefile   |  3 +++
 drivers/{staging => }/iio/adc/ad7606.c |  0
 drivers/{staging => }/iio/adc/ad7606.h |  0
 drivers/{staging => }/iio/adc/ad7606_par.c |  0
 drivers/{staging => }/iio/adc/ad7606_spi.c |  0
 drivers/staging/iio/adc/Kconfig| 34 --
 drivers/staging/iio/adc/Makefile   |  4 
 8 files changed, 37 insertions(+), 38 deletions(-)
 rename drivers/{staging => }/iio/adc/ad7606.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606.h (100%)
 rename drivers/{staging => }/iio/adc/ad7606_par.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606_spi.c (100%)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index be81ba3..3fa2c60 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -58,6 +58,40 @@ config AD7476
  To compile this driver as a module, choose M here: the
  module will be called ad7476.
 
+config AD7606
+   tristate "Analog Devices AD7606 ADC driver"
+   depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to build support for Analog Devices:
+ ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606.
+
+config AD7606_IFACE_PARALLEL
+   tristate "parallel interface support"
+   depends on AD7606
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_parallel.
+
+config AD7606_IFACE_SPI
+   tristate "spi interface support"
+   depends on AD7606
+   depends on SPI
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_spi.
+
 config AD7766
tristate "Analog Devices AD7766/AD7767 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index f8e1218..dfe7dea 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -9,6 +9,9 @@ obj-$(CONFIG_AD7291) += ad7291.o
 obj-$(CONFIG_AD7298) += ad7298.o
 obj-$(CONFIG_AD7923) += ad7923.o
 obj-$(CONFIG_AD7476) += ad7476.o
+obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
+obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
+obj-$(CONFIG_AD7606) += ad7606.o
 obj-$(CONFIG_AD7766) += ad7766.o
 obj-$(CONFIG_AD7791) += ad7791.o
 obj-$(CONFIG_AD7793) += ad7793.o
diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606.c
rename to drivers/iio/adc/ad7606.c
diff --git a/drivers/staging/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
similarity index 100%
rename from drivers/staging/iio/adc/ad7606.h
rename to drivers/iio/adc/ad7606.h
diff --git a/drivers/staging/iio/adc/ad7606_par.c b/drivers/iio/adc/ad7606_par.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606_par.c
rename to drivers/iio/adc/ad7606_par.c
diff --git a/drivers/staging/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606_spi.c
rename to drivers/iio/adc/ad7606_spi.c
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index deff899..995867b 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -3,40 +3,6 @@
 #
 menu "Analog to digital converters"
 
-config AD7606
-   tristate "Analog Devices AD7606 ADC driver"
-   depends on GPIOLIB || COMPILE_TEST
-   depends on HAS_IOMEM
-   select IIO_BUFFER
-   select IIO_TRIGGERED_BUFFER
-   help
- Say yes here to build support for Analog Devices:
- ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
-
- To compile this driver as a module, choose M here: the
- module will be called ad7606.
-
-config AD7606_IFACE_PARALLEL
-   tristate "parallel interface support"
-   depends on AD7606
-   help
- Say yes here to include parallel interface support on the AD7606
- ADC driver.
-
- To compile this driver as a module, choose M here: the
- module will be called ad7606_parallel.
-
-config AD7606_IFACE_SPI
-   tristate "spi interface support"
-   depends on AD7606
-   depends on SPI
-   help
- Say yes here to include parallel interface support on the AD7606
- ADC driver.
-
-   

[PATCH v3 2/2] staging: iio: ad7606: move out of staging

[Eva Rachel Retuya]

Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the
corresponding Makefile and Kconfig associated with the change.

Signed-off-by: Eva Rachel Retuya 
---
 drivers/iio/adc/Kconfig| 34 ++
 drivers/iio/adc/Makefile   |  3 +++
 drivers/{staging => }/iio/adc/ad7606.c |  0
 drivers/{staging => }/iio/adc/ad7606.h |  0
 drivers/{staging => }/iio/adc/ad7606_par.c |  0
 drivers/{staging => }/iio/adc/ad7606_spi.c |  0
 drivers/staging/iio/adc/Kconfig| 34 --
 drivers/staging/iio/adc/Makefile   |  4 
 8 files changed, 37 insertions(+), 38 deletions(-)
 rename drivers/{staging => }/iio/adc/ad7606.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606.h (100%)
 rename drivers/{staging => }/iio/adc/ad7606_par.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606_spi.c (100%)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index be81ba3..3fa2c60 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -58,6 +58,40 @@ config AD7476
  To compile this driver as a module, choose M here: the
  module will be called ad7476.
 
+config AD7606
+   tristate "Analog Devices AD7606 ADC driver"
+   depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to build support for Analog Devices:
+ ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606.
+
+config AD7606_IFACE_PARALLEL
+   tristate "parallel interface support"
+   depends on AD7606
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_parallel.
+
+config AD7606_IFACE_SPI
+   tristate "spi interface support"
+   depends on AD7606
+   depends on SPI
+   help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_spi.
+
 config AD7766
tristate "Analog Devices AD7766/AD7767 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index f8e1218..dfe7dea 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -9,6 +9,9 @@ obj-$(CONFIG_AD7291) += ad7291.o
 obj-$(CONFIG_AD7298) += ad7298.o
 obj-$(CONFIG_AD7923) += ad7923.o
 obj-$(CONFIG_AD7476) += ad7476.o
+obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
+obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
+obj-$(CONFIG_AD7606) += ad7606.o
 obj-$(CONFIG_AD7766) += ad7766.o
 obj-$(CONFIG_AD7791) += ad7791.o
 obj-$(CONFIG_AD7793) += ad7793.o
diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606.c
rename to drivers/iio/adc/ad7606.c
diff --git a/drivers/staging/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
similarity index 100%
rename from drivers/staging/iio/adc/ad7606.h
rename to drivers/iio/adc/ad7606.h
diff --git a/drivers/staging/iio/adc/ad7606_par.c b/drivers/iio/adc/ad7606_par.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606_par.c
rename to drivers/iio/adc/ad7606_par.c
diff --git a/drivers/staging/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c
similarity index 100%
rename from drivers/staging/iio/adc/ad7606_spi.c
rename to drivers/iio/adc/ad7606_spi.c
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index deff899..995867b 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -3,40 +3,6 @@
 #
 menu "Analog to digital converters"
 
-config AD7606
-   tristate "Analog Devices AD7606 ADC driver"
-   depends on GPIOLIB || COMPILE_TEST
-   depends on HAS_IOMEM
-   select IIO_BUFFER
-   select IIO_TRIGGERED_BUFFER
-   help
- Say yes here to build support for Analog Devices:
- ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC).
-
- To compile this driver as a module, choose M here: the
- module will be called ad7606.
-
-config AD7606_IFACE_PARALLEL
-   tristate "parallel interface support"
-   depends on AD7606
-   help
- Say yes here to include parallel interface support on the AD7606
- ADC driver.
-
- To compile this driver as a module, choose M here: the
- module will be called ad7606_parallel.
-
-config AD7606_IFACE_SPI
-   tristate "spi interface support"
-   depends on AD7606
-   depends on SPI
-   help
- Say yes here to include parallel interface support on the AD7606
- ADC driver.
-
- To compile this 

[PATCH v3 0/2] staging: iio: ad7606: move driver out of staging

[Eva Rachel Retuya]

Address the last remaining TODO [1] for this driver and move it from staging
into mainline.

[1] https://marc.info/?l=linux-iio=147689684332118=2 

Change in v3:
* Fix incorrect type of 'scale'. (Pointed out by kbuild test robot)

Change in v2:
* Address the incorrect way of implementing the scale. (Pointed out by Lars)

Eva Rachel Retuya (2):
  staging: iio: ad7606: replace range/range_available with corresponding
scale
  staging: iio: ad7606: move out of staging

 drivers/iio/adc/Kconfig|  34 ++
 drivers/iio/adc/Makefile   |   3 +
 drivers/{staging => }/iio/adc/ad7606.c | 100 ++---
 drivers/{staging => }/iio/adc/ad7606.h |   1 +
 drivers/{staging => }/iio/adc/ad7606_par.c |   0
 drivers/{staging => }/iio/adc/ad7606_spi.c |   0
 drivers/staging/iio/adc/Kconfig|  34 --
 drivers/staging/iio/adc/Makefile   |   4 --
 8 files changed, 99 insertions(+), 77 deletions(-)
 rename drivers/{staging => }/iio/adc/ad7606.c (86%)
 rename drivers/{staging => }/iio/adc/ad7606.h (98%)
 rename drivers/{staging => }/iio/adc/ad7606_par.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606_spi.c (100%)

-- 
2.7.4

[PATCH v3 0/2] staging: iio: ad7606: move driver out of staging

[Eva Rachel Retuya]

Address the last remaining TODO [1] for this driver and move it from staging
into mainline.

[1] https://marc.info/?l=linux-iio=147689684332118=2 

Change in v3:
* Fix incorrect type of 'scale'. (Pointed out by kbuild test robot)

Change in v2:
* Address the incorrect way of implementing the scale. (Pointed out by Lars)

Eva Rachel Retuya (2):
  staging: iio: ad7606: replace range/range_available with corresponding
scale
  staging: iio: ad7606: move out of staging

 drivers/iio/adc/Kconfig|  34 ++
 drivers/iio/adc/Makefile   |   3 +
 drivers/{staging => }/iio/adc/ad7606.c | 100 ++---
 drivers/{staging => }/iio/adc/ad7606.h |   1 +
 drivers/{staging => }/iio/adc/ad7606_par.c |   0
 drivers/{staging => }/iio/adc/ad7606_spi.c |   0
 drivers/staging/iio/adc/Kconfig|  34 --
 drivers/staging/iio/adc/Makefile   |   4 --
 8 files changed, 99 insertions(+), 77 deletions(-)
 rename drivers/{staging => }/iio/adc/ad7606.c (86%)
 rename drivers/{staging => }/iio/adc/ad7606.h (98%)
 rename drivers/{staging => }/iio/adc/ad7606_par.c (100%)
 rename drivers/{staging => }/iio/adc/ad7606_spi.c (100%)

-- 
2.7.4

[PATCH v3 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

[Eva Rachel Retuya]

Eliminate the non-standard attributes in_voltage_range and
in_voltage_range_available. Implement in_voltage_scale_available in place
of these attributes and update the SCALE accordingly. The array
scale_avail is introduced to hold the available scale values.

Signed-off-by: Eva Rachel Retuya 
---
Change in v3:
* Change incorrect type of 'scale' from unsigned int to unsigned long long

Changes in v2:
* Update commit message to reflect changes.
* Introduce scale_avail[] array to hold the available scales.
* Rewrite read_raw's SCALE to make use of the scale_avail[].
* Provide write_raw and write_raw_get_fmt for implementing SCALE.
* Populate the scale_avail[] with values in probe().

 drivers/staging/iio/adc/ad7606.c | 100 ---
 drivers/staging/iio/adc/ad7606.h |   1 +
 2 files changed, 62 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c
index 4531908..b878664 100644
--- a/drivers/staging/iio/adc/ad7606.c
+++ b/drivers/staging/iio/adc/ad7606.c
@@ -151,9 +151,9 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
*val = (short)ret;
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
-   *val = st->range * 2;
-   *val2 = st->chip_info->channels[0].scan_type.realbits;
-   return IIO_VAL_FRACTIONAL_LOG2;
+   *val = st->scale_avail[st->range][0];
+   *val2 = st->scale_avail[st->range][1];
+   return IIO_VAL_INT_PLUS_NANO;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
*val = st->oversampling;
return IIO_VAL_INT;
@@ -161,42 +161,24 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 }
 
-static ssize_t ad7606_show_range(struct device *dev,
-struct device_attribute *attr, char *buf)
+static ssize_t in_voltage_scale_available_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ad7606_state *st = iio_priv(indio_dev);
+   int i, len = 0;
 
-   return sprintf(buf, "%u\n", st->range);
-}
-
-static ssize_t ad7606_store_range(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-   unsigned long lval;
-   int ret;
-
-   ret = kstrtoul(buf, 10, );
-   if (ret)
-   return ret;
-
-   if (!(lval == 5000 || lval == 1))
-   return -EINVAL;
+   for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++)
+   len += scnprintf(buf + len, PAGE_SIZE - len, "%d.%09u ",
+st->scale_avail[i][0], st->scale_avail[i][1]);
 
-   mutex_lock(_dev->mlock);
-   gpiod_set_value(st->gpio_range, lval == 1);
-   st->range = lval;
-   mutex_unlock(_dev->mlock);
+   buf[len - 1] = '\n';
 
-   return count;
+   return len;
 }
 
-static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR,
-  ad7606_show_range, ad7606_store_range, 0);
-static IIO_CONST_ATTR(in_voltage_range_available, "5000 1");
+static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
 
 static int ad7606_oversampling_get_index(unsigned int val)
 {
@@ -218,9 +200,23 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
 {
struct ad7606_state *st = iio_priv(indio_dev);
int values[3];
-   int ret;
+   int ret, i;
 
switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   ret = -EINVAL;
+   mutex_lock(_dev->mlock);
+   for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++)
+   if (val2 == st->scale_avail[i][1]) {
+   gpiod_set_value(st->gpio_range, i);
+   st->range = i;
+
+   ret = 0;
+   break;
+   }
+   mutex_unlock(_dev->mlock);
+
+   return ret;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
if (val2)
return -EINVAL;
@@ -244,11 +240,22 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
}
 }
 
+static int ad7606_write_raw_get_fmt(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   long mask)
+{
+   switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   return IIO_VAL_INT_PLUS_NANO;
+   default:
+   return -EINVAL;
+   }
+}
+
 static IIO_CONST_ATTR(oversampling_ratio_available, "1 2 4 8 16 32 64");
 
 static struct attribute 

[PATCH v3 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

[Eva Rachel Retuya]

Eliminate the non-standard attributes in_voltage_range and
in_voltage_range_available. Implement in_voltage_scale_available in place
of these attributes and update the SCALE accordingly. The array
scale_avail is introduced to hold the available scale values.

Signed-off-by: Eva Rachel Retuya 
---
Change in v3:
* Change incorrect type of 'scale' from unsigned int to unsigned long long

Changes in v2:
* Update commit message to reflect changes.
* Introduce scale_avail[] array to hold the available scales.
* Rewrite read_raw's SCALE to make use of the scale_avail[].
* Provide write_raw and write_raw_get_fmt for implementing SCALE.
* Populate the scale_avail[] with values in probe().

 drivers/staging/iio/adc/ad7606.c | 100 ---
 drivers/staging/iio/adc/ad7606.h |   1 +
 2 files changed, 62 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606.c b/drivers/staging/iio/adc/ad7606.c
index 4531908..b878664 100644
--- a/drivers/staging/iio/adc/ad7606.c
+++ b/drivers/staging/iio/adc/ad7606.c
@@ -151,9 +151,9 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
*val = (short)ret;
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
-   *val = st->range * 2;
-   *val2 = st->chip_info->channels[0].scan_type.realbits;
-   return IIO_VAL_FRACTIONAL_LOG2;
+   *val = st->scale_avail[st->range][0];
+   *val2 = st->scale_avail[st->range][1];
+   return IIO_VAL_INT_PLUS_NANO;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
*val = st->oversampling;
return IIO_VAL_INT;
@@ -161,42 +161,24 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 }
 
-static ssize_t ad7606_show_range(struct device *dev,
-struct device_attribute *attr, char *buf)
+static ssize_t in_voltage_scale_available_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
 {
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ad7606_state *st = iio_priv(indio_dev);
+   int i, len = 0;
 
-   return sprintf(buf, "%u\n", st->range);
-}
-
-static ssize_t ad7606_store_range(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
-   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
-   struct ad7606_state *st = iio_priv(indio_dev);
-   unsigned long lval;
-   int ret;
-
-   ret = kstrtoul(buf, 10, );
-   if (ret)
-   return ret;
-
-   if (!(lval == 5000 || lval == 1))
-   return -EINVAL;
+   for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++)
+   len += scnprintf(buf + len, PAGE_SIZE - len, "%d.%09u ",
+st->scale_avail[i][0], st->scale_avail[i][1]);
 
-   mutex_lock(_dev->mlock);
-   gpiod_set_value(st->gpio_range, lval == 1);
-   st->range = lval;
-   mutex_unlock(_dev->mlock);
+   buf[len - 1] = '\n';
 
-   return count;
+   return len;
 }
 
-static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR,
-  ad7606_show_range, ad7606_store_range, 0);
-static IIO_CONST_ATTR(in_voltage_range_available, "5000 1");
+static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
 
 static int ad7606_oversampling_get_index(unsigned int val)
 {
@@ -218,9 +200,23 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
 {
struct ad7606_state *st = iio_priv(indio_dev);
int values[3];
-   int ret;
+   int ret, i;
 
switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   ret = -EINVAL;
+   mutex_lock(_dev->mlock);
+   for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++)
+   if (val2 == st->scale_avail[i][1]) {
+   gpiod_set_value(st->gpio_range, i);
+   st->range = i;
+
+   ret = 0;
+   break;
+   }
+   mutex_unlock(_dev->mlock);
+
+   return ret;
case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
if (val2)
return -EINVAL;
@@ -244,11 +240,22 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
}
 }
 
+static int ad7606_write_raw_get_fmt(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan,
+   long mask)
+{
+   switch (mask) {
+   case IIO_CHAN_INFO_SCALE:
+   return IIO_VAL_INT_PLUS_NANO;
+   default:
+   return -EINVAL;
+   }
+}
+
 static IIO_CONST_ATTR(oversampling_ratio_available, "1 2 4 8 16 32 64");
 
 static struct attribute 

Re: [GIT PULL] readlink cleanup

[Al Viro]

On Sun, Dec 11, 2016 at 02:36:20AM +, Al Viro wrote:

> I'm still not sure what does "vfs: convert ->readlink to same signature as
> ->get_link" buy us.  If anything, the result appears to be more complex -
> you make freeing that buffer delayed (and introduce a dynamically allocated
> buffer in one case that didn't use it)...

PS: everything prior to that point looks fine.

Re: [GIT PULL] readlink cleanup

[Al Viro]

On Sun, Dec 11, 2016 at 02:36:20AM +, Al Viro wrote:

> I'm still not sure what does "vfs: convert ->readlink to same signature as
> ->get_link" buy us.  If anything, the result appears to be more complex -
> you make freeing that buffer delayed (and introduce a dynamically allocated
> buffer in one case that didn't use it)...

PS: everything prior to that point looks fine.

Re: [GIT PULL] readlink cleanup

[Al Viro]

On Sat, Dec 10, 2016 at 09:41:45PM +0100, Miklos Szeredi wrote:
> Hi Al,
> 
> Please pull from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git readlink
> 
> This is a rework of the readlink cleanup patchset.  Now readlink(2) does the
> following:
> 
>  - if i_op->readlink() is non-NULL (only proc and afs mountpoints for now) 
> then
>it calls that;
>  - otherwise call i_op->get_link();
>  - signature of ->readlink() now matches that of ->get_link();
> 
> This is against the #misc branch (the stats look better that way ;)

I'm still not sure what does "vfs: convert ->readlink to same signature as
->get_link" buy us.  If anything, the result appears to be more complex -
you make freeing that buffer delayed (and introduce a dynamically allocated
buffer in one case that didn't use it)...

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   9 months ago
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
   fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
   fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_96 +96 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09  80 
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09  81 
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09  82 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  83 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09  84 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  85 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09 @86 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09  87 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  88 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  89 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09  90 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  91 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  92 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09  93 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  94 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  95 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09 @96 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  97 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09  98 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09  99  

:: The code at line 96 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: application/gzip

Re: [GIT PULL] readlink cleanup

[Al Viro]

On Sat, Dec 10, 2016 at 09:41:45PM +0100, Miklos Szeredi wrote:
> Hi Al,
> 
> Please pull from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git readlink
> 
> This is a rework of the readlink cleanup patchset.  Now readlink(2) does the
> following:
> 
>  - if i_op->readlink() is non-NULL (only proc and afs mountpoints for now) 
> then
>it calls that;
>  - otherwise call i_op->get_link();
>  - signature of ->readlink() now matches that of ->get_link();
> 
> This is against the #misc branch (the stats look better that way ;)

I'm still not sure what does "vfs: convert ->readlink to same signature as
->get_link" buy us.  If anything, the result appears to be more complex -
you make freeing that buffer delayed (and introduce a dynamically allocated
buffer in one case that didn't use it)...

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   9 months ago
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
   fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
   fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_96 +96 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09  80 
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09  81 
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09  82 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  83 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09  84 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  85 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09 @86 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09  87 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  88 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  89 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09  90 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  91 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  92 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09  93 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  94 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  95 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09 @96 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  97 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09  98 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09  99  

:: The code at line 96 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: application/gzip

Re: [regression ?] kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled

[Sergey Senozhatsky]

On (12/10/16 16:04), Nicolas Pitre wrote:
> On Sat, 10 Dec 2016, Sergey Senozhatsky wrote:
[..]
> > so this will not install modules:
> >  make prepare; make kernelrelease; make -j4; make prepare; make 
> > kernelrelease; make -j4 INSTALL_MOD_PATH=/tmp/MODULES modules_install
> > 
> > and this will:
> >  make prepare; make kernelrelease; make -j4; make kernelrelease; make -j4 
> > INSTALL_MOD_PATH=/tmp/MODULES modules_install
> 
> Right. And this is because of this in the main Makefile:
> 
> # Create temporary dir for module support files
> # clean it up only when building all modules
> cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \
>   $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*)
> 
> The list of modules to install is created from files found in 
> $(MODVERDIR)/. This is cleared when KBUILD_MODULES is set.  Oddly 
> enough, KBUILD_MODULES is _not_ globally set when building individual 
> modules probably not to clear MODVERDIR. This requires explicit override 
> like in this rule:
> 
> %.ko: prepare scripts FORCE
>   $(cmd_crmodverdir)
>   $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1)  \
> $(build)=$(build-dir) $(@:.ko=.o)
> 
> One could wonder why $(cmd_crmodverdir) is executed again here given 
> that it is already part of the "prepare" target, but that's an 
> orthogonal issue.
> 
> Another question is whether or not KBUILD_MODULES is the right criteria 
> for clearing MODVERDIR. My first reaction is to say it is not, but I 
> can't come up with anything better at the moment.
> 
> And KBUILD_MODULES must be set for any target that results in 
> vmlinux being built (and there are many of them including arch specific) 
> whenever CONFIG_TRIM_UNUSED_KSYMS=y. Can this be enforced elsewhere in 
> the Makefile, like in the recipe for $(vmlinux-dirs)? I don't know. IMHO 
> this will only make things even less pretty than they are now.
> 
> In the mean time, though, I'm wondering why you have to do "make 
> prepare" twice, or even at all.

well, not that I really wanted to execute it twice, it just was at
the beginning of the build/packaging script that I touched some 6-7
years ago.

> So, given all the above considerations, would it be possible for you to 
> "fix" your build script instead?

sure.

thanks.

-ss

Re: [regression ?] kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled

[Sergey Senozhatsky]

On (12/10/16 16:04), Nicolas Pitre wrote:
> On Sat, 10 Dec 2016, Sergey Senozhatsky wrote:
[..]
> > so this will not install modules:
> >  make prepare; make kernelrelease; make -j4; make prepare; make 
> > kernelrelease; make -j4 INSTALL_MOD_PATH=/tmp/MODULES modules_install
> > 
> > and this will:
> >  make prepare; make kernelrelease; make -j4; make kernelrelease; make -j4 
> > INSTALL_MOD_PATH=/tmp/MODULES modules_install
> 
> Right. And this is because of this in the main Makefile:
> 
> # Create temporary dir for module support files
> # clean it up only when building all modules
> cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \
>   $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*)
> 
> The list of modules to install is created from files found in 
> $(MODVERDIR)/. This is cleared when KBUILD_MODULES is set.  Oddly 
> enough, KBUILD_MODULES is _not_ globally set when building individual 
> modules probably not to clear MODVERDIR. This requires explicit override 
> like in this rule:
> 
> %.ko: prepare scripts FORCE
>   $(cmd_crmodverdir)
>   $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1)  \
> $(build)=$(build-dir) $(@:.ko=.o)
> 
> One could wonder why $(cmd_crmodverdir) is executed again here given 
> that it is already part of the "prepare" target, but that's an 
> orthogonal issue.
> 
> Another question is whether or not KBUILD_MODULES is the right criteria 
> for clearing MODVERDIR. My first reaction is to say it is not, but I 
> can't come up with anything better at the moment.
> 
> And KBUILD_MODULES must be set for any target that results in 
> vmlinux being built (and there are many of them including arch specific) 
> whenever CONFIG_TRIM_UNUSED_KSYMS=y. Can this be enforced elsewhere in 
> the Makefile, like in the recipe for $(vmlinux-dirs)? I don't know. IMHO 
> this will only make things even less pretty than they are now.
> 
> In the mean time, though, I'm wondering why you have to do "make 
> prepare" twice, or even at all.

well, not that I really wanted to execute it twice, it just was at
the beginning of the build/packaging script that I touched some 6-7
years ago.

> So, given all the above considerations, would it be possible for you to 
> "fix" your build script instead?

sure.

thanks.

-ss

Re: [GIT PULL] overlayfs update for 4.10

[Al Viro]

On Sat, Dec 10, 2016 at 09:49:26PM +0100, Miklos Szeredi wrote:
> Hi Al,
> 
> I usually send overlayfs pulls directly to Linus, but it it suits you, please
> feel free to pull from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-linus
> 
> This update contains:
> 
>  - try to clone on copy-up;
>  - allow renaming a directory;
>  - fix data inconsistency of read-only fds after copy up;
>  - misc cleanups and fixes.

Miklos, I'm very tempted to just let Linus do the... explaining
why "ovl: add infrastructure for intercepting file ops" is not nicely done.
It relies upon so damn many subtle things that result is a minefield for
any later work.  If nothing else, you've just created a magical place that
will have to be modified every time somebody adds a method.  Moreover, ->open()
instances have every right to expect that nothing will change ->f_op after
they return, period.  That includes things like later comparisons of ->f_op
with known pointers, etc.

Worse, there's nothing to prohibit embedding file_operations into an object
with lifetime shorter than that of a module.  Your approach will blow up on
those.  Sure, at the moment all of them live on weird filesystems that will be
(hopefully) rejected before you get to that point.  With no promise whatsoever
that this situation will persist.

overlayfs is already one hell of a special snowflake, but this is just plain
ridiculous - that sticks its fingers into so many places that making sure they
don't get squashed will be very hard.  IMO that kind of stuff is on the
"this should be handled by VFS or not at all" side of things, and I'm not
at all sure that doing that anywhere is a good idea.

PS: macros like
+#define OVL_CALL_REAL_FOP(file, call) \
+   ({ struct ovl_fops *__ofop = \
+   container_of(file->f_op, struct ovl_fops, fops); \
+  WARN_ON(__ofop->magic != OVL_FOPS_MAGIC) ? -EIO : \
+  __ofop->orig_fops->call;  \
+   })

with uses along the lines of
+   return OVL_CALL_REAL_FOP(file,
+fsync(file, start, end, datasync));
make some things (like, you know, "find all places where a method could
be called") harder for no good reason.

While we are at it,
+   module_put(ofop->owner);
+   fops_put(ofop->orig_fops);
is wrong - if that was the last reference to a module, your fops_put()
might very well try and access a vfree'd area...

Re: [GIT PULL] overlayfs update for 4.10

[Al Viro]

On Sat, Dec 10, 2016 at 09:49:26PM +0100, Miklos Szeredi wrote:
> Hi Al,
> 
> I usually send overlayfs pulls directly to Linus, but it it suits you, please
> feel free to pull from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git 
> overlayfs-linus
> 
> This update contains:
> 
>  - try to clone on copy-up;
>  - allow renaming a directory;
>  - fix data inconsistency of read-only fds after copy up;
>  - misc cleanups and fixes.

Miklos, I'm very tempted to just let Linus do the... explaining
why "ovl: add infrastructure for intercepting file ops" is not nicely done.
It relies upon so damn many subtle things that result is a minefield for
any later work.  If nothing else, you've just created a magical place that
will have to be modified every time somebody adds a method.  Moreover, ->open()
instances have every right to expect that nothing will change ->f_op after
they return, period.  That includes things like later comparisons of ->f_op
with known pointers, etc.

Worse, there's nothing to prohibit embedding file_operations into an object
with lifetime shorter than that of a module.  Your approach will blow up on
those.  Sure, at the moment all of them live on weird filesystems that will be
(hopefully) rejected before you get to that point.  With no promise whatsoever
that this situation will persist.

overlayfs is already one hell of a special snowflake, but this is just plain
ridiculous - that sticks its fingers into so many places that making sure they
don't get squashed will be very hard.  IMO that kind of stuff is on the
"this should be handled by VFS or not at all" side of things, and I'm not
at all sure that doing that anywhere is a good idea.

PS: macros like
+#define OVL_CALL_REAL_FOP(file, call) \
+   ({ struct ovl_fops *__ofop = \
+   container_of(file->f_op, struct ovl_fops, fops); \
+  WARN_ON(__ofop->magic != OVL_FOPS_MAGIC) ? -EIO : \
+  __ofop->orig_fops->call;  \
+   })

with uses along the lines of
+   return OVL_CALL_REAL_FOP(file,
+fsync(file, start, end, datasync));
make some things (like, you know, "find all places where a method could
be called") harder for no good reason.

While we are at it,
+   module_put(ofop->owner);
+   fops_put(ofop->orig_fops);
is wrong - if that was the last reference to a module, your fops_put()
might very well try and access a vfree'd area...

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

[kbuild test robot]

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a 
builtin device tree blob in the kernel
date:   4 months ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 190fe191cfbead9fe089453dd092869c9469c6d4
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 
>> 'arch/sh/boot/dts/built-in.o'.
   make[2]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

[kbuild test robot]

Hi Rich,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a 
builtin device tree blob in the kernel
date:   4 months ago
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 190fe191cfbead9fe089453dd092869c9469c6d4
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 
>> 'arch/sh/boot/dts/built-in.o'.
   make[2]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

[Balbir Singh]

On 11/12/16 04:17, Josh Poimboeuf wrote:
> On Sat, Dec 10, 2016 at 04:46:17PM +1100, Balbir Singh wrote:
>> On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote:
>>> Dusting the cobwebs off the consistency model again.  This is based on
>>> linux-next/master.
>>>  
>>> v1 was posted on 2015-02-09:
>>>  
>>>   https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com
>>>  
>>> v2 was posted on 2016-04-28:
>>>  
>>>   https://lkml.kernel.org/r/cover.1461875890.git.jpoim...@redhat.com
>>>  
>>> The biggest issue from v2 was finding a decent way to detect preemption
>>> and page faults on the stack of a sleeping task.  
>>
>> Could you please elaborate on this? Preemption of a sleeping task and
>> faults as in the future (time) preemption and faults?
> 
> The normal way for a task to go to sleep is to call schedule().  objtool
> ensures the stack trace is reliable in that case, by making sure that
> all functions save the frame pointer on the stack before calling out to
> another function.
> 
> But a task can also go to sleep in a few other ways.  One way is by
> preemption, where an interrupt handler interrupts the task and calls
> preempt_schedule_irq().

It's preempted, not sleeping. It's on_rq but not on_cpu.

  Another way is by a page fault exception.  In
> both cases, there's no guarantee that the interrupted function saved the
> frame pointer on the stack beforehand.  So the stack trace might be
> unreliable.  Fortunately, interrupts and exceptions leave evidence
> behind on the stack.  So when walking the stack of a sleeping task, we
> can detect when an IRQ or exception occurred, and consider such a stack
> unreliable.
> 

Thanks for the explanation. I presume a whole lot of this is arch specific
code? I'll look at the patches as well

Balbir

Re: [PATCH v3 00/15] livepatch: hybrid consistency model

[Balbir Singh]

On 11/12/16 04:17, Josh Poimboeuf wrote:
> On Sat, Dec 10, 2016 at 04:46:17PM +1100, Balbir Singh wrote:
>> On Thu, 2016-12-08 at 12:08 -0600, Josh Poimboeuf wrote:
>>> Dusting the cobwebs off the consistency model again.  This is based on
>>> linux-next/master.
>>>  
>>> v1 was posted on 2015-02-09:
>>>  
>>>   https://lkml.kernel.org/r/cover.1423499826.git.jpoim...@redhat.com
>>>  
>>> v2 was posted on 2016-04-28:
>>>  
>>>   https://lkml.kernel.org/r/cover.1461875890.git.jpoim...@redhat.com
>>>  
>>> The biggest issue from v2 was finding a decent way to detect preemption
>>> and page faults on the stack of a sleeping task.  
>>
>> Could you please elaborate on this? Preemption of a sleeping task and
>> faults as in the future (time) preemption and faults?
> 
> The normal way for a task to go to sleep is to call schedule().  objtool
> ensures the stack trace is reliable in that case, by making sure that
> all functions save the frame pointer on the stack before calling out to
> another function.
> 
> But a task can also go to sleep in a few other ways.  One way is by
> preemption, where an interrupt handler interrupts the task and calls
> preempt_schedule_irq().

It's preempted, not sleeping. It's on_rq but not on_cpu.

  Another way is by a page fault exception.  In
> both cases, there's no guarantee that the interrupted function saved the
> frame pointer on the stack beforehand.  So the stack trace might be
> unreliable.  Fortunately, interrupts and exceptions leave evidence
> behind on the stack.  So when walking the stack of a sleeping task, we
> can detect when an IRQ or exception occurred, and consider such a stack
> unreliable.
> 

Thanks for the explanation. I presume a whole lot of this is arch specific
code? I'll look at the patches as well

Balbir

[PATCH] Revert "tty: serial: 8250: add CON_CONSDEV to flags"

[Herbert Xu]

This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu 

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 240a361..e8819aa 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -675,7 +675,7 @@ static int univ8250_console_match(struct console *co, char 
*name, int idx,
.device = uart_console_device,
.setup  = univ8250_console_setup,
.match  = univ8250_console_match,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
.index  = -1,
.data   = _reg,
 };
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Don Dutile]

On 12/08/2016 04:36 AM, Auger Eric wrote:

Hi,

On 15/11/2016 14:09, Eric Auger wrote:

Following LPC discussions, we now report reserved regions through
iommu-group sysfs reserved_regions attribute file.



While I am respinning this series into v4, here is a tentative summary
of technical topics for which no consensus was reached at this point.

1) Shall we report the usable IOVA range instead of reserved IOVA
ranges. Not discussed at/after LPC.
x I currently report reserved regions. Alex expressed the need to
  report the full usable IOVA range instead (x86 min-max range
  minus MSI APIC window). I think this is meaningful for ARM
  too where arm-smmu might not support the full 64b range.
x Any objection we report the usable IOVA regions instead?

2) Shall the kernel check collision with MSI window* when userspace
calls VFIO_IOMMU_MAP_DMA?
Joerg/Will No; Alex yes
*for IOVA regions consumed downstream to the IOMMU: everyone says NO

3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no

Um, I'm missing context, but the only thing I recall saying no to wrt RMRR
is that _any_ device that has an RMRR cannot be assigned to a guest.
Or, are you saying, RMRR's should be exposed in the guest os?  if so, then
you have my 'no' there.


My current series does not expose them in iommu group sysfs.
I understand we can expose the RMRR regions in the iomm group sysfs
without necessarily supporting RMRR requiring device assignment.

This sentence doesn't make sense to me.
Can you try re-wording it?
I can't tell what RMRR has to do w/device assignment, other than what I said 
above.
Exposing RMRR's in sysfs is not an issue in general.


We can also add this support later.

Thanks

Eric




Reserved regions are populated through the IOMMU get_resv_region callback
(former get_dm_regions), now implemented by amd-iommu, intel-iommu and
arm-smmu.

The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an
IOMMU_RESV_NOMAP reserved region.

arm-smmu reports the MSI window (arbitrarily located at 0x800 and
1MB large) and the PCI host bridge windows.

The series integrates a not officially posted patch from Robin:
"iommu/dma: Allow MSI-only cookies".

This series currently does not address IRQ safety assessment.

Best Regards

Eric

Git: complete series available at
https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3

History:
RFC v2 -> v3:
- switch to an iommu-group sysfs API
- use new dummy allocator provided by Robin
- dummy allocator initialized by vfio-iommu-type1 after enumerating
   the reserved regions
- at the moment ARM MSI base address/size is left unchanged compared
   to v2
- we currently report reserved regions and not usable IOVA regions as
   requested by Alex

RFC v1 -> v2:
- fix intel_add_reserved_regions
- add mutex lock/unlock in vfio_iommu_type1


Eric Auger (10):
   iommu/dma: Allow MSI-only cookies
   iommu: Rename iommu_dm_regions into iommu_resv_regions
   iommu: Add new reserved IOMMU attributes
   iommu: iommu_alloc_resv_region
   iommu: Do not map reserved regions
   iommu: iommu_get_group_resv_regions
   iommu: Implement reserved_regions iommu-group sysfs file
   iommu/vt-d: Implement reserved region get/put callbacks
   iommu/arm-smmu: Implement reserved region get/put callbacks
   vfio/type1: Get MSI cookie

  drivers/iommu/amd_iommu.c   |  20 +++---
  drivers/iommu/arm-smmu.c|  52 +++
  drivers/iommu/dma-iommu.c   | 116 ++---
  drivers/iommu/intel-iommu.c |  50 ++
  drivers/iommu/iommu.c   | 141 
  drivers/vfio/vfio_iommu_type1.c |  26 
  include/linux/dma-iommu.h   |   7 ++
  include/linux/iommu.h   |  49 ++
  8 files changed, 391 insertions(+), 70 deletions(-)

[PATCH] Revert "tty: serial: 8250: add CON_CONSDEV to flags"

[Herbert Xu]

This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.

IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0.  With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.

Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu 

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 240a361..e8819aa 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -675,7 +675,7 @@ static int univ8250_console_match(struct console *co, char 
*name, int idx,
.device = uart_console_device,
.setup  = univ8250_console_setup,
.match  = univ8250_console_match,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
.index  = -1,
.data   = _reg,
 };
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

[Don Dutile]

On 12/08/2016 04:36 AM, Auger Eric wrote:

Hi,

On 15/11/2016 14:09, Eric Auger wrote:

Following LPC discussions, we now report reserved regions through
iommu-group sysfs reserved_regions attribute file.



While I am respinning this series into v4, here is a tentative summary
of technical topics for which no consensus was reached at this point.

1) Shall we report the usable IOVA range instead of reserved IOVA
ranges. Not discussed at/after LPC.
x I currently report reserved regions. Alex expressed the need to
  report the full usable IOVA range instead (x86 min-max range
  minus MSI APIC window). I think this is meaningful for ARM
  too where arm-smmu might not support the full 64b range.
x Any objection we report the usable IOVA regions instead?

2) Shall the kernel check collision with MSI window* when userspace
calls VFIO_IOMMU_MAP_DMA?
Joerg/Will No; Alex yes
*for IOVA regions consumed downstream to the IOMMU: everyone says NO

3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no

Um, I'm missing context, but the only thing I recall saying no to wrt RMRR
is that _any_ device that has an RMRR cannot be assigned to a guest.
Or, are you saying, RMRR's should be exposed in the guest os?  if so, then
you have my 'no' there.


My current series does not expose them in iommu group sysfs.
I understand we can expose the RMRR regions in the iomm group sysfs
without necessarily supporting RMRR requiring device assignment.

This sentence doesn't make sense to me.
Can you try re-wording it?
I can't tell what RMRR has to do w/device assignment, other than what I said 
above.
Exposing RMRR's in sysfs is not an issue in general.


We can also add this support later.

Thanks

Eric




Reserved regions are populated through the IOMMU get_resv_region callback
(former get_dm_regions), now implemented by amd-iommu, intel-iommu and
arm-smmu.

The intel-iommu reports the [FEE0_h - FEF0_000h] MSI window as an
IOMMU_RESV_NOMAP reserved region.

arm-smmu reports the MSI window (arbitrarily located at 0x800 and
1MB large) and the PCI host bridge windows.

The series integrates a not officially posted patch from Robin:
"iommu/dma: Allow MSI-only cookies".

This series currently does not address IRQ safety assessment.

Best Regards

Eric

Git: complete series available at
https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3

History:
RFC v2 -> v3:
- switch to an iommu-group sysfs API
- use new dummy allocator provided by Robin
- dummy allocator initialized by vfio-iommu-type1 after enumerating
   the reserved regions
- at the moment ARM MSI base address/size is left unchanged compared
   to v2
- we currently report reserved regions and not usable IOVA regions as
   requested by Alex

RFC v1 -> v2:
- fix intel_add_reserved_regions
- add mutex lock/unlock in vfio_iommu_type1


Eric Auger (10):
   iommu/dma: Allow MSI-only cookies
   iommu: Rename iommu_dm_regions into iommu_resv_regions
   iommu: Add new reserved IOMMU attributes
   iommu: iommu_alloc_resv_region
   iommu: Do not map reserved regions
   iommu: iommu_get_group_resv_regions
   iommu: Implement reserved_regions iommu-group sysfs file
   iommu/vt-d: Implement reserved region get/put callbacks
   iommu/arm-smmu: Implement reserved region get/put callbacks
   vfio/type1: Get MSI cookie

  drivers/iommu/amd_iommu.c   |  20 +++---
  drivers/iommu/arm-smmu.c|  52 +++
  drivers/iommu/dma-iommu.c   | 116 ++---
  drivers/iommu/intel-iommu.c |  50 ++
  drivers/iommu/iommu.c   | 141 
  drivers/vfio/vfio_iommu_type1.c |  26 
  include/linux/dma-iommu.h   |   7 ++
  include/linux/iommu.h   |  49 ++
  8 files changed, 391 insertions(+), 70 deletions(-)

Re: [PATCH] scsi/qla2xxx: label endian-ness for many fields

[Michael S. Tsirkin]

On Fri, Dec 09, 2016 at 09:49:28PM -0800, Joe Perches wrote:
> On Fri, 2016-12-09 at 22:45 +0200, Michael S. Tsirkin wrote:
> > This adds endian-ness labels for lots of qla structs.
> > Doing this cuts down number of sparse warnings from ~1700 to ~1400.
> > Will help find and resolve some of real issues down the road.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > 
> > ---
> > 
> > Compile-tested only.
> > 
> > diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
> > index 73b12e4..a4d3071 100644
> > --- a/drivers/scsi/qla2xxx/qla_def.h
> > +++ b/drivers/scsi/qla2xxx/qla_def.h
> > @@ -1159,28 +1159,28 @@ typedef struct {
> >  */
> > uint8_t  firmware_options[2];
> >  
> > -   uint16_t frame_payload_size;
> > -   uint16_t max_iocb_allocation;
> > -   uint16_t execution_throttle;
> > +   __le16 frame_payload_size;
> > +   __le16 max_iocb_allocation;
> > +   __le16 execution_throttle;
> 
> Shouldn't all these _not_ have the leading __?

[linux]$ git grep le32 include/linux/|grep -v _le32|grep -v le32_
[linux]$ 


> Perhaps the uint8_t uses should be converted to u8 as well.
> 
> [etc...]

Sure.  It's up to maintainers to clean up this driver though. I merely
posted this to show that proper tagging of endian-ness is not hard.

-- 
MST

Re: [PATCH] scsi/qla2xxx: label endian-ness for many fields

[Michael S. Tsirkin]

On Fri, Dec 09, 2016 at 09:49:28PM -0800, Joe Perches wrote:
> On Fri, 2016-12-09 at 22:45 +0200, Michael S. Tsirkin wrote:
> > This adds endian-ness labels for lots of qla structs.
> > Doing this cuts down number of sparse warnings from ~1700 to ~1400.
> > Will help find and resolve some of real issues down the road.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > 
> > ---
> > 
> > Compile-tested only.
> > 
> > diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
> > index 73b12e4..a4d3071 100644
> > --- a/drivers/scsi/qla2xxx/qla_def.h
> > +++ b/drivers/scsi/qla2xxx/qla_def.h
> > @@ -1159,28 +1159,28 @@ typedef struct {
> >  */
> > uint8_t  firmware_options[2];
> >  
> > -   uint16_t frame_payload_size;
> > -   uint16_t max_iocb_allocation;
> > -   uint16_t execution_throttle;
> > +   __le16 frame_payload_size;
> > +   __le16 max_iocb_allocation;
> > +   __le16 execution_throttle;
> 
> Shouldn't all these _not_ have the leading __?

[linux]$ git grep le32 include/linux/|grep -v _le32|grep -v le32_
[linux]$ 


> Perhaps the uint8_t uses should be converted to u8 as well.
> 
> [etc...]

Sure.  It's up to maintainers to clean up this driver though. I merely
posted this to show that proper tagging of endian-ness is not hard.

-- 
MST

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   9 weeks ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   9 weeks ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

Re: [PATCH] driver core: flush async calls before testing driver removal

[Vladimir Zapolskiy]

Hello Greg,

I'm adding Tejun to the list of addressees.

On 12/10/2016 03:04 PM, Greg Kroah-Hartman wrote:
> On Sat, Dec 10, 2016 at 02:38:41PM +0200, Vladimir Zapolskiy wrote:
>> Hello Greg,
>>
>> On 12/10/2016 09:32 AM, Greg Kroah-Hartman wrote:
>>> On Sat, Dec 10, 2016 at 02:15:19AM +0200, Vladimir Zapolskiy wrote:
 If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false
 positives are reported for ATA controller drivers, because ATA port
 probes are done asynchronously, and the same problem may also touch
 other asynchronously probed drivers.

 To reduce the rate of false reports on boot call async_synchronize_full()
 before attempting to remove a driver, the same is done in delete_module()
 syscall for all possible drivers and in __device_release_driver() function
 for asynchronously probed drivers.
>>>
>>> __device_release_driver() already calls this function, why call it
>>> again?
>>>
>>
>> __device_release_driver() is not called on test removal of drivers, if
>> CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled.
>>
>> This opens a possibility to races like one I've discovered:
>>
>>   https://www.spinics.net/lists/linux-ide/msg53473.html
>>
>> Next, async_synchronize_full() from __device_release_driver() is not
>> called in case of removal of ATA controller drivers, because
>> driver_allows_async_probing(drv) return value is false.
> 
> Hm, how does this not also get hit if you unbind/bind/unbind/bind/etc.
> from userspace as well?  I don't think this is a
> CONFIG_DEBUG_TEST_DRIVER_REMOVE issue, but just that this option finds
> the problem corner cases as you are finding out :)
> 

and you are right, I managed to reproduce exactly the same race as before
running the unmodified kernel built from Torvald's branch head:

root@imx6q-sabresd:~# zcat /proc/config.gz | grep TEST_DRIVER_REMOVE
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set

root@imx6q-sabresd:~# uname -a
Linux imx6q-sabresd 4.9.0-rc8-00134-g0451698 #23 SMP Sun Dec 11 03:37:30 EET 
2016 armv7l GNU/Linux

root@imx6q-sabresd:~# echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/unbind ; echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/bind; echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/unbind
ahci-imx 220.sata: fsl,transmit-level-mV not specified, using 0024
ahci-imx 220.sata: fsl,transmit-boost-mdB not specified, using 0480
ahci-imx 220.sata: fsl,transmit-atten-16ths not specified, using 2000
ahci-imx 220.sata: fsl,receive-eq-mdB not specified, using 0500
ahci-imx 220.sata: SSS flag set, parallel bus scan disabled
ahci-imx 220.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform 
mode
ahci-imx 220.sata: flags: ncq sntf stag pm led clo only pmp pio slum part 
ccc apst
scsi host0: ahci-imx
ata3: SATA max UDMA/133 mmio [mem 0x0220-0x02203fff] port 0x100 irq 72
ata3: SATA link down (SStatus 0 SControl 300)
ahci-imx 220.sata: no device found, disabling link.
ahci-imx 220.sata: pass .hotplug=1 to enable hotplug
[ cut here ]
WARNING: CPU: 2 PID: 375 at drivers/ata/libata-core.c:6482 
ata_port_detach+0x130/0x140
Modules linked in: ahci_imx dw_hdmi_ahb_audio evbug
CPU: 2 PID: 375 Comm: sh Not tainted 4.9.0-rc8-00134-g0451698 #23
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<>] (dump_backtrace) from [<>] (show_stack+0x20/0x24)
[<>] (show_stack) from [<>] (dump_stack+0xb4/0xe8)
[<>] (dump_stack) from [<>] (__warn+0xe4/0x110)
[<>] (__warn) from [<>] (warn_slowpath_null+0x30/0x38)
[<>] (warn_slowpath_null) from [<>] (ata_port_detach+0x130/0x140)
[<>] (ata_port_detach) from [<>] (ata_platform_remove_one+0x34/0x4c)
[<>] (ata_platform_remove_one) from [<>] (platform_drv_remove+0x34/0x4c)
[<>] (platform_drv_remove) from [<>] (__device_release_driver+0x98/0x134)
[<>] (__device_release_driver) from [<>] (device_release_driver+0x30/0x3c)
[<>] (device_release_driver) from [<>] (unbind_store+0x88/0x108)
[<>] (unbind_store) from [<>] (drv_attr_store+0x30/0x3c)
[<>] (drv_attr_store) from [<>] (sysfs_kf_write+0x58/0x5c)
[<>] (sysfs_kf_write) from [<>] (kernfs_fop_write+0x108/0x21c)
[<>] (kernfs_fop_write) from [<>] (__vfs_write+0x3c/0x128)
[<>] (__vfs_write) from [<>] (vfs_write+0xb0/0x178)
[<>] (vfs_write) from [<>] (SyS_write+0x4c/0xa0)
[<>] (SyS_write) from [<>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 457071853738c95e ]---

Tejun, will you look at the problem again?

--
With best wishes,
Vladimir

Re: [PATCH] driver core: flush async calls before testing driver removal

[Vladimir Zapolskiy]

Hello Greg,

I'm adding Tejun to the list of addressees.

On 12/10/2016 03:04 PM, Greg Kroah-Hartman wrote:
> On Sat, Dec 10, 2016 at 02:38:41PM +0200, Vladimir Zapolskiy wrote:
>> Hello Greg,
>>
>> On 12/10/2016 09:32 AM, Greg Kroah-Hartman wrote:
>>> On Sat, Dec 10, 2016 at 02:15:19AM +0200, Vladimir Zapolskiy wrote:
 If CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled a number of false
 positives are reported for ATA controller drivers, because ATA port
 probes are done asynchronously, and the same problem may also touch
 other asynchronously probed drivers.

 To reduce the rate of false reports on boot call async_synchronize_full()
 before attempting to remove a driver, the same is done in delete_module()
 syscall for all possible drivers and in __device_release_driver() function
 for asynchronously probed drivers.
>>>
>>> __device_release_driver() already calls this function, why call it
>>> again?
>>>
>>
>> __device_release_driver() is not called on test removal of drivers, if
>> CONFIG_DEBUG_TEST_DRIVER_REMOVE option is enabled.
>>
>> This opens a possibility to races like one I've discovered:
>>
>>   https://www.spinics.net/lists/linux-ide/msg53473.html
>>
>> Next, async_synchronize_full() from __device_release_driver() is not
>> called in case of removal of ATA controller drivers, because
>> driver_allows_async_probing(drv) return value is false.
> 
> Hm, how does this not also get hit if you unbind/bind/unbind/bind/etc.
> from userspace as well?  I don't think this is a
> CONFIG_DEBUG_TEST_DRIVER_REMOVE issue, but just that this option finds
> the problem corner cases as you are finding out :)
> 

and you are right, I managed to reproduce exactly the same race as before
running the unmodified kernel built from Torvald's branch head:

root@imx6q-sabresd:~# zcat /proc/config.gz | grep TEST_DRIVER_REMOVE
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set

root@imx6q-sabresd:~# uname -a
Linux imx6q-sabresd 4.9.0-rc8-00134-g0451698 #23 SMP Sun Dec 11 03:37:30 EET 
2016 armv7l GNU/Linux

root@imx6q-sabresd:~# echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/unbind ; echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/bind; echo 220.sata > 
/sys/bus/platform/drivers/ahci-imx/unbind
ahci-imx 220.sata: fsl,transmit-level-mV not specified, using 0024
ahci-imx 220.sata: fsl,transmit-boost-mdB not specified, using 0480
ahci-imx 220.sata: fsl,transmit-atten-16ths not specified, using 2000
ahci-imx 220.sata: fsl,receive-eq-mdB not specified, using 0500
ahci-imx 220.sata: SSS flag set, parallel bus scan disabled
ahci-imx 220.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform 
mode
ahci-imx 220.sata: flags: ncq sntf stag pm led clo only pmp pio slum part 
ccc apst
scsi host0: ahci-imx
ata3: SATA max UDMA/133 mmio [mem 0x0220-0x02203fff] port 0x100 irq 72
ata3: SATA link down (SStatus 0 SControl 300)
ahci-imx 220.sata: no device found, disabling link.
ahci-imx 220.sata: pass .hotplug=1 to enable hotplug
[ cut here ]
WARNING: CPU: 2 PID: 375 at drivers/ata/libata-core.c:6482 
ata_port_detach+0x130/0x140
Modules linked in: ahci_imx dw_hdmi_ahb_audio evbug
CPU: 2 PID: 375 Comm: sh Not tainted 4.9.0-rc8-00134-g0451698 #23
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<>] (dump_backtrace) from [<>] (show_stack+0x20/0x24)
[<>] (show_stack) from [<>] (dump_stack+0xb4/0xe8)
[<>] (dump_stack) from [<>] (__warn+0xe4/0x110)
[<>] (__warn) from [<>] (warn_slowpath_null+0x30/0x38)
[<>] (warn_slowpath_null) from [<>] (ata_port_detach+0x130/0x140)
[<>] (ata_port_detach) from [<>] (ata_platform_remove_one+0x34/0x4c)
[<>] (ata_platform_remove_one) from [<>] (platform_drv_remove+0x34/0x4c)
[<>] (platform_drv_remove) from [<>] (__device_release_driver+0x98/0x134)
[<>] (__device_release_driver) from [<>] (device_release_driver+0x30/0x3c)
[<>] (device_release_driver) from [<>] (unbind_store+0x88/0x108)
[<>] (unbind_store) from [<>] (drv_attr_store+0x30/0x3c)
[<>] (drv_attr_store) from [<>] (sysfs_kf_write+0x58/0x5c)
[<>] (sysfs_kf_write) from [<>] (kernfs_fop_write+0x108/0x21c)
[<>] (kernfs_fop_write) from [<>] (__vfs_write+0x3c/0x128)
[<>] (__vfs_write) from [<>] (vfs_write+0xb0/0x178)
[<>] (vfs_write) from [<>] (SyS_write+0x4c/0xa0)
[<>] (SyS_write) from [<>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 457071853738c95e ]---

Tejun, will you look at the problem again?

--
With best wishes,
Vladimir

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   7 months ago
config: x86_64-randconfig-a0-12110905 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

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


.config.gz
Description: application/gzip

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   7 months ago
config: x86_64-randconfig-a0-12110905 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

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


.config.gz
Description: application/gzip

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   12 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   12 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip

Re: [PATCH] PCI: pciehp: Optimize PCIe root resume time

[Yinghai Lu]

On Fri, Dec 09, 2016 at 06:27:44PM -0600, Bjorn Helgaas wrote:
> [+cc Yinghai, author of 2f5d8e4ff947]
> 
> On Fri, Dec 09, 2016 at 02:43:26PM -0800, Vaibhav Shankar wrote:
> > On Apollolake platforms, PCIe rootport takes a long time to resume
> > from S3. With 100ms delay before read pci conf, rootport takes
> > ~200ms during resume.
> > 
> > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep with
> > config space access check") is the one that added the 100ms delay
> > before reading pci conf.
> > 
> > This patch removes the 100ms delay.By removing the delay, the
> > PCIe root port takes ~16ms during resume. As per PCIe spec, we
> > only require 1000ms delay. This delay is provide by
> > pci_bus_check_dev() function.
> > 
> > Signed-off-by: Vaibhav Shankar 
> > ---
> >  drivers/pci/hotplug/pciehp_hpc.c |2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/pci/hotplug/pciehp_hpc.c 
> > b/drivers/pci/hotplug/pciehp_hpc.c
> > index 5c24e93..08357e7 100644
> > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > @@ -311,8 +311,6 @@ int pciehp_check_link_status(struct controller *ctrl)
> > else
> > msleep(1000);
> >  
> > -   /* wait 100ms before read pci conf, and try in 1s */
> > -   msleep(100);
> > found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > PCI_DEVFN(0, 0));

that msleep(100) is from that commit:

-   /*
-* If the port supports Link speeds greater than 5.0 GT/s, we
-* must wait for 100 ms after Link training completes before
-* sending configuration request.
-*/
-   if (ctrl->pcie->port->subordinate->max_bus_speed > PCIE_SPEED_5_0GT)
-   msleep(100);

so we should put the checking back.

diff --git a/drivers/pci/hotplug/pciehp_hpc.c
b/drivers/pci/hotplug/pciehp_hpc.c
index 026830a..1b0fc0b 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -311,8 +311,15 @@ int pciehp_check_link_status(struct controller *ctrl)
else
msleep(1000);
 
-   /* wait 100ms before read pci conf, and try in 1s */
-   msleep(100);
+   /*
+* If the port supports Link speeds greater than 5.0 GT/s, we
+* must wait for 100 ms after Link training completes before
+* sending configuration request.
+*/
+   if (ctrl->pcie->port->subordinate->max_bus_speed > PCIE_SPEED_5_0GT)
+   msleep(100);
+
+   /* try in 1s */
found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
PCI_DEVFN(0, 0));



Thanks

Yinghai

Re: [PATCH] PCI: pciehp: Optimize PCIe root resume time

[Yinghai Lu]

On Fri, Dec 09, 2016 at 06:27:44PM -0600, Bjorn Helgaas wrote:
> [+cc Yinghai, author of 2f5d8e4ff947]
> 
> On Fri, Dec 09, 2016 at 02:43:26PM -0800, Vaibhav Shankar wrote:
> > On Apollolake platforms, PCIe rootport takes a long time to resume
> > from S3. With 100ms delay before read pci conf, rootport takes
> > ~200ms during resume.
> > 
> > commit 2f5d8e4ff947 ("PCI: pciehp: replace unconditional sleep with
> > config space access check") is the one that added the 100ms delay
> > before reading pci conf.
> > 
> > This patch removes the 100ms delay.By removing the delay, the
> > PCIe root port takes ~16ms during resume. As per PCIe spec, we
> > only require 1000ms delay. This delay is provide by
> > pci_bus_check_dev() function.
> > 
> > Signed-off-by: Vaibhav Shankar 
> > ---
> >  drivers/pci/hotplug/pciehp_hpc.c |2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/pci/hotplug/pciehp_hpc.c 
> > b/drivers/pci/hotplug/pciehp_hpc.c
> > index 5c24e93..08357e7 100644
> > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > @@ -311,8 +311,6 @@ int pciehp_check_link_status(struct controller *ctrl)
> > else
> > msleep(1000);
> >  
> > -   /* wait 100ms before read pci conf, and try in 1s */
> > -   msleep(100);
> > found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
> > PCI_DEVFN(0, 0));

that msleep(100) is from that commit:

-   /*
-* If the port supports Link speeds greater than 5.0 GT/s, we
-* must wait for 100 ms after Link training completes before
-* sending configuration request.
-*/
-   if (ctrl->pcie->port->subordinate->max_bus_speed > PCIE_SPEED_5_0GT)
-   msleep(100);

so we should put the checking back.

diff --git a/drivers/pci/hotplug/pciehp_hpc.c
b/drivers/pci/hotplug/pciehp_hpc.c
index 026830a..1b0fc0b 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -311,8 +311,15 @@ int pciehp_check_link_status(struct controller *ctrl)
else
msleep(1000);
 
-   /* wait 100ms before read pci conf, and try in 1s */
-   msleep(100);
+   /*
+* If the port supports Link speeds greater than 5.0 GT/s, we
+* must wait for 100 ms after Link training completes before
+* sending configuration request.
+*/
+   if (ctrl->pcie->port->subordinate->max_bus_speed > PCIE_SPEED_5_0GT)
+   msleep(100);
+
+   /* try in 1s */
found = pci_bus_check_dev(ctrl->pcie->port->subordinate,
PCI_DEVFN(0, 0));



Thanks

Yinghai

[PATCH v3 1/1] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.

Signed-off-by: Adam Borowski 
Tested-by: Kalle Valo 
Acked-by: Nicholas Piggin 
Tested-by: Peter Wu 
Tested-by: Oliver Hartkopp 
---
 arch/x86/include/asm/asm-prototypes.h | 16 
 include/asm-generic/asm-prototypes.h  |  7 +++
 2 files changed, 23 insertions(+)
 create mode 100644 arch/x86/include/asm/asm-prototypes.h
 create mode 100644 include/asm-generic/asm-prototypes.h

diff --git a/arch/x86/include/asm/asm-prototypes.h 
b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index ..44b8762fa0c7
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,16 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_X86_CMPXCHG64
+extern void cmpxchg8b_emu(void);
+#endif
diff --git a/include/asm-generic/asm-prototypes.h 
b/include/asm-generic/asm-prototypes.h
new file mode 100644
index ..df13637e4017
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include 
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.11.0

[PATCH v3 1/1] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.

Signed-off-by: Adam Borowski 
Tested-by: Kalle Valo 
Acked-by: Nicholas Piggin 
Tested-by: Peter Wu 
Tested-by: Oliver Hartkopp 
---
 arch/x86/include/asm/asm-prototypes.h | 16 
 include/asm-generic/asm-prototypes.h  |  7 +++
 2 files changed, 23 insertions(+)
 create mode 100644 arch/x86/include/asm/asm-prototypes.h
 create mode 100644 include/asm-generic/asm-prototypes.h

diff --git a/arch/x86/include/asm/asm-prototypes.h 
b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index ..44b8762fa0c7
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,16 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_X86_CMPXCHG64
+extern void cmpxchg8b_emu(void);
+#endif
diff --git a/include/asm-generic/asm-prototypes.h 
b/include/asm-generic/asm-prototypes.h
new file mode 100644
index ..df13637e4017
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include 
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.11.0

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   1 year, 1 month ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   045169816b31b10faed984b01c390db1b32ee4c1
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   1 year, 1 month ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip