linux-kernel - Re: [ck] Re: 2.6.20-ck1

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:	Sat, 17 Feb 2007 16:50:37 -0500
From:	"michael chang" <thenewme91@...il.com>
To:	"Con Kolivas" <kernel@...ivas.org>
Cc:	"Chuck Ebbert" <cebbert@...hat.com>,
	"ck mailing list" <ck@....kolivas.org>,
	"linux kernel mailing list" <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: 2.6.20-ck1

On 2/17/07, Con Kolivas <kernel@...ivas.org> wrote:
> On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
> > Con Kolivas wrote:
> > > Maintainers are far too busy off testing code for
> > > 16+ cpus, petabytes of disk storage and so on to try it for themselves.
> > > Plus they worry incessantly that my patches may harm those precious
> > > machines' performance...
> >
> > But the one I like, mm-filesize_dependant_lru_cache_add.patch,
> > has an on-off switch.
> >
> > In other words it adds an option to do things differently.
> > How could that possibly affect any workload if that option
> > isn't enabled?
>
> Swap prefetch not only has an on-off switch, you can even build your kernel
> without it entirely so it costs even less than this patch... I'm not going to
> support the argument that it might be built into the kernel and enabled
> unknowingly and _then_ cause overhead.

The patch, the way it's written now -- is the default to build with
swap-prefetch, or build without by default? If the former, maybe it
would be more accepted if the latter was the default. (Of course, that
defeats the point for desktop users who add the patch and then wonder
why it doesn't work, but... *shrugs*)

> Oh and this patch depends on some of the code from the swap prefetch patch
> too. I guess since they're so suspicious of swap prefetch the swap prefetch
> patch can be ripped apart for the portions of code required to make this
> patch work.

While I'm all for putting Con's patches into mainline, I'm worried
about what happens if you rip swap prefetch apart and (if the
unthinkable happens) somebody accidentally omits something or worse.
Then mainline would have even more reason to be suspicious of code
from you, Con. Unless you already ripped the swap prefetch patch into
the parts that mm-filesize_dependant_lru_cache_add.patch depend on and
the parts it doesn't, and check it's "sane" to use them
independently...

(I'd be WAY more suspicious of having "half" of swap prefetch than
having all of it. I hope that most of mainline agrees with me, but I
have a sneaking suspicion they don't.)

In any case, this "ripping"... would it make the reverse happen? i.e.
swap prefetch being dependent on
mm-filesize_dependant_lru_cache_add.patch instead?

-- 
~Mike
 - Just the crazy copy cat.
-
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/