linux-kernel - Re: [RFC] LZO de/compression support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 May 2007 09:34:12 +0530
From:	"Nitin Gupta" <nitingupta910@...il.com>
To:	"Richard Purdie" <richard@...nedhand.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"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 5/23/07, Richard Purdie <richard@...nedhand.com> wrote:
> 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 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).

Richard, are you planning to use this patch for LZO or your own port?
Can we decide on a Final Unified(tm) version of LZO port and then
patch up reiser4 or whatever to use that Ultimate LZO instead?

Can you please look into this (take 3) version on LZO patch posted and
we can edit/add/remove things from this to unify our effort - there is
no point in this duplication.

Perhaps you have opinion of maintaining diffability with original LZO
code which differs from mine. Since the code is now just ~500 lines it
should be fair enough to have major overhauls for sake of clean
KernelStyle(tm) code. It shouldn't be that hard to verify this small
code for bugs that might have crept in during porting work. As regard
to keeping up with future LZO versions, hm.... that will be hard - but
I don't think algorithm itself will change and optimizations can
always be done separately in this fork.

>
> > 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.
>

Yes. Compressed Caching is one of cases where compressed data cannot
get magically corrupted. Hence, there is no need to go for the 'safe'
version. There might be other such cases too, so removing 'unsafe'
version is not good.

Ok, I will rename 'unsafe' version as such (as suggested by Michael).

Cheers,
Nitin
-
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/