[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1179938960.5864.26.camel@localhost.localdomain>
Date: Wed, 23 May 2007 17:49:20 +0100
From: Richard Purdie <richard@...nedhand.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Nitin Gupta <nitingupta910@...il.com>,
Michael-Luke Jones <mlj28@....ac.uk>,
linux-kernel@...r.kernel.org, linux-mm-cc@...top.org
Subject: Re: [RFC] LZO de/compression support - take 3
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 19:51:44 +0530 "Nitin Gupta" <nitingupta910@...il.com> wrote:
> > On 5/23/07, Michael-Luke Jones <mlj28@....ac.uk> wrote:
> > If I rename 'nonsafe' version as such then it will seem like its a
> > 'broken' implementation which is not the case. If somebody is upto
> > including compression he must be having head to use the right
> > decompress version depending on this scenario :-)
> >
>
> <wakes up>
>
> What's "unsafe" here? If you fed it bad data, the decompressor will
> scribble on memory or crash the kernel or hang up?
It can scribble on memory it shouldn't.
> If so, it was quite inappropriate that a filesystem be using the unsafe
> version.
Yes, I'll give you a patch to change the resier4 code in -mm then (if
its not already been changed).
> I'd agree with the proposed renaming. In fact I'd suggest that the unsafe
> APIs just be removed - it's hard to imagine a situation in which they're OK
> to be used in the kernel.
The compressed cache code might be one exception since it does the
compression itself and shouldn't get corrupted. If it does get
corrupted, you have bigger problems.
I'll provide a patch to update the LZO code in -mm to add unsafe to the
name.
Cheers,
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists