aboutsummaryrefslogtreecommitdiffstats
path: root/arch/powerpc/lib/code-patching.c
diff options
context:
space:
mode:
Diffstat (limited to 'arch/powerpc/lib/code-patching.c')
-rw-r--r--arch/powerpc/lib/code-patching.c64
1 files changed, 49 insertions, 15 deletions
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 0d1f3ee91115..7f423fa3c51b 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -20,15 +20,14 @@
#include <asm/code-patching.h>
#include <asm/inst.h>
-static int __patch_instruction(u32 *exec_addr, ppc_inst_t instr, u32 *patch_addr)
+static int __patch_mem(void *exec_addr, unsigned long val, void *patch_addr, bool is_dword)
{
- if (!ppc_inst_prefixed(instr)) {
- u32 val = ppc_inst_val(instr);
+ if (!IS_ENABLED(CONFIG_PPC64) || likely(!is_dword)) {
+ /* For big endian correctness: plain address would use the wrong half */
+ u32 val32 = val;
- __put_kernel_nofault(patch_addr, &val, u32, failed);
+ __put_kernel_nofault(patch_addr, &val32, u32, failed);
} else {
- u64 val = ppc_inst_as_ulong(instr);
-
__put_kernel_nofault(patch_addr, &val, u64, failed);
}
@@ -44,7 +43,10 @@ failed:
int raw_patch_instruction(u32 *addr, ppc_inst_t instr)
{
- return __patch_instruction(addr, instr, addr);
+ if (ppc_inst_prefixed(instr))
+ return __patch_mem(addr, ppc_inst_as_ulong(instr), addr, true);
+ else
+ return __patch_mem(addr, ppc_inst_val(instr), addr, false);
}
struct patch_context {
@@ -276,7 +278,7 @@ static void unmap_patch_area(unsigned long addr)
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
}
-static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
+static int __do_patch_mem_mm(void *addr, unsigned long val, bool is_dword)
{
int err;
u32 *patch_addr;
@@ -305,7 +307,7 @@ static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
orig_mm = start_using_temp_mm(patching_mm);
- err = __patch_instruction(addr, instr, patch_addr);
+ err = __patch_mem(addr, val, patch_addr, is_dword);
/* context synchronisation performed by __patch_instruction (isync or exception) */
stop_using_temp_mm(patching_mm, orig_mm);
@@ -322,7 +324,7 @@ static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t instr)
return err;
}
-static int __do_patch_instruction(u32 *addr, ppc_inst_t instr)
+static int __do_patch_mem(void *addr, unsigned long val, bool is_dword)
{
int err;
u32 *patch_addr;
@@ -339,7 +341,7 @@ static int __do_patch_instruction(u32 *addr, ppc_inst_t instr)
if (radix_enabled())
asm volatile("ptesync": : :"memory");
- err = __patch_instruction(addr, instr, patch_addr);
+ err = __patch_mem(addr, val, patch_addr, is_dword);
pte_clear(&init_mm, text_poke_addr, pte);
flush_tlb_kernel_range(text_poke_addr, text_poke_addr + PAGE_SIZE);
@@ -347,7 +349,7 @@ static int __do_patch_instruction(u32 *addr, ppc_inst_t instr)
return err;
}
-int patch_instruction(u32 *addr, ppc_inst_t instr)
+static int patch_mem(void *addr, unsigned long val, bool is_dword)
{
int err;
unsigned long flags;
@@ -359,19 +361,51 @@ int patch_instruction(u32 *addr, ppc_inst_t instr)
*/
if (!IS_ENABLED(CONFIG_STRICT_KERNEL_RWX) ||
!static_branch_likely(&poking_init_done))
- return raw_patch_instruction(addr, instr);
+ return __patch_mem(addr, val, addr, is_dword);
local_irq_save(flags);
if (mm_patch_enabled())
- err = __do_patch_instruction_mm(addr, instr);
+ err = __do_patch_mem_mm(addr, val, is_dword);
else
- err = __do_patch_instruction(addr, instr);
+ err = __do_patch_mem(addr, val, is_dword);
local_irq_restore(flags);
return err;
}
+
+#ifdef CONFIG_PPC64
+
+int patch_instruction(u32 *addr, ppc_inst_t instr)
+{
+ if (ppc_inst_prefixed(instr))
+ return patch_mem(addr, ppc_inst_as_ulong(instr), true);
+ else
+ return patch_mem(addr, ppc_inst_val(instr), false);
+}
NOKPROBE_SYMBOL(patch_instruction);
+int patch_uint(void *addr, unsigned int val)
+{
+ return patch_mem(addr, val, false);
+}
+NOKPROBE_SYMBOL(patch_uint);
+
+int patch_ulong(void *addr, unsigned long val)
+{
+ return patch_mem(addr, val, true);
+}
+NOKPROBE_SYMBOL(patch_ulong);
+
+#else
+
+int patch_instruction(u32 *addr, ppc_inst_t instr)
+{
+ return patch_mem(addr, ppc_inst_val(instr), false);
+}
+NOKPROBE_SYMBOL(patch_instruction)
+
+#endif
+
static int patch_memset64(u64 *addr, u64 val, size_t count)
{
for (u64 *end = addr + count; addr < end; addr++)
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-12 14:50:27 +0000
port overlapping shelved changelists where one change touches the files modified by another. Trying to do this will result in merge conflicts. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22check-non-portable-shell.pl: `wc -l` may have leading WSTorsten Bögershausen1-0/+1 Test scripts count number of lines in an output and check it againt its expectation. fb3340a6 ("test-lib: introduce test_line_count to measure files", 2010-10-31) introduced a helper to show a failure in such a test in a more readable way than comparing `wc -l` output with a number. Besides, on some platforms, "$(wc -l <file)" is padded with leading whitespace on the left, so test "$(wc -l <file)" = 4 would not work (most notably on macosX); the users of test_line_count helper would not suffer from such a portability glitch. Add a check in check-non-portable-shell.pl to find '"' between `wc -l` and '=' and hint the user about test_line_count(). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22config.txt: document behavior of backslashes in subsectionsDave Borowitz1-5/+7 Unrecognized escape sequences are invalid in values: $ git config -f - --list <<EOF [foo] bar = "\t\\\y\"\u" EOF fatal: bad config line 2 in standard input But in subsection names, the backslash is simply dropped if the following character does not produce a recognized escape sequence: $ git config -f - --list <<EOF [foo "\t\\\y\"\u"] bar = baz EOF foo.t\y"u.bar=baz Although it would be nice for subsection names and values to have consistent behavior, changing the behavior for subsection names is a nonstarter since it would cause existing, valid config files to suddenly be interpreted differently. Signed-off-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22merge-recursive: avoid incorporating uncommitted changes in a mergeElijah Newren2-1/+8 builtin/merge.c contains this important requirement for merge strategies: /* * At this point, we need a real merge. No matter what strategy * we use, it would operate on the index, possibly affecting the * working tree, and when resolved cleanly, have the desired * tree in the index -- this means that the index must be in * sync with the head commit. The strategies are responsible * to ensure this. */ merge-recursive does not do this check directly, instead it relies on unpack_trees() to do it. However, merge_trees() has a special check for the merge branch exactly matching the merge base; when it detects that situation, it returns early without calling unpack_trees(), because it knows that the HEAD commit already has the correct result. Unfortunately, it didn't check that the index matched HEAD, so after it returned, the outer logic ended up creating a merge commit that included something other than HEAD. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22move index_has_changes() from builtin/am.c to merge.c for reuseElijah Newren3-37/+42 index_has_changes() is a function we want to reuse outside of just am, making it also available for merge-recursive and merge-ort. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22t6044: recursive can silently incorporate dirty changes in a mergeElijah Newren1-5/+21 The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-22t/helper/test-lazy-name-hash: fix compilationStefan Beller1-1/+1 I was compiling origin/master today with DEVELOPER compiler flags and was greeted by: t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’: t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used uninitilized in this function [-Werror=maybe-uninitialized] printf("avg [size %8d] [single %f] %c [multi %f %d]\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr, ~~~ (double)avg_single/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (avg_single < avg_multi ? '<' : '>'), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (double)avg_multi/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr_threads_used); ~~~~~~~~~~~~~~~~ t/helper/test-lazy-init-name-hash.c:115:6: note: ‘nr_threads_used’ was declared here int nr_threads_used; ^~~~~~~~~~~~~~~ I do not see how we can arrive at that line without having `nr_threads_used` initialized, as we'd have `count > 1` (which asserts that we ran the loop above at least once, such that it *should* be initialized). Just clear the variable at the beginning of the function to squelch the warning. Signed-off-by: Stefan Beller <sbeller@google.com> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19t5573, t7612: clean up after unexpected success of 'pull' and 'merge'Junio C Hamano2-8/+17 The previous steps added test_when_finished to tests that run 'git pull' or 'git merge' with expectation of success, so that the test after them can start from a known state even when their 'git pull' invocation unexpectedly fails. However, tests that run 'git pull' or 'git merge' expecting it not to succeed forgot to protect later tests the same way---if they unexpectedly succeed, the test after them would start from an unexpected state. Reset and checkout the initial commit after all these tests, whether they expect their invocations to succeed or fail. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19RelNotes: the tenth batchJunio C Hamano1-0/+46 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19builtin/describe.c: describe a blobStefan Beller3-7/+107 Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) When describing commits, we try to anchor them to tags or refs, as these are conceptually on a higher level than the commit. And if there is no ref or tag that matches exactly, we're out of luck. So we employ a heuristic to make up a name for the commit. These names are ambiguous, there might be different tags or refs to anchor to, and there might be different path in the DAG to travel to arrive at the commit precisely. When describing a blob, we want to describe the blob from a higher layer as well, which is a tuple of (commit, deep/path) as the tree objects involved are rather uninteresting. The same blob can be referenced by multiple commits, so how we decide which commit to use? This patch implements a rather naive approach on this: As there are no back pointers from blobs to commits in which the blob occurs, we'll start walking from any tips available, listing the blobs in-order of the commit and once we found the blob, we'll take the first commit that listed the blob. For example git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile tells us the Makefile as it was in v0.99 was introduced in commit 7672db20. The walking is performed in reverse order to show the introduction of a blob rather than its last occurrence. [1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19http: support CURLPROXY_HTTPSWei Shuyu1-0/+5 HTTP proxy over SSL is supported by curl since 7.52.0. This is very useful for networks with protocol whitelist. Signed-off-by: Wei Shuyu <wsy@dogben.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19rebase: rebasing can also be done when HEAD is detachedKaartic Sivaraam1-2/+14 Attempting to rebase when the HEAD is detached and is already up to date with upstream (so there's nothing to do), the following message is shown Current branch HEAD is up to date. which is clearly wrong as HEAD is not a branch. Handle the special case of HEAD correctly to give a more precise error message. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19rebase: distinguish user input by quoting itKaartic Sivaraam1-2/+2 Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19rebase: consistently use branch_name variableKaartic Sivaraam1-7/+10 The variable "branch_name" holds the <branch> parameter in "git rebase <upstream> <branch>", but one codepath did not use it after assigning $1 to it (instead it kept using $1). Make it use the variable consistently. Also, update an error message to say there is no such branch or commit, as we are expecting either of them, and not limiting ourselves to a branch name. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-19Doc/check-ref-format: clarify information about @{-N} syntaxKaartic Sivaraam1-7/+12 When the N-th previous thing checked out syntax (@{-N}) is used with '--branch' option of check-ref-format the result may not be the name of a branch that currently exists or ever existed. This is because @{-N} is used to refer to the N-th last checked out "thing", which might be a commit object name if the previous check out was a detached HEAD state; or a branch name, otherwise. The documentation thus does a wrong thing by promoting it as the "previous branch syntax". State that @{-N} is the syntax for specifying "N-th last thing checked out" and also state that the result of using @{-N} might also result in an commit object name. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-18config: document default value of http.sslVerifySimon Ruderich1-2/+2 Remove any doubt that certificates might not be verified by default. Signed-off-by: Simon Ruderich <simon@ruderich.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-18p7519: improve check for prerequisite WATCHMANRené Scharfe1-2/+1 The return code of command -v with a non-existing command is 1 in bash and 127 in dash. Use that return code directly to allow the script to work with dash and without watchman (e.g. on Debian). While at it stop redirecting the output. stderr is redirected to /dev/null by test_lazy_prereq already, and stdout can actually be useful -- the path of the found watchman executable is sent there, but it's shown only if the script was run with --verbose. Signed-off-by: Rene Scharfe <l.s.r@web.de> Acked-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-18imap-send: URI encode server folderNicolas Morey-Chaisemartin1-1/+7 When trying to send a patch using 'imap-send' with 'curl' and the following configuration: [imap] folder = "[Gmail]/Drafts" host = imaps://imap.gmail.com port = 993 sslverify = false results in the following error, curl_easy_perform() failed: URL using bad/illegal format or missing URL This is a consequence of not URI-encoding the folder portion of the URL which contains characters such as '[' which are not allowed in a URI. According to RFC3986, these characters should be URI-encoded. So, URI-encode the folder before adding it to the URI to ensure it doesn't contain characters that aren't allowed in a URI. Reported-by: Doron Behar <doron.behar@gmail.com> Signed-off-by: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.com> Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-14version --build-options: report commit, too, if possibleJohannes Schindelin4-1/+10 In particular when local tags are used (or tags that are pushed to some fork) to build Git, it is very hard to figure out from which particular revision a particular Git executable was built. It gets worse when those tags are deleted, or even updated. Let's just report an exact, unabbreviated commit name in our build options. We need to be careful, though, to report when the current commit cannot be determined, e.g. when building from a tarball without any associated Git repository. This could be the case also when extracting Git's source code into an unrelated Git worktree. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-14version --build-options: also report host CPUEric Sunshine2-0/+10 It can be helpful for bug reports to include information about the environment in which the bug occurs. "git version --build-options" can help to supplement this information. In addition to the size of 'long' already reported by --build-options, also report the host's CPU type. Example output: $ git version --build-options git version 2.9.3.windows.2.826.g06c0f2f cpu: x86_64 sizeof-long: 4 New Makefile variable HOST_CPU supports cross-compiling. Suggested-by: Adric Norris <landstander668@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-14transport: make transport vtable more privateJonathan Tan4-87/+120 Move the definition of the transport-specific functions provided by transports, whether declared in transport.c or transport-helper.c, into an internal header. This means that transport-using code (as opposed to transport-declaring code) can no longer access these functions (without importing the internal header themselves), making it clear that they should use the transport_*() functions instead, and also allowing the interface between the transport mechanism and an individual transport to independently evolve. This is superficially a reversal of commit 824d5776c3f2 ("Refactor struct transport_ops inlined into struct transport", 2007-09-19). However, the scope of the involved variables was neither affected nor discussed in that commit, and I think that the advantages in making those functions more private outweigh the advantages described in that commit's commit message. A minor additional point is that the code has gotten more complicated since then, in that the function-pointer variables are potentially mutated twice (once initially and once if transport_take_over() is invoked), increasing the value of corralling them into their own struct. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-12-14clone, fetch: remove redundant transport checkJonathan Tan2-6/+0 Prior to commit a2d725b7bdf7 ("Use an external program to implement fetching with curl", 2009-08-05), if Git was compiled with NO_CURL, the get_refs_list and fetch methods in struct transport might not be populated, hence the checks in clone and fetch. After that commit, all transports populate get_refs_list and fetch, making the checks in clone and fetch redundant. Remove those checks. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>