Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1310415 > unrolled thread

[PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

Started byBoris Ostrovsky <boris.ostrovsky@oracle.com>
First post2016-01-15 20:50 +0100
Last post2016-01-19 15:40 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-01-15 20:50 +0100
    Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct  gntdev_copy_batch on stack Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-01-15 21:00 +0100
    Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct  gntdev_copy_batch on stack Andrew Cooper <andrew.cooper3@citrix.com> - 2016-01-15 21:00 +0100
    Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch  on stack David Vrabel <david.vrabel@citrix.com> - 2016-01-18 12:20 +0100
      Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct  gntdev_copy_batch on stack David Vrabel <david.vrabel@citrix.com> - 2016-01-19 15:40 +0100
      Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct  gntdev_copy_batch on stack Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-01-19 15:40 +0100

#1310415 — [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-01-15 20:50 +0100
Subject[PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qRixI-2cl-21@gated-at.bofh.it>
struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
put it on stack.

Some compilers (e.g. 5.2.1) complain:
 drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
 drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
  is larger than 1024 bytes [-Wframe-larger-than=]

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 drivers/xen/gntdev.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index dc49538..43a2c1c 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -915,15 +915,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch,
 static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 {
 	struct ioctl_gntdev_grant_copy copy;
-	struct gntdev_copy_batch batch;
+	struct gntdev_copy_batch *batch;
 	unsigned int i;
 	int ret = 0;
 
 	if (copy_from_user(&copy, u, sizeof(copy)))
 		return -EFAULT;
 
-	batch.nr_ops = 0;
-	batch.nr_pages = 0;
+	batch = kmalloc(sizeof(*batch), GFP_KERNEL);
+	if (!batch)
+		return -ENOMEM;
+
+	batch->nr_ops = 0;
+	batch->nr_pages = 0;
 
 	for (i = 0; i < copy.count; i++) {
 		struct gntdev_grant_copy_segment seg;
@@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 			goto out;
 		}
 
-		ret = gntdev_grant_copy_seg(&batch, &seg, &copy.segments[i].status);
+		ret = gntdev_grant_copy_seg(batch, &seg,
+			&copy.segments[i].status);
 		if (ret < 0)
 			goto out;
 
 		cond_resched();
 	}
-	if (batch.nr_ops)
-		ret = gntdev_copy(&batch);
+	if (batch->nr_ops)
+		ret = gntdev_copy(batch);
 	return ret;
 
   out:
-	gntdev_put_pages(&batch);
+	gntdev_put_pages(batch);
+	kfree(batch);
 	return ret;
 }
 
-- 
2.5.0

[toc] | [next] | [standalone]

#1310426 — Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-01-15 21:00 +0100
SubjectRe: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qRiHo-2fB-13@gated-at.bofh.it>
In reply to#1310415
On 01/15/2016 02:50 PM, Andrew Cooper wrote:
> On 15/01/16 19:43, Boris Ostrovsky wrote:
>> @@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>>   			goto out;
>>   		}
>>   
>> -		ret = gntdev_grant_copy_seg(&batch, &seg, &copy.segments[i].status);
>> +		ret = gntdev_grant_copy_seg(batch, &seg,
>> +			&copy.segments[i].status);
>>   		if (ret < 0)
>>   			goto out;
>>   
>>   		cond_resched();
>>   	}
>> -	if (batch.nr_ops)
>> -		ret = gntdev_copy(&batch);
>> +	if (batch->nr_ops)
>> +		ret = gntdev_copy(batch);
> You presumably want a kfree() here?

Ah, missed it. Thanks.

>
>>   	return ret;
>>

[toc] | [prev] | [next] | [standalone]

