Building x86_64:tools/perf ... failed
--------------
Error log:
tools/perf/util/python.c:
In function ‘get_md’:
tools/perf/util/python.c:987:9: error: ‘struct perf_mmap’ has no member named ‘cpu’
At top level:
cc1: error: unrecognized command line option ‘-Wno-cast-function-type’ [-Werror]
cc1: all warnings being treated as errors error: command 'gcc' failed with exit status 1
Guenter
On Tue, Sep 11, 2018 at 12:14:30PM +0200, gregkh(a)linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> tracing: Handle CC_FLAGS_FTRACE more accurately
>
> to the 4.14-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
...
> to the 4.18-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
...
> to the 4.4-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
...
> to the 4.9-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
I believe there is no need to backport this patch in neither of stable
branches listed above. This patch is the first one in the patch series:
http://lkml.kernel.org/r/cover.thread-aa7b8d.your-ad-here.call-01533557518-…
The patch series adds s390 support for utilizing newly available for s390
in gcc 9 flags -fentry -mrecord-mcount and -mnop-mcount, and adds generic
-mnop-mcount support. And there is no benefit in backporting just the
first one.
Moreover this patch cause kernel recompile for intdeb-pkg and tar%pkg
targets (i.e. make targz-pkg), because those targets call make recursively
(they do extra "make modules_install"), and exported variable cause
duplicated build flags in sub-make.
There is a potential fix:
https://www.spinics.net/lists/linux-kbuild/msg19297.html
> The filename of the patch is:
> tracing-handle-cc_flags_ftrace-more-accurately.patch
> and it can be found in the queue-4.9 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
>
> From foo@baz Tue Sep 11 12:09:55 CEST 2018
> From: Vasily Gorbik <gor(a)linux.ibm.com>
> Date: Mon, 6 Aug 2018 15:17:42 +0200
> Subject: tracing: Handle CC_FLAGS_FTRACE more accurately
>
> From: Vasily Gorbik <gor(a)linux.ibm.com>
>
> [ Upstream commit f28bc3c32c059ab4d13f52155fabd3e20f477f65 ]
>
> CC_FLAGS_FTRACE is exported and later used to remove ftrace relevant
> build flags from files which should be built without ftrace support.
> For that reason add -mfentry to CC_FLAGS_FTRACE as well. That fixes
> a problem with vdso32 build on s390, where -mfentry could not be used
> together with -m31 flag.
>
> At the same time flags like -pg and -mfentry are not relevant for asm
> files, so avoid adding them to KBUILD_AFLAGS.
>
> Introduce CC_FLAGS_USING instead of CC_USING_FENTRY to collect
> -DCC_USING_FENTRY (and future alike) which are relevant for both
> KBUILD_CFLAGS and KBUILD_AFLAGS.
>
> Link: http://lkml.kernel.org/r/patch-1.thread-aa7b8d.git-42971afe87de.your-ad-her…
>
> Signed-off-by: Vasily Gorbik <gor(a)linux.ibm.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> Makefile | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> --- a/Makefile
> +++ b/Makefile
> @@ -760,12 +760,15 @@ ifdef CONFIG_FUNCTION_TRACER
> ifndef CC_FLAGS_FTRACE
> CC_FLAGS_FTRACE := -pg
> endif
> -export CC_FLAGS_FTRACE
> ifdef CONFIG_HAVE_FENTRY
> -CC_USING_FENTRY := $(call cc-option, -mfentry -DCC_USING_FENTRY)
> + ifeq ($(call cc-option-yn, -mfentry),y)
> + CC_FLAGS_FTRACE += -mfentry
> + CC_FLAGS_USING += -DCC_USING_FENTRY
> + endif
> endif
> -KBUILD_CFLAGS += $(CC_FLAGS_FTRACE) $(CC_USING_FENTRY)
> -KBUILD_AFLAGS += $(CC_USING_FENTRY)
> +export CC_FLAGS_FTRACE
> +KBUILD_CFLAGS += $(CC_FLAGS_FTRACE) $(CC_FLAGS_USING)
> +KBUILD_AFLAGS += $(CC_FLAGS_USING)
> ifdef CONFIG_DYNAMIC_FTRACE
> ifdef CONFIG_HAVE_C_RECORDMCOUNT
> BUILD_C_RECORDMCOUNT := y
>
>
> Patches currently in stable-queue which might be from gor(a)linux.ibm.com are
>
> queue-4.9/tracing-handle-cc_flags_ftrace-more-accurately.patch
>
The nr_dentry_unused per-cpu counter tracks dentries in both the
LRU lists and the shrink lists where the DCACHE_LRU_LIST bit is set.
The shrink_dcache_sb() function moves dentries from the LRU list to a
shrink list and subtracts the dentry count from nr_dentry_unused. This
is incorrect as the nr_dentry_unused count Will also be decremented in
shrink_dentry_list() via d_shrink_del(). To fix this double decrement,
the decrement in the shrink_dcache_sb() function is taken out.
Fixes: 4e717f5c1083 ("list_lru: remove special case function list_lru_dispose_all."
Cc: stable(a)vger.kernel.org
Signed-off-by: Waiman Long <longman(a)redhat.com>
Reviewed-by: Dave Chinner <dchinner(a)redhat.com>
---
fs/dcache.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 2e7e8d8..cb515f1 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1202,15 +1202,11 @@ static enum lru_status dentry_lru_isolate_shrink(struct list_head *item,
*/
void shrink_dcache_sb(struct super_block *sb)
{
- long freed;
-
do {
LIST_HEAD(dispose);
- freed = list_lru_walk(&sb->s_dentry_lru,
+ list_lru_walk(&sb->s_dentry_lru,
dentry_lru_isolate_shrink, &dispose, 1024);
-
- this_cpu_sub(nr_dentry_unused, freed);
shrink_dentry_list(&dispose);
} while (list_lru_count(&sb->s_dentry_lru) > 0);
}
--
1.8.3.1
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b2b599fb54f90ae395ddc51f0d49e4f28244a8f8 Mon Sep 17 00:00:00 2001
From: Hang Yuan <hang.yuan(a)linux.intel.com>
Date: Wed, 29 Aug 2018 17:15:56 +0800
Subject: [PATCH] drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in
stop_schedule
pm_runtime_get_sync in intel_runtime_pm_get might sleep if i915
device is not active. When stop vgpu schedule, the device may be
inactive. So need to move runtime_pm_get out of spin_lock/unlock.
Fixes: b24881e0b0b6("drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Hang Yuan <hang.yuan(a)linux.intel.com>
Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw(a)linux.intel.com>
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c b/drivers/gpu/drm/i915/gvt/mmio_context.c
index 42e1e6bdcc2c..e872f4847fbe 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -562,11 +562,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
* performace for batch mmio read/write, so we need
* handle forcewake mannually.
*/
- intel_runtime_pm_get(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
switch_mmio(pre, next, ring_id);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
- intel_runtime_pm_put(dev_priv);
}
/**
diff --git a/drivers/gpu/drm/i915/gvt/sched_policy.c b/drivers/gpu/drm/i915/gvt/sched_policy.c
index 09d7bb72b4ff..985fe81794dd 100644
--- a/drivers/gpu/drm/i915/gvt/sched_policy.c
+++ b/drivers/gpu/drm/i915/gvt/sched_policy.c
@@ -426,6 +426,7 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu)
&vgpu->gvt->scheduler;
int ring_id;
struct vgpu_sched_data *vgpu_data = vgpu->sched_data;
+ struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
if (!vgpu_data->active)
return;
@@ -444,6 +445,7 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu)
scheduler->current_vgpu = NULL;
}
+ intel_runtime_pm_get(dev_priv);
spin_lock_bh(&scheduler->mmio_context_lock);
for (ring_id = 0; ring_id < I915_NUM_ENGINES; ring_id++) {
if (scheduler->engine_owner[ring_id] == vgpu) {
@@ -452,5 +454,6 @@ void intel_vgpu_stop_schedule(struct intel_vgpu *vgpu)
}
}
spin_unlock_bh(&scheduler->mmio_context_lock);
+ intel_runtime_pm_put(dev_priv);
mutex_unlock(&vgpu->gvt->sched_lock);
}