From: David Mansfield <lkml@dm.ultramaster.com>
To: Pierre Etchemaite <petchema@concept-micro.com>
Cc: Jani Jaakkola <jjaakkol@cs.Helsinki.FI>,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: [PATCH] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2
Date: Fri, 16 Mar 2001 14:09:38 -0500 [thread overview]
Message-ID: <3AB264F2.7D19842F@dm.ultramaster.com> (raw)
In-Reply-To: <XFMail.20010315140400.petchema@concept-micro.com>
Pierre Etchemaite wrote:
>
> Le 14-Mar-2001, Jani Jaakkola écrivait :
> >
> > Using ioctl(CDROMREADAUDIO) with nframes argument being larger than 8 and
> > not divisible by 8 causes kernel to read and return more audio data than
> > was requested. This is bad since it clobbers up processes memory
> > (I noticed this when my patched cdparanoia segfaulted).
>
> Same thing for 2.4.2.
>
> Is my allocation loop "over engineering", or just plain bad thing to do ?
>
I've been running this (or close: my version tries 8 frames, then jumps
immediately to 1, without trying 4 and 2 in between if the kmalloc
fails) since it was changed. Without such a patch, my CDDA read speed
drops to 25% the original rate. You also have the fix that started the
thread!
Jens (cdrom maintainer) said he was working on a more elegant solution,
but to me, such a simple fix as yours should go in the kernel in the
meantime. Jens?
--
David Mansfield (718) 963-2020
david@ultramaster.com
Ultramaster Group, LLC www.ultramaster.com
next prev parent reply other threads:[~2001-03-16 19:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-14 14:17 [PATCH] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2.18 Jani Jaakkola
2001-03-15 13:04 ` [PATCH] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2 Pierre Etchemaite
2001-03-16 19:09 ` David Mansfield [this message]
2001-03-19 11:24 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3AB264F2.7D19842F@dm.ultramaster.com \
--to=lkml@dm.ultramaster.com \
--cc=axboe@suse.de \
--cc=jjaakkol@cs.Helsinki.FI \
--cc=linux-kernel@vger.kernel.org \
--cc=petchema@concept-micro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.