aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/cpu/microcode/intel.c
diff options
context:
space:
mode:
Diffstat (limited to 'arch/x86/kernel/cpu/microcode/intel.c')
-rw-r--r--arch/x86/kernel/cpu/microcode/intel.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 2ad40b73c8df..d852ca984f87 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -675,8 +675,8 @@ int __init save_microcode_in_initrd_intel(void)
ret = save_microcode(&mc_saved_data, mc_saved, count);
if (ret)
pr_err("Cannot save microcode patches from initrd.\n");
-
- show_saved_mc();
+ else
+ show_saved_mc();
return ret;
}
-product of merge-recursive's design. Since it was doing a four way merge with the contents of the working tree being the fourth factor it had to consider, it had working tree handling spread all over the code. It also had directory/file conflict handling spread everywhere through all the other types of conflicts. And our testsuite has a huge number of directory/file conflict tests because trying to get them right required modifying so many different codepaths. A natural outgrowth of this kind of structure is conflict messages that combine all the different types that the current codepath is considering. However, if we want to make the different conflict types orthogonal and avoid repeating ourselves and getting very brittle code, then we need to split the messages from these different conflict types apart. Besides, trying to determine all possible permutations is a _royal_ mess. The code to handle the rename/delete/directory/file conflict output is already somewhat hard to parse, and is somewhat brittle. But if we really wanted to go that route, then we'd have to have special handling for the following types of combinations: * rename/add/delete: on side of history that didn't rename the given file, remove the file instead and place an unrelated file in the way of the rename * rename/rename(2to1)/mode conflict/delete/delete: two different files, one executable and the other not, are renamed to the same location, each side deletes the source file that the other side renames * rename/rename(1to2)/add/add: file renamed differently on each side of history, with each side placing an unrelated file in the way of the other * rename/rename(1to2)/content conflict/file location/(D/F)/(D/F)/: both sides modify a file in conflicting way, both rename that file but to different paths, one side renames the directory which the other side had renamed that file into causing it to possibly need a transitive rename, and each side puts a directory in the way of the other's path. Let's back away from this path of insanity, and allow the different types of conflicts to be handled by separate pieces of non-repeated code by allowing the conflict messages to be split into their separate types. (If multiple conflict types affect a single path, the conflict messages can be printed sequentially.) Start this path with a simple change: modify this test to be more flexible and accept the output either merge backend (recursive or the new ort) will produce. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t642[23]: be more flexible for add/add conflicts involving pair renamesElijah Newren2-8/+14 Much like the last commit accepted 'add/add' and 'rename/add' interchangably, we also want to do the same for 'add/add' and 'rename/rename'. This also allows us to avoid the ambiguity in meaning with 'rename/rename' (is it two separate files renamed to the same location, or one file renamed on both sides but differently)? Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6422, t6426: be more flexible for add/add conflicts involving renamesElijah Newren2-9/+14 merge-recursive treats an add/add conflict where one of the adds came from a rename as a separate 'rename/add' type of conflict. However, if there is not content conflict after the content merge(s), then the file is not considered to be conflicted. That suggests the conflict type is really just add/add. Other merge engines might choose to print messages to the console that just refer to these as add/add conflicts; accept both types of output. Note: it could help to notify users if the three-way content merge of the rename had content conflicts, because when we then go to two-way merge THAT with the conflicting add we can get nested conflict markers. merge-recursive, unfortunately, doesn't do that, but other merge engines could. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6423: add an explanation about why one of the tests does not passElijah Newren1-0/+8 I had long since forgotten the idea behind this test and why it failed, and took a little while to figure it out. To prevent others from having to spend a similar time on it, add an explanation in the comments. However, the reasoning in the explanation makes me question why I considered it a failure at all. I'm not sure if I had a better reason when I originally wrote it, but for now just add commentary about the possible expectations and why it behaves the way it does right now. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6416, t6423: clarify some comments and fix some typosElijah Newren2-14/+13 Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6422: fix multiple errors with the mod6 test expectationsElijah Newren1-9/+10 This test had multiple issues causing it to fail for the wrong reason(s): * rename/rename(1to2) conflicts have always left the original source path present in the working directory and index (at stage 1). Thus, the triple rename/rename(1to2) should result in 9 unstaged files, not 6. * It messed up the three-way content merge for checking the results of merging for one of the renames, accidentally turning it into a two-way merge. * It got the contents of the base files it was using to compare against wrong, due to an off-by-one error, and overwrite-redirection ('>') instead of append-redirection ('>>'). * It used slightly too-long conflict markers * It didn't include filenames in the conflict marker hunks (granted, that was a shortcoming of the merge-recursive backend for rename/add and rename/rename(2to1) conflicts, but since it's test_expect_failure anyway we might as well make it expect our preferred behavior rather than some compromise that we can't yet reach anyway). Fix these issues so that a merge backend which correctly handles these kinds of nested conflicts will pass the test. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6423: fix test setup for a couple testsElijah Newren1-0/+2 Commit da1e295e00 ("t604[236]: do not run setup in separate tests", 2019-10-22) removed approximately half the tests (which were setup-only tests) in t6043 by turning them into functions that the subsequent test would call as their first step. This ensured that any test from this file could be run entirely independently of all the other tests in the file. Unfortunately, the call to the new setup function was missed in two of the test_expect_failure cases. Add them in. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6416, t6422: fix incorrect untracked file countElijah Newren2-3/+3 Apparently I don't know how to count untracked files, and since the tests in question were marked as test_expect_failure, no one ever noticed it until now. Correct the count, as these tests clearly create three untracked files ('out', 'err', and 'file_count'). (I believe this problem arose because earlier incarnations counted lines via a pipe to 'wc -l'. Reviewers asked that it be replaced by writing the output to a file and using test_line_count, but when the temporary output was added to a separate file, the count of untracked files should have increased.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6422: fix bad check against missing fileElijah Newren1-3/+3 Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10t6418: tighten delete/normalize conflict testcaseElijah Newren1-1/+2 The testcase only required that the merge complete without conflict, without specifying what the correct resolution was. Since normalization changed this from a modify/delete to a not-modified/delete, the correct resolution is to have the file be removed at the end. Add a check for this resolution. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10Collect merge-related tests to t64xxElijah Newren35-0/+0 The tests for the merge machinery are spread over several places. Collect them into t64xx for simplicity. Some notes: t60[234]*.sh: Merge tests started in t602*, overgrew bisect and remote tracking tests in t6030, t6040, and t6041, and nearly overtook replace tests in t6050. This made picking out relevant tests that I wanted to run in a tighter loop slightly more annoying for years. t303*.sh: These started out as tests for the 'merge-recursive' toplevel command, but did not restrict to that and had lots of overlap with the underlying merge machinery. t7405, t7613: submodule-specific merge logic started out in submodule.c but was moved to merge-recursive.c in commit 18cfc08866 ("submodule.c: move submodule merging to merge-recursive.c", 2018-05-15). Since these tests are about the logic found in the merge machinery, moving these tests to be with the merge tests makes sense. t7607, t7609: Having tests spread all over the place makes it more likely that additional tests related to a certain piece of logic grow in all those other places. Much like t303*.sh, these two tests were about the underlying merge machinery rather than outer levels. Tests that were NOT moved: t76[01]*.sh: Other than the four tests mentioned above, the remaining tests in t76[01]*.sh are related to non-recursive merge strategies, parameter parsing, and other stuff associated with the highlevel builtin/merge.c rather than the recursive merge machinery. t3[45]*.sh: The rebase testcases in t34*.sh also test the merge logic pretty heavily; sometimes changes I make only trigger failures in the rebase tests. The rebase tests are already nicely coupled together, though, and I didn't want to mess that up. Similar comments apply for the cherry-pick tests in t35*.sh. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10progress: don't dereference before checking for NULLMartin Ågren1-2/+10 In `stop_progress()`, we're careful to check that `p_progress` is non-NULL before we dereference it, but by then we have already dereferenced it when calling `finish_if_sparse(*p_progress)`. And, for what it's worth, we'll go on to blindly dereference it again inside `stop_progress_msg()`. We could return early if we get a NULL-pointer, but let's go one step further and BUG instead. The progress API handles NULL just fine, but that's the NULL-ness of `*p_progress`, e.g., when running with `--no-progress`. If `p_progress` is NULL, chances are that's a mistake. For symmetry, let's do the same check in `stop_progress_msg()`, too. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10Fifth batchJunio C Hamano1-0/+15 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-10init: disallow --separate-git-dir with bare repositoryEric Sunshine2-0/+18 The purpose of "git init --separate-git-dir" is to separate the repository from the worktree. This is true even when --separate-git-dir is used on an existing worktree, in which case, it moves the .git/ subdirectory to a new location outside the worktree. However, an outright bare repository (such as one created by "git init --bare"), has no worktree, so using --separate-git-dir to separate it from its non-existent worktree is nonsensical. Therefore, make it an error to use --separate-git-dir on a bare repository. Implementation note: "git init" considers a repository bare if told so explicitly via --bare or if it guesses it to be so based upon heuristics. In the explicit --bare case, a conflict with --separate-git-dir is easy to detect early. In the guessed case, however, the conflict can only be detected once "bareness" is guessed, which happens after "git init" has begun creating the repository. Technically, we can get by with a single late check which would cover both cases, however, erroring out early, when possible, without leaving detritus provides a better user experience. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-09test_cmp: diagnose incorrect argumentsEric Sunshine1-2/+14 Under normal circumstances, if a test author misspells a filename passed to test_cmp(), the error is quickly discovered when the test fails unexpectedly due to test_cmp() being unable to find the file. However, if the test is expected to fail, as with test_expect_failure(), a misspelled filename as argument to test_cmp() will go unnoticed since the test will indeed fail, but for the wrong reason. Make it easier for test authors to discover such problems early by sanity-checking the arguments to test_cmp(). To avoid penalizing all clients of test_cmp() in the general case, only check for missing files if the comparison fails. While at it, make test_cmp_bin() sanity-check its arguments, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-08-09diff-lib: use worktree mode in diffs from i-t-a entriesRaymond E. Pasco1-1/+2 When creating "new file" diffs against i-t-a index entries, diff-lib erroneously used the mode of the cache entry rather than the mode of the file in the worktree. This changes run_diff_files() to correctly use the mode of the worktree file in this case. Signed-off-by: Raymond E. Pasco <ray@ameretat.dev> Signed-off-by: Junio C Hamano <gitster@pobox.com>