linux-kernel - Re: ia64 broken by transparent huge pages

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, 15 Jan 2011 20:02:41 +0100
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"Luck, Tony" <tony.luck@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arch@...r.kernel.org
Subject: Re: ia64 broken by transparent huge pages - other arches too?

On Sat, Jan 15, 2011 at 18:23, Andrea Arcangeli <aarcange@...hat.com> wrote:
>> The problem is very often not in the actual code, but in the side
>> effects the code causes.  This is what linux-next integration helps
>> mitigate. So, please use it next time.  Just testing on x86 in your own
>> configuration isn't sufficient to pick up the problems.
>
> I fully agree with you about build time regression, there linux-next
> might have helped more. I'm talking about runtime regressions. If it
> build it'll work because nothing relevant has changed for not-x86
> archs.
>
> By all means next times I'll try to get through linux-next too if this
> is preferred, but the brainer part has been heavily tested and that's
> the important thing as far as I can see.
>
> I'm also not sure if having it in linux-next instead of -mm, would
> have been better in terms of handling of the patchstream. I think
> having it managed in -mm reviewed by all other -mm developers using
> raw patches floating in the linux-mm and mm-commit lists, was ideal
> and potentially more valuable for an increased amount of review, than
> what a blind pull from linux-next could provide. For the brainer part,
> maximizing the reviewing was certainly more valuable than checking if
> it builds and boots on some arch not affected in any functional way.

These are not mutually exclusive options: we want to (a) have everything
reviewed and discussed _and_ (b) have everything build (and optionally run)
tested in linux-next. If perfection was the goal, we don't settle for anything
less.

Furthermore, even stupid and trivial to fix build issues may mask other
more severe issues, and delay the fixing of those.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/