Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Lee Jones
On Mon, 22 Sep 2014, Octavian Purdila wrote:

 Currently the I/O buffer is allocated part of the device status
 structure, potentially sharing the same cache line with other members
 in this structure.
 
 Allocate the buffer separately, to avoid the I/O operations corrupting
 the device status structure due to cache line sharing.
 
 Compiled tested only as I don't have access to hardware.
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 ---
  drivers/mfd/viperboard.c   | 8 
  include/linux/mfd/viperboard.h | 2 +-
  2 files changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
 index e00f534..5f62f4e 100644
 --- a/drivers/mfd/viperboard.c
 +++ b/drivers/mfd/viperboard.c
 @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
   return -ENOMEM;
   }
  
 + vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);

Can you obtain the 'struct device' first then use managed resources
(devm_*)?

 + if (vb-buf == NULL) {
 + ret = -ENOMEM;
 + goto error;
 + }
 +
   mutex_init(vb-lock);
  
   vb-usb_dev = usb_get_dev(interface_to_usbdev(interface));
 @@ -105,6 +111,7 @@ static int vprbrd_probe(struct usb_interface *interface,
  error:
   if (vb) {
   usb_put_dev(vb-usb_dev);
 + kfree(vb-buf);

Then you don't need this.

   kfree(vb);
   }
  
 @@ -118,6 +125,7 @@ static void vprbrd_disconnect(struct usb_interface 
 *interface)
   mfd_remove_devices(interface-dev);
   usb_set_intfdata(interface, NULL);
   usb_put_dev(vb-usb_dev);
 + kfree(vb-buf);

Or this.

   kfree(vb);
  
   dev_dbg(interface-dev, disconnected\n);
 diff --git a/include/linux/mfd/viperboard.h b/include/linux/mfd/viperboard.h
 index 1934528..af928d0 100644
 --- a/include/linux/mfd/viperboard.h
 +++ b/include/linux/mfd/viperboard.h
 @@ -103,7 +103,7 @@ struct vprbrd_i2c_addr_msg {
  struct vprbrd {
   struct usb_device *usb_dev; /* the usb device for this device */
   struct mutex lock;
 - u8 buf[sizeof(struct vprbrd_i2c_write_msg)];
 + u8 *buf;
   struct platform_device pdev;
  };
  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Johan Hovold
On Wed, Sep 24, 2014 at 11:12:06AM +0100, Lee Jones wrote:
 On Mon, 22 Sep 2014, Octavian Purdila wrote:
 
  Currently the I/O buffer is allocated part of the device status
  structure, potentially sharing the same cache line with other members
  in this structure.
  
  Allocate the buffer separately, to avoid the I/O operations corrupting
  the device status structure due to cache line sharing.
  
  Compiled tested only as I don't have access to hardware.
  
  Signed-off-by: Octavian Purdila octavian.purd...@intel.com
  ---
   drivers/mfd/viperboard.c   | 8 
   include/linux/mfd/viperboard.h | 2 +-
   2 files changed, 9 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
  index e00f534..5f62f4e 100644
  --- a/drivers/mfd/viperboard.c
  +++ b/drivers/mfd/viperboard.c
  @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
  return -ENOMEM;
  }
   
  +   vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
 
 Can you obtain the 'struct device' first then use managed resources
 (devm_*)?

I think any devres conversion should be done in a follow-up patch and
not be included in the fix (e.g. in order to facilitate backporting). We
also don't want to mix allocation schemes.

Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Lee Jones
On Wed, 24 Sep 2014, Johan Hovold wrote:

 On Wed, Sep 24, 2014 at 11:12:06AM +0100, Lee Jones wrote:
  On Mon, 22 Sep 2014, Octavian Purdila wrote:
  
   Currently the I/O buffer is allocated part of the device status
   structure, potentially sharing the same cache line with other members
   in this structure.
   
   Allocate the buffer separately, to avoid the I/O operations corrupting
   the device status structure due to cache line sharing.
   
   Compiled tested only as I don't have access to hardware.
   
   Signed-off-by: Octavian Purdila octavian.purd...@intel.com
   ---
drivers/mfd/viperboard.c   | 8 
include/linux/mfd/viperboard.h | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
   
   diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
   index e00f534..5f62f4e 100644
   --- a/drivers/mfd/viperboard.c
   +++ b/drivers/mfd/viperboard.c
   @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface 
   *interface,
 return -ENOMEM;
 }

   + vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
  
  Can you obtain the 'struct device' first then use managed resources
  (devm_*)?
 
 I think any devres conversion should be done in a follow-up patch and
 not be included in the fix (e.g. in order to facilitate backporting). We
 also don't want to mix allocation schemes.

I agree, but equally I'm not keen on accepting this patch as I believe
it could be done better.

Please submit two patches, one converting to shared resources and this
being the subsequent one, fixed up to do the right thing.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Johan Hovold
On Wed, Sep 24, 2014 at 01:00:02PM +0100, Lee Jones wrote:
 On Wed, 24 Sep 2014, Johan Hovold wrote:
 
  On Wed, Sep 24, 2014 at 11:12:06AM +0100, Lee Jones wrote:
   On Mon, 22 Sep 2014, Octavian Purdila wrote:
   
