Skip to contentSkip to conversation

reduce stack in cdrom/optcd.c

PATCH In review Randy.Dunlap 5 participants 5 messages Mar 22, 2003 – Mar 25, 2003

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 reduce stack in cdrom/optcd.c

Hi,

This reduces stack usage in drivers/cdrom/optcd.c by dynamically allocating a large (> 2 KB) buffer.

Patch is to 2.5.65. Please apply.

~Randy

patch_name: optcdrom-stack.patch
patch_version: 2003-03-21.22:31:24
author: Randy.Dunlap <[email protected]>
description: reduce stack usage in drivers/cdrom/optcd::cdromread()
product: Linux
product_versions: 2.5.65
changelog: kmalloc() the large buffer
maintainer: Leo Spiekman <[email protected]>
diffstat: =

 drivers/cdrom/optcd.c |   22 +++++++++++++++++-----
 1 files changed, 17 insertions(+), 5 deletions(-)
drivers/cdrom/optcd.c renamed from drivers/cdrom/optcd.c%CDROM +17 -5
diff -Naur ./drivers/cdrom/optcd.c%CDROM ./drivers/cdrom/optcd.c
@@ -1600,13 +1600,17 @@
 
 static int cdromread(unsigned long arg, int blocksize, int cmd)
 {
-	int status;
+	int status, ret = 0;
 	struct cdrom_msf msf;
-	char buf[CD_FRAMESIZE_RAWER];
+	char *buf;
 
 	if (copy_from_user(&msf, (void *) arg, sizeof msf))
 		return -EFAULT;
 
+	buf = kmalloc(CD_FRAMESIZE_RAWER, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
 	bin2bcd(&msf);
 	msf.cdmsf_min1 = 0;
 	msf.cdmsf_sec1 = 0;
@@ -1615,11 +1619,19 @@
 
 	DEBUG((DEBUG_VFS, "read cmd status 0x%x", status));
 
-	if (!sleep_flag_low(FL_DTEN, SLEEP_TIMEOUT))
-		return -EIO;
+	if (!sleep_flag_low(FL_DTEN, SLEEP_TIMEOUT)) {
+		ret = -EIO;
+		goto cdr_free;
+	}
+
 	fetch_data(buf, blocksize);
 
-	return copy_to_user((void *)arg, &buf, blocksize) ? -EFAULT : 0;
+	if (copy_to_user((void *)arg, &buf, blocksize))
+		ret = -EFAULT;
+
+cdr_free:
+	kfree(buf);
+	return ret;
 }
 
 
#1 lore raw
Quoted 6 lines · Randy.Dunlap

Hi,

This reduces stack usage in drivers/cdrom/optcd.c by dynamically allocating a large (> 2 KB) buffer.

Patch is to 2.5.65. Please apply.

This loosk broken. You are using GFP_KERNEL memory allocations on the read path of a block device. What happens if the allocation fails because we need memory

Surely that buffer needs to be allocated once at open and freed on close ?

#2 lore raw
Quoted 11 lines · Alan Cox
Quoted 6 lines · Randy.Dunlap

Hi,

This reduces stack usage in drivers/cdrom/optcd.c by dynamically allocating a large (> 2 KB) buffer.

Patch is to 2.5.65. Please apply.

This loosk broken. You are using GFP_KERNEL memory allocations on the read path of a block device. What happens if the allocation fails because we need memory

it's unlikely that you have your swap on the cdrom ;)

#3 lore raw
Quoted 7 lines · Arjan van de Ven
Quoted 6 lines · Alan Cox
Quoted 5 lines · Randy.Dunlap

Hi,

This reduces stack usage in drivers/cdrom/optcd.c by dynamically allocating a large (> 2 KB) buffer.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Patch is to 2.5.65. Please apply.

This loosk broken. You are using GFP_KERNEL memory allocations on the read path of a block device. What happens if the allocation fails because we need memory

it's unlikely that you have your swap on the cdrom ;)

your swap device could still be plugged behind your cdrom.

Signature · 1 line
Jens Axboe
#4 lore raw

On Tue, 25 Mar 2003 19:29:16 +0100 Jens Axboe <[email protected]> wrote:

| On Sat, Mar 22 2003, Arjan van de Ven wrote:
| > On Sat, 2003-03-22 at 21:43, Alan Cox wrote:
| > > On Sat, 2003-03-22 at 06:51, Randy.Dunlap wrote:
| > > > Hi,
| > > > 
| > > > This reduces stack usage in drivers/cdrom/optcd.c by
| > > > dynamically allocating a large (> 2 KB) buffer.
| > > > 
| > > > Patch is to 2.5.65.  Please apply.
| > > 
| > > This loosk broken. You are using GFP_KERNEL memory allocations on the
| > > read path of a block device. What happens if the allocation fails 
| > > because we need memory
| > 
| > it's unlikely that you have your swap on the cdrom ;)
| 
| your swap device could still be plugged behind your cdrom.

I plan to change it as Alan suggested. Will do.

--
~Randy