linux-kernel - Re: [PATCH] Add LZO1X compression support to the kernel

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]

Message-Id: <20070509232129.371f49d5.akpm@linux-foundation.org>
Date:	Wed, 9 May 2007 23:21:29 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Richard Purdie <richard@...nedhand.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, torvalds@...ux-foundation.org,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH] Add LZO1X compression support to the kernel

On Wed, 02 May 2007 09:56:23 +0100 Richard Purdie <richard@...nedhand.com> wrote:

> Current thinking is that lzo should get merged directly followed by the
> subsystem parts through their specific trees. It appears this should
> make it onto LKML despite the size so here goes.
> 
> Please keep in mind I haven't reformatted the LZO code itself as if I do
> so, it will make maintenance of it against any changes in LZO itself
> near impossible. In its current form, it should be possible to diff
> against upstream. All the bad formatting is confined to a handful of
> files in lib/lzo/ and the kernel interface should be clean.
> 
> I realise a maze of ifdefs still remain. I've already spent a lot of
> time removing a ton of them and going much further might start to affect
> diffability of the code - I hoping whats there is a good compromise.
> 
> I've asked the LZO author about the comments on lzo_copyright function
> but the code is GPLv2 licensed so is suitable for inclusion in the
> kernel.
> 
> 
> 
> Add LZO1X compression/decompression support to the kernel.
> 
> This is based on the standard userspace lzo library, particularly
> minilzo with the headers much trimmed down and simplified for kernel
> use. Its structured so that it should still diff with the userspace
> version for ease of future updating.

Well that's attractive-looking code.

Why is this needed?  What code plans to use it?

How many buffer overruns are there in it?

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