Currently the I/O buffer is allocated part of the device status
structure, potentially sharing the same cache line with other members
in this structure.

Allocate the buffer separately, to avoid the I/O operations corrupting
the device status structure due to cache line sharing.

Compiled tested only as I don't have access to hardware.

Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
 drivers/mfd/viperboard.c   | 8 
 include/linux/mfd/viperboard.h | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e00f534..5f62f4e 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface 
*interface,
return -ENOMEM;
}
 
+   vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), 
GFP_KERNEL);
   
   Can you obtain the 'struct device' first then use managed resources
   (devm_*)?
  
  I think any devres conversion should be done in a follow-up patch and
  not be included in the fix (e.g. in order to facilitate backporting). We
  also don't want to mix allocation schemes.
 
 I agree, but equally I'm not keen on accepting this patch as I believe
 it could be done better.

 Please submit two patches, one converting to shared resources and this
 being the subsequent one, fixed up to do the right thing.

A buffer-corruption fix is a candidate for stable, whereas a devres
conversion (clean up) is not. Hence the former should not depend on the
latter.

Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Octavian Purdila
On Wed, Sep 24, 2014 at 3:26 PM, Johan Hovold jo...@kernel.org wrote:
 On Wed, Sep 24, 2014 at 01:00:02PM +0100, Lee Jones wrote:
 On Wed, 24 Sep 2014, Johan Hovold wrote:

  On Wed, Sep 24, 2014 at 11:12:06AM +0100, Lee Jones wrote:
   On Mon, 22 Sep 2014, Octavian Purdila wrote:
  
Currently the I/O buffer is allocated part of the device status
structure, potentially sharing the same cache line with other members
in this structure.
   
Allocate the buffer separately, to avoid the I/O operations corrupting
the device status structure due to cache line sharing.
   
Compiled tested only as I don't have access to hardware.
   
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
 drivers/mfd/viperboard.c   | 8 
 include/linux/mfd/viperboard.h | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)
   
diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e00f534..5f62f4e 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface 
*interface,
return -ENOMEM;
}
   
+   vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), 
GFP_KERNEL);
  
   Can you obtain the 'struct device' first then use managed resources
   (devm_*)?
 
  I think any devres conversion should be done in a follow-up patch and
  not be included in the fix (e.g. in order to facilitate backporting). We
  also don't want to mix allocation schemes.

 I agree, but equally I'm not keen on accepting this patch as I believe
 it could be done better.

 Please submit two patches, one converting to shared resources and this
 being the subsequent one, fixed up to do the right thing.

 A buffer-corruption fix is a candidate for stable, whereas a devres
 conversion (clean up) is not. Hence the former should not depend on the
 latter.


I can follow-up with a v3 3 patch series: first for the fix, second
for the OOM  error path cleanup, third for devm conversion.

I think this will address both issues (backport and better final result).
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-24 Thread Johan Hovold
On Wed, Sep 24, 2014 at 03:34:08PM +0300, Octavian Purdila wrote:

 I can follow-up with a v3 3 patch series: first for the fix, second
 for the OOM  error path cleanup, third for devm conversion.

I'd include the error-path clean up bit in the devres conversion as that
is what it's really all about.

Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-23 Thread Johan Hovold
On Mon, Sep 22, 2014 at 10:39:18PM +0300, Octavian Purdila wrote:
 Currently the I/O buffer is allocated part of the device status
 structure, potentially sharing the same cache line with other members
 in this structure.
 
 Allocate the buffer separately, to avoid the I/O operations corrupting
 the device status structure due to cache line sharing.
 
 Compiled tested only as I don't have access to hardware.
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 ---
  drivers/mfd/viperboard.c   | 8 
  include/linux/mfd/viperboard.h | 2 +-
  2 files changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
 index e00f534..5f62f4e 100644
 --- a/drivers/mfd/viperboard.c
 +++ b/drivers/mfd/viperboard.c
 @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
   return -ENOMEM;
   }
  
 + vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
 + if (vb-buf == NULL) {
 + ret = -ENOMEM;
 + goto error;

This will cause a kref imbalance as you have a usb_put_dev in error,
but haven't done the get yet.

 + }
 +
   mutex_init(vb-lock);
  
   vb-usb_dev = usb_get_dev(interface_to_usbdev(interface));