#1310429 — Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromAndrew Cooper <andrew.cooper3@citrix.com>
Date2016-01-15 21:00 +0100
SubjectRe: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qRiHo-2fB-15@gated-at.bofh.it>
In reply to#1310415
On 15/01/16 19:43, Boris Ostrovsky wrote:
> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
> put it on stack.
>
> Some compilers (e.g. 5.2.1) complain:
>  drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
>  drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
>   is larger than 1024 bytes [-Wframe-larger-than=]
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  drivers/xen/gntdev.c | 20 +++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index dc49538..43a2c1c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -915,15 +915,19 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch,
>  static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>  {
>  	struct ioctl_gntdev_grant_copy copy;
> -	struct gntdev_copy_batch batch;
> +	struct gntdev_copy_batch *batch;
>  	unsigned int i;
>  	int ret = 0;
>  
>  	if (copy_from_user(&copy, u, sizeof(copy)))
>  		return -EFAULT;
>  
> -	batch.nr_ops = 0;
> -	batch.nr_pages = 0;
> +	batch = kmalloc(sizeof(*batch), GFP_KERNEL);
> +	if (!batch)
> +		return -ENOMEM;
> +
> +	batch->nr_ops = 0;
> +	batch->nr_pages = 0;
>  
>  	for (i = 0; i < copy.count; i++) {
>  		struct gntdev_grant_copy_segment seg;
> @@ -933,18 +937,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
>  			goto out;
>  		}
>  
> -		ret = gntdev_grant_copy_seg(&batch, &seg, &copy.segments[i].status);
> +		ret = gntdev_grant_copy_seg(batch, &seg,
> +			&copy.segments[i].status);
>  		if (ret < 0)
>  			goto out;
>  
>  		cond_resched();
>  	}
> -	if (batch.nr_ops)
> -		ret = gntdev_copy(&batch);
> +	if (batch->nr_ops)
> +		ret = gntdev_copy(batch);

You presumably want a kfree() here?

>  	return ret;
>  
>    out:
> -	gntdev_put_pages(&batch);
> +	gntdev_put_pages(batch);
> +	kfree(batch);
>  	return ret;
>  }
>

[toc] | [prev] | [next] | [standalone]

#1311486 — Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromDavid Vrabel <david.vrabel@citrix.com>
Date2016-01-18 12:20 +0100
SubjectRe: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qSg0N-8k6-5@gated-at.bofh.it>
In reply to#1310415
On 15/01/16 19:43, Boris Ostrovsky wrote:
> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
> put it on stack.
> 
> Some compilers (e.g. 5.2.1) complain:
>  drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
>  drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
>   is larger than 1024 bytes [-Wframe-larger-than=]

I thought I'd already reduced the size of this enough (from a batch size
of 32 to 24) but this obviously isn't enough for 64-bit platforms.

In the absence of any performance data on the best approach I would
prefer just reducing the batch size to 16.

David

[toc] | [prev] | [next] | [standalone]

#1312297 — Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromDavid Vrabel <david.vrabel@citrix.com>
Date2016-01-19 15:40 +0100
SubjectRe: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qSFBU-HG-17@gated-at.bofh.it>
In reply to#1311486
On 19/01/16 14:26, Boris Ostrovsky wrote:
> On 01/18/2016 06:11 AM, David Vrabel wrote:
>> On 15/01/16 19:43, Boris Ostrovsky wrote:
>>> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
>>> put it on stack.
>>>
>>> Some compilers (e.g. 5.2.1) complain:
>>>   drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
>>>   drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
>>>    is larger than 1024 bytes [-Wframe-larger-than=]
>> I thought I'd already reduced the size of this enough (from a batch size
>> of 32 to 24) but this obviously isn't enough for 64-bit platforms.
>>
>> In the absence of any performance data on the best approach I would
>> prefer just reducing the batch size to 16.
> 
> That would still leave us with over 900 bytes on the stack which I think
> is rather high.

The stack depth to here isn't very deep, so I think even the ~1500 byte
frame was fine.

> Do we expect this ioctl to be on some sort of a hot path?

Yes.

David

[toc] | [prev] | [next] | [standalone]

#1312299 — Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-01-19 15:40 +0100
SubjectRe: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack
Message-ID<qSFBU-HG-19@gated-at.bofh.it>
In reply to#1311486
On 01/18/2016 06:11 AM, David Vrabel wrote:
> On 15/01/16 19:43, Boris Ostrovsky wrote:
>> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't
>> put it on stack.
>>
>> Some compilers (e.g. 5.2.1) complain:
>>   drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’:
>>   drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes
>>    is larger than 1024 bytes [-Wframe-larger-than=]
> I thought I'd already reduced the size of this enough (from a batch size
> of 32 to 24) but this obviously isn't enough for 64-bit platforms.
>
> In the absence of any performance data on the best approach I would
> prefer just reducing the batch size to 16.

That would still leave us with over 900 bytes on the stack which I think 
is rather high.

Do we expect this ioctl to be on some sort of a hot path?


-boris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web