The array type of get_domain_list_resp is incorrectly marked as NO_ARRAY.
Due to which the following error was observed when using pdr helpers with
the downstream proprietary pd-mapper. Fix this up by marking it as
VAR_LEN_ARRAY instead.
Err logs:
qmi_decode_struct_elem: Fault in decoding: dl(2), db(27), tl(160), i(1), el(1)
failed to decode incoming message
PDR: tms/servreg get domain list txn wait failed: -14
PDR: service lookup for tms/servreg failed: -14
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Reported-by: Rishabh Bhatnagar <rishabhb(a)codeaurora.org>
Signed-off-by: Sibi Sankar <sibis(a)codeaurora.org>
---
drivers/soc/qcom/pdr_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 15b5002e4127b..ab9ae8cdfa54c 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -185,7 +185,7 @@ struct qmi_elem_info servreg_get_domain_list_resp_ei[] = {
.data_type = QMI_STRUCT,
.elem_len = SERVREG_DOMAIN_LIST_LENGTH,
.elem_size = sizeof(struct servreg_location_entry),
- .array_type = NO_ARRAY,
+ .array_type = VAR_LEN_ARRAY,
.tlv_type = 0x12,
.offset = offsetof(struct servreg_get_domain_list_resp,
domain_list),
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Thu, 10 Sep 2020 09:54:06 +0800
kernel test robot <lkp(a)intel.com> wrote:
> Hi Christian,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on iio/togreg]
> [also build test ERROR on v5.9-rc4 next-20200909]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Christian-Eggers/iio-trigger-Don-t…
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> config: i386-randconfig-r026-20200909 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> reproduce (this is a W=1 build):
> # save the attached .config to linux build tree
> make W=1 ARCH=i386
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp(a)intel.com>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> >> ERROR: modpost: "sched_setscheduler_nocheck" [drivers/iio/industrialio.ko] undefined!
Looks like we can't do this unless we have a precusor patch to export that
function for module use.
Jonathan
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
A recent change to a default value of configuration variable
(ENABLE_X86_RELAX_RELOCATIONS OFF -> ON) in LLVM now causes Clang's
integrated assembler to emit R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX
relocations. LLD will relax instructions with these relocations based on
whether the image is being linked as position independent or not. When
not, then LLD will relax these instructions to use absolute addressing
mode (R_RELAX_GOT_PC_NOPIC). This causes kernels built with Clang
and linked with LLD to fail to boot.
Also, the LLVM commit notes that these relocation types aren't supported
until binutils 2.26. Since we support binutils 2.23+, avoid the
relocations regardless of linker.
The proper solution is to build the compressed boot image as position
independent. There's a series working its way through code review
currently that does that, but it's unlikely to be backported to stable,
due to its size. For now, cut a smaller patch that's more likely to be
easily picked up into stable, so that we can get our kernels booting
again.
Cc: stable(a)vger.kernel.org # 4.14.y
Link: https://github.com/ClangBuiltLinux/linux/issues/1121
Link: https://reviews.llvm.org/rGc41a18cf61790fc898dcda1055c3efbf442c14c0
Link: https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/builds/…
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
---
https://lore.kernel.org/lkml/20200731230820.1742553-7-keescook@chromium.org/
is the patch I'm hopeful for building the compressed image as -pie, but
I don't think the series will be backported. Regardless, we probably
want this for older binutils support.
arch/x86/boot/compressed/Makefile | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 3962f592633d..ab0f7e7dabf9 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -44,6 +44,13 @@ KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS += -D__DISABLE_EXPORTS
+# Until we can build arch/x86/boot/compressed/vmlinux as -Wl,-pie, don't emit
+# R_X86_64_GOTPCRELX or R_X86_64_REX_GOTPCRELX relocations that LLD will relax
+# into absolute addressed operands, and that BFD didn't support until 2.26.
+ifdef CONFIG_CC_IS_CLANG
+KBUILD_CFLAGS += -Wa,-mrelax-relocations=no
+endif
+
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
GCOV_PROFILE := n
UBSAN_SANITIZE :=n
--
2.28.0.236.gb10cc79966-goog
The following commit has been merged into the perf/kprobes branch of tip:
Commit-ID: bcb53209be5cb32d485507452edda19b78f31d84
Gitweb: https://git.kernel.org/tip/bcb53209be5cb32d485507452edda19b78f31d84
Author: Masami Hiramatsu <mhiramat(a)kernel.org>
AuthorDate: Tue, 01 Sep 2020 00:12:07 +09:00
Committer: Ingo Molnar <mingo(a)kernel.org>
CommitterDate: Mon, 14 Sep 2020 11:20:03 +02:00
kprobes: Fix to check probe enabled before disarm_kprobe_ftrace()
Commit:
0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
fixed one bug but the underlying bugs are not completely fixed yet.
If we run a kprobe_module.tc of ftracetest, a warning triggers:
# ./ftracetest test.d/kprobe/kprobe_module.tc
=== Ftrace unit tests ===
[1] Kprobe dynamic event - probing module
...
------------[ cut here ]------------
Failed to disarm kprobe-ftrace at trace_printk_irq_work+0x0/0x7e [trace_printk] (-2)
WARNING: CPU: 7 PID: 200 at kernel/kprobes.c:1091 __disarm_kprobe_ftrace.isra.0+0x7e/0xa0
This is because the kill_kprobe() calls disarm_kprobe_ftrace() even
if the given probe is not enabled. In that case, ftrace_set_filter_ip()
fails because the given probe point is not registered to ftrace.
Fix to check the given (going) probe is enabled before invoking
disarm_kprobe_ftrace().
Fixes: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/159888672694.1411785.5987998076694782591.stgit@de…
---
kernel/kprobes.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 732a701..3b61ae8 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2235,9 +2235,10 @@ static void kill_kprobe(struct kprobe *p)
/*
* The module is going away. We should disarm the kprobe which
- * is using ftrace.
+ * is using ftrace, because ftrace framework is still available at
+ * MODULE_STATE_GOING notification.
*/
- if (kprobe_ftrace(p))
+ if (kprobe_ftrace(p) && !kprobe_disabled(p) && !kprobes_all_disarmed)
disarm_kprobe_ftrace(p);
}
From: Olga Kornievskaia <kolga(a)netapp.com>
[ Upstream commit 3d7a9520f0c3e6a68b6de8c5812fc8b6d7a52626 ]
A client should be able to handle getting an ERR_DELAY error
while doing a LOCK call to reclaim state due to delegation being
recalled. This is a transient error that can happen due to server
moving its volumes and invalidating its file location cache and
upon reference to it during the LOCK call needing to do an
expensive lookup (leading to an ERR_DELAY error on a PUTFH).
Signed-off-by: Olga Kornievskaia <kolga(a)netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/nfs/nfs4proc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index ca1702cefb852..64d15c2662db6 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6171,7 +6171,12 @@ int nfs4_lock_delegation_recall(struct file_lock *fl, struct nfs4_state *state,
err = nfs4_set_lock_state(state, fl);
if (err != 0)
return err;
- err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
+ do {
+ err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
+ if (err != -NFS4ERR_DELAY)
+ break;
+ ssleep(1);
+ } while (err == -NFS4ERR_DELAY);
return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
}
--
2.25.1
From: Olga Kornievskaia <kolga(a)netapp.com>
[ Upstream commit 3d7a9520f0c3e6a68b6de8c5812fc8b6d7a52626 ]
A client should be able to handle getting an ERR_DELAY error
while doing a LOCK call to reclaim state due to delegation being
recalled. This is a transient error that can happen due to server
moving its volumes and invalidating its file location cache and
upon reference to it during the LOCK call needing to do an
expensive lookup (leading to an ERR_DELAY error on a PUTFH).
Signed-off-by: Olga Kornievskaia <kolga(a)netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
fs/nfs/nfs4proc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 714457bb1440a..4e2f18c26535d 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6527,7 +6527,12 @@ int nfs4_lock_delegation_recall(struct file_lock *fl, struct nfs4_state *state,
err = nfs4_set_lock_state(state, fl);
if (err != 0)
return err;
- err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
+ do {
+ err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
+ if (err != -NFS4ERR_DELAY)
+ break;
+ ssleep(1);
+ } while (err == -NFS4ERR_DELAY);
return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
}
--
2.25.1