linux-kernel - Re: [PATCH -mm 0/5] LZO and swap write failure patches for -mm

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: <1180990731.6313.179.camel@localhost.localdomain>
Date:	Mon, 04 Jun 2007 21:58:51 +0100
From:	Richard Purdie <rpurdie@...nedhand.com>
To:	Nitin Gupta <nitingupta910@...il.com>
Cc:	Daniel Hazelton <dhazelton@...er.net>,
	akpm <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hugh@...itas.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH -mm 0/5] LZO and swap write failure patches for -mm

On Mon, 2007-06-04 at 23:56 +0530, Nitin Gupta wrote:
> Yes there might still be problems - that is why I posted as RFC. I got
> useful comments and the code is improving. Going for such fork might
> be pain initially but IMHO its worth it. My idea for this 'fork' is
> not just clean-ups but potential optimizations that such cleanups
> usually bring along. I do not think there will be major overhauls in
> such mature de/compression implementations so I believe its okay to go
> for such 'fork' for sake of cleaner and perhaps faster code.

If you want to make cleaner and faster code, why not work on LZO
upstream directly? I'm sure the LZO author would welcome the speedups,
just as much as the kernel would. 

If they're accepted into LZO, I'm nearly certain the kernel will accept
them and if the kernel code is as I've proposed, upgrading is
straightforward too. Working with "upstream" is often harder but
ultimately much more rewarding.

> Again, I am working on improving the code as per feedback. This is
> what I expect from RFC. Many people raised concerns regarding
> bloatware in your patch too, including me.

And there are concerns against your patches including:

* endian issues
* alignment issues
* potential security holes
* unexplained code generation differences
* difficulty of upgrading

Compared to the style/bloat issue, I'd say that's a fair compromise.

Regards,

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/