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(-)
diff -Naur ./drivers/cdrom/optcd.c%CDROM ./drivers/cdrom/optcd.c
--- ./drivers/cdrom/optcd.c%CDROM Mon Mar 17 13:43:49 2003
+++ ./drivers/cdrom/optcd.c Fri Mar 21 22:30:08 2003
@@ -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;
}
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
Surely that buffer needs to be allocated once at open and freed on close
?
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 ;)
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.
--
Jens Axboe
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