Here's the get.

Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-23 Thread Johan Hovold
On Tue, Sep 23, 2014 at 09:35:41AM +0200, Johan Hovold wrote:
 On Mon, Sep 22, 2014 at 10:39:18PM +0300, Octavian Purdila wrote:
  Currently the I/O buffer is allocated part of the device status
  structure, potentially sharing the same cache line with other members
  in this structure.
  
  Allocate the buffer separately, to avoid the I/O operations corrupting
  the device status structure due to cache line sharing.
  
  Compiled tested only as I don't have access to hardware.
  
  Signed-off-by: Octavian Purdila octavian.purd...@intel.com
  ---
   drivers/mfd/viperboard.c   | 8 
   include/linux/mfd/viperboard.h | 2 +-
   2 files changed, 9 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
  index e00f534..5f62f4e 100644
  --- a/drivers/mfd/viperboard.c
  +++ b/drivers/mfd/viperboard.c
  @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
  return -ENOMEM;
  }
   
  +   vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
  +   if (vb-buf == NULL) {
  +   ret = -ENOMEM;
  +   goto error;
 
 This will cause a kref imbalance as you have a usb_put_dev in error,
 but haven't done the get yet.

Nevermind. This isn't problem as the usb device is null.

Haven't had my morning coffee yet. ;)

Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-23 Thread Johan Hovold
On Mon, Sep 22, 2014 at 10:39:18PM +0300, Octavian Purdila wrote:
 Currently the I/O buffer is allocated part of the device status
 structure, potentially sharing the same cache line with other members
 in this structure.
 
 Allocate the buffer separately, to avoid the I/O operations corrupting
 the device status structure due to cache line sharing.
 
 Compiled tested only as I don't have access to hardware.
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com

Reviewed-by: Johan Hovold jo...@kernel.org

 ---
  drivers/mfd/viperboard.c   | 8 
  include/linux/mfd/viperboard.h | 2 +-
  2 files changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
 index e00f534..5f62f4e 100644
 --- a/drivers/mfd/viperboard.c
 +++ b/drivers/mfd/viperboard.c
 @@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
   return -ENOMEM;
   }
  
 + vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
 + if (vb-buf == NULL) {
 + ret = -ENOMEM;
 + goto error;
 + }
 +
   mutex_init(vb-lock);
  
   vb-usb_dev = usb_get_dev(interface_to_usbdev(interface));
 @@ -105,6 +111,7 @@ static int vprbrd_probe(struct usb_interface *interface,
  error:
   if (vb) {
   usb_put_dev(vb-usb_dev);
 + kfree(vb-buf);
   kfree(vb);
   }
  
 @@ -118,6 +125,7 @@ static void vprbrd_disconnect(struct usb_interface 
 *interface)
   mfd_remove_devices(interface-dev);
   usb_set_intfdata(interface, NULL);
   usb_put_dev(vb-usb_dev);
 + kfree(vb-buf);
   kfree(vb);
  
   dev_dbg(interface-dev, disconnected\n);
 diff --git a/include/linux/mfd/viperboard.h b/include/linux/mfd/viperboard.h
 index 1934528..af928d0 100644
 --- a/include/linux/mfd/viperboard.h
 +++ b/include/linux/mfd/viperboard.h
 @@ -103,7 +103,7 @@ struct vprbrd_i2c_addr_msg {
  struct vprbrd {
   struct usb_device *usb_dev; /* the usb device for this device */
   struct mutex lock;
 - u8 buf[sizeof(struct vprbrd_i2c_write_msg)];
 + u8 *buf;
   struct platform_device pdev;
  };
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/2] mfd: viperboard: allocate I/O buffer separately

2014-09-22 Thread Octavian Purdila
Currently the I/O buffer is allocated part of the device status
structure, potentially sharing the same cache line with other members
in this structure.

Allocate the buffer separately, to avoid the I/O operations corrupting
the device status structure due to cache line sharing.

Compiled tested only as I don't have access to hardware.

Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
 drivers/mfd/viperboard.c   | 8 
 include/linux/mfd/viperboard.h | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e00f534..5f62f4e 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -64,6 +64,12 @@ static int vprbrd_probe(struct usb_interface *interface,
return -ENOMEM;
}
 
+   vb-buf = kzalloc(sizeof(struct vprbrd_i2c_write_msg), GFP_KERNEL);
+   if (vb-buf == NULL) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
mutex_init(vb-lock);
 
vb-usb_dev = usb_get_dev(interface_to_usbdev(interface));
@@ -105,6 +111,7 @@ static int vprbrd_probe(struct usb_interface *interface,
 error:
if (vb) {
usb_put_dev(vb-usb_dev);
+   kfree(vb-buf);
kfree(vb);
}
 
@@ -118,6 +125,7 @@ static void vprbrd_disconnect(struct usb_interface 
*interface)
mfd_remove_devices(interface-dev);
usb_set_intfdata(interface, NULL);
usb_put_dev(vb-usb_dev);
+   kfree(vb-buf);
kfree(vb);
 
dev_dbg(interface-dev, disconnected\n);
diff --git a/include/linux/mfd/viperboard.h b/include/linux/mfd/viperboard.h
index 1934528..af928d0 100644
--- a/include/linux/mfd/viperboard.h
+++ b/include/linux/mfd/viperboard.h
@@ -103,7 +103,7 @@ struct vprbrd_i2c_addr_msg {
 struct vprbrd {
struct usb_device *usb_dev; /* the usb device for this device */
struct mutex lock;
-   u8 buf[sizeof(struct vprbrd_i2c_write_msg)];
+   u8 *buf;
struct platform_device pdev;
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html