Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
Date: Wed, 12 Aug 2015 06:48:31
Message-Id: 20150812094806.5cec466f3b418f9dac688170@gentoo.org
In Reply to: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/ by hasufell
1 On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote:
2 > On 08/11/2015 08:34 AM, Mike Frysinger wrote:
3 > > commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12
4 > > Author: Mike Frysinger <vapier <AT> gentoo <DOT> org>
5 > > AuthorDate: Tue Aug 11 06:28:16 2015 +0000
6 > > Commit: Mike Frysinger <vapier <AT> gentoo <DOT> org>
7 > > CommitDate: Tue Aug 11 06:34:22 2015 +0000
8 > > URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef
9 > >
10 > > microcode-ctl: stop installing the init script
11 > >
12 > > Updating microcode on the fly is dangerous as it can modify the set of
13 > > valid instructions. An active example of this is Intel's TSX insns --
14 > > the latest microcode push disables the insn on newer CPUs and causes
15 > > SIGILL when you try to use it. But if you test for the insn before the
16 > > microcode is updated, it will execute fine. For daemons that launched
17 > > before the update, they'll find the flag works, and then crash later on
18 > > when the insn no longer exists.
19 > >
20 > > Thus the only safe way to update microcode is at boot time via a builtin
21 > > initramfs. Details on this operation can be found in #528712#41.
22 > >
23 >
24 > I've already asked you twice on the ML why you keep ignoring the
25 > standard we set for the commit message summary and pretty much everyone
26 > is following except you.
27
28 Let me remind you that:
29 1. this is not a standard, but a draft;
30 2. not all issues are clear right now (e.g. how to reference bugs);
31 3. it is not approved by the Council;
32 4. not everyone agrees with these rules anyway.
33
34 Best regards,
35 Andrew Savchenko

Replies