linux-kernel - [Regression] Please revert a91a2785b20

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-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1103290006070.2774@localhost6.localdomain6>
Date:	Tue, 29 Mar 2011 00:35:20 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Mike Snitzer <snizer@...hat.com>,
	James Bottomley <James.Bottomley@...e.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ingo Molnar <mingo@...e.hu>
Subject: [Regression] Please revert a91a2785b20

Out of the blue all my perfectly fine working test machines which use
RAID stopped working with the very helpful error message:

	md/raid1:md1: active with 2 out of 2 mirrors
	md: pers->run() failed ...

Reverting a91a2785b20 fixes the problem.

Neither the subject line:

 block: Require subsystems to explicitly allocate bio_set integrity mempool

nor the changelog have any hint why that wreckage is in any way
sensible.

The wreckage happens due to:

-       md_integrity_register(mddev);
-       return 0;
+       return md_integrity_register(mddev);

But the changelog does not give the courtesy of explaining these
changes. Also there is no fcking reason why the kernel cannot deal
with the missing integrity capabilities of a drive just by emitting a
warning msg and dealing gracefully with the outcome.

All my RAID setups have been working perfectly fine until now, so
what's the rationale to break this?

Did anyone test this shite on a non enterprise class hardware with a
distro default config ? Obviously _NOT_.

FYI, the config files of those machines are based off a fedora default
config, so this would hit all raid users based on popular distro
configs sooner than later.

Thanks for stealing my time,

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