Re: [BUG] oops in cpufreq driver with AMD Kaveri CPU

[Oleksandr Natalenko]

On Wednesday 13 August 2014 10:02:26 Viresh Kumar wrote:
> That's why you should have copied the diff here, so that I could have
> confirmed if what you have done is correct or not.

You may check my modifications here [1] or attached to this email.

[1] https://gist.github.com/bdcc7d41883b5e077974

-- 
Oleksandr post-factum Natalenko, MSc
pf-kernel community
https://natalenko.name/>From 493cd190339201c264cdc4cbc1c96c70c786a776 Mon Sep 17 00:00:00 2001
From: Oleksandr Natalenko 
Date: Wed, 13 Aug 2014 08:54:09 +0300
Subject: [PATCH] add cpufreq debug

---
 arch/arm/kernel/smp.c| 2 ++
 arch/arm/kernel/smp_twd.c| 2 ++
 arch/arm/mach-pxa/viper.c| 2 ++
 arch/arm/mach-s3c24xx/mach-osiris-dvs.c  | 2 ++
 arch/blackfin/mach-common/dpmc.c | 2 ++
 arch/cris/arch-v32/kernel/time.c | 3 +++
 arch/powerpc/oprofile/op_model_cell.c| 3 +++
 arch/sparc/kernel/time_64.c  | 2 ++
 arch/x86/kernel/tsc.c| 2 ++
 arch/x86/kvm/x86.c   | 2 ++
 drivers/acpi/processor_perflib.c | 2 ++
 drivers/acpi/processor_thermal.c | 2 ++
 drivers/cpufreq/cpufreq.c| 1 +
 drivers/cpufreq/cpufreq_stats.c  | 2 ++
 drivers/cpufreq/cris-artpec3-cpufreq.c   | 3 +++
 drivers/cpufreq/cris-etraxfs-cpufreq.c   | 3 +++
 drivers/cpufreq/loongson2_cpufreq.c  | 2 ++
 drivers/cpufreq/ppc_cbe_cpufreq_pmi.c| 2 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 3 +++
 drivers/i2c/busses/i2c-davinci.c | 2 ++
 drivers/i2c/busses/i2c-s3c2410.c | 2 ++
 drivers/macintosh/windfarm_cpufreq_clamp.c   | 2 ++
 drivers/mmc/host/davinci_mmc.c   | 2 ++
 drivers/mmc/host/s3cmci.c| 2 ++
 drivers/mtd/nand/s3c2410.c   | 2 ++
 drivers/pcmcia/soc_common.c  | 2 ++
 drivers/staging/tidspbridge/rmgr/drv_interface.c | 2 ++
 drivers/thermal/cpu_cooling.c| 2 ++
 drivers/tty/serial/samsung.c | 2 ++
 drivers/tty/serial/sh-sci.c  | 2 ++
 drivers/video/fbdev/da8xx-fb.c   | 2 ++
 drivers/video/fbdev/nuc900fb.c   | 1 +
 drivers/video/fbdev/pxafb.c  | 2 ++
 drivers/video/fbdev/s3c2410fb.c  | 2 ++
 drivers/video/fbdev/sa1100fb.c   | 2 ++
 drivers/watchdog/s3c2410_wdt.c   | 2 ++
 36 files changed, 75 insertions(+)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada..57dff15 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -660,6 +660,8 @@ static int cpufreq_callback(struct notifier_block *nb,
 	struct cpufreq_freqs *freq = data;
 	int cpu = freq->cpu;
 
+	pr_info("%s\n", __func__);
+
 	if (freq->flags & CPUFREQ_CONST_LOOPS)
 		return NOTIFY_OK;
 
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index dfc3213..986df64 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -161,6 +161,8 @@ static int twd_cpufreq_transition(struct notifier_block *nb,
 {
 	struct cpufreq_freqs *freqs = data;
 
+	pr_info("%s\n", __func__);
+
 	/*
 	 * The twd clock events must be reprogrammed to account for the new
 	 * frequency.  The timer is local to a cpu, so cross-call to the
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 41f27f6..c047617 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -868,6 +868,8 @@ static int viper_cpufreq_notifier(struct notifier_block *nb,
 {
 	struct cpufreq_freqs *freq = data;
 
+	pr_info("%s\n", __func__);
+
 	/* TODO: Adjust timings??? */
 
 	switch (val) {
diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
index 33afb91..1caf694 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
@@ -61,6 +61,8 @@ static int osiris_dvs_notify(struct notifier_block *nb,
 	bool new_dvs = is_dvs(>new);
 	int ret = 0;
 
+	pr_info("%s\n", __func__);
+
 	if (!dvs_en)
 		return 0;
 
diff --git a/arch/blackfin/mach-common/dpmc.c b/arch/blackfin/mach-common/dpmc.c
index 724a8c5..1fd9a05 100644
--- a/arch/blackfin/mach-common/dpmc.c
+++ b/arch/blackfin/mach-common/dpmc.c
@@ -103,6 +103,8 @@ vreg_cpufreq_notifier(struct notifier_block *nb, unsigned long val, void *data)
 {
 	struct cpufreq_freqs *freq = data;
 
+	pr_info("%s\n", __func__);
+
 	if (freq->cpu != CPUFREQ_CPU)
 		return 0;
 
diff --git a/arch/cris/arch-v32/kernel/time.c b/arch/cris/arch-v32/kernel/time.c
index ee66866..b7cb448 100644
--- a/arch/cris/arch-v32/kernel/time.c
+++ b/arch/cris/arch-v32/kernel/time.c
@@ -303,6 +303,9 @@ cris_time_freq_notifier(struct notifier_block *nb, unsigned long val,
 			void *data)
 {
 	struct cpufreq_freqs *freqs = 

Re: [PATCH 3/4] perf tools: Fix probing the kernel API with cpu-wide events

[Adrian Hunter]

On 08/13/2014 08:37 AM, Namhyung Kim wrote:
> On Tue, 12 Aug 2014 18:04:30 +0300, Adrian Hunter wrote:
>> Fall back to probing with the current pid if cpu-wide
>> probing fails.  This primarily affects the setting of
>> comm_exec flag when the user is un-privileged and
>> /proc/sys/kernel/perf_event_paranoid > 0.  The change
>> to comm_exec can be observed by using -vv with
>> perf record and a kernel that supports comm_exec.
> 
> Maybe I'm missing something - why not just try process-wide probing in
> the first place?

Same reason as patch 4 i.e. to avoid a jump label change when doing
system-wide tracing.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] locking/rwsem: more aggressive use of optimistic spinning

[Dave Chinner]

On Mon, Aug 04, 2014 at 11:44:19AM -0400, Waiman Long wrote:
> On 08/04/2014 12:10 AM, Jason Low wrote:
> >On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote:
> >>The rwsem_can_spin_on_owner() function currently allows optimistic
> >>spinning only if the owner field is defined and is running. That is
> >>too conservative as it will cause some tasks to miss the opportunity
> >>of doing spinning in case the owner hasn't been able to set the owner
> >>field in time or the lock has just become available.
> >>
> >>This patch enables more aggressive use of optimistic spinning by
> >>assuming that the lock is spinnable unless proved otherwise.
> >>
> >>Signed-off-by: Waiman Long
> >>---
> >>  kernel/locking/rwsem-xadd.c |2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >>diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> >>index d058946..dce22b8 100644
> >>--- a/kernel/locking/rwsem-xadd.c
> >>+++ b/kernel/locking/rwsem-xadd.c
> >>@@ -285,7 +285,7 @@ static inline bool rwsem_try_write_lock_unqueued(struct 
> >>rw_semaphore *sem)
> >>  static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem)
> >>  {
> >>struct task_struct *owner;
> >>-   bool on_cpu = false;
> >>+   bool on_cpu = true; /* Assume spinnable unless proved not to be */
> >Hi,
> >
> >So "on_cpu = true" was recently converted to "on_cpu = false" in order
> >to address issues such as a 5x performance regression in the xfs_repair
> >workload that was caused by the original rwsem optimistic spinning code.
> >
> >However, patch 4 in this patchset does address some of the problems with
> >spinning when there are readers. CC'ing Dave Chinner, who did the
> >testing with the xfs_repair workload.
> >
> 
> This patch set enables proper reader spinning and so the problem
> that we see with xfs_repair workload should go away. I should have
> this patch after patch 4 to make it less confusing. BTW, patch 3 can
> significantly reduce spinlock contention in rwsem. So I believe the
> xfs_repair workload should run faster with this patch than both 3.15
> and 3.16.

I see lots of handwaving. I documented the test I ran when I
reported the problem so anyone with a 16p system and an SSD can
reproduce it. I don't have the bandwidth to keep track of the lunacy
of making locks scale these days - that's what you guys are doing.

I gave you a simple, reliable workload that is extremely sensitive
to rwsem perturbations, so you should be adding it to your
regression tests rather than leaving it for others to notice you
screwed up

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 1/2] perf top: Fix -z option behavior

[David Ahern]

On 8/12/14, 10:52 PM, Namhyung Kim wrote:


Are you sure?  I don't recall seeing any big change in this area so I
guess the problem existed since long time ago.  In fact I couldn't find
a logic to zero/clear out existing hist entries in a hists..


Just gave a quick try. v3.4 fails; v3.1 works.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups

[Amit Shah]

On (Tue) 12 Aug 2014 [14:41:51], Paul E. McKenney wrote:
> On Tue, Aug 12, 2014 at 02:39:36PM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 12, 2014 at 09:06:21AM -0700, Paul E. McKenney wrote:
> > > On Tue, Aug 12, 2014 at 11:03:21AM +0530, Amit Shah wrote:
> > 
> > [ . . . ]
> > 
> > > > I know of only virtio-console doing this (via userspace only,
> > > > though).
> > > 
> > > As in userspace within the guest?  That would not work.  The userspace
> > > that the qemu is running in might.  There is a way to extract ftrace info
> > > from crash dumps, so one approach would be "sendkey alt-sysrq-c", then
> > > pull the buffer from the resulting dump.  For all I know, there might also
> > > be some script that uses the qemu "x" command to get at the ftrace buffer.
> > > 
> > > Again, I cannot reproduce this, and I have been through the code several
> > > times over the past few days, and am not seeing it.  I could start
> > > sending you random diagnostic patches, but it would be much better if
> > > we could get the trace data from the failure.

I think the only recourse I now have is to dump the guest state from
qemu, and attempt to find the ftrace buffers by poking pages and
finding some ftrace-like struct... and then dumping the buffers.

> > Hearing no objections, random patch #1.  The compiler could in theory
> > cause trouble without this patch, so there is some possibility that
> > it is a fix.
> 
> #2...  This would have been a problem without the earlier patch, but
> who knows?  (#1 moved from theoretically possible but not on x86 to
> maybe on x86 given a sufficiently malevolent compiler with the
> patch that you located with bisection.)

I tried all 3 patches individually, and all 3 together, no success.

My gcc is gcc-4.8.3-1.fc20.x86_64.  I'm using a fairly uptodate Fedora
20 system on my laptop for these tests.

Curiously, patches 1 and 3 applied fine, but this one had a conflict.

> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 1dc72f523c4a..1da605740e8d 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2137,6 +2137,17 @@ static bool __call_rcu_nocb(struct rcu_data *rdp, 
> struct rcu_head *rhp,

I have this hunk at line 2161, and...

>   trace_rcu_callback(rdp->rsp->name, rhp,
>  -atomic_long_read(>nocb_q_count_lazy),
>  -atomic_long_read(>nocb_q_count));
> +
> + /*
> +  * If called from an extended quiescent state with interrupts
> +  * disabled, invoke the RCU core in order to allow the idle-entry
> +  * deferred-wakeup check to function.
> +  */
> + if (irqs_disabled_flags(flags) &&
> + !rcu_is_watching() &&
> + cpu_online(smp_processor_id()))
> + invoke_rcu_core();
> +
>   return true;

I have return 1; here.

I'm on linux.git, c8d6637d0497d62093dbba0694c7b3a80b79bfe1.


Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] staging: vt6656: fix incorrect indentation

[Ragnar B. Johannsson]

Use tabs, not spaces.

Signed-off-by: Ragnar B. Johannsson 
---
 drivers/staging/vt6656/rxtx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 2d1ef88..08ce18d 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -573,7 +573,7 @@ static u16 vnt_fill_cts_head(struct vnt_usb_send_context 
*tx_context,
memcpy(buf->data.ra, priv->current_net_addr, ETH_ALEN);
 
return vnt_rxtx_datahead_g(tx_context, >data_head);
-}
+   }
 
return 0;
 }
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] staging: vt6656: remove unnecessary braces

[Ragnar B. Johannsson]

Removes unnecessary braces to comply with coding style.

Signed-off-by: Ragnar B. Johannsson 
---
 drivers/staging/vt6656/usbpipe.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index cba6532..88bf518 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -131,11 +131,10 @@ static void vnt_start_interrupt_urb_complete(struct urb 
*urb)
}
 
status = usb_submit_urb(priv->interrupt_urb, GFP_ATOMIC);
-   if (status) {
+   if (status)
dev_dbg(>usb->dev, "Submit int URB failed %d\n", status);
-   } else {
+   else
priv->int_buf.in_use = true;
-   }
 }
 
 int vnt_start_interrupt_urb(struct vnt_private *priv)
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf report: Set proper sort__mode for the branch option

[Namhyung Kim]

Hi Naohiro,

(CC'ing Stephane)

> When you specify "--branch-stack"("-b" for short) or
> "--no-branch-stack", "branch_mode" variable is set to 1 or 0
> respectively. However, the code is just checking if the variable is -1
> or not, ignoring "branch_mode == 1" case. Thus "perf report -b" dose not
> show its result with the branch sorted mode. This patch fix the problem.
>
> Signed-off-by: Naohiro Aota 

Acked-by: Namhyung Kim 

Thanks for fixing this!
Namhyung


> ---
>  tools/perf/builtin-report.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 21d830b..94dcf2d 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -719,7 +719,7 @@ repeat:
>   has_br_stack = perf_header__has_feat(>header,
>HEADER_BRANCH_STACK);
>  
> - if (branch_mode == -1 && has_br_stack) {
> + if ((branch_mode == -1 && has_br_stack) || branch_mode == 1) {
>   sort__mode = SORT_MODE__BRANCH;
>   symbol_conf.cumulate_callchain = false;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] oops in cpufreq driver with AMD Kaveri CPU

[Oleksandr Natalenko]

On Wednesday 13 August 2014 10:12:06 Viresh Kumar wrote: 
> Also will it be possible for you to find the last working kernel after
> which this
> happened?

I'll try to reproduce the issue with older kernels, but that could be 
problematic and may take some time. So far, I can say that 3.13 and 3.15 are 
also affected (haven't tried 3.14, though).

-- 
Oleksandr post-factum Natalenko, MSc
pf-kernel community
https://natalenko.name/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] staging: vt6656: cleanup

[Ragnar B. Johannsson]

This patchset fixes a few small coding style problems as reported by checkpatch.

Ragnar B. Johannsson (3):
  staging: vt6656: remove unnecessary braces
  staging: vt6656: fix incorrect indentation
  staging: vt6656: add blank line after declaration

 drivers/staging/vt6656/rxtx.c| 3 ++-
 drivers/staging/vt6656/usbpipe.c | 5 ++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] perf tools: Fix probing the kernel API with cpu-wide events

[Namhyung Kim]

On Tue, 12 Aug 2014 18:04:30 +0300, Adrian Hunter wrote:
> Fall back to probing with the current pid if cpu-wide
> probing fails.  This primarily affects the setting of
> comm_exec flag when the user is un-privileged and
> /proc/sys/kernel/perf_event_paranoid > 0.  The change
> to comm_exec can be observed by using -vv with
> perf record and a kernel that supports comm_exec.

Maybe I'm missing something - why not just try process-wide probing in
the first place?

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] staging: vt6656: add blank line after declaration

[Ragnar B. Johannsson]

Adds a blank line after declaration to comply with coding style.

Signed-off-by: Ragnar B. Johannsson 
---
 drivers/staging/vt6656/rxtx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 08ce18d..852ebe8 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -1036,6 +1036,7 @@ static int vnt_beacon_xmit(struct vnt_private *priv,
info = IEEE80211_SKB_CB(skb);
if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ) {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)mgmt_hdr;
+
hdr->duration_id = 0;
hdr->seq_ctrl = cpu_to_le16(priv->seq_counter << 4);
}
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] perf tools: Fix one of the probe events to exclude kernel

[Namhyung Kim]

On Tue, 12 Aug 2014 18:04:29 +0300, Adrian Hunter wrote:
> When probing the kernel API the kernel should be excluded
> otherwise the probe will fail for users with insufficient
> privilege to profile the kernel.
>
> Signed-off-by: Adrian Hunter 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/record.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> index 787b882..68ad2d0 100644
> --- a/tools/perf/util/record.c
> +++ b/tools/perf/util/record.c
> @@ -47,7 +47,7 @@ out_delete:
>  
>  static bool perf_probe_api(setup_probe_fn_t fn)
>  {
> - const char *try[] = {"cycles:u", "instructions:u", "cpu-clock", NULL};
> + const char *try[] = {"cycles:u", "instructions:u", "cpu-clock:u", NULL};
>   struct cpu_map *cpus;
>   int cpu, ret, i = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] perf tools: Fix CLOEXEC probe for perf_event_paranoid == 2

[Namhyung Kim]

Hi Adrian,

On Tue, 12 Aug 2014 18:04:28 +0300, Adrian Hunter wrote:
> With /proc/sys/kernel/perf_event_paranoid set to 2, the
> probe of PERF_FLAG_FD_CLOEXEC would fail.  Fix by excluding
> kernel profiling from the probe event.
>
> Signed-off-by: Adrian Hunter 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/cloexec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
> index 5073c01..47c 100644
> --- a/tools/perf/util/cloexec.c
> +++ b/tools/perf/util/cloexec.c
> @@ -11,6 +11,7 @@ static int perf_flag_probe(void)
>   struct perf_event_attr attr = {
>   .type = PERF_TYPE_SOFTWARE,
>   .config = PERF_COUNT_SW_CPU_CLOCK,
> + .exclude_kernel = 1,
>   };
>   int fd;
>   int err;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y

[Dexuan Cui]

> -Original Message-
> From: KY Srinivasan
> > The Arch users can simply select to build i8042 into the kernel as a
> > workaround.
> >
> > The proper solution is to allow loading libps2 module even if i8042 did not
> find
> > its device. I wish I could simply drop this i8042_lock_chip and stuff, but
> > unfortunately i8042 ports are not truly independent. We need to figure a
> > way for libps2 to engage locking in i8042 if the driver is loaded, otherwise
> just
> > ignore it.
> 
> When I first wrote this driver, we took the decision not to replicate all the
> code in the at keyboard driver and to
> make this  a serio based driver. I like the proposal made by Dmitry here.
> 
> K. Y

Thanks for explaining the background, KY!
I like Dmitry's proposal too.

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arch: Kconfig: Let all little endian architectures define CPU_LITTLE_ENDIAN explicitly

[Chen Gang]

On 8/13/14 13:08, Sam Ravnborg wrote:
> On Wed, Aug 13, 2014 at 06:48:35AM +0800, Chen Gang wrote:
>> x86 and ia64 are always little endian. And another architectures may be
>> little endian: mips, sh, powerpc, and m32r (may mark CPU_LITTLE_ENDIAN
>> explicitly); also arm(64) and c6x (which may be !CPU_BIG_ENDIAN).
>>
>> Some drivers (e.g. some of "drivers/isdn/hisax") may only support little
>> endian (CPU_LITTLE_ENDIAN), and some drivers may only support big endian
>> (!CPU_LITTLE_ENDIAN).
>>
>> So export all little endian architectures within kernel wide, so can let
>> Kconfig easier for the modules which only support little endian or only
>> for big endian (assume !CPU_LITTLE_ENDIAN is same as CPU_BIG_ENDIAN).
> We need to cover three cases here:
> - An arch supports only little endian
> - An arch supports only big endian
> - An arch may be both little and big endian
> 

Yeah, we need.

> The solution you suggest assumes that an arch is either little or big endian.
> But we cannot ignore the hybriads that can do both.
> 

For the architectures which can do both, for me, they are: sh, powerpc,
m32r, and mips (may mark CPU_LITTLE_ENDIAN), also are: arm/arm64, and
c6x (may mark !CPU_BIG_ENDIAN).

For the architectures which only support little endian: x86, and ia64.

The left, I assumes they are big endian (no any 'ENDIAN' can be found
in their Kconfig files). In my memory, except related with Intel, all
are (or support) big endian.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y

[Dexuan Cui]

> -Original Message-
> From: Dmitry Torokhov
> Sent: Wednesday, August 13, 2014 1:55 AM
> > > > To decouple the dependency between the hyperv-keyboard and i8042
> > > > modules, I suppose we probably have to re-implement hyperv-
> keyboard by
> > > > using input_allocate_device(), input_register_device(), and using
> > > > input_report_key() to pass the key strokes to the high level.
> > >
> > > Yes, that would be the best thing to do,
> 
> Why? The backend still delivers AT keyboard data, so why does it make
> sense to write a new driver instead of making sure you can load
> atkbd/libps2 even without i8042 loaded?

Hi Dmitry,
Thanks for pointing this out!
I didn't realize input_report_key() can't accept AT keyboard scan codes.

> > The issue is: the latest Arch Linux release doesn't have a working (virtual)
> > keyboard when it runs as Generation 2 hyper-v guest -- when it runs as
> > a "traditional" Generation 1 hyper-v guest, everything works fine.
> > I hope this patch can temporarily help Arch users if they find the issue
> > and if they can rebuild the kernel.
> 
> The Arch users can simply select to build i8042 into the kernel as a
> workaround.
I agree.

> The proper solution is to allow loading libps2 module even if i8042 did
> not find its device. I wish I could simply drop this i8042_lock_chip and
> stuff, but unfortunately i8042 ports are not truly independent. We need
> to figure a way for libps2 to engage locking in i8042 if the driver is
> loaded, otherwise just ignore it.
> 
> Dmitry
Yeah, this seems the right solution.

How about this:
in libps2.c let's add  and export a function pointer
i8042_lock_chip_if_port_owner: it is used to replace the current 
if (i8042_check_port_owner(ps2dev->serio))
i8042_lock_chip();
The function pointer has a default value NULL, and in i8042.c: i8042_init()
we set the function pointer if an i8042 device is found?

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] [BUGFIX] perf probe: Fix --list option to show events only with uprobe events

[Namhyung Kim]

Hi Masami,

On Wed, 13 Aug 2014 00:50:55 +, Masami Hiramatsu wrote:
> + if (kp_fd < 0 && up_fd < 0) {
> + /* Both kprobes and uprobes are disabled, warn it. */
> + if (kp_fd == -ENOTSUP && up_fd == -ENOTSUP)
> + pr_warning("Debugfs is not mounted.\n");
> + else if (kp_fd == -ENOENT && up_fd == -ENOENT)
> + pr_warning("Please rebuild kernel with "
> +"CONFIG_KPROBE_EVENTS or/and "
> +"CONFIG_UPROBE_EVENTS.\n");
> + else
> + pr_warning("Failed to open kprobe events: %s.\n" \
> +"Failed to open uprobe events: %s.\n",
> +strerror(-kp_fd), strerror(-up_fd));

It seems the second strerror() might overwrite the message of the
first.  You'd better using strerror_r() IMHO.

Thanks,
Namhyung


> + ret = kp_fd;
> + goto out;
>   }
>  
> + if (up_fd >= 0) {
> + ret = __show_perf_probe_events(up_fd, false);
> + close(up_fd);
> + }
> +out:
>   exit_symbol_maps();
>   return ret;
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Rename ordered_samples bool to ordered_events

[tip-bot for Jiri Olsa]

Commit-ID:  0a8cb85c200c4082ed7e57efd90dd9d18c8d40b6
Gitweb: http://git.kernel.org/tip/0a8cb85c200c4082ed7e57efd90dd9d18c8d40b6
Author: Jiri Olsa 
AuthorDate: Sun, 6 Jul 2014 14:18:21 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:54 -0300

perf tools: Rename ordered_samples bool to ordered_events

The time ordering is generic for all kinds of events, so using generic
name 'ordered_events' for ordered_samples bool in perf_tool struct.

No functional change was intended.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-07mrqzcuhsks9wfmxrzsv...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-annotate.c  |  2 +-
 tools/perf/builtin-diff.c  |  2 +-
 tools/perf/builtin-inject.c|  2 +-
 tools/perf/builtin-kmem.c  |  2 +-
 tools/perf/builtin-kvm.c   |  4 ++--
 tools/perf/builtin-lock.c  |  2 +-
 tools/perf/builtin-mem.c   |  2 +-
 tools/perf/builtin-report.c|  2 +-
 tools/perf/builtin-sched.c |  2 +-
 tools/perf/builtin-script.c|  2 +-
 tools/perf/builtin-timechart.c |  2 +-
 tools/perf/builtin-trace.c |  2 +-
 tools/perf/util/session.c  | 10 +-
 tools/perf/util/tool.h |  2 +-
 14 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 1ec429f..952b5ec 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -297,7 +297,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
.comm   = perf_event__process_comm,
.exit   = perf_event__process_exit,
.fork   = perf_event__process_fork,
-   .ordered_samples = true,
+   .ordered_events = true,
.ordering_requires_timestamps = true,
},
};
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9a5a035..c10cc44 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -360,7 +360,7 @@ static struct perf_tool tool = {
.exit   = perf_event__process_exit,
.fork   = perf_event__process_fork,
.lost   = perf_event__process_lost,
-   .ordered_samples = true,
+   .ordered_events = true,
.ordering_requires_timestamps = true,
 };
 
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 9a02807..ee875cc 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -366,7 +366,7 @@ static int __cmd_inject(struct perf_inject *inject)
} else if (inject->sched_stat) {
struct perf_evsel *evsel;
 
-   inject->tool.ordered_samples = true;
+   inject->tool.ordered_events = true;
 
evlist__for_each(session->evlist, evsel) {
const char *name = perf_evsel__name(evsel);
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index bef3376..b572111 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -256,7 +256,7 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
 static struct perf_tool perf_kmem = {
.sample  = process_sample_event,
.comm= perf_event__process_comm,
-   .ordered_samples = true,
+   .ordered_events  = true,
 };
 
 static double fragmentation(unsigned long n_req, unsigned long n_alloc)
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index fe92dfd..a05f435 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1058,7 +1058,7 @@ static int read_events(struct perf_kvm_stat *kvm)
struct perf_tool eops = {
.sample = process_sample_event,
.comm   = perf_event__process_comm,
-   .ordered_samples= true,
+   .ordered_events = true,
};
struct perf_data_file file = {
.path = kvm->file_name,
@@ -1311,7 +1311,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
kvm->tool.exit   = perf_event__process_exit;
kvm->tool.fork   = perf_event__process_fork;
kvm->tool.lost   = process_lost_event;
-   kvm->tool.ordered_samples = true;
+   kvm->tool.ordered_events = true;
perf_tool__fill_defaults(>tool);
 
/* set defaults */
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 6148afc..c8122d3 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -852,7 +852,7 @@ static int __cmd_report(bool display_info)
struct perf_tool eops = {
.sample  = process_sample_event,
.comm= 

[tip:perf/core] perf tools: Default to python version 2

[tip-bot for Thomas Ilsche]

Commit-ID:  d6a947fb6cdff3a19db93895c746f70b5903a965
Gitweb: http://git.kernel.org/tip/d6a947fb6cdff3a19db93895c746f70b5903a965
Author: Thomas Ilsche 
AuthorDate: Mon, 4 Aug 2014 15:03:15 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:08 -0300

perf tools: Default to python version 2

According to PEP 394 recommendation [1], it's more portable to use
python2 rather than plain python to refer python binary version 2.

Since there're distros using python3 by default like Arch, and we don't
support python3 (yet), it'd be better using python2 explicitly.

But older versions (prior to 2.7) seem not to provide python2 but just
python.  Given that it's only old version, try python2 first and then
fallback to python.  It'll ensure that it always points to python 2.x.

I tested (compiles and perf script runs) with the combinations:

1) python  -> python2.x, python-config  -> python2.x-config
   python2 N/A,  python2-config N/A

2) python  -> python3.x, python-config  -> python3.x-config
   python2 -> python2.x, python2-config -> python2.x-config

3) python  -> python2.x, python-config  -> python2.x-config
   python2 -> python2.x, python2-config -> python2.x-config

4) python  -> python2.x, python-config  -> python2.x-config
   python2 -> python2.x, python2-config N/A

Based on / replaces the patch 2/2 by Namhyung Kim.

[1] https://www.python.org/dev/peps/pep-0394

Based-on-patch-by: Namhyung Kim 
Signed-off-by: Thomas Ilsche 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/53df8493.6070...@tu-dresden.de
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/config/Makefile | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index e05d8f9..75d4c23 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -121,10 +121,16 @@ ifdef PARSER_DEBUG
 endif
 
 ifndef NO_LIBPYTHON
-  override PYTHON := \
-$(call get-executable-or-default,PYTHON,python)
+  # Try different combinations to accommodate systems that only have
+  # python[2][-config] in weird combinations but always preferring
+  # python2 and python2-config as per pep-0394. If we catch a
+  # python[-config] in version 3, the version check will kill it.
+  PYTHON2 := $(if $(call get-executable,python2),python2,python)
+  override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))
+  PYTHON2_CONFIG := \
+$(if $(call 
get-executable,$(PYTHON)-config),$(PYTHON)-config,python-config)
   override PYTHON_CONFIG := \
-$(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON)-config)
+$(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON2_CONFIG))
 
   PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Fix PERF_FLAG_FD_CLOEXEC flag probing event type open counters due to EBUSY error

[tip-bot for Jiri Olsa]

Commit-ID:  038fa0b9739d7f375f3f61a2ce4f78ad44329f66
Gitweb: http://git.kernel.org/tip/038fa0b9739d7f375f3f61a2ce4f78ad44329f66
Author: Jiri Olsa 
AuthorDate: Sun, 3 Aug 2014 14:10:36 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:08 -0300

perf tools: Fix PERF_FLAG_FD_CLOEXEC flag probing event type open counters due 
to EBUSY error

We were using PERF_COUNT_SW_CPU_CLOCK as an probing event type.  Using
expected PERF_TYPE_SOFTWARE type instead.

Signed-off-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: William Cohen 
Cc: Yann Droneaud 
Link: http://lkml.kernel.org/r/20140803121036.ga1...@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cloexec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index dede0c3..5073c01 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -9,7 +9,7 @@ static int perf_flag_probe(void)
 {
/* use 'safest' configuration as used in perf_evsel__fallback() */
struct perf_event_attr attr = {
-   .type = PERF_COUNT_SW_CPU_CLOCK,
+   .type = PERF_TYPE_SOFTWARE,
.config = PERF_COUNT_SW_CPU_CLOCK,
};
int fd;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf report: Honor column width setting

[tip-bot for Namhyung Kim]

Commit-ID:  5b5916696051b88e63f3726cc3db44bf9561bad9
Gitweb: http://git.kernel.org/tip/5b5916696051b88e63f3726cc3db44bf9561bad9
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:38 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:06 -0300

perf report: Honor column width setting

Set column width and do not change it if user gives -w/--column-widths
option.  It'll truncate longer symbols than the width if exists.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-5-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c | 18 +
 tools/perf/ui/gtk/hists.c  | 10 ++---
 tools/perf/ui/hist.c   | 84 +-
 tools/perf/ui/stdio/hist.c |  4 +-
 tools/perf/util/hist.h | 14 ---
 tools/perf/util/sort.c | 49 +++-
 6 files changed, 116 insertions(+), 63 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index c1d8d39..e07d4e8 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -678,12 +678,12 @@ static u64 __hpp_get_##_field(struct hist_entry *he)  
\
 }  \
\
 static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt,  \
struct perf_hpp *hpp,   \
struct hist_entry *he)  \
 {  \
-   return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6,   \
- __hpp__slsmg_color_printf, true); \
+   return hpp__fmt(fmt, hpp, he, __hpp_get_##_field, " %*.2f%%",   \
+   __hpp__slsmg_color_printf, true);   \
 }
 
 #define __HPP_COLOR_ACC_PERCENT_FN(_type, _field)  \
@@ -693,19 +693,20 @@ static u64 __hpp_get_acc_##_field(struct hist_entry *he)  
\
 }  \
\
 static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt,  \
struct perf_hpp *hpp,   \
struct hist_entry *he)  \
 {  \
if (!symbol_conf.cumulate_callchain) {  \
+   int len = fmt->user_len ?: fmt->len;\
int ret = scnprintf(hpp->buf, hpp->size,\
-   "%*s", 8, "N/A");   \
+   "%*s", len, "N/A"); \
slsmg_printf("%s", hpp->buf);   \
\
return ret; \
}   \
-   return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%",  \
- 6, __hpp__slsmg_color_printf, true);  \
+   return hpp__fmt(fmt, hpp, he, __hpp_get_acc_##_field,   \
+   " %*.2f%%", __hpp__slsmg_color_printf, true);   \
 }
 
 __HPP_COLOR_PERCENT_FN(overhead, period)
@@ -1549,6 +1550,9 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
 
memset(options, 0, sizeof(options));
 
+   if (symbol_conf.col_width_list_str)
+   perf_hpp__set_user_width(symbol_conf.col_width_list_str);
+
while (1) {
const struct thread *thread = NULL;
const struct dso *dso = NULL;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 91f6cd7..897b2e1 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -41,12 +41,12 @@ static u64 he_get_##_field(struct hist_entry *he)   
\
return he->stat._field; 
\
 }  
\

\
-static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt *fmt 
__maybe_unused,  

[tip:perf/core] perf tools: Fix column alignment when headers aren't shown on TUI

[tip-bot for Namhyung Kim]

Commit-ID:  59dc9f2534569d11a55c8b5dbe93c36f2b2fa506
Gitweb: http://git.kernel.org/tip/59dc9f2534569d11a55c8b5dbe93c36f2b2fa506
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:41 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:07 -0300

perf tools: Fix column alignment when headers aren't shown on TUI

If user sets ui.show-headers config option to false, it didn't calculate
default column width so it broke the alignment.  This is because it does
the calculation just before showing headers.

Move it to the beginning of the hist browser so that it can be called
regardless of the config option.

Reported-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-8-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index e07d4e8..045c1e1 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -850,9 +850,6 @@ static int hists__scnprintf_headers(char *buf, size_t size, 
struct hists *hists)
if (perf_hpp__should_skip(fmt))
continue;
 
-   /* We need to ensure length of the columns header. */
-   perf_hpp__reset_width(fmt, hists);
-
ret = fmt->header(fmt, _hpp, hists_to_evsel(hists));
if (advance_hpp_check(_hpp, ret))
break;
@@ -1501,6 +1498,7 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
char buf[64];
char script_opt[64];
int delay_secs = hbt ? hbt->refresh : 0;
+   struct perf_hpp_fmt *fmt;
 
 #define HIST_BROWSER_HELP_COMMON   \
"h/?/F1Show this window\n"  \
@@ -1550,6 +1548,9 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
 
memset(options, 0, sizeof(options));
 
+   perf_hpp__for_each_format(fmt)
+   perf_hpp__reset_width(fmt, hists);
+
if (symbol_conf.col_width_list_str)
perf_hpp__set_user_width(symbol_conf.col_width_list_str);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Make __hpp__fmt() receive an additional len argument

[tip-bot for Namhyung Kim]

Commit-ID:  d675107ce6fa988102851e0b0ef06e46c8aa7ac6
Gitweb: http://git.kernel.org/tip/d675107ce6fa988102851e0b0ef06e46c8aa7ac6
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:36 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:05 -0300

perf tools: Make __hpp__fmt() receive an additional len argument

So that it can properly handle alignment requirements later.  To do
that, add percent_color_len_snprintf() fucntion to help coloring of
overhead columns.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c | 14 --
 tools/perf/ui/gtk/hists.c  |  8 +---
 tools/perf/ui/hist.c   | 43 +-
 tools/perf/util/color.c| 16 
 tools/perf/util/color.h|  1 +
 tools/perf/util/hist.h |  4 ++--
 6 files changed, 54 insertions(+), 32 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a94b11fc..02507ba 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -653,17 +653,18 @@ struct hpp_arg {
 static int __hpp__slsmg_color_printf(struct perf_hpp *hpp, const char *fmt, 
...)
 {
struct hpp_arg *arg = hpp->ptr;
-   int ret;
+   int ret, len;
va_list args;
double percent;
 
va_start(args, fmt);
+   len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
 
ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
 
-   ret = scnprintf(hpp->buf, hpp->size, fmt, percent);
+   ret = scnprintf(hpp->buf, hpp->size, fmt, len, percent);
slsmg_printf("%s", hpp->buf);
 
advance_hpp(hpp, ret);
@@ -681,7 +682,7 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt 
__maybe_unused,\
struct perf_hpp *hpp,   \
struct hist_entry *he)  \
 {  \
-   return __hpp__fmt(hpp, he, __hpp_get_##_field, " %6.2f%%",  \
+   return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6,   \
  __hpp__slsmg_color_printf, true); \
 }
 
@@ -697,13 +698,14 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt 
__maybe_unused,\
struct hist_entry *he)  \
 {  \
if (!symbol_conf.cumulate_callchain) {  \
-   int ret = scnprintf(hpp->buf, hpp->size, "%8s", "N/A"); \
+   int ret = scnprintf(hpp->buf, hpp->size,\
+   "%*s", 8, "N/A");   \
slsmg_printf("%s", hpp->buf);   \
\
return ret; \
}   \
-   return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %6.2f%%",  \
- __hpp__slsmg_color_printf, true); \
+   return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%",  \
+ 6, __hpp__slsmg_color_printf, true);  \
 }
 
 __HPP_COLOR_PERCENT_FN(overhead, period)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 6ca60e4..91f6cd7 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -11,6 +11,7 @@
 static int __percent_color_snprintf(struct perf_hpp *hpp, const char *fmt, ...)
 {
int ret = 0;
+   int len;
va_list args;
double percent;
const char *markup;
@@ -18,6 +19,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp, 
const char *fmt, ...)
size_t size = hpp->size;
 
va_start(args, fmt);
+   len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
 
@@ -25,7 +27,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp, 
const char *fmt, ...)
if (markup)
ret += scnprintf(buf, size, markup);
 
-   ret += scnprintf(buf + ret, size - ret, fmt, percent);
+   ret += scnprintf(buf + ret, size - ret, fmt, len, percent);
 
if (markup)
ret += scnprintf(buf + ret, size - ret, "");
@@ -43,7 +45,7 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt 
*fmt __maybe_unused,
   struct perf_hpp *hpp,
\
   struct hist_entry *he)   
\
 {  

[tip:perf/core] perf top: Add -w option for setting column width

[tip-bot for Namhyung Kim]

Commit-ID:  cf59002fdebc9c00ee29233e65bc39dd69e0eaf6
Gitweb: http://git.kernel.org/tip/cf59002fdebc9c00ee29233e65bc39dd69e0eaf6
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:39 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:06 -0300

perf top: Add -w option for setting column width

Add -w/--column-widths option like perf report does so that users are
able to see symbols even with some very long C++ library/functions.

It can be a list separated by comma for each column.

  $ perf top -w 0,20,30

The value of 0 means there's no limit.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-report.txt | 2 +-
 tools/perf/Documentation/perf-top.txt| 6 ++
 tools/perf/builtin-top.c | 3 +++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index d2b59af..d561e02 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -147,7 +147,7 @@ OPTIONS
 -w::
 --column-widths=::
Force each column width to the provided list, for large terminal
-   readability.
+   readability.  0 means no limit (default behavior).
 
 -t::
 --field-separator=::
diff --git a/tools/perf/Documentation/perf-top.txt 
b/tools/perf/Documentation/perf-top.txt
index 180ae02..28fdee3 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -193,6 +193,12 @@ Default is to monitor all CPUS.
sum of shown entries will be always 100%. "absolute" means it retains
the original value before and after the filter is applied.
 
+-w::
+--column-widths=::
+   Force each column width to the provided list, for large terminal
+   readability.  0 means no limit (default behavior).
+
+
 INTERACTIVE PROMPTING KEYS
 --
 
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 377971d..bde216b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1131,6 +1131,9 @@ int cmd_top(int argc, const char **argv, const char 
*prefix __maybe_unused)
 "Don't show entries under that percent", 
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
 "How to display percentage of filtered entries", 
parse_filter_percentage),
+   OPT_STRING('w', "column-widths", _conf.col_width_list_str,
+  "width[,width...]",
+  "don't try to adjust column width, use these fixed values"),
OPT_END()
};
const char * const top_usage[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Add name field into perf_hpp_fmt

[tip-bot for Namhyung Kim]

Commit-ID:  1ecd44533a8a724f64d4305abb69836ca73c7390
Gitweb: http://git.kernel.org/tip/1ecd44533a8a724f64d4305abb69836ca73c7390
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:40 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:07 -0300

perf tools: Add name field into perf_hpp_fmt

It makes the code a bit simpler and easier to debug IMHO.

I guess it can also remove similar code in perf diff, but let's keep
it for a future work. :)

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-7-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/gtk/hists.c |   4 +-
 tools/perf/ui/hist.c  | 136 +-
 tools/perf/util/hist.h|   1 +
 tools/perf/util/sort.c|   6 +-
 4 files changed, 66 insertions(+), 81 deletions(-)

diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 897b2e1..f3fa425 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -207,10 +207,8 @@ static void perf_gtk__show_hists(GtkWidget *window, struct 
hists *hists,
if (perf_hpp__is_sort_entry(fmt))
sym_col = col_idx;
 
-   fmt->header(fmt, , hists_to_evsel(hists));
-
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
-   -1, ltrim(s),
+   -1, fmt->name,
renderer, "markup",
col_idx++, NULL);
}
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index b2d60a9..b5fa701 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -209,29 +209,26 @@ static int __hpp__sort_acc(struct hist_entry *a, struct 
hist_entry *b,
return ret;
 }
 
-#define __HPP_WIDTH_FN(_type, _str)\
-static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
- struct perf_hpp *hpp __maybe_unused,  \
- struct perf_evsel *evsel) \
-{  \
-   int len = fmt->user_len ?: fmt->len;\
-   \
-   if (symbol_conf.event_group)\
-   len = max(len, evsel->nr_members * fmt->len);   \
-   \
-   if (len < (int)strlen(_str))\
-   len = strlen(_str); \
-   \
-   return len; \
-}
-
-#define __HPP_HEADER_FN(_type, _str)   \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt,   \
-  struct perf_hpp *hpp,\
-  struct perf_evsel *evsel)\
-{  \
-   int len = hpp__width_##_type(fmt, hpp, evsel);  \
-   return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+static int hpp__width_fn(struct perf_hpp_fmt *fmt,
+struct perf_hpp *hpp __maybe_unused,
+struct perf_evsel *evsel)
+{
+   int len = fmt->user_len ?: fmt->len;
+
+   if (symbol_conf.event_group)
+   len = max(len, evsel->nr_members * fmt->len);
+
+   if (len < (int)strlen(fmt->name))
+   len = strlen(fmt->name);
+
+   return len;
+}
+
+static int hpp__header_fn(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+ struct perf_evsel *evsel)
+{
+   int len = hpp__width_fn(fmt, hpp, evsel);
+   return scnprintf(hpp->buf, hpp->size, "%*s", len, fmt->name);
 }
 
 static int hpp_color_scnprintf(struct perf_hpp *hpp, const char *fmt, ...)
@@ -337,38 +334,29 @@ static int64_t hpp__sort_##_type(struct hist_entry *a, 
struct hist_entry *b)  \
 }
 
 
-#define HPP_PERCENT_FNS(_type, _str, _field)   \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str)   \
+#define HPP_PERCENT_FNS(_type, _field) \
 __HPP_COLOR_PERCENT_FN(_type, _field)  \
 __HPP_ENTRY_PERCENT_FN(_type, _field)  \
 __HPP_SORT_FN(_type, _field)
 
-#define HPP_PERCENT_ACC_FNS(_type, 

[tip:perf/core] perf tools: Left-align output contents

[tip-bot for Namhyung Kim]

Commit-ID:  8246de88e95ddef7508f5601d7af85c3ab9e476b
Gitweb: http://git.kernel.org/tip/8246de88e95ddef7508f5601d7af85c3ab9e476b
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:35 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:04 -0300

perf tools: Left-align output contents

Now perf left-aligns column headers but the contents does not.  It
should have same alignment.  This requires a change in pid sort key - it
consists of two part (pid and comm).  As length of comm can be vary it'd
be better to change the order of them.

Thanks to Jiri Olsa for pointing this out.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/sort.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 14e5a03..eda9ee8 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -70,12 +70,12 @@ static int hist_entry__thread_snprintf(struct hist_entry 
*he, char *bf,
   size_t size, unsigned int width)
 {
const char *comm = thread__comm_str(he->thread);
-   return repsep_snprintf(bf, size, "%*s:%5d", width - 6,
-  comm ?: "", he->thread->tid);
+   return repsep_snprintf(bf, size, "%5d:%-*s", he->thread->tid,
+  width - 6, comm ?: "");
 }
 
 struct sort_entry sort_thread = {
-   .se_header  = "Command:  Pid",
+   .se_header  = "  Pid:Command",
.se_cmp = sort__thread_cmp,
.se_snprintf= hist_entry__thread_snprintf,
.se_width_idx   = HISTC_THREAD,
@@ -106,7 +106,7 @@ sort__comm_sort(struct hist_entry *left, struct hist_entry 
*right)
 static int hist_entry__comm_snprintf(struct hist_entry *he, char *bf,
 size_t size, unsigned int width)
 {
-   return repsep_snprintf(bf, size, "%*s", width, comm__str(he->comm));
+   return repsep_snprintf(bf, size, "%-*s", width, comm__str(he->comm));
 }
 
 struct sort_entry sort_comm = {
@@ -305,7 +305,7 @@ static int hist_entry__srcline_snprintf(struct hist_entry 
*he, char *bf,
size_t size,
unsigned int width __maybe_unused)
 {
-   return repsep_snprintf(bf, size, "%s", he->srcline);
+   return repsep_snprintf(bf, size, "%-s", he->srcline);
 }
 
 struct sort_entry sort_srcline = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Show better error message in case we fail to open counters due to EBUSY error

[tip-bot for Jiri Olsa]

Commit-ID:  63914aca8f7e7a75d0ee027af7b1755c69cc1e2c
Gitweb: http://git.kernel.org/tip/63914aca8f7e7a75d0ee027af7b1755c69cc1e2c
Author: Jiri Olsa 
AuthorDate: Fri, 1 Aug 2014 17:46:54 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:02 -0300

perf tools: Show better error message in case we fail to open counters due to 
EBUSY error

Showing better error message in case we fail to open counters due to the
EBUSY error. If we detect oprofile daemon process running, we now
display following message for EBUSY error:

  $ perf record ls
  Error:
  The PMU counters are busy/taken by another profiler.
  We found oprofile daemon running, please stop it and try again.

In case oprofiled was not detected the current error message stays:

  $ perf record ls
  Error:
  The sys_perf_event_open() syscall returned with 16 (Device or resource busy) 
for event (cycles).
  /bin/dmesg may provide additional information.
  No CONFIG_PERF_EVENTS=y kernel support configured?

Also changing PERF_FLAG_FD_CLOEXEC detection code not to display error
in case of EBUSY error, as it currently does:

  $ perf record ls
  Error:
  perf_event_open(..., PERF_FLAG_FD_CLOEXEC) failed with unexpected error 16 
(Device or resource busy)
  perf_event_open(..., 0) failed unexpectedly with error 16 (Device or resource 
busy)
  The PMU counters are busy/taken by another profiler.
  We found oprofile daemon running, please stop it and try again.

Signed-off-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: William Cohen 
Cc: Yann Droneaud 
Link: http://lkml.kernel.org/r/1406908014-8312-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cloexec.c |  4 ++--
 tools/perf/util/evsel.c   |  6 ++
 tools/perf/util/util.c| 36 
 tools/perf/util/util.h|  1 +
 4 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cloexec.c b/tools/perf/util/cloexec.c
index c5d05ec..dede0c3 100644
--- a/tools/perf/util/cloexec.c
+++ b/tools/perf/util/cloexec.c
@@ -25,7 +25,7 @@ static int perf_flag_probe(void)
return 1;
}
 
-   WARN_ONCE(err != EINVAL,
+   WARN_ONCE(err != EINVAL && err != EBUSY,
  "perf_event_open(..., PERF_FLAG_FD_CLOEXEC) failed with 
unexpected error %d (%s)\n",
  err, strerror(err));
 
@@ -33,7 +33,7 @@ static int perf_flag_probe(void)
fd = sys_perf_event_open(, 0, -1, -1, 0);
err = errno;
 
-   if (WARN_ONCE(fd < 0,
+   if (WARN_ONCE(fd < 0 && err != EBUSY,
  "perf_event_open(..., 0) failed unexpectedly with error 
%d (%s)\n",
  err, strerror(err)))
return -1;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 92e5235..0c8919d 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2039,6 +2039,12 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel, 
struct target *target,
"No APIC? If so then you can boot the kernel with the \"lapic\" boot 
parameter to force-enable it.");
 #endif
break;
+   case EBUSY:
+   if (find_process("oprofiled"))
+   return scnprintf(msg, size,
+   "The PMU counters are busy/taken by another profiler.\n"
+   "We found oprofile daemon running, please stop it and try again.");
+   break;
default:
break;
}
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index e52e746..b82a93c 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -536,3 +536,39 @@ void mem_bswap_64(void *src, int byte_size)
++m;
}
 }
+
+bool find_process(const char *name)
+{
+   size_t len = strlen(name);
+   DIR *dir;
+   struct dirent *d;
+   int ret = -1;
+
+   dir = opendir(procfs__mountpoint());
+   if (!dir)
+   return -1;
+
+   /* Walk through the directory. */
+   while (ret && (d = readdir(dir)) != NULL) {
+   char path[PATH_MAX];
+   char *data;
+   size_t size;
+
+   if ((d->d_type != DT_DIR) ||
+!strcmp(".", d->d_name) ||
+!strcmp("..", d->d_name))
+   continue;
+
+   scnprintf(path, sizeof(path), "%s/%s/comm",
+ procfs__mountpoint(), d->d_name);
+
+   if (filename__read_str(path, , ))
+   continue;
+
+   ret = strncmp(name, data, len);
+   free(data);
+   }
+
+   closedir(dir);
+   return ret ? false : true;
+}
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 38af775..03a1ea2 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -346,4 +346,5 @@ void mem_bswap_64(void 

[tip:perf/core] perf tools: Save column length in perf_hpp_fmt

[tip-bot for Namhyung Kim]

Commit-ID:  e0d66c74b09f5103eef441a98b68056c4dae4cac
Gitweb: http://git.kernel.org/tip/e0d66c74b09f5103eef441a98b68056c4dae4cac
Author: Namhyung Kim 
AuthorDate: Thu, 31 Jul 2014 14:47:37 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:05 -0300

perf tools: Save column length in perf_hpp_fmt

Save column length in the hpp format and pass it to print functions.
This is a preparation for users to control column width in the output.

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406785662-5534-4-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c |   2 +-
 tools/perf/ui/hist.c   | 135 +++--
 tools/perf/util/hist.h |   2 +
 tools/perf/util/sort.c |   3 +-
 4 files changed, 94 insertions(+), 48 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 02507ba..c1d8d39 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -849,7 +849,7 @@ static int hists__scnprintf_headers(char *buf, size_t size, 
struct hists *hists)
if (perf_hpp__should_skip(fmt))
continue;
 
-   /* We need to add the length of the columns header. */
+   /* We need to ensure length of the columns header. */
perf_hpp__reset_width(fmt, hists);
 
ret = fmt->header(fmt, _hpp, hists_to_evsel(hists));
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index c6cffbd..e28ca97 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -110,7 +110,7 @@ int __hpp__fmt_acc(struct perf_hpp *hpp, struct hist_entry 
*he,
 {
if (!symbol_conf.cumulate_callchain) {
return snprintf(hpp->buf, hpp->size, "%*s",
-   fmt_percent ? 8 : 12, "N/A");
+   fmt_percent ? len + 2 : len + 1, "N/A");
}
 
return __hpp__fmt(hpp, he, get_field, fmt, len, print_fn, fmt_percent);
@@ -190,32 +190,31 @@ static int __hpp__sort_acc(struct hist_entry *a, struct 
hist_entry *b,
return ret;
 }
 
-#define __HPP_HEADER_FN(_type, _str, _min_width, _unit_width)  \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
-  struct perf_hpp *hpp,\
-  struct perf_evsel *evsel)\
-{  \
-   int len = _min_width;   \
-   \
-   if (symbol_conf.event_group)\
-   len = max(len, evsel->nr_members * _unit_width);\
-   \
-   return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
-}
-
-#define __HPP_WIDTH_FN(_type, _min_width, _unit_width) 
\
-static int hpp__width_##_type(struct perf_hpp_fmt *fmt __maybe_unused, \
+#define __HPP_WIDTH_FN(_type, _str)\
+static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
  struct perf_hpp *hpp __maybe_unused,  \
  struct perf_evsel *evsel) \
 {  \
-   int len = _min_width;   \
+   int len = fmt->len; \
\
if (symbol_conf.event_group)\
-   len = max(len, evsel->nr_members * _unit_width);\
+   len = max(len, evsel->nr_members * len);\
+   \
+   if (len < (int)strlen(_str))\
+   len = strlen(_str); \
\
return len; \
 }
 
+#define __HPP_HEADER_FN(_type, _str)   \
+static int hpp__header_##_type(struct perf_hpp_fmt *fmt,   \
+  struct perf_hpp *hpp,\
+  struct perf_evsel *evsel)\
+{  \
+   int len = hpp__width_##_type(fmt, hpp, evsel);  \
+   return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+}
+
 

[tip:perf/core] perf tools: Fix make PYTHON override

[tip-bot for Namhyung Kim]

Commit-ID:  56c7d79e49776084b852e451bda5f59dc3bcf894
Gitweb: http://git.kernel.org/tip/56c7d79e49776084b852e451bda5f59dc3bcf894
Author: Namhyung Kim 
AuthorDate: Tue, 29 Jul 2014 15:57:19 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:04 -0300

perf tools: Fix make PYTHON override

Thomas reported that make PYTHON=python2 is not work on some systems.  I
can reproduce it on my ArchLinux box too.

This is because it's overridden by config/feature-checks/Makefile
regardless of PYTHON setting.  I guess it's a bug slipped into during
the feature checking change.

Actually, we don't need to check python-config in the feature-checks.
We can just pass appropriate FEATURE_CHECK_*FLAGS.

Reported-by: Thomas Ilsche 
Signed-off-by: Namhyung Kim 
Tested-by: Thomas Ilsche 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Ilsche 
Link: 
http://lkml.kernel.org/r/1406617040-26909-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/config/Makefile| 34 ---
 tools/perf/config/feature-checks/Makefile | 18 ++--
 2 files changed, 24 insertions(+), 28 deletions(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 1f67aa0..e05d8f9 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -120,6 +120,23 @@ ifdef PARSER_DEBUG
   CFLAGS += -DPARSER_DEBUG
 endif
 
+ifndef NO_LIBPYTHON
+  override PYTHON := \
+$(call get-executable-or-default,PYTHON,python)
+  override PYTHON_CONFIG := \
+$(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON)-config)
+
+  PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
+
+  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+  PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+
+  FEATURE_CHECK_CFLAGS-libpython := $(PYTHON_EMBED_CCOPTS)
+  FEATURE_CHECK_LDFLAGS-libpython := $(PYTHON_EMBED_LDOPTS)
+  FEATURE_CHECK_CFLAGS-libpython-version := $(PYTHON_EMBED_CCOPTS)
+  FEATURE_CHECK_LDFLAGS-libpython-version := $(PYTHON_EMBED_LDOPTS)
+endif
+
 CFLAGS += -fno-omit-frame-pointer
 CFLAGS += -ggdb3
 CFLAGS += -funwind-tables
@@ -482,21 +499,14 @@ define disable-python_code
   NO_LIBPYTHON := 1
 endef
 
-override PYTHON := \
-  $(call get-executable-or-default,PYTHON,python)
-
-ifndef PYTHON
-  $(call disable-python,python interpreter)
+ifdef NO_LIBPYTHON
+  $(call disable-python)
 else
 
-  PYTHON_WORD := $(call shell-wordify,$(PYTHON))
-
-  ifdef NO_LIBPYTHON
-$(call disable-python)
+  ifndef PYTHON
+$(call disable-python,python interpreter)
   else
-
-override PYTHON_CONFIG := \
-  $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON)-config)
+PYTHON_WORD := $(call shell-wordify,$(PYTHON))
 
 ifndef PYTHON_CONFIG
   $(call disable-python,python-config tool)
diff --git a/tools/perf/config/feature-checks/Makefile 
b/tools/perf/config/feature-checks/Makefile
index 6088f8d..72ab298 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -101,25 +101,11 @@ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 test-libperl.bin:
$(BUILD) $(FLAGS_PERL_EMBED)
 
-override PYTHON := python
-override PYTHON_CONFIG := python-config
-
-escape-for-shell-sq =  $(subst ','\'',$(1))
-shell-sq = '$(escape-for-shell-sq)'
-
-PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
-
-PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
-PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
-PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
-PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
-FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
-
 test-libpython.bin:
-   $(BUILD) $(FLAGS_PYTHON_EMBED)
+   $(BUILD)
 
 test-libpython-version.bin:
-   $(BUILD) $(FLAGS_PYTHON_EMBED)
+   $(BUILD)
 
 test-libbfd.bin:
$(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf kmem: Do not ignore mmap events

[tip-bot for Namhyung Kim]

Commit-ID:  64c40908938953d7afa90e9363327875286349e5
Gitweb: http://git.kernel.org/tip/64c40908938953d7afa90e9363327875286349e5
Author: Namhyung Kim 
AuthorDate: Fri, 1 Aug 2014 14:59:31 +0900
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:03 -0300

perf kmem: Do not ignore mmap events

The perf kmem command didn't process mmap events for some unknown reason
and it instead gets symbol info from a running kernel.  This is
problematic if perf kmem record was run on a different kernel.

This patch adds the mmap event handlers and reverts the commit
e727ca73f85d ("perf kmem: Resolve kernel symbols again").

Signed-off-by: Namhyung Kim 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406872771-23933-1-git-send-email-namhy...@kernel.org
[ Fixed up merge conflict with Jiri's ordered_events rename patch set ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-kmem.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index b572111..84b8239 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -256,6 +256,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
 static struct perf_tool perf_kmem = {
.sample  = process_sample_event,
.comm= perf_event__process_comm,
+   .mmap= perf_event__process_mmap,
+   .mmap2   = perf_event__process_mmap2,
.ordered_events  = true,
 };
 
@@ -424,9 +426,6 @@ static int __cmd_kmem(void)
if (session == NULL)
return -ENOMEM;
 
-   if (perf_session__create_kernel_maps(session) < 0)
-   goto out_delete;
-
if (!perf_session__has_traces(session, "kmem record"))
goto out_delete;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Add debug prints for ordered events queue

[tip-bot for Jiri Olsa]

Commit-ID:  cee3ab9caa7ae5ee81027e60c0109063664d9217
Gitweb: http://git.kernel.org/tip/cee3ab9caa7ae5ee81027e60c0109063664d9217
Author: Jiri Olsa 
AuthorDate: Fri, 11 Jul 2014 14:49:54 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:01 -0300

perf tools: Add debug prints for ordered events queue

Adding some prints for ordered events queue, to help debug issues.

Adding debug_ordered_events debug variable to be able to enable ordered
events debug messages using:

  $ perf --debug ordered-events=2 report ...

Also using oe pointer in perf_session__queue_event instead of chained
session variable dereferencing.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-7p3mnnopjvsp9nmk9msqc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/debug.c  | 36 +++-
 tools/perf/util/debug.h  |  8 
 tools/perf/util/ordered-events.c | 26 ++
 tools/perf/util/session.c|  4 +++-
 4 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index 71d4193..ba357f3 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -13,8 +13,12 @@
 #include "util.h"
 #include "target.h"
 
+#define NSECS_PER_SEC  10ULL
+#define NSECS_PER_USEC 1000ULL
+
 int verbose;
 bool dump_trace = false, quiet = false;
+int debug_ordered_events;
 
 static int _eprintf(int level, int var, const char *fmt, va_list args)
 {
@@ -42,6 +46,35 @@ int eprintf(int level, int var, const char *fmt, ...)
return ret;
 }
 
+static int __eprintf_time(u64 t, const char *fmt, va_list args)
+{
+   int ret = 0;
+   u64 secs, usecs, nsecs = t;
+
+   secs   = nsecs / NSECS_PER_SEC;
+   nsecs -= secs  * NSECS_PER_SEC;
+   usecs  = nsecs / NSECS_PER_USEC;
+
+   ret = fprintf(stderr, "[%13" PRIu64 ".%06" PRIu64 "] ",
+ secs, usecs);
+   ret += vfprintf(stderr, fmt, args);
+   return ret;
+}
+
+int eprintf_time(int level, int var, u64 t, const char *fmt, ...)
+{
+   int ret = 0;
+   va_list args;
+
+   if (var >= level) {
+   va_start(args, fmt);
+   ret = __eprintf_time(t, fmt, args);
+   va_end(args);
+   }
+
+   return ret;
+}
+
 /*
  * Overloading libtraceevent standard info print
  * function, display with -v in perf.
@@ -110,7 +143,8 @@ static struct debug_variable {
const char *name;
int *ptr;
 } debug_variables[] = {
-   { .name = "verbose", .ptr =  },
+   { .name = "verbose",.ptr =  },
+   { .name = "ordered-events", .ptr = _ordered_events},
{ .name = NULL, }
 };
 
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index 89fb6b0..6944ea3 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -10,6 +10,7 @@
 
 extern int verbose;
 extern bool quiet, dump_trace;
+extern int debug_ordered_events;
 
 #ifndef pr_fmt
 #define pr_fmt(fmt) fmt
@@ -29,6 +30,12 @@ extern bool quiet, dump_trace;
 #define pr_debug3(fmt, ...) pr_debugN(3, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debug4(fmt, ...) pr_debugN(4, pr_fmt(fmt), ##__VA_ARGS__)
 
+#define pr_time_N(n, var, t, fmt, ...) \
+   eprintf_time(n, var, t, fmt, ##__VA_ARGS__)
+
+#define pr_oe_time(t, fmt, ...)  pr_time_N(1, debug_ordered_events, t, 
pr_fmt(fmt), ##__VA_ARGS__)
+#define pr_oe_time2(t, fmt, ...) pr_time_N(2, debug_ordered_events, t, 
pr_fmt(fmt), ##__VA_ARGS__)
+
 int dump_printf(const char *fmt, ...) __attribute__((format(printf, 1, 2)));
 void trace_event(union perf_event *event);
 
@@ -38,6 +45,7 @@ int ui__warning(const char *format, ...) 
__attribute__((format(printf, 1, 2)));
 void pr_stat(const char *fmt, ...);
 
 int eprintf(int level, int var, const char *fmt, ...) 
__attribute__((format(printf, 3, 4)));
+int eprintf_time(int level, int var, u64 t, const char *fmt, ...) 
__attribute__((format(printf, 4, 5)));
 
 int perf_debug_option(const char *str);
 
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 381d5fe..8a8aeab 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -1,10 +1,16 @@
 #include 
+#include 
 #include "ordered-events.h"
 #include "evlist.h"
 #include "session.h"
 #include "asm/bug.h"
 #include "debug.h"
 
+#define pr_N(n, fmt, ...) \
+   eprintf(n, debug_ordered_events, fmt, ##__VA_ARGS__)
+
+#define pr(fmt, ...) pr_N(1, pr_fmt(fmt), ##__VA_ARGS__)
+
 static void queue_event(struct ordered_events *oe, struct ordered_event *new)
 {
struct ordered_event *last = oe->last;
@@ -14,6 +20,8 @@ static void queue_event(struct ordered_events *oe, struct 
ordered_event *new)
++oe->nr_events;
oe->last = 

[tip:perf/core] perf tools: Add report.queue-size config file option

[tip-bot for Jiri Olsa]

Commit-ID:  94786b67b5f4577c16486e8eb10ff045e59f80ef
Gitweb: http://git.kernel.org/tip/94786b67b5f4577c16486e8eb10ff045e59f80ef
Author: Jiri Olsa 
AuthorDate: Thu, 5 Jun 2014 11:00:20 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:01 -0300

perf tools: Add report.queue-size config file option

Adding report.queue-size config file option to setup the maximum
allocation size for session's struct ordered_events object.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-lm42mbpu0cwljpyy8vw5y...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-report.c  | 13 -
 tools/perf/util/ordered-events.h |  6 ++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index c72cc5a..041e93d 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -58,17 +58,19 @@ struct report {
const char  *symbol_filter_str;
float   min_percent;
u64 nr_entries;
+   u64 queue_size;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
 };
 
 static int report__config(const char *var, const char *value, void *cb)
 {
+   struct report *rep = cb;
+
if (!strcmp(var, "report.group")) {
symbol_conf.event_group = perf_config_bool(var, value);
return 0;
}
if (!strcmp(var, "report.percent-limit")) {
-   struct report *rep = cb;
rep->min_percent = strtof(value, NULL);
return 0;
}
@@ -76,6 +78,10 @@ static int report__config(const char *var, const char 
*value, void *cb)
symbol_conf.cumulate_callchain = perf_config_bool(var, value);
return 0;
}
+   if (!strcmp(var, "report.queue-size")) {
+   rep->queue_size = perf_config_u64(var, value);
+   return 0;
+   }
 
return perf_default_config(var, value, cb);
 }
@@ -714,6 +720,11 @@ repeat:
if (session == NULL)
return -ENOMEM;
 
+   if (report.queue_size) {
+   ordered_events__set_alloc_size(>ordered_events,
+  report.queue_size);
+   }
+
report.session = session;
 
has_br_stack = perf_header__has_feat(>header,
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 6036bd6..2ce847f 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -40,4 +40,10 @@ int ordered_events__flush(struct perf_session *s, struct 
perf_tool *tool,
  enum oe_flush how);
 void ordered_events__init(struct ordered_events *oe);
 void ordered_events__free(struct ordered_events *oe);
+
+static inline
+void ordered_events__set_alloc_size(struct ordered_events *oe, u64 size)
+{
+   oe->max_alloc_size = size;
+}
 #endif /* __ORDERED_EVENTS_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Allow out of order messages in forced flush

[tip-bot for Jiri Olsa]

Commit-ID:  b0a45203a75a800015828ac89f2945981019b65b
Gitweb: http://git.kernel.org/tip/b0a45203a75a800015828ac89f2945981019b65b
Author: Jiri Olsa 
AuthorDate: Thu, 12 Jun 2014 09:50:11 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:02 -0300

perf tools: Allow out of order messages in forced flush

In forced flush (OE_FLUSH__HALF) we break the rules of the flush
timestamp via PERF_RECORD_FINISHED_ROUND event, so we could get out of
order event.

Do not force error in this case plus changing the output warning to use
WARN_ONCE.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-8q8794a8nlmpd1u8xrqmc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c |  4 
 tools/perf/util/ordered-events.h |  2 ++
 tools/perf/util/session.c| 12 +---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 8a8aeab..706ce1a 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -169,6 +169,7 @@ int ordered_events__flush(struct perf_session *s, struct 
perf_tool *tool,
 {
struct ordered_events *oe = >ordered_events;
static const char * const str[] = {
+   "NONE",
"FINAL",
"ROUND",
"HALF ",
@@ -198,6 +199,7 @@ int ordered_events__flush(struct perf_session *s, struct 
perf_tool *tool,
}
 
case OE_FLUSH__ROUND:
+   case OE_FLUSH__NONE:
default:
break;
};
@@ -211,6 +213,8 @@ int ordered_events__flush(struct perf_session *s, struct 
perf_tool *tool,
if (!err) {
if (how == OE_FLUSH__ROUND)
oe->next_flush = oe->max_timestamp;
+
+   oe->last_flush_type = how;
}
 
pr_oe_time(oe->next_flush, "next_flush - ordered_events__flush POST %s, 
nr_events %u\n",
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 2ce847f..3b2f205 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -14,6 +14,7 @@ struct ordered_event {
 };
 
 enum oe_flush {
+   OE_FLUSH__NONE,
OE_FLUSH__FINAL,
OE_FLUSH__ROUND,
OE_FLUSH__HALF,
@@ -32,6 +33,7 @@ struct ordered_events {
struct ordered_event*last;
int buffer_idx;
unsigned intnr_events;
+   enum oe_flush   last_flush_type;
 };
 
 struct ordered_event *ordered_events__new(struct ordered_events *oe, u64 
timestamp);
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 462be27..7e27f1e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -14,6 +14,7 @@
 #include "util.h"
 #include "cpumap.h"
 #include "perf_regs.h"
+#include "asm/bug.h"
 
 static int perf_session__open(struct perf_session *session)
 {
@@ -500,10 +501,15 @@ int perf_session_queue_event(struct perf_session *s, 
union perf_event *event,
return -ETIME;
 
if (timestamp < oe->last_flush) {
-   printf("Warning: Timestamp below last timeslice flush\n");
+   WARN_ONCE(1, "Timestamp below last timeslice flush\n");
+
pr_oe_time(timestamp,  "out of order event");
-   pr_oe_time(oe->last_flush, "last flush");
-   return -EINVAL;
+   pr_oe_time(oe->last_flush, "last flush, last_flush_type %d\n",
+  oe->last_flush_type);
+
+   /* We could get out of order messages after forced flush. */
+   if (oe->last_flush_type != OE_FLUSH__HALF)
+   return -EINVAL;
}
 
new = ordered_events__new(oe, timestamp);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Add perf_config_u64 function

[tip-bot for Jiri Olsa]

Commit-ID:  94c0655fc16b0c09edc21cadddbeef95c408f3e7
Gitweb: http://git.kernel.org/tip/94c0655fc16b0c09edc21cadddbeef95c408f3e7
Author: Jiri Olsa 
AuthorDate: Fri, 6 Jun 2014 05:27:28 -0400
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:00 -0300

perf tools: Add perf_config_u64 function

Adding perf_config_u64 function to be able to parse 'llong' values out
of config file.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-ni6gqdlvw7khp74r9htvk...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cache.h  |  1 +
 tools/perf/util/config.c | 24 
 2 files changed, 25 insertions(+)

diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 7b176dd..5cf9e1b 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -22,6 +22,7 @@ typedef int (*config_fn_t)(const char *, const char *, void 
*);
 extern int perf_default_config(const char *, const char *, void *);
 extern int perf_config(config_fn_t fn, void *);
 extern int perf_config_int(const char *, const char *);
+extern u64 perf_config_u64(const char *, const char *);
 extern int perf_config_bool(const char *, const char *);
 extern int config_error_nonbool(const char *);
 extern const char *perf_config_dirname(const char *, const char *);
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 1e5e2e5..9970b8b 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -286,6 +286,21 @@ static int parse_unit_factor(const char *end, unsigned 
long *val)
return 0;
 }
 
+static int perf_parse_llong(const char *value, long long *ret)
+{
+   if (value && *value) {
+   char *end;
+   long long val = strtoll(value, , 0);
+   unsigned long factor = 1;
+
+   if (!parse_unit_factor(end, ))
+   return 0;
+   *ret = val * factor;
+   return 1;
+   }
+   return 0;
+}
+
 static int perf_parse_long(const char *value, long *ret)
 {
if (value && *value) {
@@ -307,6 +322,15 @@ static void die_bad_config(const char *name)
die("bad config value for '%s'", name);
 }
 
+u64 perf_config_u64(const char *name, const char *value)
+{
+   long long ret = 0;
+
+   if (!perf_parse_llong(value, ))
+   die_bad_config(name);
+   return (u64) ret;
+}
+
 int perf_config_int(const char *name, const char *value)
 {
long ret = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Add ordered_events__free function

[tip-bot for Jiri Olsa]

Commit-ID:  adc56ed1e01f1c43fc7bf75340f11f4ad5e11145
Gitweb: http://git.kernel.org/tip/adc56ed1e01f1c43fc7bf75340f11f4ad5e11145
Author: Jiri Olsa 
AuthorDate: Tue, 10 Jun 2014 22:50:03 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:03:00 -0300

perf tools: Add ordered_events__free function

Adding ordered_events__free function to release all the struct
ordered_events data. It's replacement for former
perf_session_free_sample_buffers function.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-urraa8ccay4o14wambjra...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 11 +++
 tools/perf/util/ordered-events.h |  1 +
 tools/perf/util/session.c| 17 ++---
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 7b8923e..381d5fe 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -202,3 +202,14 @@ void ordered_events__init(struct ordered_events *oe)
oe->max_alloc_size = (u64) -1;
oe->cur_alloc_size = 0;
 }
+
+void ordered_events__free(struct ordered_events *oe)
+{
+   while (!list_empty(>to_free)) {
+   struct ordered_event *event;
+
+   event = list_entry(oe->to_free.next, struct ordered_event, 
list);
+   list_del(>list);
+   free(event);
+   }
+}
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 62f9945..6036bd6 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -39,4 +39,5 @@ void ordered_events__delete(struct ordered_events *oe, struct 
ordered_event *eve
 int ordered_events__flush(struct perf_session *s, struct perf_tool *tool,
  enum oe_flush how);
 void ordered_events__init(struct ordered_events *oe);
+void ordered_events__free(struct ordered_events *oe);
 #endif /* __ORDERED_EVENTS_H */
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 7f5851e..7d8dbf2 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -442,19 +442,6 @@ static perf_event__swap_op perf_event__swap_ops[] = {
[PERF_RECORD_HEADER_MAX]  = NULL,
 };
 
-static void perf_session_free_sample_buffers(struct perf_session *session)
-{
-   struct ordered_events *oe = >ordered_events;
-
-   while (!list_empty(>to_free)) {
-   struct ordered_event *event;
-
-   event = list_entry(oe->to_free.next, struct ordered_event, 
list);
-   list_del(>list);
-   free(event);
-   }
-}
-
 /*
  * When perf record finishes a pass on every buffers, it records this pseudo
  * event.
@@ -1092,7 +1079,7 @@ done:
 out_err:
free(buf);
perf_session__warn_about_errors(session, tool);
-   perf_session_free_sample_buffers(session);
+   ordered_events__free(>ordered_events);
return err;
 }
 
@@ -1237,7 +1224,7 @@ out:
 out_err:
ui_progress__finish();
perf_session__warn_about_errors(session, tool);
-   perf_session_free_sample_buffers(session);
+   ordered_events__free(>ordered_events);
session->one_mmap = false;
return err;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Use list_move in ordered_events_delete function

[tip-bot for Jiri Olsa]

Commit-ID:  fa4e5c67a2d169b9ef83f51b94e1d4a562ddfc0f
Gitweb: http://git.kernel.org/tip/fa4e5c67a2d169b9ef83f51b94e1d4a562ddfc0f
Author: Jiri Olsa 
AuthorDate: Sun, 15 Jun 2014 19:46:08 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:59 -0300

perf tools: Use list_move in ordered_events_delete function

As Namhyung pointed out we can use list_move in ordered_events_delete.

Signed-off-by: Jiri Olsa 
Suggested-by: Namhyung Kim 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-m8ae5s5cuwyytitgb6iqi...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 95f8211..be6a48c 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -96,8 +96,7 @@ ordered_events__new(struct ordered_events *oe, u64 timestamp)
 
 void ordered_events__delete(struct ordered_events *oe, struct ordered_event 
*event)
 {
-   list_del(>list);
-   list_add(>list, >cache);
+   list_move(>list, >cache);
oe->nr_events--;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Add ordered_events__init function

[tip-bot for Jiri Olsa]

Commit-ID:  36522f5cf2ad280c971557e04120d52f9330ed36
Gitweb: http://git.kernel.org/tip/36522f5cf2ad280c971557e04120d52f9330ed36
Author: Jiri Olsa 
AuthorDate: Tue, 10 Jun 2014 22:47:40 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:59 -0300

perf tools: Add ordered_events__init function

Adding ordered_events__init function for struct ordered_events struct
initialization.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-g6dx35hed8g14eh1ygx4u...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/ordered-events.c | 9 +
 tools/perf/util/ordered-events.h | 1 +
 tools/perf/util/session.c| 6 +-
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index be6a48c..7b8923e 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -193,3 +193,12 @@ int ordered_events__flush(struct perf_session *s, struct 
perf_tool *tool,
 
return err;
 }
+
+void ordered_events__init(struct ordered_events *oe)
+{
+   INIT_LIST_HEAD(>events);
+   INIT_LIST_HEAD(>cache);
+   INIT_LIST_HEAD(>to_free);
+   oe->max_alloc_size = (u64) -1;
+   oe->cur_alloc_size = 0;
+}
diff --git a/tools/perf/util/ordered-events.h b/tools/perf/util/ordered-events.h
index 8309983..62f9945 100644
--- a/tools/perf/util/ordered-events.h
+++ b/tools/perf/util/ordered-events.h
@@ -38,4 +38,5 @@ struct ordered_event *ordered_events__new(struct 
ordered_events *oe, u64 timesta
 void ordered_events__delete(struct ordered_events *oe, struct ordered_event 
*event);
 int ordered_events__flush(struct perf_session *s, struct perf_tool *tool,
  enum oe_flush how);
+void ordered_events__init(struct ordered_events *oe);
 #endif /* __ORDERED_EVENTS_H */
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 0ccf051..7f5851e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -75,11 +75,7 @@ struct perf_session *perf_session__new(struct perf_data_file 
*file,
goto out;
 
session->repipe = repipe;
-   INIT_LIST_HEAD(>ordered_events.events);
-   INIT_LIST_HEAD(>ordered_events.cache);
-   INIT_LIST_HEAD(>ordered_events.to_free);
-   session->ordered_events.max_alloc_size = (u64) -1;
-   session->ordered_events.cur_alloc_size = 0;
+   ordered_events__init(>ordered_events);
machines__init(>machines);
 
if (file) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 3/5] mmc: mmci: relax blksz check for SDIO

[Srinivas Kandagatla]

Thankyou for the feedback.

On 12/08/14 15:12, Russell King - ARM Linux wrote:

On Tue, Aug 12, 2014 at 01:04:40PM +0100, Srinivas Kandagatla wrote:

From: Srinivas Kandagatla 

This patch adds condition in mmci_validate_data to skip checking
blocksize for SDIO card types. SDIO card type can issue blocksizes
which are not exactly power of 2 so this check always fails, resulting
in SDIO failures.


Do you understand why this check is there?

Do you realise that the standard MMCI from ARM Ltd can /only/ perform
power-of-2 block transfers?


Yes, I noticed that in pl180 TRM. I agree this patch will break standard 
MMCI.


In the past Ulf Hansson and Stefan Nilsson have submitted a patch to fix 
this issue for ux500v2. This patch adds new flag non_power_of_2_blksize 
/ any_blksize to variant_data.


http://www.spinics.net/lists/linux-mmc/msg12160.html
http://marc.info/?l=linux-mmc=131710963908853=2

This patch will fix the issue for Qcom too. If you are Ok with adding 
new flag non_power_of_2_blksize/any_blksize in the variant_data, I can 
rebase and include Ulf's patch in next version.



thanks,
--srini



Hence, NAK on this change as it stands.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Flush ordered events in case of allocation failure

[tip-bot for Jiri Olsa]

Commit-ID:  d40b4a15ab2bfcfa7d946b69ca1f12c93b22d169
Gitweb: http://git.kernel.org/tip/d40b4a15ab2bfcfa7d946b69ca1f12c93b22d169
Author: Jiri Olsa 
AuthorDate: Fri, 1 Aug 2014 13:01:04 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:57 -0300

perf tools: Flush ordered events in case of allocation failure

In previous patches we added a limit for ordered events queue allocation
size. If we reach this size we need to flush (part of) the queue to get
some free buffers.

The current functionality is not affected, because the limit is hard
coded to (u64) -1. The configuration code for size will come in
following patches.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-ggcas0xdq847fi85bz73d...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-kvm.c  |  2 +-
 tools/perf/util/session.c | 29 +++--
 tools/perf/util/session.h |  3 ++-
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 258a527..7cccead 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -732,7 +732,7 @@ static s64 perf_kvm__mmap_read_idx(struct perf_kvm_stat 
*kvm, int idx,
return -1;
}
 
-   err = perf_session_queue_event(kvm->session, event, , 0);
+   err = perf_session_queue_event(kvm->session, event, >tool, 
, 0);
/*
 * FIXME: Here we can't consume the event, as 
perf_session_queue_event will
 *point to it, and it'll get possibly overwritten by 
the kernel.
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 8d4538c..bd2483b 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -14,6 +14,7 @@
 #include "util.h"
 #include "cpumap.h"
 #include "perf_regs.h"
+#include "asm/bug.h"
 
 static int perf_session__open(struct perf_session *session)
 {
@@ -456,6 +457,7 @@ struct ordered_event {
 enum oe_flush {
OE_FLUSH__FINAL,
OE_FLUSH__ROUND,
+   OE_FLUSH__HALF,
 };
 
 static void perf_session_free_sample_buffers(struct perf_session *session)
@@ -637,6 +639,23 @@ static int ordered_events__flush(struct perf_session *s, 
struct perf_tool *tool,
oe->next_flush = ULLONG_MAX;
break;
 
+   case OE_FLUSH__HALF:
+   {
+   struct ordered_event *first, *last;
+   struct list_head *head = >events;
+
+   first = list_entry(head->next, struct ordered_event, list);
+   last = oe->last;
+
+   /* Warn if we are called before any event got allocated. */
+   if (WARN_ONCE(!last || list_empty(head), "empty queue"))
+   return 0;
+
+   oe->next_flush  = first->timestamp;
+   oe->next_flush += (last->timestamp - first->timestamp) / 2;
+   break;
+   }
+
case OE_FLUSH__ROUND:
default:
break;
@@ -699,7 +718,8 @@ static int process_finished_round(struct perf_tool *tool,
 }
 
 int perf_session_queue_event(struct perf_session *s, union perf_event *event,
-   struct perf_sample *sample, u64 file_offset)
+struct perf_tool *tool, struct perf_sample *sample,
+u64 file_offset)
 {
struct ordered_events *oe = >ordered_events;
u64 timestamp = sample->time;
@@ -714,6 +734,11 @@ int perf_session_queue_event(struct perf_session *s, union 
perf_event *event,
}
 
new = ordered_events__new(oe, timestamp);
+   if (!new) {
+   ordered_events__flush(s, tool, OE_FLUSH__HALF);
+   new = ordered_events__new(oe, timestamp);
+   }
+
if (!new)
return -ENOMEM;
 
@@ -1121,7 +1146,7 @@ static s64 perf_session__process_event(struct 
perf_session *session,
return ret;
 
if (tool->ordered_events) {
-   ret = perf_session_queue_event(session, event, ,
+   ret = perf_session_queue_event(session, event, tool, ,
   file_offset);
if (ret != -ETIME)
return ret;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index e2fbaf2..a09e3c8 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -67,7 +67,8 @@ int perf_session__process_events(struct perf_session *session,
 struct perf_tool *tool);
 
 int perf_session_queue_event(struct perf_session *s, union perf_event *event,
-struct perf_sample *sample, u64 file_offset);
+struct perf_tool *tool, struct 

[tip:perf/core] perf tools: Make perf_session__deliver_event global

[tip-bot for Jiri Olsa]

Commit-ID:  79a30fe4f3758c98e1b7a474952b9701d513e580
Gitweb: http://git.kernel.org/tip/79a30fe4f3758c98e1b7a474952b9701d513e580
Author: Jiri Olsa 
AuthorDate: Tue, 10 Jun 2014 22:31:35 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:58 -0300

perf tools: Make perf_session__deliver_event global

Making perf_session__deliver_event global function, as it will be called
from another object in following patch.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-rz7s2b8uwv567bigckh75...@git.kernel.org
[ Fixup naming to match class__method schema, as now is more widely exposed ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/session.c | 23 ---
 tools/perf/util/session.h |  5 +
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index bd2483b..ed6b7f1 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -571,12 +571,6 @@ ordered_events__delete(struct ordered_events *oe, struct 
ordered_event *event)
oe->nr_events--;
 }
 
-static int perf_session_deliver_event(struct perf_session *session,
- union perf_event *event,
- struct perf_sample *sample,
- struct perf_tool *tool,
- u64 file_offset);
-
 static int __ordered_events__flush(struct perf_session *s,
   struct perf_tool *tool)
 {
@@ -607,8 +601,8 @@ static int __ordered_events__flush(struct perf_session *s,
if (ret)
pr_err("Can't parse sample, err = %d\n", ret);
else {
-   ret = perf_session_deliver_event(s, iter->event, 
, tool,
-iter->file_offset);
+   ret = perf_session__deliver_event(s, iter->event, 
, tool,
+ iter->file_offset);
if (ret)
return ret;
}
@@ -1003,11 +997,10 @@ perf_session__deliver_sample(struct perf_session 
*session,
>read.one, machine);
 }
 
-static int perf_session_deliver_event(struct perf_session *session,
- union perf_event *event,
- struct perf_sample *sample,
- struct perf_tool *tool,
- u64 file_offset)
+int perf_session__deliver_event(struct perf_session *session,
+   union perf_event *event,
+   struct perf_sample *sample,
+   struct perf_tool *tool, u64 file_offset)
 {
struct perf_evsel *evsel;
struct machine *machine;
@@ -1152,8 +1145,8 @@ static s64 perf_session__process_event(struct 
perf_session *session,
return ret;
}
 
-   return perf_session_deliver_event(session, event, , tool,
- file_offset);
+   return perf_session__deliver_event(session, event, , tool,
+  file_offset);
 }
 
 void perf_event_header__bswap(struct perf_event_header *hdr)
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index a09e3c8..03da1cb 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -72,6 +72,11 @@ int perf_session_queue_event(struct perf_session *s, union 
perf_event *event,
 
 void perf_tool__fill_defaults(struct perf_tool *tool);
 
+int perf_session__deliver_event(struct perf_session *session,
+   union perf_event *event,
+   struct perf_sample *sample,
+   struct perf_tool *tool, u64 file_offset);
+
 int perf_session__resolve_callchain(struct perf_session *session,
struct perf_evsel *evsel,
struct thread *thread,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Limit ordered events queue size

[tip-bot for Jiri Olsa]

Commit-ID:  8d99a6ceebe862ac4afd832cdab332ee7b3b5599
Gitweb: http://git.kernel.org/tip/8d99a6ceebe862ac4afd832cdab332ee7b3b5599
Author: Jiri Olsa 
AuthorDate: Wed, 11 Jun 2014 15:09:35 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:57 -0300

perf tools: Limit ordered events queue size

Add limit to the ordered events queue allocation. This way we will be
able to control the size of the queue buffers.

There's no limit at the moment (it's set to (u64) -1). The config code
will come in following patches.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-lw1ny3mk4ctb6su5ght5r...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/session.c | 12 +---
 tools/perf/util/session.h |  2 ++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 72c7b0d..8d4538c 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -78,6 +78,8 @@ struct perf_session *perf_session__new(struct perf_data_file 
*file,
INIT_LIST_HEAD(>ordered_events.events);
INIT_LIST_HEAD(>ordered_events.cache);
INIT_LIST_HEAD(>ordered_events.to_free);
+   session->ordered_events.max_alloc_size = (u64) -1;
+   session->ordered_events.cur_alloc_size = 0;
machines__init(>machines);
 
if (file) {
@@ -518,7 +520,7 @@ static void queue_event(struct ordered_events *oe, struct 
ordered_event *new)
 static struct ordered_event *alloc_event(struct ordered_events *oe)
 {
struct list_head *cache = >cache;
-   struct ordered_event *new;
+   struct ordered_event *new = NULL;
 
if (!list_empty(cache)) {
new = list_entry(cache->next, struct ordered_event, list);
@@ -527,10 +529,14 @@ static struct ordered_event *alloc_event(struct 
ordered_events *oe)
new = oe->buffer + oe->buffer_idx;
if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
oe->buffer = NULL;
-   } else {
-   oe->buffer = malloc(MAX_SAMPLE_BUFFER * sizeof(*new));
+   } else if (oe->cur_alloc_size < oe->max_alloc_size) {
+   size_t size = MAX_SAMPLE_BUFFER * sizeof(*new);
+
+   oe->buffer = malloc(size);
if (!oe->buffer)
return NULL;
+
+   oe->cur_alloc_size += size;
list_add(>buffer->list, >to_free);
 
/* First entry is abused to maintain the to_free list. */
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index 419eb50..e2fbaf2 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -20,6 +20,8 @@ struct ordered_events {
u64 last_flush;
u64 next_flush;
u64 max_timestamp;
+   u64 max_alloc_size;
+   u64 cur_alloc_size;
struct list_headevents;
struct list_headcache;
struct list_headto_free;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Create ordered-events object

[tip-bot for Jiri Olsa]

Commit-ID:  5f86b80b85f0dcd05fd1471eac6984181a707c4f
Gitweb: http://git.kernel.org/tip/5f86b80b85f0dcd05fd1471eac6984181a707c4f
Author: Jiri Olsa 
AuthorDate: Fri, 1 Aug 2014 13:02:58 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:58 -0300

perf tools: Create ordered-events object

Move ordered events code into separated object ordered-events.[ch].

No functional change was intended.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-1ge3rilgudszbl87cejm1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile.perf |   2 +
 tools/perf/util/ordered-events.c | 196 +
 tools/perf/util/ordered-events.h |  41 
 tools/perf/util/session.c| 206 ---
 tools/perf/util/session.h|  17 +---
 5 files changed, 240 insertions(+), 222 deletions(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2240974..1ea31e2 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -263,6 +263,7 @@ LIB_H += util/xyarray.h
 LIB_H += util/header.h
 LIB_H += util/help.h
 LIB_H += util/session.h
+LIB_H += util/ordered-events.h
 LIB_H += util/strbuf.h
 LIB_H += util/strlist.h
 LIB_H += util/strfilter.h
@@ -347,6 +348,7 @@ LIB_OBJS += $(OUTPUT)util/machine.o
 LIB_OBJS += $(OUTPUT)util/map.o
 LIB_OBJS += $(OUTPUT)util/pstack.o
 LIB_OBJS += $(OUTPUT)util/session.o
+LIB_OBJS += $(OUTPUT)util/ordered-events.o
 LIB_OBJS += $(OUTPUT)util/comm.o
 LIB_OBJS += $(OUTPUT)util/thread.o
 LIB_OBJS += $(OUTPUT)util/thread_map.o
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
new file mode 100644
index 000..95f8211
--- /dev/null
+++ b/tools/perf/util/ordered-events.c
@@ -0,0 +1,196 @@
+#include 
+#include "ordered-events.h"
+#include "evlist.h"
+#include "session.h"
+#include "asm/bug.h"
+#include "debug.h"
+
+static void queue_event(struct ordered_events *oe, struct ordered_event *new)
+{
+   struct ordered_event *last = oe->last;
+   u64 timestamp = new->timestamp;
+   struct list_head *p;
+
+   ++oe->nr_events;
+   oe->last = new;
+
+   if (!last) {
+   list_add(>list, >events);
+   oe->max_timestamp = timestamp;
+   return;
+   }
+
+   /*
+* last event might point to some random place in the list as it's
+* the last queued event. We expect that the new event is close to
+* this.
+*/
+   if (last->timestamp <= timestamp) {
+   while (last->timestamp <= timestamp) {
+   p = last->list.next;
+   if (p == >events) {
+   list_add_tail(>list, >events);
+   oe->max_timestamp = timestamp;
+   return;
+   }
+   last = list_entry(p, struct ordered_event, list);
+   }
+   list_add_tail(>list, >list);
+   } else {
+   while (last->timestamp > timestamp) {
+   p = last->list.prev;
+   if (p == >events) {
+   list_add(>list, >events);
+   return;
+   }
+   last = list_entry(p, struct ordered_event, list);
+   }
+   list_add(>list, >list);
+   }
+}
+
+#define MAX_SAMPLE_BUFFER  (64 * 1024 / sizeof(struct ordered_event))
+static struct ordered_event *alloc_event(struct ordered_events *oe)
+{
+   struct list_head *cache = >cache;
+   struct ordered_event *new = NULL;
+
+   if (!list_empty(cache)) {
+   new = list_entry(cache->next, struct ordered_event, list);
+   list_del(>list);
+   } else if (oe->buffer) {
+   new = oe->buffer + oe->buffer_idx;
+   if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
+   oe->buffer = NULL;
+   } else if (oe->cur_alloc_size < oe->max_alloc_size) {
+   size_t size = MAX_SAMPLE_BUFFER * sizeof(*new);
+
+   oe->buffer = malloc(size);
+   if (!oe->buffer)
+   return NULL;
+
+   oe->cur_alloc_size += size;
+   list_add(>buffer->list, >to_free);
+
+   /* First entry is abused to maintain the to_free list. */
+   oe->buffer_idx = 2;
+   new = oe->buffer + 1;
+   }
+
+   return new;
+}
+
+struct ordered_event *
+ordered_events__new(struct ordered_events *oe, u64 timestamp)
+{
+   struct ordered_event *new;
+
+   new = alloc_event(oe);
+   if (new) {
+   new->timestamp = timestamp;
+   queue_event(oe, new);
+ 

[tip:perf/core] perf tools: Rename ordered_events members

[tip-bot for Jiri Olsa]

Commit-ID:  fc12482f4f7ae5c6fca13922a1e0898ff9002aa6
Gitweb: http://git.kernel.org/tip/fc12482f4f7ae5c6fca13922a1e0898ff9002aa6
Author: Jiri Olsa 
AuthorDate: Mon, 9 Jun 2014 23:11:30 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:55 -0300

perf tools: Rename ordered_events members

Rename 'struct ordered_events' members to fit better the ordered events
style.

No functional change was intended.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-v0eb2hsmrxbolnoawu5fn...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/session.c | 86 +++
 tools/perf/util/session.h | 12 +++
 2 files changed, 48 insertions(+), 50 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 6570282..619778e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -75,8 +75,8 @@ struct perf_session *perf_session__new(struct perf_data_file 
*file,
goto out;
 
session->repipe = repipe;
-   INIT_LIST_HEAD(>ordered_events.samples);
-   INIT_LIST_HEAD(>ordered_events.sample_cache);
+   INIT_LIST_HEAD(>ordered_events.events);
+   INIT_LIST_HEAD(>ordered_events.cache);
INIT_LIST_HEAD(>ordered_events.to_free);
machines__init(>machines);
 
@@ -474,11 +474,11 @@ static int ordered_events__flush(struct perf_session *s,
 struct perf_tool *tool)
 {
struct ordered_events *oe = >ordered_events;
-   struct list_head *head = >samples;
+   struct list_head *head = >events;
struct ordered_event *tmp, *iter;
struct perf_sample sample;
u64 limit = oe->next_flush;
-   u64 last_ts = oe->last_sample ? oe->last_sample->timestamp : 0ULL;
+   u64 last_ts = oe->last ? oe->last->timestamp : 0ULL;
bool show_progress = limit == ULLONG_MAX;
struct ui_progress prog;
int ret;
@@ -487,7 +487,7 @@ static int ordered_events__flush(struct perf_session *s,
return 0;
 
if (show_progress)
-   ui_progress__init(, oe->nr_samples, "Processing time 
ordered events...");
+   ui_progress__init(, oe->nr_events, "Processing time 
ordered events...");
 
list_for_each_entry_safe(iter, tmp, head, list) {
if (session_done())
@@ -508,19 +508,17 @@ static int ordered_events__flush(struct perf_session *s,
 
oe->last_flush = iter->timestamp;
list_del(>list);
-   list_add(>list, >sample_cache);
-   oe->nr_samples--;
+   list_add(>list, >cache);
+   oe->nr_events--;
 
if (show_progress)
ui_progress__update(, 1);
}
 
-   if (list_empty(head)) {
-   oe->last_sample = NULL;
-   } else if (last_ts <= limit) {
-   oe->last_sample =
-   list_entry(head->prev, struct ordered_event, list);
-   }
+   if (list_empty(head))
+   oe->last = NULL;
+   else if (last_ts <= limit)
+   oe->last = list_entry(head->prev, struct ordered_event, list);
 
return 0;
 }
@@ -579,45 +577,45 @@ static int process_finished_round(struct perf_tool *tool,
 static void __queue_event(struct ordered_event *new, struct perf_session *s)
 {
struct ordered_events *oe = >ordered_events;
-   struct ordered_event *sample = oe->last_sample;
+   struct ordered_event *last = oe->last;
u64 timestamp = new->timestamp;
struct list_head *p;
 
-   ++oe->nr_samples;
-   oe->last_sample = new;
+   ++oe->nr_events;
+   oe->last = new;
 
-   if (!sample) {
-   list_add(>list, >samples);
+   if (!last) {
+   list_add(>list, >events);
oe->max_timestamp = timestamp;
return;
}
 
/*
-* last_sample might point to some random place in the list as it's
+* last event might point to some random place in the list as it's
 * the last queued event. We expect that the new event is close to
 * this.
 */
-   if (sample->timestamp <= timestamp) {
-   while (sample->timestamp <= timestamp) {
-   p = sample->list.next;
-   if (p == >samples) {
-   list_add_tail(>list, >samples);
+   if (last->timestamp <= timestamp) {
+   while (last->timestamp <= timestamp) {
+   p = last->list.next;
+   if (p == >events) {
+   list_add_tail(>list, >events);
oe->max_timestamp = timestamp;

[tip:perf/core] perf record: Honour --no-time command line option

[tip-bot for Andi Kleen]

Commit-ID:  8affc2b8c27bfc2d6e70827b746f490b62c44eaa
Gitweb: http://git.kernel.org/tip/8affc2b8c27bfc2d6e70827b746f490b62c44eaa
Author: Andi Kleen 
AuthorDate: Thu, 31 Jul 2014 14:45:04 +0800
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:00:03 -0300

perf record: Honour --no-time command line option

Time stamps are always implicitely enabled for record currently.  The
old --time/-T option is a nop.

Allow the user to disable timestamps by using --no-time, honouring the
existing option.

The defaults are unchanged.

Signed-off-by: Andi Kleen 
Cc: Andi Kleen 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: 
http://lkml.kernel.org/r/1406789104-25863-10-git-send-email-zheng.z@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 1 +
 tools/perf/util/evsel.c | 9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4869050..ca0251e 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -781,6 +781,7 @@ static const char * const record_usage[] = {
  */
 static struct record record = {
.opts = {
+   .sample_time = true,
.mmap_pages  = UINT_MAX,
.user_freq   = UINT_MAX,
.user_interval   = ULLONG_MAX,
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 21a373e..92e5235 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -633,9 +633,12 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts)
if (opts->period)
perf_evsel__set_sample_bit(evsel, PERIOD);
 
-   if (!perf_missing_features.sample_id_all &&
-   (opts->sample_time || !opts->no_inherit ||
-target__has_cpu(>target) || per_cpu))
+   /*
+* When the user explicitely disabled time don't force it here.
+*/
+   if (opts->sample_time &&
+   (!perf_missing_features.sample_id_all &&
+   (!opts->no_inherit || target__has_cpu(>target) || per_cpu)))
perf_evsel__set_sample_bit(evsel, TIME);
 
if (opts->raw_samples && !evsel->no_aux_samples) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Rename ordered_samples struct to ordered_events

[tip-bot for Jiri Olsa]

Commit-ID:  37e39aa8a8a42ad2fd72b7c7349115dad8297d9c
Gitweb: http://git.kernel.org/tip/37e39aa8a8a42ad2fd72b7c7349115dad8297d9c
Author: Jiri Olsa 
AuthorDate: Sun, 6 Jul 2014 14:23:03 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:55 -0300

perf tools: Rename ordered_samples struct to ordered_events

Following up with ordered_samples rename for ordered_samples and
sample_queue structs to ordered_events and ordered_event structs
respectively.

Also changing flush_sample_queue function name to ordered_events_flush.

No functional change was intended.

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-2dkrdvh0bbmzxdse437fc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-kvm.c  |   2 +-
 tools/perf/util/session.c | 118 +++---
 tools/perf/util/session.h |  10 ++--
 3 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index a05f435..258a527 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -785,7 +785,7 @@ static int perf_kvm__mmap_read(struct perf_kvm_stat *kvm)
 
/* flush queue after each round in which we processed events */
if (ntotal) {
-   kvm->session->ordered_samples.next_flush = flush_time;
+   kvm->session->ordered_events.next_flush = flush_time;
err = kvm->tool.finished_round(>tool, NULL, kvm->session);
if (err) {
if (kvm->lost_events)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index a2c97ff..6570282 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -75,9 +75,9 @@ struct perf_session *perf_session__new(struct perf_data_file 
*file,
goto out;
 
session->repipe = repipe;
-   INIT_LIST_HEAD(>ordered_samples.samples);
-   INIT_LIST_HEAD(>ordered_samples.sample_cache);
-   INIT_LIST_HEAD(>ordered_samples.to_free);
+   INIT_LIST_HEAD(>ordered_events.samples);
+   INIT_LIST_HEAD(>ordered_events.sample_cache);
+   INIT_LIST_HEAD(>ordered_events.to_free);
machines__init(>machines);
 
if (file) {
@@ -444,7 +444,7 @@ static perf_event__swap_op perf_event__swap_ops[] = {
[PERF_RECORD_HEADER_MAX]  = NULL,
 };
 
-struct sample_queue {
+struct ordered_event {
u64 timestamp;
u64 file_offset;
union perf_event*event;
@@ -453,14 +453,14 @@ struct sample_queue {
 
 static void perf_session_free_sample_buffers(struct perf_session *session)
 {
-   struct ordered_samples *os = >ordered_samples;
+   struct ordered_events *oe = >ordered_events;
 
-   while (!list_empty(>to_free)) {
-   struct sample_queue *sq;
+   while (!list_empty(>to_free)) {
+   struct ordered_event *event;
 
-   sq = list_entry(os->to_free.next, struct sample_queue, list);
-   list_del(>list);
-   free(sq);
+   event = list_entry(oe->to_free.next, struct ordered_event, 
list);
+   list_del(>list);
+   free(event);
}
 }
 
@@ -470,15 +470,15 @@ static int perf_session_deliver_event(struct perf_session 
*session,
  struct perf_tool *tool,
  u64 file_offset);
 
-static int flush_sample_queue(struct perf_session *s,
-  struct perf_tool *tool)
+static int ordered_events__flush(struct perf_session *s,
+struct perf_tool *tool)
 {
-   struct ordered_samples *os = >ordered_samples;
-   struct list_head *head = >samples;
-   struct sample_queue *tmp, *iter;
+   struct ordered_events *oe = >ordered_events;
+   struct list_head *head = >samples;
+   struct ordered_event *tmp, *iter;
struct perf_sample sample;
-   u64 limit = os->next_flush;
-   u64 last_ts = os->last_sample ? os->last_sample->timestamp : 0ULL;
+   u64 limit = oe->next_flush;
+   u64 last_ts = oe->last_sample ? oe->last_sample->timestamp : 0ULL;
bool show_progress = limit == ULLONG_MAX;
struct ui_progress prog;
int ret;
@@ -487,7 +487,7 @@ static int flush_sample_queue(struct perf_session *s,
return 0;
 
if (show_progress)
-   ui_progress__init(, os->nr_samples, "Processing time 
ordered events...");
+   ui_progress__init(, oe->nr_samples, "Processing time 
ordered events...");
 
list_for_each_entry_safe(iter, tmp, head, list) {
if (session_done())
@@ -506,20 +506,20 @@ static int flush_sample_queue(struct perf_session *s,

[tip:perf/core] perf tools: Add ordered_events__(new|delete) interface

[tip-bot for Jiri Olsa]

Commit-ID:  c64c7e1a5addf93b7dec98a27b8c48457506aa06
Gitweb: http://git.kernel.org/tip/c64c7e1a5addf93b7dec98a27b8c48457506aa06
Author: Jiri Olsa 
AuthorDate: Tue, 10 Jun 2014 21:58:02 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 12 Aug 2014 12:02:56 -0300

perf tools: Add ordered_events__(new|delete) interface

Adding new ordered events interface to new|delete event buffer:

  ordered_events__new- allocate event buffer from the cache
  ordered_events__delete - return event buffer to the cache

Signed-off-by: Jiri Olsa 
Acked-by: David Ahern 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-srwunsy7o5wl17vpt4a10...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/session.c | 169 +++---
 1 file changed, 98 insertions(+), 71 deletions(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 619778e..ff0188c 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -464,6 +464,100 @@ static void perf_session_free_sample_buffers(struct 
perf_session *session)
}
 }
 
+/* The queue is ordered by time */
+static void queue_event(struct ordered_events *oe, struct ordered_event *new)
+{
+   struct ordered_event *last = oe->last;
+   u64 timestamp = new->timestamp;
+   struct list_head *p;
+
+   ++oe->nr_events;
+   oe->last = new;
+
+   if (!last) {
+   list_add(>list, >events);
+   oe->max_timestamp = timestamp;
+   return;
+   }
+
+   /*
+* last event might point to some random place in the list as it's
+* the last queued event. We expect that the new event is close to
+* this.
+*/
+   if (last->timestamp <= timestamp) {
+   while (last->timestamp <= timestamp) {
+   p = last->list.next;
+   if (p == >events) {
+   list_add_tail(>list, >events);
+   oe->max_timestamp = timestamp;
+   return;
+   }
+   last = list_entry(p, struct ordered_event, list);
+   }
+   list_add_tail(>list, >list);
+   } else {
+   while (last->timestamp > timestamp) {
+   p = last->list.prev;
+   if (p == >events) {
+   list_add(>list, >events);
+   return;
+   }
+   last = list_entry(p, struct ordered_event, list);
+   }
+   list_add(>list, >list);
+   }
+}
+
+#define MAX_SAMPLE_BUFFER  (64 * 1024 / sizeof(struct ordered_event))
+static struct ordered_event *alloc_event(struct ordered_events *oe)
+{
+   struct list_head *cache = >cache;
+   struct ordered_event *new;
+
+   if (!list_empty(cache)) {
+   new = list_entry(cache->next, struct ordered_event, list);
+   list_del(>list);
+   } else if (oe->buffer) {
+   new = oe->buffer + oe->buffer_idx;
+   if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
+   oe->buffer = NULL;
+   } else {
+   oe->buffer = malloc(MAX_SAMPLE_BUFFER * sizeof(*new));
+   if (!oe->buffer)
+   return NULL;
+   list_add(>buffer->list, >to_free);
+
+   /* First entry is abused to maintain the to_free list. */
+   oe->buffer_idx = 2;
+   new = oe->buffer + 1;
+   }
+
+   return new;
+}
+
+static struct ordered_event *
+ordered_events__new(struct ordered_events *oe, u64 timestamp)
+{
+   struct ordered_event *new;
+
+   new = alloc_event(oe);
+   if (new) {
+   new->timestamp = timestamp;
+   queue_event(oe, new);
+   }
+
+   return new;
+}
+
+static void
+ordered_events__delete(struct ordered_events *oe, struct ordered_event *event)
+{
+   list_del(>list);
+   list_add(>list, >cache);
+   oe->nr_events--;
+}
+
 static int perf_session_deliver_event(struct perf_session *session,
  union perf_event *event,
  struct perf_sample *sample,
@@ -506,10 +600,8 @@ static int ordered_events__flush(struct perf_session *s,
return ret;
}
 
+   ordered_events__delete(oe, iter);
oe->last_flush = iter->timestamp;
-   list_del(>list);
-   list_add(>list, >cache);
-   oe->nr_events--;
 
if (show_progress)
ui_progress__update(, 1);
@@ -573,59 +665,10 @@ static int process_finished_round(struct perf_tool *tool,
return ret;
 

[tip:perf/core] perf evlist: Don't run workload if not told to

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  5f1c4225f6bcb20cc004b271dc72b96d0da29e9e
Gitweb: http://git.kernel.org/tip/5f1c4225f6bcb20cc004b271dc72b96d0da29e9e
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 28 Jul 2014 12:39:50 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 31 Jul 2014 09:57:20 -0300

perf evlist: Don't run workload if not told to

The perf_evlist__prepare_workload() method works by forking and then
waiting on a fd that must be written to to allow the workload to be
exec()ed.

But if the tool calling it fails to, say, set up the events with which
it wants to sample the workload for, it will not call
perf_evlist__start_workload(), but even in this case the workload ended
up running:

  [acme@zoo linux]$ trace /bin/echo workload ends up running, it should not...
  Couldn't mmap the events: Operation not permitted
  workload ends up running, it should not...
  [acme@zoo linux]$

So check if at least one byte was written before letting exec() be
called.

Now the expected behaviour:

  [acme@zoo linux]$ trace /bin/echo workload ends up running, it should not...
  Couldn't mmap the events: Operation not permitted
  [acme@zoo linux]$

Acked-by: Jiri Olsa 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Don Zickus 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Mike Galbraith 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-oh1ixo8m74rf295a05gfj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 814e954..3b366c0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1061,6 +1061,8 @@ int perf_evlist__prepare_workload(struct perf_evlist 
*evlist, struct target *tar
}
 
if (!evlist->workload.pid) {
+   int ret;
+
if (pipe_output)
dup2(2, 1);
 
@@ -1078,8 +1080,22 @@ int perf_evlist__prepare_workload(struct perf_evlist 
*evlist, struct target *tar
/*
 * Wait until the parent tells us to go.
 */
-   if (read(go_pipe[0], , 1) == -1)
-   perror("unable to read pipe");
+   ret = read(go_pipe[0], , 1);
+   /*
+* The parent will ask for the execvp() to be performed by
+* writing exactly one byte, in workload.cork_fd, usually via
+* perf_evlist__start_workload().
+*
+* For cancelling the workload without actuallin running it,
+* the parent will just close workload.cork_fd, without writing
+* anything, i.e. read will return zero and we just exit()
+* here.
+*/
+   if (ret != 1) {
+   if (ret == -1)
+   perror("unable to read pipe");
+   exit(ret);
+   }
 
execvp(argv[0], (char **)argv);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf tools: Fix arm64 build error

[tip-bot for Mark Salter]

Commit-ID:  7d885749b6de2c9a1168d566e2380207b9177108
Gitweb: http://git.kernel.org/tip/7d885749b6de2c9a1168d566e2380207b9177108
Author: Mark Salter 
AuthorDate: Fri, 25 Jul 2014 18:02:46 -0400
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Wed, 30 Jul 2014 12:37:55 -0300

perf tools: Fix arm64 build error

I'm seeing the following build error on arm64:

  In file included from util/event.c:3:0:
  util/event.h:95:17: error: 'PERF_REGS_MAX' undeclared here (not in a function)
u64 cache_regs[PERF_REGS_MAX];
 ^

This patch adds a PERF_REGS_MAX definition for arm64.

Signed-off-by: Mark Salter 
Acked-by: Jean Pihet 
Cc: Ingo Molnar 
Cc: Jean Pihet 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1406325766-8085-1-git-send-email-msal...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/arm64/include/perf_regs.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/arch/arm64/include/perf_regs.h 
b/tools/perf/arch/arm64/include/perf_regs.h
index e9441b9..1d3f39c 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -6,6 +6,8 @@
 #include 
 
 #define PERF_REGS_MASK ((1ULL << PERF_REG_ARM64_MAX) - 1)
+#define PERF_REGS_MAX  PERF_REG_ARM64_MAX
+
 #define PERF_REG_IPPERF_REG_ARM64_PC
 #define PERF_REG_SPPERF_REG_ARM64_SP
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/core] perf symbols: Make sure --symfs usage includes the path separator

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  972f393bc8870e236edbd2ea0150a8da85b709e2
Gitweb: http://git.kernel.org/tip/972f393bc8870e236edbd2ea0150a8da85b709e2
Author: Arnaldo Carvalho de Melo 
AuthorDate: Tue, 29 Jul 2014 10:21:58 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 31 Jul 2014 09:58:21 -0300

perf symbols: Make sure --symfs usage includes the path separator

Minchan reported that perf failed to load vmlinux if --symfs argument
doesn't end with '/' character.

Fix it by making sure that the '/' path separator is used when composing
pathnames with a --symfs provided directory name.

Reported-by: Minchan Kim 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Minchan Kim 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-8n4s6b6zvsez5ktanw006...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c |  9 +++--
 tools/perf/util/dso.c  | 28 +---
 tools/perf/util/symbol.c   |  3 +--
 tools/perf/util/symbol.h   |  9 +
 tools/perf/util/util.h | 16 
 5 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 809b4c5..7745fec 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -899,10 +899,8 @@ int symbol__annotate(struct symbol *sym, struct map *map, 
size_t privsize)
struct kcore_extract kce;
bool delete_extract = false;
 
-   if (filename) {
-   snprintf(symfs_filename, sizeof(symfs_filename), "%s%s",
-symbol_conf.symfs, filename);
-   }
+   if (filename)
+   symbol__join_symfs(symfs_filename, filename);
 
if (filename == NULL) {
if (dso->has_build_id) {
@@ -922,8 +920,7 @@ fallback:
 * DSO is the same as when 'perf record' ran.
 */
filename = (char *)dso->long_name;
-   snprintf(symfs_filename, sizeof(symfs_filename), "%s%s",
-symbol_conf.symfs, filename);
+   symbol__join_symfs(symfs_filename, filename);
free_filename = false;
}
 
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 90d02c66..bdafd30 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -37,6 +37,7 @@ int dso__read_binary_type_filename(const struct dso *dso,
 {
char build_id_hex[BUILD_ID_SIZE * 2 + 1];
int ret = 0;
+   size_t len;
 
switch (type) {
case DSO_BINARY_TYPE__DEBUGLINK: {
@@ -60,26 +61,25 @@ int dso__read_binary_type_filename(const struct dso *dso,
break;
 
case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
-   snprintf(filename, size, "%s/usr/lib/debug%s.debug",
-symbol_conf.symfs, dso->long_name);
+   len = __symbol__join_symfs(filename, size, "/usr/lib/debug");
+   snprintf(filename + len, size - len, "%s.debug", 
dso->long_name);
break;
 
case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
-   snprintf(filename, size, "%s/usr/lib/debug%s",
-symbol_conf.symfs, dso->long_name);
+   len = __symbol__join_symfs(filename, size, "/usr/lib/debug");
+   snprintf(filename + len, size - len, "%s", dso->long_name);
break;
 
case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
{
const char *last_slash;
-   size_t len;
size_t dir_size;
 
last_slash = dso->long_name + dso->long_name_len;
while (last_slash != dso->long_name && *last_slash != '/')
last_slash--;
 
-   len = scnprintf(filename, size, "%s", symbol_conf.symfs);
+   len = __symbol__join_symfs(filename, size, "");
dir_size = last_slash - dso->long_name + 2;
if (dir_size > (size - len)) {
ret = -1;
@@ -100,26 +100,24 @@ int dso__read_binary_type_filename(const struct dso *dso,
build_id__sprintf(dso->build_id,
  sizeof(dso->build_id),
  build_id_hex);
-   snprintf(filename, size,
-"%s/usr/lib/debug/.build-id/%.2s/%s.debug",
-symbol_conf.symfs, build_id_hex, build_id_hex + 2);
+   len = __symbol__join_symfs(filename, size, 
"/usr/lib/debug/.build-id/");
+   snprintf(filename + len, size - len, "%.2s/%s.debug",
+build_id_hex, build_id_hex + 2);
break;
 
case DSO_BINARY_TYPE__VMLINUX:
case DSO_BINARY_TYPE__GUEST_VMLINUX:
case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
-   snprintf(filename, size, "%s%s",
-symbol_conf.symfs, dso->long_name);
+   __symbol__join_symfs(filename, size, dso->long_name);
 

[tip:perf/core] perf kvm stat: Properly show submicrosecond times

[tip-bot for Christian Borntraeger]

Commit-ID:  b048a24cc8f29dce1bad564aaeb8680020d3701c
Gitweb: http://git.kernel.org/tip/b048a24cc8f29dce1bad564aaeb8680020d3701c
Author: Christian Borntraeger 
AuthorDate: Thu, 31 Jul 2014 13:13:51 +0200
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Sat, 2 Aug 2014 10:21:11 -0300

perf kvm stat: Properly show submicrosecond times

For lots of exits the min time (and sometimes max) is 0 or 1. Lets
increase the accurancy similar to what the average field alread does.

Signed-off-by: Christian Borntraeger 
Acked-by: David Ahern 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Paolo Bonzini 
Cc: k...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1406805231-10675-2-git-send-email-borntrae...@de.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-kvm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 43367eb..fe92dfd 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -592,8 +592,8 @@ static void print_result(struct perf_kvm_stat *kvm)
pr_info("%9s ", "Samples%");
 
pr_info("%9s ", "Time%");
-   pr_info("%10s ", "Min Time");
-   pr_info("%10s ", "Max Time");
+   pr_info("%11s ", "Min Time");
+   pr_info("%11s ", "Max Time");
pr_info("%16s ", "Avg time");
pr_info("\n\n");
 
@@ -610,8 +610,8 @@ static void print_result(struct perf_kvm_stat *kvm)
pr_info("%10llu ", (unsigned long long)ecount);
pr_info("%8.2f%% ", (double)ecount / kvm->total_count * 100);
pr_info("%8.2f%% ", (double)etime / kvm->total_time * 100);
-   pr_info("%8" PRIu64 "us ", min / 1000);
-   pr_info("%8" PRIu64 "us ", max / 1000);
+   pr_info("%9.2fus ", (double)min / 1e3);
+   pr_info("%9.2fus ", (double)max / 1e3);
pr_info("%9.2fus ( +-%7.2f%% )", (double)etime / ecount/1e3,
kvm_event_rel_stddev(vcpu, event));
pr_info("\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/33] perf record: Allow the user to disable time stamps

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Em Tue, Aug 12, 2014 at 04:58:19PM +0200, Ingo Molnar escreveu:
> > * Arnaldo Carvalho de Melo  wrote:
> > > Em Tue, Aug 05, 2014 at 08:08:56AM +0200, Ingo Molnar escreveu:
> > > > This patch looks dangerous and misleading to me.
> 
> > > I took it more from the angle: hey, it fixes a regression, i.e. 
> > > -T/--time somehow became a noop, and also it doesn't change any 
> > > default.
> 
> > > It also states that you will get misaccounting, why that would 
> > > happen, althought wording could've been better, as mmaps won't be 
> > > "missing", i.e. they will be there as this governs just 
> > > PERF_SAMPLE_TIME, not perf_event_attr.mmap, so it MMAPs may come 
> > > after samples for its maps.
> 
> > > So, I took it.
> 
> > > How should we proceed?
> 
> > I'd be fine with applying the patch and fixing the misleading 
> > changelog.
> 
> Done:
> 
> https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core=8affc2b8c27bfc2d6e70827b746f490b62c44eaa
> 
> Consider now pulling the perf-core-for-mingo tag there, I updated it
> after updating the changelog for this specific commit, all the
> rest is the same as in the previous pull req.

Pulled into tip:perf/core, thanks a lot Arnaldo!

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arch: Kconfig: Let all little endian architectures define CPU_LITTLE_ENDIAN explicitly

[Sam Ravnborg]

On Wed, Aug 13, 2014 at 06:48:35AM +0800, Chen Gang wrote:
> x86 and ia64 are always little endian. And another architectures may be
> little endian: mips, sh, powerpc, and m32r (may mark CPU_LITTLE_ENDIAN
> explicitly); also arm(64) and c6x (which may be !CPU_BIG_ENDIAN).
> 
> Some drivers (e.g. some of "drivers/isdn/hisax") may only support little
> endian (CPU_LITTLE_ENDIAN), and some drivers may only support big endian
> (!CPU_LITTLE_ENDIAN).
> 
> So export all little endian architectures within kernel wide, so can let
> Kconfig easier for the modules which only support little endian or only
> for big endian (assume !CPU_LITTLE_ENDIAN is same as CPU_BIG_ENDIAN).
We need to cover three cases here:
- An arch supports only little endian
- An arch supports only big endian
- An arch may be both little and big endian

The solution you suggest assumes that an arch is either little or big endian.
But we cannot ignore the hybriads that can do both.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] memblock, memhotplug: Fix wrong type in memblock_find_in_range_node().

[tangchen]

On 08/13/2014 06:03 AM, Andrew Morton wrote:

On Sun, 10 Aug 2014 14:12:03 +0800 Tang Chen  wrote:


In memblock_find_in_range_node(), we defeind ret as int. But it shoule
be phys_addr_t because it is used to store the return value from
__memblock_find_range_bottom_up().

The bug has not been triggered because when allocating low memory near
the kernel end, the "int ret" won't turn out to be minus. When we started
to allocate memory on other nodes, and the "int ret" could be minus.
Then the kernel will panic.

A simple way to reproduce this: comment out the following code in numa_init(),

 memblock_set_bottom_up(false);

and the kernel won't boot.

Which kernel versions need this fix?


This bug has been in the kernel since v3.13-rc1.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 1/2] perf top: Fix -z option behavior

[Namhyung Kim]

Hi David,

On Tue, 12 Aug 2014 13:01:41 -0600, David Ahern wrote:
> On 8/12/14, 2:16 AM, Namhyung Kim wrote:
>> The current -z option does almost nothing.  It doesn't zero the
>> existing samples so that we can see profiles of exited process after
>> last refresh.  It seems it only affects annotation.
>>
>> This patch clears existing entries before processing if -z option is
>> given.  For this original decaying logic also moved before processing.
>
> This option was broken somewhere recently. I am on vacation for
> another week, so I can't do a git bisect myself but I recall it worked
> a year or so ago. Try v3.4 as a start point.

Are you sure?  I don't recall seeing any big change in this area so I
guess the problem existed since long time ago.  In fact I couldn't find
a logic to zero/clear out existing hist entries in a hists..

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Greetings

[Donald Shing Lam]

Greetings, may I ask if you would be eligible to pursue a business 
deal/proposal worth USD 28.5m with me if you don't mind? Let me know if you are 
interested.
Reply me via this e-mail:sssww1...@yahoo.com.hk

Donald Shing Lam.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] oops in cpufreq driver with AMD Kaveri CPU

[Viresh Kumar]

On 13 August 2014 00:24, Oleksandr Natalenko  wrote:
> Updated logs.

Also will it be possible for you to find the last working kernel after
which this
happened?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] namespace updates for v3.17-rc1

[Andy Lutomirski]

On Tue, Aug 12, 2014 at 9:17 PM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
>> On 08/05/2014 05:57 PM, Eric W. Biederman wrote:
>>
>> Sorry for catching this late.  I think this fix is likely to
>> unnecessarily break valid userspace due to an odd interaction.
>
> The code is correct and safe (no security issues), but yes a blind
> remount might hit a snag.
>
> If you can find a userspace application that matters I might care
> that a security fix breaks it.
>
> I think you have made a point that several more filesystems might
> be ok to not set nodev on (because we can not do anything to create
> device nodes on those filesystems).  I personally would prefer the much
> more paranoid approach of only allowing device nodes on a unprivileged
> mount if we have audited all of the code paths and know it is safe
> for device nodes to appear there.
>
> I don't actually think anyone cares ad remounts of filesystems like
> tmpfs, mqueue, sysfs, proc, ramfs are all quite rare.  Blind remounts
> are even rare.  The normal userspace utilities look at the appropriate
> version of /proc/mounts on remount.

Bind remounts are the only kind of remounts, because we've never
supported do_remount_sb in a user namespace.  So, if you want to
create some static content in your user namespace, the way to do it
is:

unshare(CLONE_NEWUSER | CLONE_NEWNS);
mount tmpfs somewhere;
write to the tmpfs;
mount("path to tmpfs", "path to tmpfs", nullptr, MS_REMOUNT | MS_BIND
| MS_RDONLY);

>
> These are not filesystems that a blind remount will likely be applied
> to.
>
> Furthermore there is work underway to prepare patches to allow
> "mount --bind -ro" to work as expected.  That will further reduce
> the pressure from blind remounts.

Not for example above.  It really does need the remount.

>
> If there is an actual regression of actual code I am happy to deal
> with it.  But having the MNT_NODEV on those mounts has been the case
> for a long time now and is not new (no regression).  This change just
> closed the security hole that allowed nodev to be removed.  And that
> security hole we need to have fixed.

Sandstorm does this.  (Well, it did until today.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] oops in cpufreq driver with AMD Kaveri CPU

[Viresh Kumar]

On 13 August 2014 00:24, Oleksandr Natalenko  wrote:
> Updated logs.
>
> Registered notifiers:
>
> ===
> pf@defiant:~$ cat /var/log/kern.log | grep "Registered transition notifier"
> Aug 12 21:50:13 defiant kernel: [3.081759] cpufreq: Registered transition
> notifier: 81590378, (81cb0ba0)
> ===
>
> Triggered notifiers:
>
> ===
> pf@defiant:~$ dmesg | grep CPUFREQ_NOTIFIER | awk '{ s = ""; for (i = 3; i <=
> NF; i++) s = s $i " "; print s }' | sort -u
> CPUFREQ_NOTIFIER: acpi_processor_ppc_notifier
> CPUFREQ_NOTIFIER: acpi_thermal_cpufreq_notifier
> CPUFREQ_NOTIFIER: cpufreq_stat_notifier_trans

I don't know why there are three lines here. The first two are registered
for policy-notifiers and not transition ones.

So, I think its just about cpufreq-stat's notifier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] oops in cpufreq driver with AMD Kaveri CPU

[Viresh Kumar]

On 12 August 2014 23:48, Oleksandr Natalenko  wrote:
> Hmm, looks like I've put pr_info to policy notifier instead of transition
> notifier. Will fix it now and post new logs.

That's why you should have copied the diff here, so that I could have
confirmed if what you have done is correct or not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Hibernate: save e820 table to snapshot header for comparison

[joeyli]

Hi Pavel, 

Thanks for your review, first!

On Tue, Aug 12, 2014 at 11:41:36AM +0200, Pavel Machek wrote:
> Hi!
> 
> > [7.374714] e820: Check memory region: [mem 
> > 0x0001-0x00187fff] usable
> > [7.378041] PM: Image mismatch: memory map changed
> > [7.381314] PM: Read 2398272 kbytes in 0.27 seconds (8882.48 MB/s)
> > [7.385476] PM: Error -1 resuming
> > [7.388730] PM: Failed to load hibernation image, recovering.
> > [7.688989] PM: Basic memory bitmaps freed
> 
> Nice!
> 
> > +int save_mem_chk_map(struct mementry *mem_chk_map)
> 
> I'd prefer _chk_ -> _check_
>

OK, I will change the naming.
 
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < e820.nr_map; i++) {
> > +   struct e820entry *ei = [i];
> > +
> > +   if (i > MEMCHKMAX)
> > +   break;
> 
> MEMCHKMAX -> MEM_CHECK_MAX?
> 
> What happens when there are more entries?
> 

Yes, the number 128 is from E820MAX, the legacy E820 BIOS limitation. My 
original thinking is keep
the size of swsusp_info in 4K then don't need change the swap accessing codes 
in swsusp_read() and
swsusp_write(). On the other hand, I have no machine that provides E820 entries 
more then 128.

hm but, yes, this is an magic number causes we didn't check the entries 
bigger than 128.
I will modify this patch to keep the pages of E820 table behind the swsusp_info 
header.

> > +bool check_mem_map(int mem_chk_entries, struct mementry *mem_chk_map)
> > +{
> > +   int i;
> > +   bool ret = true;
> > +
> > +   if (mem_chk_entries != e820.nr_map) {
> > +   pr_err("PM: memory check entry number %d:%d\n",
> > +   mem_chk_entries, e820.nr_map);
> > +   ret = false;
> > +   goto Print_map;
> > +   }
> 
> I'd change name to something like mem_map_matches() or mem_map_ok(),
> so that it is clear what true/false means.
> 
> Can you reduce ammount of gotos?
> 

OK, I will change naming and reduce goto.

> > +   for (i = 0; i < mem_chk_entries; i++) {
> > +   struct e820entry *ei = [i];
> > +
> > +   if (i > MEMCHKMAX)
> > +   break;
> > +
> > +   /* check regions not E820_RAM or E820_RESERVED_KERN */
> > +   if (ei->type != E820_RAM && ei->type != E820_RESERVED_KERN) {
> > +   if (mem_chk_map[i].addr != ei->addr ||
> > +   mem_chk_map[i].size != ei->size ||
> > +   mem_chk_map[i].type != ei->type) {
> > +   ret = false;
> > +   goto Print_map;
> > +   }
> > +   }
> 
> Why don't you check RAM and RESERVED_KERN, too? If those changed, we
> don't want to resume, either, right?
> 

The RESERVED_KERN is boot_params.hdr.setup_data, reserved by kernel for
PCI RomImage and extend e820 entries. The E820_RAM and E820_RESERVED_KERN 
are saved in hibernate snapshot image and will restore to appropriate page
frame. If hibernate can not restore data to the original page frame, then
whole hibernate resume process will be stop. So I think don't need check
RAM and RESERVED_KERN because image saved it.

> (Plus, you only check ei->type; you should check mem_chk_map[].type,
> too AFAICT).
>

Yes, thanks for your suggestion, I will also check type of mem_chk_map.
 
> Thanks,
>   Pavel

Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] PC, KVM, CMA: Fix regression caused by wrong get_order() use

[Alexey Kardashevskiy]

fc95ca7284bc54953165cba76c3228bd2cdb9591 claims that there is no
functional change but this is not true as it calls get_order() (which
takes bytes) where it should have called ilog2() and the kernel stops
on VM_BUG_ON().

This replaces get_order() with ilog2().

Suggested-by: Paul Mackerras 
Cc: Alexander Graf 
Cc: Aneesh Kumar K.V 
Cc: Joonsoo Kim 
Cc: Benjamin Herrenschmidt 
Cc: 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/kvm/book3s_hv_builtin.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 329d7fd..bfe9f01 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -101,7 +101,7 @@ struct kvm_rma_info *kvm_alloc_rma()
ri = kmalloc(sizeof(struct kvm_rma_info), GFP_KERNEL);
if (!ri)
return NULL;
-   page = cma_alloc(kvm_cma, kvm_rma_pages, get_order(kvm_rma_pages));
+   page = cma_alloc(kvm_cma, kvm_rma_pages, ilog2(kvm_rma_pages));
if (!page)
goto err_out;
atomic_set(>use_count, 1);
@@ -135,12 +135,12 @@ struct page *kvm_alloc_hpt(unsigned long nr_pages)
 {
unsigned long align_pages = HPT_ALIGN_PAGES;
 
-   VM_BUG_ON(get_order(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
+   VM_BUG_ON(ilog2(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
 
/* Old CPUs require HPT aligned on a multiple of its size */
if (!cpu_has_feature(CPU_FTR_ARCH_206))
align_pages = nr_pages;
-   return cma_alloc(kvm_cma, nr_pages, get_order(align_pages));
+   return cma_alloc(kvm_cma, nr_pages, ilog2(align_pages));
 }
 EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
 
-- 
2.0.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] namespace updates for v3.17-rc1

[Eric W. Biederman]

Andy Lutomirski  writes:

> On 08/05/2014 05:57 PM, Eric W. Biederman wrote:
>
> Sorry for catching this late.  I think this fix is likely to
> unnecessarily break valid userspace due to an odd interaction.

The code is correct and safe (no security issues), but yes a blind
remount might hit a snag.

If you can find a userspace application that matters I might care
that a security fix breaks it.

I think you have made a point that several more filesystems might
be ok to not set nodev on (because we can not do anything to create
device nodes on those filesystems).  I personally would prefer the much
more paranoid approach of only allowing device nodes on a unprivileged
mount if we have audited all of the code paths and know it is safe
for device nodes to appear there.

I don't actually think anyone cares ad remounts of filesystems like
tmpfs, mqueue, sysfs, proc, ramfs are all quite rare.  Blind remounts
are even rare.  The normal userspace utilities look at the appropriate
version of /proc/mounts on remount.

These are not filesystems that a blind remount will likely be applied
to.

Furthermore there is work underway to prepare patches to allow
"mount --bind -ro" to work as expected.  That will further reduce
the pressure from blind remounts.

If there is an actual regression of actual code I am happy to deal
with it.  But having the MNT_NODEV on those mounts has been the case
for a long time now and is not new (no regression).  This change just
closed the security hole that allowed nodev to be removed.  And that
security hole we need to have fixed.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] memory-hotplug: add sysfs zones_online_to attribute

[Zhang Zhen]

Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
2. If the memory block is in ZONE_MOVABLE, you can change it to
ZONE_NORMAL, but this memory block must be adjacent to ZONE_NORMAL.

With this patch, we can easy to know a memory block can be onlined to
which zone, and don't need to know the above two limits.

Updated the related Documentation.

Change v1 -> v2:
- optimize the implementation following Dave Hansen's suggestion

Signed-off-by: Zhang Zhen 
---
 Documentation/ABI/testing/sysfs-devices-memory |  8 
 Documentation/memory-hotplug.txt   |  4 +-
 drivers/base/memory.c  | 62 ++
 include/linux/memory_hotplug.h |  1 +
 mm/memory_hotplug.c|  2 +-
 5 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-devices-memory 
b/Documentation/ABI/testing/sysfs-devices-memory
index 7405de2..2b2a1d7 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -61,6 +61,14 @@ Users:   hotplug memory remove tools

http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils


+What:   /sys/devices/system/memory/memoryX/zones_online_to
+Date:   July 2014
+Contact:   Zhang Zhen 
+Description:
+   The file /sys/devices/system/memory/memoryX/zones_online_to
+   is read-only and is designed to show which zone this memory 
block can
+   be onlined to.
+
 What:  /sys/devices/system/memoryX/nodeY
 Date:  October 2009
 Contact:   Linux Memory Management list 
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 45134dc..5b34e33 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -155,6 +155,7 @@ Under each memory block, you can see 4 files:
 /sys/devices/system/memory/memoryXXX/phys_device
 /sys/devices/system/memory/memoryXXX/state
 /sys/devices/system/memory/memoryXXX/removable
+/sys/devices/system/memory/memoryXXX/zones_online_to

 'phys_index'  : read-only and contains memory block id, same as XXX.
 'state'   : read-write
@@ -170,6 +171,8 @@ Under each memory block, you can see 4 files:
 block is removable and a value of 0 indicates that
 it is not removable. A memory block is removable only if
 every section in the block is removable.
+'zones_online_to' : read-only: designed to show which zone this memory block
+   can be onlined to.

 NOTE:
   These directories/files appear after physical memory hotplug phase.
@@ -408,7 +411,6 @@ node if necessary.
   - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
 sysctl or new control file.
   - showing memory block and physical device relationship.
-  - showing memory block is under ZONE_MOVABLE or not
   - test and make it better memory offlining.
   - support HugeTLB page migration and offlining.
   - memmap removing at memory offline.
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index a2e13e2..b5d693f 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -373,10 +373,71 @@ static ssize_t show_phys_device(struct device *dev,
return sprintf(buf, "%d\n", mem->phys_device);
 }

+static int __zones_online_to(unsigned long end_pfn,
+   struct page *first_page, unsigned long nr_pages)
+{
+   struct zone *zone_next;
+
+   /*The mem block is the last block of memory.*/
+   if (!pfn_valid(end_pfn + 1))
+   return 1;
+   zone_next = page_zone(first_page + nr_pages);
+   if (zone_idx(zone_next) == ZONE_MOVABLE)
+   return 1;
+   return 0;
+}
+
+static ssize_t show_zones_online_to(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct memory_block *mem = to_memory_block(dev);
+   unsigned long start_pfn, end_pfn;
+   unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
+   struct page *first_page;
+   struct zone *zone, *zone_prev;
+
+   start_pfn = section_nr_to_pfn(mem->start_section_nr);
+   end_pfn = start_pfn + nr_pages;
+   first_page = pfn_to_page(start_pfn);
+
+   /*The block contains more than one zone can not be offlined.*/
+   if (!test_pages_in_a_zone(start_pfn, end_pfn))
+   return sprintf(buf, "none\n");
+
+   zone = page_zone(first_page);
+
+#ifdef CONFIG_HIGHMEM
+   if (zone_idx(zone) == ZONE_HIGHMEM) {
+   if (__zones_online_to(end_pfn, first_page, nr_pages))
+   return sprintf(buf, "%s %s\n",
+   zone->name, (zone + 1)->name);
+   }
+#else
+   if 

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[John Stultz]

On 08/12/2014 07:06 PM, Ben Hutchings wrote:
> On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
> [...]
>> The downsides here are many. The distros will probably hate this idea,
> I certainly hate the idea of adding another 32-bit port to Debian.
> I think that it's OK for traditional distros to say 'just upgrade to
> 64bit' while you solve the problem for 32-bit embedded systems where
> there's probably little demand for supporting multiple ABIs at once.

So I don't necessarily disagree, but if the rule really is "we don't
break userspace" we will need a solution that at least allows for
multiple ABIs from the kernel side, and we can then let distros chose if
they want to handle both or not.  Even in the embedded world, as usage
grows with things like Android, we're starting to see more strict needs
for ABI/platform stability (see the ARMv8 SWP discussion from last
month).  Fancy android based dashboard infotainment systems probably
want to both be 2038 safe and run today's unsafe applications (hoping
that they get upgraded eventually).


>
>>  as it requires rebuilding the world, and maintaining another legacy
>> architecture support. I’m also not completely sure how robust
>> multi-arch packaging is in the face of having to handle 3-4
>> architectures on one system.
> dpkg multiarch covers this just fine, while I believe RPM is limited to
> biarch.
>
>> On the kernel side, it also adds more complexity, where we have to add
>> even more complex compat support for 64bit systems to handle all the
>> various 32bit applications possible.
> [...]
>
> Didn't we need to do this already to support x32?  Have compat ioctls
> involving time been botched?
I'm not sure exactly what you mean here, but yea, its very much like
supporting something like x32, but its one more to the list and has to
be supported on both 32 and 64 architectures.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:timers/core] timekeeping: Fixup typo in update_vsyscall_old definition

[Tony Breeds]

On Tue, Aug 12, 2014 at 08:30:40AM -0700, John Stultz wrote:

> Thanks for pointing it out. I'll send a fix here shortly (though I only
> have the ppc64le toolchain handy, so forgive me if its not quite right).

/me pimps the kernel.org toolchains:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_powerpc64-linux.tar.xz

and gets back in his box.

Yours Tony


pgpu3TpovSj1r.pgp
Description: PGP signature

linux-next: Tree for Aug 13

[Stephen Rothwell]

Hi all,

Please do not add code intended for v3.18 until after v3.17-rc1 is
released.

Changes since 20140812:

*crickets*

Non-merge commits (relative to Linus' tree): 1630
 1296 files changed, 35584 insertions(+), 16939 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 220 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (c8d6637d0497 Merge tag 'modules-next-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux)
Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org 
backwards" error)
Merging kbuild-current/rc-fixes (dd5a6752ae7d firmware: Create directories for 
external firmware)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall)
Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement 
no longer needed)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (08a9c3c9afcf MIPS: OCTEON: make 
get_system_type() thread-safe)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging sparc/master (8bccf5b31318 sparc64: Fix pcr_ops initialization and 
usage bugs.)
Merging net/master (61dac43ee6be Merge branch 'bcmgenet')
Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs)
Merging sound-current/for-linus (e24aa0a4c5ac ALSA: hda/ca0132 - Don't try 
loading firmware at resume when already failed)
Merging pci-current/for-linus (9baa3c34ac4e PCI: Remove DEFINE_PCI_DEVICE_TABLE 
macro use)
Merging wireless/master (2da2c5854ed7 net: wireless: ipw2x00: ipw2200.c: 
Cleaning up missing null-terminate after strncpy call)
Merging driver-core.current/driver-core-linus (c489d98c8c81 Merge branch 
'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm)
Merging tty.current/tty-linus (c489d98c8c81 Merge branch 'for-linus' of 
git://ftp.arm.linux.org.uk/~rmk/linux-arm)
Merging usb.current/usb-linus (c489d98c8c81 Merge branch 'for-linus' of 
git://ftp.arm.linux.org.uk/~rmk/linux-arm)
Merging usb-gadget-fixes/fixes (a8a85b01d185 usb: musb/cppi41: call 
musb_ep_select() before accessing an endpoint's CSR)
CONFLICT (content): Merge conflict in drivers/usb/musb/musb_host.c
Merging usb-serial-fixes/usb-linus (19583ca584d6 Linux 3.16)
Merging staging.current/staging-linus (c309bfa9b481 Merge tag 
'for-linus-20140808' of git://git.infradead.org/linux-mtd)
Merging char-misc.current/char-misc-linus (c489d98c8c81 Merge branch 
'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm)
Merging input-current/for-linus (a6b48699ae50 Input: joystick - use get_cycles 
on ARMv8)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of 
generating multiple of 2**16 bytes)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree 
fixup machine function)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for

Re: [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder

[John Stultz]

On 08/12/2014 06:33 PM, j...@joshtriplett.org wrote:
> On Tue, Aug 12, 2014 at 05:08:53PM -0700, John Stultz wrote:
>> Also, just to clarify, as time related discussions can bring out a laundry
>> list of issues, I would like to focus this discussion on providing a 2038
>> solution for existing interfaces and applications in a way that ideally
>> doesn't require modifying application source code.  While there will be
>> plenty of places where applications have cast or stored time_t values
>> explicitly as longs, and for those applications, deep modifications will be
>> necessary. But I’d like to avoid getting into new-interface discussions,
>> like exporting ktime_t like nanosecond interfaces instead of timepsecs,
>> unifying time-stamping formats, or methods for avoiding leapseconds. Those
>> are all interesting issues, and I’d be up for discussing them separately,
>> but those issue apply equally to 32bit and 64bit systems, and really aren't
>> 2038 specific, so I think its best to separate them out.
> That's understandable.  However, I wonder to what extent we could
> support unmodified source code via libc wrappers (since code calling
> syscalls directly can't work completely unmodified), while using better
> interfaces for new syscalls.  Given syscalls written in terms of (for
> instance) nanoseconds rather than timespec values, it seems
> straightforward enough for libc to provide compatibility interfaces.

So we'd be then introducing new syscalls not just for 32bit but 64bit
systems as well, and its a fairly substantial list:
http://kernelnewbies.org/y2038

Again, I worry that just getting time_t to be 64bits is a big enough
problem to solve without trying to mix in interface preference
discussions along, adding totally new interfaces, coordinating all the
libcs out there to provide wrappers, and then deprecating the old
interfaces.

If there are more desirable interfaces wanted, I really think that needs
to be a separate topic from fixing the ones we have.


>
>> From discussions so far, it seems the preferred change to the userspace
>> interface is what I’ll call the “Large File” method, as it follows the
>> approach used for large file support:
>>
>> Create new 64bit time_t/timespec/timeval/etc variants for syscalls, while
>> preserving existing interfaces. This has some complexity around IOCTLs, but
>> that can mostly be handled by creating new ioctl numbers while preserving
>> the old ones. Since we’re only modifying time types, we’ll also need to add
>> compat versions for many of these syscalls for 64bit native systems.
>>
>> Libc then introduces versioned symbols, and a new compile options to allow
>> applications to be built for “large time”. New and old applications could
>> then share the same libc.
>>
>> The benefits of this approach is is simply and minimally extends the
>> current 32 bit environment, without any effect on existing applications
>> which continue to work. Most of the complexity is in the libc library and
>> its build environment.
>>
>> The downsides to this approach is that as it follows the large-file
>> approach, it has many of the same problems as large-file support, in that
>> the transition to large-file has been slow and is still ongoing. Also,
>> since this solution focuses on libc, there is also the problem of existing
>> 3rd party libraries, which have no way of knowing which sized time is being
>> used, will break. So all libraries that do anything with time will then
>> have to implement their own versioned interfaces. This approach also makes
>> it a little more difficult to audit that a system is 2038 safe, without
>> running it and looking for issues.
> If we go this route, we should also provide a "depends on EMBEDDED"
> Kconfig option that omits all of the compatibility support, for systems
> that have fully migrated to new userspace.

Right, though I think for any of the solutions, having methods to
actually remove support for the 2038 unsafe interfaces is important to
help ensure systems are completely converted.


>
>> A potential alternative I’d like to also propose is the “Libc Version Bump”
>> approach.
>>
>> Basically this is the same as the above, where the kernel provides both
>> legacy and new time_t related interfaces. However, the libc would make a
>> version break, migrating to using 64bit time_t types and syscalls. Legacy
>> applications would still work using the old glibc version, but this would
>> provide a stronger line in the sand between 2038 safe and unsafe
>> applications and libraries, making it easier to avoid mixing the two.
>> NetBSD developers discussed this same approach back in 2008 here:
>> https://mail-index.netbsd.org/tech-userlevel/2008/03/22/msg000231.html
>>
>> The downsides here is, for legacy application support, one would have to
>> have all the requisite legacy libraries also installed, which will add a
>> burden to distro vendors. However, this extra storage overhead would likely
>> be a positive motivator to 

Re: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

[Yoshihiro YUNOMAE]

Hi Elliot,

Thank you for your comment.

(2014/08/12 23:51), Elliott, Robert (Server Storage) wrote:




-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Yoshihiro YUNOMAE
Sent: Friday, 08 August, 2014 6:50 AM

...

Subject: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in
__scsi_print_sense()

A device name is output like "sda: Sense Key : Medium Error [current]"
in __scsi_print_sense(), but it should be "[sda] Sense Key : Medium Error
[current]" because other printk messages output a device name like "[sda]
foo."


...

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index c6a7a4a..a0e8159 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1470,7 +1470,7 @@ void __scsi_print_sense(struct scsi_device *sdev,
const char *name,
return;
}

-   sdev_printk(KERN_INFO, sdev, "%s: Sense Key : %s %s%s\n", name,
+   sdev_printk(KERN_INFO, sdev, "[%s] Sense Key : %s %s%s\n", name,
   scsi_sense_key_string(sshdr.sense_key),
   scsi_sense_type_string(),
   scsi_sense_format_string());




The callers of __scsi_print_sense do not always pass in a name
like "sda".  In fact, sd.c doesn't even call that function; its
sd_print_sense_hdr calls sd_printk (which prints name as "[%s]")
and scsi_show_sense_hdr.


OK, I understood.
Current Linux kernel also outputs ":" in __scsi_print_sense(),
so we should not change this.

Thanks,
Yoshihiro YUNOMOAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace

[Yoshihiro YUNOMAE]

Hi Douglas,

Thank you for your comment.

(2014/08/08 22:07), Douglas Gilbert wrote:

On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote:

Hi All,

This patch set introduces new traceevents in order to output
continuous error
messages. Current SCSI printk messages in upstream kernel can be
divided by and
mixed with other messages. Even if each error message has its device id,
sometimes we can easily be lost in mixed logs because the message's
device id
is separated from it's body. To avoid it, I'd like to use traceevents to
store error messages into the ftrace or perf buuffer, because traceevents
are atomically commited to the buffer.

In this patch set, all printk messages are removed based on a local
discussion with Hannes, but I think printk messages should be kept
because all
users don't enable traceevents and rsyslog can store as files.

However, if printk of logging branch is kept, the messages are
duplicate and
it can induce stack overflow by using local buffer(*1).

  (*1) https://lkml.org/lkml/2014/5/20/742

So, my suggestion is follows:

1) printk
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can check the
error
messages without any settings.

2) traceevents
To get the complete messages, we can use ftrace or perf (or something
on them).
Users can always understand correct messages, but they need to set up the
tracers.

This patch set is based on Hannes' logging branch:
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


[1/10] ~  [6/10]: just cleanup for logging branch
[7/10] ~ [10/10]: introduce new traceevents

Any comments are welcome!


In sg3_utils there are now string yielding equivalents
to the sense buffer "print" functions. They take a form
like this:
   char * get_sense_str(const unsigned char * sense_buffer,
int sb_len, int blen, char * b);

So this just does the hard work of decoding the sense buffer
(or saying it is invalid) the result of which it places in
buffer 'b'. And 'b' is returned (so this function can be in
the arguments of a driver's printing function).

Adding such string functions would give other parts of the
SCSI subsystem the capability of tailoring their own
messages that include sense data information.


Existing sense buffer "print" function could be kept and
implemented using the newer "_str" variants. Would that
be worth the trouble?


I have already sent the idea using local buffer on this February,
but it was rejected by James (*1). By using stack region for local
buffer, stack overflow can occur. So, I implemented this feature
to atomically output an error message with device information.

(*1) https://lkml.org/lkml/2014/5/20/742

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Idea: new parameter: save_boot_messages_to_a_file_on=/dev/sdb1

[積丹尼 Dan Jacobson]

Problem: boot messages fly off the screen before the kernel panic is reached.
Possible to write boot messages to a file on a USB stick?

Gentlemen, we all know what a hassle it can be to get all those error
messages that fly off your screen upon failed boots. One needs extra
equipment etc.

Well how about a new parameter that one could add there via typing "e"
in grub,

 linux /boot/vmlinuz... root=... ro single panic=333 
save_boot_messages_to_a_file_on=/dev/sdb1

Whereas normally the system would be just attempted to be booted, upon
seeing the "save_boot_messages_to_a_file_on=" parameter, the kernel's
first job would be to start writing copies of messages that it sends to
the screen to some file (default BOOTMES.TXT) on /dev/sdb1 , then
proceed to do the booting, making sure after writing its final stack
trace to the screen to then close that file and sync it to the disk
before giving up and starting the panic wait.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] I2C: Make I2C core able to be module when I2C_ACPI is selected.

[Lan Tianyu]

On 2014年08月13日 10:03, Wolfram Sang wrote:
> On Tue, Aug 12, 2014 at 12:53:21PM +0300, Mika Westerberg wrote:
>> On Mon, Aug 11, 2014 at 03:00:55PM +0800, Lan Tianyu wrote:
>>> Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI
>>> config) adds a new kernel config I2C_ACPI and make I2C core built in
>>> when the config is selected. This is wrong because distributions
>>> etc generally compile I2C as a module and the commit broken that.
>>> This patch is to make I2C core able to be a module when I2C_ACPI is
>>> selected. Original issue the commit da3c6647 tried to avoid will
>>> be fixed in ACPICA and it's rarely triggered during unloading module. 
>>>
>>> Signed-off-by: Lan Tianyu 
>>
>> I wonder if we can do
>>
>>  depends on I2C=y
>>
>> here? If I understand it right, then we only build the ACPI_I2C if I2C
>> is compiled into the kernel. That way the problem da3c6647 tried to
>> solve doens't re-appear.
>>
>> We can later on relax this once ACPICA has been fixed. Thoughts?
> 
> I had the same idea yet my travel to Chicago interrupted thinking about
> it further. Once I get rid of my jetlag, I'll have a closer look. Unless
> you already came up with the perfect solution until then, of course ;)
>

Hi Mika & Wolfram:
I have one concern about "depends on I2C=y". If distribution config
file selects I2C core as a module, the original code can enumerate I2C
slave devices from ACPI table. But now I2C_ACPI depends on I2C core
built in, the I2C module can't enumerate devices from ACPI table. This
maybe a regression for distribution?

-- 
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] namespace updates for v3.17-rc1

[Andy Lutomirski]

On 08/05/2014 05:57 PM, Eric W. Biederman wrote:
> 
> Linus,
> 
> Please pull the for-linus branch from the git tree:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
> for-linus
> 
>HEAD: 344470cac42e887e68cfb5bdfa6171baf27f1eb5 proc: Point /proc/mounts at 
> /proc/thread-self/mounts instead of /proc/self/mounts
> 
> This is a bunch of small changes built against 3.16-rc6.  The most
> significant change for users is the first patch which makes setns
> drmatically faster by removing unneded rcu handling.
> 
> The next chunk of changes are so that "mount -o remount,.." will not
> allow the user namespace root to drop flags on a mount set by the system
> wide root.  Aks this forces read-only mounts to stay read-only, no-dev
> mounts to stay no-dev, no-suid mounts to stay no-suid, no-exec mounts to
> stay no exec and it prevents unprivileged users from messing with a
> mounts atime settings.  I have included my test case as the last patch
> in this series so people performing backports can verify this change
> works correctly.
> 

Sorry for catching this late.  I think this fix is likely to
unnecessarily break valid userspace due to an odd interaction.

do_new_mount contains this:

if (user_ns != _user_ns) {
if (!(type->fs_flags & FS_USERNS_MOUNT)) {
put_filesystem(type);
return -EPERM;
}
/* Only in special cases allow devices from mounts
 * created outside the initial user namespace.
 */
if (!(type->fs_flags & FS_USERNS_DEV_MOUNT)) {
flags |= MS_NODEV;
mnt_flags |= MNT_NODEV | MNT_LOCK_NODEV;
}
}

This means that private tmpfs mounts end up with MNT_NODEV |
MNT_LOCK_NODEV.  Certainly the change from MNT_NODEV to MNT_LOCK_NODEV
is sensible *if MNT_NODEV made sense in the first place*.  But we didn't
have MNT_LOCK_NODEV in the past, so this well-intentioned code never
really worked.

This has a very strange effect: mounting a private tmpfs with all
default flags and then remounting with MS_REMOUNT | MS_BIND *without
MS_NODEV* will now fail.  I suspect that this practice is rather common,
since most likely no one ever paid attention to that implicit MNT_NODEV
before.

I would argue that the correct fix is to either remove the implicit
MNT_NODEV entirely or to set FS_USERNS_DEV_MOUNT on most filesystems.

The relevant filesystems are tmpfs, mqueue, sysfs, proc, ramfs, and
devpts.  devpts already sets FS_USERNS_DEV_MOUNT.  Setting
FS_USERNS_DEV_MOUNT should be safe on all of the others in this list --
I think that the only one that initially contains device nodes is sysfs
on selinux systems, which contains a null node.

I think the point of this is to prevent mounts of filesystems with
user-controlled initial contents from being dangerous.  But we don't
have any of those yet.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc/sem.c: [RFC] memory barrier in sem_lock()

[Davidlohr Bueso]

On Tue, 2014-08-12 at 21:43 +0200, Manfred Spraul wrote:
> sem_lock right now contains an smp_mb().
> I think smp_rmb() would be sufficient - and performance of semop() with rmb()
> is up to 10% faster. It would be a pairing of rmb() with spin_unlock().
> 
> The race we must protect against is:
> 
> sem->lock is free
> sma->complex_count = 0
> sma->sem_perm.lock held by thread B
> 
> thread A:
> 
> A: spin_lock(>lock)
> 
>   B: sma->complex_count++; (now 1)
>   B: spin_unlock(>sem_perm.lock);
> 
> A: spin_is_locked(>sem_perm.lock);
> A: X which memory barrier is necessary?
> A: if (sma->complex_count == 0)
> 
> Thread A must read the increased complex_count value, i.e. the read must
> not be reordered with the read of sem_perm.lock done by spin_is_locked().
> 
> But that's it, there are no writes that must be ordered.

Looks right. You might also replace the current (useless) comment with
the patch's changelog, describing why the barrier is there.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/7] arm: use fixmap for text patching when text is RO

[Kees Cook]

On Tue, Aug 12, 2014 at 5:27 PM, Stephen Boyd  wrote:
> On 08/12/14 14:47, Kees Cook wrote:
>> On Tue, Aug 12, 2014 at 2:39 PM, Stephen Boyd  wrote:
>>> On 08/12/14 11:24, Kees Cook wrote:
 diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
 index 07314af47733..03dd4e39c833 100644
 --- a/arch/arm/kernel/patch.c
 +++ b/arch/arm/kernel/patch.c
 @@ -13,21 +16,69 @@ struct patch {
   unsigned int insn;
  };

 -void __kprobes __patch_text(void *addr, unsigned int insn)
 +static DEFINE_SPINLOCK(patch_lock);
 +
 +static void __kprobes *patch_map(void *addr, int fixmap, unsigned long 
 *flags)
 +{
 + unsigned int uintaddr = (uintptr_t) addr;
 + bool module = !core_kernel_text(uintaddr);
 + struct page *page;
 +
 + if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
 + page = vmalloc_to_page(addr);
 + else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
 + page = virt_to_page(addr);
 + else
 + return addr;
 +
 + if (flags)
 + spin_lock_irqsave(_lock, *flags);
 +
 + set_fixmap(fixmap, page_to_phys(page));
 +
 + return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
 +}
 +
 +static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
 +{
 + clear_fixmap(fixmap);
 +
 + if (flags)
 + spin_unlock_irqrestore(_lock, *flags);
 +}
>>> Has the kbuildbot complained about this one yet?
>>>
>>>   CHECK  arch/arm/kernel/patch.c
>>>   arch/arm/kernel/patch.c:47:39: warning: context imbalance in
>>> 'patch_unmap' - unexpected unlock
>>>
>>> I guess we're going to ignore it.
>> No, nothing yet from buildbot, let me do a sparse run -- I think we
>> can just add annotation and we'll be okay.
>>
>>
>
> Ok. I tried to move code around but sparse still complains because of
> conditional locking.

Oh, sorry! I should have mentioned I fixed this already. It just
requires some declarations. Here's how it looks now:

https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/commit/?h=arm/ro-nx=847a4a489d31b76797e7c7a78cd3e98c7948df4b

+static void __kprobes *patch_map(void *addr, int fixmap, unsigned long *flags)
+ __acquires(_lock)
+{
...
+ if (flags)
+ spin_lock_irqsave(_lock, *flags);
+ else
+ __acquire(_lock);

etc.

Thanks for poking at this!

-Kees

>
> ---8<---
>
> diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c
> index 03dd4e39c833..f6d4de3826a0 100644
> --- a/arch/arm/kernel/patch.c
> +++ b/arch/arm/kernel/patch.c
> @@ -18,33 +18,17 @@ struct patch {
>
>  static DEFINE_SPINLOCK(patch_lock);
>
> -static void __kprobes *patch_map(void *addr, int fixmap, unsigned long 
> *flags)
> +static struct page __kprobes *patch_page(void *addr)
>  {
> unsigned int uintaddr = (uintptr_t) addr;
> bool module = !core_kernel_text(uintaddr);
> -   struct page *page;
>
> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
> -   page = vmalloc_to_page(addr);
> +   return vmalloc_to_page(addr);
> else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
> -   page = virt_to_page(addr);
> -   else
> -   return addr;
> +   return virt_to_page(addr);
>
> -   if (flags)
> -   spin_lock_irqsave(_lock, *flags);
> -
> -   set_fixmap(fixmap, page_to_phys(page));
> -
> -   return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
> -}
> -
> -static void __kprobes patch_unmap(int fixmap, unsigned long *flags)
> -{
> -   clear_fixmap(fixmap);
> -
> -   if (flags)
> -   spin_unlock_irqrestore(_lock, *flags);
> +   return NULL;
>  }
>
>  void __kprobes __patch_text_real(void *addr, unsigned int insn, bool remap)
> @@ -54,10 +38,18 @@ void __kprobes __patch_text_real(void *addr, unsigned int 
> insn, bool remap)
> bool twopage = false;
> unsigned long flags;
> void *waddr = addr;
> +   struct page *page = NULL;
> int size;
>
> -   if (remap)
> -   waddr = patch_map(addr, FIX_TEXT_POKE0, );
> +   if (remap) {
> +   page = patch_page(addr);
> +   if (page) {
> +   spin_lock_irqsave(_lock, flags);
> +   set_fixmap(FIX_TEXT_POKE0, page_to_phys(page));
> +   waddr = (void *)(__fix_to_virt(FIX_TEXT_POKE0) +
> +   (uintaddr & ~PAGE_MASK));
> +   }
> +   }
>
> if (thumb2 && __opcode_is_thumb16(insn)) {
> *(u16 *)waddr = __opcode_to_mem_thumb16(insn);
> @@ -69,15 +61,25 @@ void __kprobes __patch_text_real(void *addr, unsigned int 
> insn, bool remap)
> u16 *addrh1 = waddr + 2;
>
> twopage = (uintaddr & ~PAGE_MASK) == PAGE_SIZE - 2;
> -   if (twopage && remap)

[PATCH v2] of: Deep-copy names of platform devices

[Stepan Moskovchenko]

When we parse the device tree and allocate platform
devices, the 'name' of the newly-created platform_device
is set to point to the 'name' field of the 'struct device'
embedded within the platform_device. This is dangerous,
because the name of the 'struct device' is dynamically
allocated. Drivers may call dev_set_name() on the device,
which will free and reallocate the name of the device,
leaving the 'name' of the platform_device pointing to the
now-freed memory.

Furthermore, if the dev_set_name() call is made from a
driver's probe() function and a subsequent request results
in probe deferral, the dangling 'name' reference may lead
to the device being re-probed using the wrong driver.

To mitigate these scenarios, we use kstrdup to perform a
deep copy of the device name when assigning the name of the
platform_device, so that the platform_device name is
unaffected by any calls to dev_set_name() that might made
by drivers to rename the embedded 'struct device'.

Signed-off-by: Stepan Moskovchenko 
---
* v2 - swap cleanup order

 drivers/of/device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index f685e55..e9beae6 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -54,7 +54,7 @@ int of_device_add(struct platform_device *ofdev)

/* name and id have to be set so that the platform bus doesn't get
 * confused on matching */
-   ofdev->name = dev_name(>dev);
+   ofdev->name = kstrdup(dev_name(>dev), GFP_KERNEL);
ofdev->id = -1;

/* device_add will assume that this device is on the same node as
@@ -75,6 +75,7 @@ EXPORT_SYMBOL(of_device_register);

 void of_device_unregister(struct platform_device *ofdev)
 {
+   kfree(ofdev->name);
device_unregister(>dev);
 }
 EXPORT_SYMBOL(of_device_unregister);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Jerome Glisse]

On Wed, Aug 13, 2014 at 04:04:15AM +0200, Mario Kleiner wrote:
> On 08/13/2014 03:50 AM, Michel Dänzer wrote:
> >On 12.08.2014 00:17, Jerome Glisse wrote:
> >>On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> >>>On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> >On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >>The other problem is that probably TTM does not reuse pages from the
> >>DMA pool. If i trace the __ttm_dma_alloc_page
> >>
> >>and
> >>__ttm_dma_free_page
> >>
> >>calls for
> >>those single page allocs/frees, then over a 20 second interval of
> >>tracing and switching tabs in firefox, scrolling things around etc. i
> >>find about as many alloc's as i find free's, e.g., 1607 allocs vs.
> >>1648 frees.
> >This is because historically the pools have been designed to keep only
> >pages with nonstandard caching attributes since changing page caching
> >attributes have been very slow but the kernel page allocators have been
> >reasonably fast.
> >
> >/Thomas
> Ok. A bit more ftraceing showed my hang problem case goes through the
> "if (is_cached)" paths, so the pool doesn't recycle anything and i see
> it bouncing up and down by 4 pages all the time.
> 
> But for the non-cached case, which i don't hit with my problem, could
> one of you look at line 954...
> 
> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c%23L954=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A=e15c51805d429ee6d8960d6b88035e9811a1cdbfbf13168eec2fbb2214b99c60
> 
> 
> ... and tell me why that unconditional npages = count; assignment
> makes sense? It seems to essentially disable all recycling for the dma
> pool whenever the pool isn't filled up to/beyond its maximum with free
> pages? When the pool is filled up, lots of stuff is recycled, but when
> it is already somewhat below capacity, it gets "punished" by not
> getting refilled? I'd just like to understand the logic behind that line.
> 
> thanks,
> -mario
> >>>I'll happily forward that question to Konrad who wrote the code (or it
> >>>may even stem from the ordinary page pool code which IIRC has Dave
> >>>Airlie / Jerome Glisse as authors)
> >>This is effectively bogus code, i now wonder how it came to stay alive.
> >>Attached patch will fix that.
> >I haven't tested Mario's scenario specifically, but it survived piglit
> >and the UE4 Effects Cave Demo (for which 1GB of VRAM isn't enough, so
> >some BOs ended up in GTT instead with write-combined CPU mappings) on
> >radeonsi without any noticeable issues.
> >
> >Tested-by: Michel Dänzer 
> >
> >
> 
> I haven't tested the patch yet. For the original bug it won't help directly,
> because the super-slow allocations which cause the desktop stall are
> tt_cached allocations, so they go through the if (is_cached) code path which
> isn't improved by Jerome's patch. is_cached always releases memory
> immediately, so the tt_cached pool just bounces up and down between 4 and 7
> pages. So this was an independent issue. The slow allocations i noticed were
> mostly caused by exa allocating new gem bo's, i don't know which path is
> taken by 3d graphics?
> 
> However, the fixed ttm path could indirectly solve the DMA_CMA stalls by
> completely killing CMA for its intended purpose. Typical CMA sizes are
> probably around < 100 MB (kernel default is 16 MB, Ubuntu config is 64 MB),
> and the limit for the page pool seems to be more like 50% of all system RAM?
> Iow. if the ttm dma pool is allowed to grow that big with recycled pages, it
> probably will almost completely monopolize the whole CMA memory after a
> short amount of time. ttm won't suffer stalls if it essentially doesn't
> interact with CMA anymore after a warmup period, but actual clients which
> really need CMA (ie., hardware without scatter-gather dma etc.) will be
> starved of what they need as far as my limited understanding of the CMA
> goes.

Yes currently we allow the pool to be way too big, given that pool was probably
never really use we most likely never had much of an issue. So i would hold on

Re: [PATCH v3] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

[Nicolas Pitre]

On Tue, 12 Aug 2014, Stephen Boyd wrote:

> Commit 1a6b69b6548c (ARM: gic: add CPU migration support,
> 2012-04-12) introduced an acquisition of the irq_controller_lock
> in gic_raise_softirq() which can lead to a spinlock recursion if
> the gic_arch_extn hooks call into the scheduler (via complete()
> or wake_up(), etc.). This happens because gic_arch_extn hooks are
> normally called with the irq_controller_lock held and calling
> into the scheduler may cause us to call smp_send_reschedule()
> which will grab the irq_controller_lock again. Here's an example
> from a vendor kernel (note that the gic_arch_extn hook code here
> isn't actually in mainline):
> 
> BUG: spinlock recursion on CPU#0, swapper/0/1
>  lock: irq_controller_lock+0x0/0x18, .magic: dead4ead, .owner: sw
> er_cpu: 0
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.10-00430-g3d433c4e
> 
> Call trace:
> [] dump_backtrace+0x0/0x140
> [] show_stack+0x10/0x1c
> [] dump_stack+0x74/0xc4
> [] spin_dump+0x78/0x88
> [] spin_bug+0x24/0x34
> [] do_raw_spin_lock+0x58/0x148
> [] _raw_spin_lock_irqsave+0x24/0x38
> [] gic_raise_softirq+0x2c/0xbc
> [] smp_send_reschedule+0x34/0x40
> [] try_to_wake_up+0x224/0x288
> [] default_wake_function+0xc/0x18
> [] __wake_up_common+0x50/0x8c
> [] __wake_up_locked+0x10/0x1c
> [] complete+0x3c/0x5c
> [] msm_mpm_enable_irq_exclusive+0x1b8/0x1c8
> [] __msm_mpm_enable_irq+0x4c/0x7c
> [] msm_mpm_enable_irq+0xc/0x18
> [] gic_unmask_irq+0x40/0x7c
> [] irq_enable+0x2c/0x48
> [] irq_startup+0x4c/0x74
> [] __setup_irq+0x264/0x3f0
> [] request_threaded_irq+0xcc/0x11c
> [] devm_request_threaded_irq+0x68/0xb4
> [] msm_iommu_ctx_probe+0x124/0x2d4
> [] platform_drv_probe+0x20/0x54
> [] driver_probe_device+0x158/0x340
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x6c/0x8c
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x120/0x204
> [] driver_register+0xbc/0x10c
> [] __platform_driver_register+0x5c/0x68
> [] msm_iommu_driver_init+0x54/0x7c
> [] do_one_initcall+0xa4/0x130
> [] kernel_init_freeable+0x138/0x1dc
> [] kernel_init+0xc/0xd4
> 
> We really just want to synchronize the sending of an SGI with the
> update of the gic_cpu_map[], so introduce a new SGI lock that we
> can use to synchronize the two code paths. Three main events are
> happening that we have to consider:
> 
>   1. We're updating the gic_cpu_mask to point to an incoming CPU
> 
>   2. We're (potentially) sending an SGI to the outgoing CPU
> 
>   3. We're redirecting any pending SGIs for the outgoing CPU to the
>  incoming CPU.
> 
> Events 1 and 3 are already ordered within the same CPU by means
> of program order and use of I/O accessors. Events 1 and 2 don't
> need to be ordered, but events 2 and 3 do because any SGIs for
> the outgoing CPU need to be pending before we can redirect them.
> Synchronize by acquiring a new lock around event 2 and before
> event 3. Use smp_mb__after_unlock_lock() before event 3 to ensure
> that event 1 is seen before event 3 on other CPUs that may be
> executing event 2. We put this all behind the b.L switcher config
> option so that if we're not using this feature we don't have to
> acquire any locks at all in the IPI path.
> 
> Cc: Nicolas Pitre 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/irqchip/irq-gic.c | 25 ++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 7c131cf7cc13..c1dc65209899 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -81,6 +81,11 @@ static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>  #define NR_GIC_CPU_IF 8
>  static u8 gic_cpu_map[NR_GIC_CPU_IF] __read_mostly;
>  
> +#ifdef CONFIG_BL_SWITCHER
> +/* Synchronize switching CPU interface and sending SGIs */
> +static DEFINE_RAW_SPINLOCK(gic_sgi_lock);

What about ...

#define sgi_map_lock(flags) raw_spin_lock_irqsave(_sgi_lock, flags)
#define sgi_map_unlock(flags) raw_spin_unlock_irqrestore(_sgi_lock, 
flags)
#else sgi_map_lock(flags) (void)(flags)
#define sgi_map_unlock(flags) (void)(flags)

That would avoid some #ifdefs in the main code.

> +#endif
> +
>  /*
>   * Supported arch specific GIC irq extension.
>   * Default make them NULL.
> @@ -656,9 +661,12 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
>  static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>  {
>   int cpu;
> - unsigned long flags, map = 0;
> + unsigned long map = 0;
> +#ifdef CONFIG_BL_SWITCHER
> + unsigned long flags;
>  
> - raw_spin_lock_irqsave(_controller_lock, flags);
> + raw_spin_lock_irqsave(_sgi_lock, flags);
> +#endif
>  
>   /* Convert our logical CPU mask into a physical one. */
>   for_each_cpu(cpu, mask)
> @@ -673,7 +681,9 @@ static void gic_raise_softirq(const struct cpumask *mask, 
> unsigned int irq)
>   /* this always happens on GIC0 */
>   writel_relaxed(map << 16 | irq, gic_data_dist_base(_data[0]) + 
> GIC_DIST_SOFTINT);
>  
> - 

Re: [PATCH 0/5] locks: move most locks_release_private calls outside of i_lock

[Stephen Rothwell]

Hi Jeff,

On Tue, 12 Aug 2014 19:47:36 -0400 Jeff Layton  
wrote:
>
> On Wed, 13 Aug 2014 08:28:27 +1000
> Stephen Rothwell  wrote:
> 
> > On Tue, 12 Aug 2014 10:48:08 -0400 Jeff Layton  
> > wrote:
> > >
> > > Absent any objections, I'll plan to merge these for 3.18.
> > 
> > This means that this patch set should *not* be in linux-next until after
> > (at least) v3.17-rc1 is released ...  This s reinforced by the lack of
> > Acked-by, Reviewed-by and Tested-by tags ... (the addition of which would
> > presumably require the rebase (or rewrite) of a published git tree.)
> 
> It would, but I sent a later reply that revised that statement.
> 
> Trond pointed out that this problem can cause a user-triggerable oops,
> so we may have to merge it for 3.17 after all. With that in mind, I
> added these to my linux-next branch and will probably send a pull
> request before the window closes (assuming that there are no glaring
> problems with it).

OK, fine.  I have merged it today in any case.

> While we're on the subject, we probably ought to rename my tree in your
> "Trees" file from "file-private-locks" to "file-locks" or something.
> File private locks (aka OFD locks) got merged in v3.15, but I have been
> collecting patches that touch fs/locks.c

OK, I will do that tomorrow.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

[Ben Hutchings]

On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
[...]
> The downsides here are many. The distros will probably hate this idea,

I certainly hate the idea of adding another 32-bit port to Debian.
I think that it's OK for traditional distros to say 'just upgrade to
64bit' while you solve the problem for 32-bit embedded systems where
there's probably little demand for supporting multiple ABIs at once.

>  as it requires rebuilding the world, and maintaining another legacy
> architecture support. I’m also not completely sure how robust
> multi-arch packaging is in the face of having to handle 3-4
> architectures on one system.

dpkg multiarch covers this just fine, while I believe RPM is limited to
biarch.

> On the kernel side, it also adds more complexity, where we have to add
> even more complex compat support for 64bit systems to handle all the
> various 32bit applications possible.
[...]

Didn't we need to do this already to support x32?  Have compat ioctls
involving time been botched?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

On 08/13/2014 03:50 AM, Michel Dänzer wrote:

On 12.08.2014 00:17, Jerome Glisse wrote:

On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:

On 08/10/2014 08:02 PM, Mario Kleiner wrote:

On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:

On 08/10/2014 05:11 AM, Mario Kleiner wrote:

The other problem is that probably TTM does not reuse pages from the
DMA pool. If i trace the __ttm_dma_alloc_page

and
__ttm_dma_free_page

calls for
those single page allocs/frees, then over a 20 second interval of
tracing and switching tabs in firefox, scrolling things around etc. i
find about as many alloc's as i find free's, e.g., 1607 allocs vs.
1648 frees.

This is because historically the pools have been designed to keep only
pages with nonstandard caching attributes since changing page caching
attributes have been very slow but the kernel page allocators have been
reasonably fast.

/Thomas

Ok. A bit more ftraceing showed my hang problem case goes through the
"if (is_cached)" paths, so the pool doesn't recycle anything and i see
it bouncing up and down by 4 pages all the time.

But for the non-cached case, which i don't hit with my problem, could
one of you look at line 954...

https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c%23L954=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A=e15c51805d429ee6d8960d6b88035e9811a1cdbfbf13168eec2fbb2214b99c60


... and tell me why that unconditional npages = count; assignment
makes sense? It seems to essentially disable all recycling for the dma
pool whenever the pool isn't filled up to/beyond its maximum with free
pages? When the pool is filled up, lots of stuff is recycled, but when
it is already somewhat below capacity, it gets "punished" by not
getting refilled? I'd just like to understand the logic behind that line.

thanks,
-mario

I'll happily forward that question to Konrad who wrote the code (or it
may even stem from the ordinary page pool code which IIRC has Dave
Airlie / Jerome Glisse as authors)

This is effectively bogus code, i now wonder how it came to stay alive.
Attached patch will fix that.

I haven't tested Mario's scenario specifically, but it survived piglit
and the UE4 Effects Cave Demo (for which 1GB of VRAM isn't enough, so
some BOs ended up in GTT instead with write-combined CPU mappings) on
radeonsi without any noticeable issues.

Tested-by: Michel Dänzer 




I haven't tested the patch yet. For the original bug it won't help 
directly, because the super-slow allocations which cause the desktop 
stall are tt_cached allocations, so they go through the if (is_cached) 
code path which isn't improved by Jerome's patch. is_cached always 
releases memory immediately, so the tt_cached pool just bounces up and 
down between 4 and 7 pages. So this was an independent issue. The slow 
allocations i noticed were mostly caused by exa allocating new gem bo's, 
i don't know which path is taken by 3d graphics?


However, the fixed ttm path could indirectly solve the DMA_CMA stalls by 
completely killing CMA for its intended purpose. Typical CMA sizes are 
probably around < 100 MB (kernel default is 16 MB, Ubuntu config is 64 
MB), and the limit for the page pool seems to be more like 50% of all 
system RAM? Iow. if the ttm dma pool is allowed to grow that big with 
recycled pages, it probably will almost completely monopolize the whole 
CMA memory after a short amount of time. ttm won't suffer stalls if it 
essentially doesn't interact with CMA anymore after a warmup period, but 
actual clients which really need CMA (ie., hardware without 
scatter-gather dma etc.) will be starved of what they need as far as my 
limited understanding of the CMA goes.


So fwiw probably the fix to ttm will increase the urgency for the CMA 
people to come up with a fix/optimization for the allocator. Unless it 
doesn't matter if most desktop systems have CMA disabled by default, and 
ttm is mostly used by desktop graphics drivers (nouveau, radeon, vmgfx)? 
I only stumbled over the problem because the Ubuntu 3.16 mainline 
testing kernels are compiled with CMA on.


-mario

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More 

Re: CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Jerome Glisse]

On Wed, Aug 13, 2014 at 10:50:25AM +0900, Michel Dänzer wrote:
> On 12.08.2014 00:17, Jerome Glisse wrote:
> > On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> >> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> >>> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
>  On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >
> > The other problem is that probably TTM does not reuse pages from the
> > DMA pool. If i trace the __ttm_dma_alloc_page
> > 
> > and
> > __ttm_dma_free_page
> > 
> > calls for
> > those single page allocs/frees, then over a 20 second interval of
> > tracing and switching tabs in firefox, scrolling things around etc. i
> > find about as many alloc's as i find free's, e.g., 1607 allocs vs.
> > 1648 frees.
>  This is because historically the pools have been designed to keep only
>  pages with nonstandard caching attributes since changing page caching
>  attributes have been very slow but the kernel page allocators have been
>  reasonably fast.
> 
>  /Thomas
> >>>
> >>> Ok. A bit more ftraceing showed my hang problem case goes through the
> >>> "if (is_cached)" paths, so the pool doesn't recycle anything and i see
> >>> it bouncing up and down by 4 pages all the time.
> >>>
> >>> But for the non-cached case, which i don't hit with my problem, could
> >>> one of you look at line 954...
> >>>
> >>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c%23L954=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A=e15c51805d429ee6d8960d6b88035e9811a1cdbfbf13168eec2fbb2214b99c60
> >>>
> >>>
> >>> ... and tell me why that unconditional npages = count; assignment
> >>> makes sense? It seems to essentially disable all recycling for the dma
> >>> pool whenever the pool isn't filled up to/beyond its maximum with free
> >>> pages? When the pool is filled up, lots of stuff is recycled, but when
> >>> it is already somewhat below capacity, it gets "punished" by not
> >>> getting refilled? I'd just like to understand the logic behind that line.
> >>>
> >>> thanks,
> >>> -mario
> >>
> >> I'll happily forward that question to Konrad who wrote the code (or it
> >> may even stem from the ordinary page pool code which IIRC has Dave
> >> Airlie / Jerome Glisse as authors)
> > 
> > This is effectively bogus code, i now wonder how it came to stay alive.
> > Attached patch will fix that.
> 
> I haven't tested Mario's scenario specifically, but it survived piglit
> and the UE4 Effects Cave Demo (for which 1GB of VRAM isn't enough, so
> some BOs ended up in GTT instead with write-combined CPU mappings) on
> radeonsi without any noticeable issues.
> 
> Tested-by: Michel Dänzer 
> 

My patch does not fix the cma bug, cma should not allocate single page into
it reserved contiguous memory. But cma is a broken technology in the first
place and it should not be enabled on x86 who ever did that is a moron.

So i would definitly encourage opening a bug against cma.

None the less ttm code was buggy too and this patch will fix that but will
only allieviate or delay the symptoms reported by Mario.

Cheers,
Jérôme

> 
> -- 
> Earthling Michel Dänzer|  http://www.amd.com
> Libre software enthusiast  |Mesa and X developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] I2C: Make I2C core able to be module when I2C_ACPI is selected.

[Wolfram Sang]

On Tue, Aug 12, 2014 at 12:53:21PM +0300, Mika Westerberg wrote:
> On Mon, Aug 11, 2014 at 03:00:55PM +0800, Lan Tianyu wrote:
> > Commit da3c6647(I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI
> > config) adds a new kernel config I2C_ACPI and make I2C core built in
> > when the config is selected. This is wrong because distributions
> > etc generally compile I2C as a module and the commit broken that.
> > This patch is to make I2C core able to be a module when I2C_ACPI is
> > selected. Original issue the commit da3c6647 tried to avoid will
> > be fixed in ACPICA and it's rarely triggered during unloading module. 
> > 
> > Signed-off-by: Lan Tianyu 
> 
> I wonder if we can do
> 
>   depends on I2C=y
> 
> here? If I understand it right, then we only build the ACPI_I2C if I2C
> is compiled into the kernel. That way the problem da3c6647 tried to
> solve doens't re-appear.
> 
> We can later on relax this once ACPICA has been fixed. Thoughts?

I had the same idea yet my travel to Chicago interrupted thinking about
it further. Once I get rid of my jetlag, I'll have a closer look. Unless
you already came up with the perfect solution until then, of course ;)



signature.asc
Description: Digital signature

[PATCH v2] zram: fix incorrectly stat with failed_reads

[Chao Yu]

Since we allocate a temporary buffer in zram_bvec_read to handle partial page
operations in this commit 924bd88d703e53d30f393fac6117f8f1bc79aab6 (Staging:
zram: allow partial page operations), our ->failed_reads value may be incorrect
as we do not increase its value when failed to allocate the temporary buffer.

Let's fix this issue and correct the annotation of failed_reads.

 v2: clean codes of failed_{reads,writes} stat pointed out by Minchan Kim, and
this cleanup also fix incorrectly stat when fail in zram_decompress_page.

Signed-off-by: Chao Yu 
---
 drivers/block/zram/zram_drv.c | 10 +++---
 drivers/block/zram/zram_drv.h |  2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index dfa4024..d00831c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -378,7 +378,6 @@ static int zram_decompress_page(struct zram *zram, char 
*mem, u32 index)
/* Should NEVER happen. Return bio error if it does. */
if (unlikely(ret)) {
pr_err("Decompression failed! err=%d, page=%u\n", ret, index);
-   atomic64_inc(>stats.failed_reads);
return ret;
}
 
@@ -547,8 +546,6 @@ out:
zcomp_strm_release(zram->comp, zstrm);
if (is_partial_io(bvec))
kfree(uncmem);
-   if (ret)
-   atomic64_inc(>stats.failed_writes);
return ret;
 }
 
@@ -566,6 +563,13 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec 
*bvec, u32 index,
ret = zram_bvec_write(zram, bvec, index, offset);
}
 
+   if (unlikely(ret)) {
+   if (rw == READ)
+   atomic64_inc(>stats.failed_reads);
+   else
+   atomic64_inc(>stats.failed_writes);
+   }
+
return ret;
 }
 
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 5b0afde..e0f725c 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -84,7 +84,7 @@ struct zram_stats {
atomic64_t compr_data_size; /* compressed size of pages stored */
atomic64_t num_reads;   /* failed + successful */
atomic64_t num_writes;  /* --do-- */
-   atomic64_t failed_reads;/* should NEVER! happen */
+   atomic64_t failed_reads;/* can happen when memory is too low */
atomic64_t failed_writes;   /* can happen when memory is too low */
atomic64_t invalid_io;  /* non-page-aligned I/O requests */
atomic64_t notify_free; /* no. of swap slot free notifications */
-- 
2.0.1.474.g72c7794


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question regarding drivers/staging/rtl8821ae/rtl8821ae/dm.c

[Greg Kroah-Hartman]

On Wed, Aug 13, 2014 at 01:06:16AM +0530, Himangi Saraogi wrote:
> Hi,
> 
> In the file, I see the code:
> 
> void rtl8821ae_dm_set_tx_ant_by_tx_
> info(...) {
>   ...
>   if ((rtlefuse->antenna_div_type == CG_TRX_HW_ANTDIV) ||
>       (rtlefuse->antenna_div_type == CG_TRX_HW_ANTDIV)){
>      SET_TX_DESC_TX_ANT(pdesc, pfat_table->antsel_a[mac_id]);
>   }
> }
> 
> Here, there is a double test. It seems the second test must be for
> CGCS_RX_HW_ANTDIV or CG_TRX_SMART_ANTDIV but am not sure. Is the second test
> just redundant or a different constant must be used?

No idea, try asking the original developers of the code (hint, almost
impossible...)

sorry,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

tvtuner pixelview B1000

[basteon]

hello.

I have pixelview B1000 card and this card won't work with assigned
modules cx8800, cx8802.

May be I'm use wrong modules or cardid prefix:
1554:4952, board: PixelView [card=3...

# /usr/bin/tvtime-scanner
Reading configuration from /etc/tvtime/tvtime.xml
Scanning using TV standard NTSC.
Scanning from  44.00 MHz to 958.00 MHz.
MHz:  - No signal

===
01:06.0 Multimedia video controller: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Subsystem: PROLINK Microsystems Corp Device 4952
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel modules: cx8800

01:06.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
PCI Video and Audio Decoder [Audio Port] (rev 05)
Subsystem: PROLINK Microsystems Corp Device 4952
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fc00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Kernel modules: cx88-alsa

01:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
PCI Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: PROLINK Microsystems Corp Device 4952
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Kernel modules: cx8802

===
[18334.495349] Linux video capture interface: v2.00
[18334.603004] IR NEC protocol handler initialized
[18334.614074] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded
[18334.618258] cx88[0]: subsystem: 1554:4952, board: PixelView
[card=3,autodetected], frontend(s): 0
[18334.618263] cx88[0]: TV tuner type 5, Radio tuner type -1
[18334.628915] IR RC5(x) protocol handler initialized
[18334.660809] IR RC6 protocol handler initialized
[18334.687047] IR JVC protocol handler initialized
[18334.714899] IR Sony protocol handler initialized
[18334.754031] lirc_dev: IR Remote Control driver registered, major 252
[18334.764669] IR LIRC bridge handler initialized
[18334.850358] cx88[0]/2: cx2388x 8802 Driver Manager
[18343.108212] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded
[18343.108317] cx8800 :01:06.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[18343.112467] cx88[0]: subsystem: 1554:4952, board: PixelView
[card=3,autodetected], frontend(s): 0
[18343.112473] cx88[0]: TV tuner type 5, Radio tuner type -1
[18343.312410] cx88[0]/0: found at :01:06.0, rev: 5, irq: 20,
latency: 32, mmio: 0xfd00
[18343.316831] cx88[0]/0: registered device video0 [v4l2]
[18343.326623] cx88[0]/0: registered device vbi0
[18343.333136] cx88[0]/0: registered device radio0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] zram: fix incorrectly stat with failed_reads

[Chao Yu]

Hi Minchan,

> -Original Message-
> From: Minchan Kim [mailto:minc...@kernel.org]
> Sent: Tuesday, August 12, 2014 3:38 PM
> To: Chao Yu
> Cc: ngu...@vflare.org; linux-kernel@vger.kernel.org; Jerome Marchand; Sergey 
> Senozhatsky;
> Andrew Morton
> Subject: Re: [PATCH] zram: fix incorrectly stat with failed_reads
> 
> On Mon, Aug 11, 2014 at 04:39:17PM +0800, Chao Yu wrote:
> > Since we allocate a temporary buffer in zram_bvec_read to handle partial 
> > page
> > operations in this commit 924bd88d703e53d30f393fac6117f8f1bc79aab6 (Staging:
> > zram: allow partial page operations), our ->failed_reads value may be 
> > incorrect
> > as we do not increase its value when failed to allocate the temporary 
> > buffer.
> >
> > Let's fix this issue and correct the annotation of failed_reads.

[snip]

> How abouting moving failed_reads/writes in zram_bvec_rw?
> 
> int zram_bvec_rw(..)
> {
> if (rw == READ) {
> atomic64_inc(num_reads);
> ret = zram_bvec_read(xxx);
> } else {
> atomic64_inc(_writes);
> ret = zram_bvec_write(xxx);
> }
> 
> if (unlikely(ret)) {
> if (rw == READ)
> atomic64_inc(failed_reads);
> else
> atomic64_inc(failed_writes);
> }
> }

I will send a v2 patch base on above codes of yours, please help to review the
following new patch.

> 
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> --
> Kind regards,
> Minchan Kim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Michel Dänzer]

On 12.08.2014 00:17, Jerome Glisse wrote:
> On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
>> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
>>> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
 On 08/10/2014 05:11 AM, Mario Kleiner wrote:
>
> The other problem is that probably TTM does not reuse pages from the
> DMA pool. If i trace the __ttm_dma_alloc_page
> 
> and
> __ttm_dma_free_page
> 
> calls for
> those single page allocs/frees, then over a 20 second interval of
> tracing and switching tabs in firefox, scrolling things around etc. i
> find about as many alloc's as i find free's, e.g., 1607 allocs vs.
> 1648 frees.
 This is because historically the pools have been designed to keep only
 pages with nonstandard caching attributes since changing page caching
 attributes have been very slow but the kernel page allocators have been
 reasonably fast.

 /Thomas
>>>
>>> Ok. A bit more ftraceing showed my hang problem case goes through the
>>> "if (is_cached)" paths, so the pool doesn't recycle anything and i see
>>> it bouncing up and down by 4 pages all the time.
>>>
>>> But for the non-cached case, which i don't hit with my problem, could
>>> one of you look at line 954...
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c%23L954=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A=e15c51805d429ee6d8960d6b88035e9811a1cdbfbf13168eec2fbb2214b99c60
>>>
>>>
>>> ... and tell me why that unconditional npages = count; assignment
>>> makes sense? It seems to essentially disable all recycling for the dma
>>> pool whenever the pool isn't filled up to/beyond its maximum with free
>>> pages? When the pool is filled up, lots of stuff is recycled, but when
>>> it is already somewhat below capacity, it gets "punished" by not
>>> getting refilled? I'd just like to understand the logic behind that line.
>>>
>>> thanks,
>>> -mario
>>
>> I'll happily forward that question to Konrad who wrote the code (or it
>> may even stem from the ordinary page pool code which IIRC has Dave
>> Airlie / Jerome Glisse as authors)
> 
> This is effectively bogus code, i now wonder how it came to stay alive.
> Attached patch will fix that.

I haven't tested Mario's scenario specifically, but it survived piglit
and the UE4 Effects Cave Demo (for which 1GB of VRAM isn't enough, so
some BOs ended up in GTT instead with write-combined CPU mappings) on
radeonsi without any noticeable issues.

Tested-by: Michel Dänzer 


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] of: Deep-copy names of platform devices

[Stephen Boyd]

On 08/12/14 17:57, Stepan Moskovchenko wrote:
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index f685e55..3e116f6 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -54,7 +54,7 @@ int of_device_add(struct platform_device *ofdev)
>
>   /* name and id have to be set so that the platform bus doesn't get
>* confused on matching */
> - ofdev->name = dev_name(>dev);
> + ofdev->name = kstrdup(dev_name(>dev), GFP_KERNEL);
>   ofdev->id = -1;
>
>   /* device_add will assume that this device is on the same node as
> @@ -76,6 +76,7 @@ EXPORT_SYMBOL(of_device_register);
>  void of_device_unregister(struct platform_device *ofdev)
>  {
>   device_unregister(>dev);
> + kfree(ofdev->name);

This probably ought to be swapped because we don't know if ofdev isn't
pointing to freed memory after device_unregister().

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] perf, x86: Add INST_RETIRED.PREC_DIST workarounds

[Andi Kleen]

From: Andi Kleen 

On Broadwell INST_RETIRED.PREC_DIST cannot be used with any period
that doesn't have the lowest 6 bits cleared. And the period
should not be smaller than 128.

Add a new callback to enforce this, and set it for Broadwell.

This is erratum BDM57 and BDM11.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event.c   |  3 +++
 arch/x86/kernel/cpu/perf_event.h   |  1 +
 arch/x86/kernel/cpu/perf_event_intel.c | 18 ++
 3 files changed, 22 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 0adc5e3..a0adf58 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -980,6 +980,9 @@ int x86_perf_event_set_period(struct perf_event *event)
if (left > x86_pmu.max_period)
left = x86_pmu.max_period;
 
+   if (x86_pmu.limit_period)
+   left = x86_pmu.limit_period(event, left);
+
per_cpu(pmc_prev_left[idx], smp_processor_id()) = left;
 
/*
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index de81627..a46e391 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -456,6 +456,7 @@ struct x86_pmu {
struct x86_pmu_quirk *quirks;
int perfctr_second_write;
boollate_ack;
+   unsigned(*limit_period)(struct perf_event *event, unsigned l);
 
/*
 * sysfs attrs
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index dd0ea95..db131b0 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2034,6 +2034,23 @@ hsw_get_event_constraints(struct cpu_hw_events *cpuc, 
struct perf_event *event)
return c;
 }
 
+/*
+ * Broadwell:
+ * The INST_RETIRED.ALL period always needs to have lowest
+ * 6bits cleared (BDM57). It shall not use a period smaller
+ * than 100 (BDM11). We combine the two to enforce
+ * a min-period of 128.
+ */
+static unsigned bdw_limit_period(struct perf_event *event, unsigned left)
+{
+   if ((event->hw.config & 0x) == 0x1c0) {
+   if (left < 128)
+   left = 128;
+   left &= ~0x3fu;
+   }
+   return left;
+}
+
 PMU_FORMAT_ATTR(event, "config:0-7");
 PMU_FORMAT_ATTR(umask, "config:8-15"   );
 PMU_FORMAT_ATTR(edge,  "config:18" );
@@ -2713,6 +2730,7 @@ __init int intel_pmu_init(void)
x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
x86_pmu.cpu_events = hsw_events_attrs;
+   x86_pmu.limit_period = bdw_limit_period;
pr_cont("Broadwell events, ");
break;
 
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] perf, x86: Add Broadwell core support

[Andi Kleen]

From: Andi Kleen 

Add Broadwell support for Broadwell Client to perf.
This is very similar to Haswell.  It uses a new cache event table,
because there were various changes there.

The constraint list has one new event that needs to be handled over Haswell.

The PEBS event list is the same, so we reuse Haswell's.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event_intel.c | 152 +
 1 file changed, 152 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index ef6c8b7..dd0ea95 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -220,6 +220,15 @@ static struct event_constraint 
intel_hsw_event_constraints[] = {
EVENT_CONSTRAINT_END
 };
 
+struct event_constraint intel_bdw_event_constraints[] = {
+   FIXED_EVENT_CONSTRAINT(0x00c0, 0),  /* INST_RETIRED.ANY */
+   FIXED_EVENT_CONSTRAINT(0x003c, 1),  /* CPU_CLK_UNHALTED.CORE */
+   FIXED_EVENT_CONSTRAINT(0x0300, 2),  /* CPU_CLK_UNHALTED.REF */
+   INTEL_UEVENT_CONSTRAINT(0x148, 0x4),/* L1D_PEND_MISS.PENDING */
+   INTEL_EVENT_CONSTRAINT(0xa3, 0x4),  /* CYCLE_ACTIVITY.* */
+   EVENT_CONSTRAINT_END
+};
+
 static u64 intel_pmu_event_map(int hw_event)
 {
return intel_perfmon_event_map[hw_event];
@@ -415,6 +424,126 @@ static __initconst const u64 snb_hw_cache_event_ids
 
 };
 
+static __initconst const u64 bdw_hw_cache_event_ids
+   [PERF_COUNT_HW_CACHE_MAX]
+   [PERF_COUNT_HW_CACHE_OP_MAX]
+   [PERF_COUNT_HW_CACHE_RESULT_MAX] =
+{
+ [ C(L1D ) ] = {
+   [ C(OP_READ) ] = {
+   [ C(RESULT_ACCESS) ] = 0x81d0,  /* MEM_UOPS_RETIRED.ALL_LOADS */
+   [ C(RESULT_MISS)   ] = 0x151,   /* L1D.REPLACEMENT */
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = 0x82d0,  /* MEM_UOPS_RETIRED.ALL_STORES 
*/
+   [ C(RESULT_MISS)   ] = 0x0,
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = 0x0,
+   [ C(RESULT_MISS)   ] = 0x0,
+   },
+ },
+ [ C(L1I ) ] = {
+   [ C(OP_READ) ] = {
+   [ C(RESULT_ACCESS) ] = 0x0,
+   [ C(RESULT_MISS)   ] = 0x280,   /* ICACHE.MISSES */
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = -1,
+   [ C(RESULT_MISS)   ] = -1,
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = 0x0,
+   [ C(RESULT_MISS)   ] = 0x0,
+   },
+ },
+ [ C(LL  ) ] = {
+   [ C(OP_READ) ] = {
+   /* OFFCORE_RESPONSE:ALL_DATA_RD|ALL_CODE_RD */
+   [ C(RESULT_ACCESS) ] = 0x1b7,
+   /* OFFCORE_RESPONSE:ALL_DATA_RD|ALL_CODE_RD|SUPPLIER_NONE|
+   L3_MISS|ANY_SNOOP */
+   [ C(RESULT_MISS)   ] = 0x1b7,
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = 0x1b7,   /* OFFCORE_RESPONSE:ALL_RFO */
+   /* OFFCORE_RESPONSE:ALL_RFO|SUPPLIER_NONE|L3_MISS|ANY_SNOOP */
+   [ C(RESULT_MISS)   ] = 0x1b7,
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = 0x0,
+   [ C(RESULT_MISS)   ] = 0x0,
+   },
+ },
+ [ C(DTLB) ] = {
+   [ C(OP_READ) ] = {
+   [ C(RESULT_ACCESS) ] = 0x81d0,  /* MEM_UOPS_RETIRED.ALL_LOADS */
+   [ C(RESULT_MISS)   ] = 0x108,   /* 
DTLB_LOAD_MISSES.MISS_CAUSES_A_WALK */
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = 0x82d0,  /* MEM_UOPS_RETIRED.ALL_STORES 
*/
+   [ C(RESULT_MISS)   ] = 0x149,   /* 
DTLB_STORE_MISSES.MISS_CAUSES_A_WALK */
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = 0x0,
+   [ C(RESULT_MISS)   ] = 0x0,
+   },
+ },
+ [ C(ITLB) ] = {
+   [ C(OP_READ) ] = {
+   [ C(RESULT_ACCESS) ] = 0x6085,  /* ITLB_MISSES.STLB_HIT */
+   [ C(RESULT_MISS)   ] = 0x185,   /* 
ITLB_MISSES.MISS_CAUSES_A_WALK */
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = -1,
+   [ C(RESULT_MISS)   ] = -1,
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = -1,
+   [ C(RESULT_MISS)   ] = -1,
+   },
+ },
+ [ C(BPU ) ] = {
+   [ C(OP_READ) ] = {
+   [ C(RESULT_ACCESS) ] = 0xc4,/* BR_INST_RETIRED.ALL_BRANCHES 
*/
+   [ C(RESULT_MISS)   ] = 0xc5,/* BR_MISP_RETIRED.ALL_BRANCHES 
*/
+   },
+   [ C(OP_WRITE) ] = {
+   [ C(RESULT_ACCESS) ] = -1,
+   [ C(RESULT_MISS)   ] = -1,
+   },
+   [ C(OP_PREFETCH) ] = {
+   [ C(RESULT_ACCESS) ] = -1,
+   [ C(RESULT_MISS)   ] = -1,
+   },
+ },
+};
+
+static __initconst const u64 bdw_hw_cache_extra_regs
+   [PERF_COUNT_HW_CACHE_MAX]
+

[PATCH 1/3] perf, x86: Remove incorrect model number from Haswell perf

[Andi Kleen]

From: Andi Kleen 

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event_intel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 2502d0d..ef6c8b7 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2541,7 +2541,6 @@ __init int intel_pmu_init(void)
 
case 60: /* Haswell Client */
case 70:
-   case 71:
case 63:
case 69:
x86_pmu.late_ack = true;
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] rtc: Remove duplicate const qualifier

[Pranith Kumar]

Remove a duplicate const qualifier

Signed-off-by: Pranith Kumar 
---
 arch/x86/kernel/rtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..fe3dbfe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -170,7 +170,7 @@ static struct platform_device rtc_device = {
 static __init int add_rtc_cmos(void)
 {
 #ifdef CONFIG_PNP
-   static const char * const  const ids[] __initconst =
+   static const char * const ids[] __initconst =
{ "PNP0b00", "PNP0b01", "PNP0b02", };
struct pnp_dev *dev;
struct pnp_id *id;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder

[Andy Lutomirski]

On Tue, Aug 12, 2014 at 6:33 PM,   wrote:
> On Tue, Aug 12, 2014 at 05:08:53PM -0700, John Stultz wrote:
>> Also, just to clarify, as time related discussions can bring out a laundry
>> list of issues, I would like to focus this discussion on providing a 2038
>> solution for existing interfaces and applications in a way that ideally
>> doesn't require modifying application source code.  While there will be
>> plenty of places where applications have cast or stored time_t values
>> explicitly as longs, and for those applications, deep modifications will be
>> necessary. But I’d like to avoid getting into new-interface discussions,
>> like exporting ktime_t like nanosecond interfaces instead of timepsecs,
>> unifying time-stamping formats, or methods for avoiding leapseconds. Those
>> are all interesting issues, and I’d be up for discussing them separately,
>> but those issue apply equally to 32bit and 64bit systems, and really aren't
>> 2038 specific, so I think its best to separate them out.
>
> That's understandable.  However, I wonder to what extent we could
> support unmodified source code via libc wrappers (since code calling
> syscalls directly can't work completely unmodified), while using better
> interfaces for new syscalls.  Given syscalls written in terms of (for
> instance) nanoseconds rather than timespec values, it seems
> straightforward enough for libc to provide compatibility interfaces.
>
>> From discussions so far, it seems the preferred change to the userspace
>> interface is what I’ll call the “Large File” method, as it follows the
>> approach used for large file support:
>>
>> Create new 64bit time_t/timespec/timeval/etc variants for syscalls, while
>> preserving existing interfaces. This has some complexity around IOCTLs, but
>> that can mostly be handled by creating new ioctl numbers while preserving
>> the old ones. Since we’re only modifying time types, we’ll also need to add
>> compat versions for many of these syscalls for 64bit native systems.
>>
>> Libc then introduces versioned symbols, and a new compile options to allow
>> applications to be built for “large time”. New and old applications could
>> then share the same libc.
>>
>> The benefits of this approach is is simply and minimally extends the
>> current 32 bit environment, without any effect on existing applications
>> which continue to work. Most of the complexity is in the libc library and
>> its build environment.
>>
>> The downsides to this approach is that as it follows the large-file
>> approach, it has many of the same problems as large-file support, in that
>> the transition to large-file has been slow and is still ongoing. Also,
>> since this solution focuses on libc, there is also the problem of existing
>> 3rd party libraries, which have no way of knowing which sized time is being
>> used, will break. So all libraries that do anything with time will then
>> have to implement their own versioned interfaces. This approach also makes
>> it a little more difficult to audit that a system is 2038 safe, without
>> running it and looking for issues.
>
> If we go this route, we should also provide a "depends on EMBEDDED"
> Kconfig option that omits all of the compatibility support, for systems
> that have fully migrated to new userspace.
>
>> A potential alternative I’d like to also propose is the “Libc Version Bump”
>> approach.
>>
>> Basically this is the same as the above, where the kernel provides both
>> legacy and new time_t related interfaces. However, the libc would make a
>> version break, migrating to using 64bit time_t types and syscalls. Legacy
>> applications would still work using the old glibc version, but this would
>> provide a stronger line in the sand between 2038 safe and unsafe
>> applications and libraries, making it easier to avoid mixing the two.
>> NetBSD developers discussed this same approach back in 2008 here:
>> https://mail-index.netbsd.org/tech-userlevel/2008/03/22/msg000231.html
>>
>> The downsides here is, for legacy application support, one would have to
>> have all the requisite legacy libraries also installed, which will add a
>> burden to distro vendors. However, this extra storage overhead would likely
>> be a positive motivator to get applications rebuilt and migrated to new
>> version. Additionally, for 3rd party libraries built against the new libc
>> version, the libraries may need to do a version bump themselves, in order
>> to be able to co-exist with versions built against the previous libc. This
>> approach also assumes that libraries that use time_t related values would
>> have a libc dependency.
>
> The migration pain here doesn't seem worth it at all.
>
>> A more aggressive version of the previous proposal is what I’m calling the
>> “New Virtual-Architecture” approach, basically extending the versioning
>> control from the linker down into the kernel as well.  It would be adding a
>> new “virtual-architecture” to the kernel, not entirely unlike how x32 is
>> supported 

Re: [Ksummit-discuss] (Resend) 2038 Kernel Summit Discussion Fodder

[josh]

On Tue, Aug 12, 2014 at 05:08:53PM -0700, John Stultz wrote:
> Also, just to clarify, as time related discussions can bring out a laundry
> list of issues, I would like to focus this discussion on providing a 2038
> solution for existing interfaces and applications in a way that ideally
> doesn't require modifying application source code.  While there will be
> plenty of places where applications have cast or stored time_t values
> explicitly as longs, and for those applications, deep modifications will be
> necessary. But I’d like to avoid getting into new-interface discussions,
> like exporting ktime_t like nanosecond interfaces instead of timepsecs,
> unifying time-stamping formats, or methods for avoiding leapseconds. Those
> are all interesting issues, and I’d be up for discussing them separately,
> but those issue apply equally to 32bit and 64bit systems, and really aren't
> 2038 specific, so I think its best to separate them out.

That's understandable.  However, I wonder to what extent we could
support unmodified source code via libc wrappers (since code calling
syscalls directly can't work completely unmodified), while using better
interfaces for new syscalls.  Given syscalls written in terms of (for
instance) nanoseconds rather than timespec values, it seems
straightforward enough for libc to provide compatibility interfaces.

> From discussions so far, it seems the preferred change to the userspace
> interface is what I’ll call the “Large File” method, as it follows the
> approach used for large file support:
> 
> Create new 64bit time_t/timespec/timeval/etc variants for syscalls, while
> preserving existing interfaces. This has some complexity around IOCTLs, but
> that can mostly be handled by creating new ioctl numbers while preserving
> the old ones. Since we’re only modifying time types, we’ll also need to add
> compat versions for many of these syscalls for 64bit native systems.
> 
> Libc then introduces versioned symbols, and a new compile options to allow
> applications to be built for “large time”. New and old applications could
> then share the same libc.
> 
> The benefits of this approach is is simply and minimally extends the
> current 32 bit environment, without any effect on existing applications
> which continue to work. Most of the complexity is in the libc library and
> its build environment.
> 
> The downsides to this approach is that as it follows the large-file
> approach, it has many of the same problems as large-file support, in that
> the transition to large-file has been slow and is still ongoing. Also,
> since this solution focuses on libc, there is also the problem of existing
> 3rd party libraries, which have no way of knowing which sized time is being
> used, will break. So all libraries that do anything with time will then
> have to implement their own versioned interfaces. This approach also makes
> it a little more difficult to audit that a system is 2038 safe, without
> running it and looking for issues.

If we go this route, we should also provide a "depends on EMBEDDED"
Kconfig option that omits all of the compatibility support, for systems
that have fully migrated to new userspace.

> A potential alternative I’d like to also propose is the “Libc Version Bump”
> approach.
> 
> Basically this is the same as the above, where the kernel provides both
> legacy and new time_t related interfaces. However, the libc would make a
> version break, migrating to using 64bit time_t types and syscalls. Legacy
> applications would still work using the old glibc version, but this would
> provide a stronger line in the sand between 2038 safe and unsafe
> applications and libraries, making it easier to avoid mixing the two.
> NetBSD developers discussed this same approach back in 2008 here:
> https://mail-index.netbsd.org/tech-userlevel/2008/03/22/msg000231.html
> 
> The downsides here is, for legacy application support, one would have to
> have all the requisite legacy libraries also installed, which will add a
> burden to distro vendors. However, this extra storage overhead would likely
> be a positive motivator to get applications rebuilt and migrated to new
> version. Additionally, for 3rd party libraries built against the new libc
> version, the libraries may need to do a version bump themselves, in order
> to be able to co-exist with versions built against the previous libc. This
> approach also assumes that libraries that use time_t related values would
> have a libc dependency.

The migration pain here doesn't seem worth it at all.

> A more aggressive version of the previous proposal is what I’m calling the
> “New Virtual-Architecture” approach, basically extending the versioning
> control from the linker down into the kernel as well.  It would be adding a
> new “virtual-architecture” to the kernel, not entirely unlike how x32 is
> supported on x86_64 systems.  We would create entirely new ABI and
> architecture name in the kernel (think something like “armllt” or
> 

Re: [PATCH 3/5] efi arm64: do not enter virtual mode in case booting with efi=noruntime or noefi

[Dave Young]

On 08/12/14 at 11:46am, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 07:10:20AM +0100, Dave Young wrote:
> > In case efi runtime disabled via noefi kernel cmdline 
> > arm64_enter_virtual_mode
> > should error out.
> > 
> > At the same time move early_memunmap(memmap.map, mapsize) to the beginning 
> > of
> > the function or it will leak early mem.
> > 
> > Signed-off-by: Dave Young 
> > ---
> >  arch/arm64/kernel/efi.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> > index e72f310..324cdd1 100644
> > --- a/arch/arm64/kernel/efi.c
> > +++ b/arch/arm64/kernel/efi.c
> > @@ -386,7 +386,10 @@ static int __init arm64_enter_virtual_mode(void)
> > int count = 0;
> > unsigned long flags;
> >  
> > -   if (!efi_enabled(EFI_BOOT)) {
> > +   mapsize = memmap.map_end - memmap.map;
> > +   early_memunmap(memmap.map, mapsize);
> > +
> > +   if (!efi_enabled(EFI_BOOT) || efi_runtime_disabled()) {
> 
> Hmm, is this right? We only set EFI_BOOT if we find EFI parameters in the
> DT (see efi_init -> uefi_init), so you run the risk of unmapping something
> we never mapped here.

Good catch, I missed the case. will fix it in next update

> 
> Furthermore, there seems to be a leak in uefi_init anyway, as we return
> -EINVAL if the signature of the EFI table doesn't match without unmapping it
> first.

Yes, will add a new patch to fix the error handling in uefi_init.

BTW, Matt, I forgot to cc Xen/SGI people, will send an update soon and cc them.

Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[LKP] [net] 8f61059a96c: +26.4% netperf.Throughput_Mbps

[kernel test robot]

FYI, we are glad to inform you that we noticed the below good changes on

commit 8f61059a96c2a29c1cc5a39dfe23d06ef5b4b065 ("net: sctp: improve timer 
slack calculation for transport HBs")

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  testbox/testcase/testparams
---  -  ---
 %stddev%change   %stddev
\  | /
  2586 ± 0% +11.1%   2873 ± 0%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
  1349 ± 2% +55.7%   2101 ± 1%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  3936 ± 0% +26.4%   4974 ± 0%  TOTAL netperf.Throughput_Mbps

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
170805 ±12%+398.9% 852164 ±14%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
170805 ±12%+398.9% 852164 ±14%  TOTAL cpuidle.C1-NHM.usage

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  4.18 ± 5%-100.0%   0.00 ± 0%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  4.18 ± 5%-100.0%   0.00 ± 0%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.mod_timer.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  3.06 ± 2% -98.4%   0.05 ± 0%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
  3.06 ± 2% -98.4%   0.05 ± 0%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.lock_timer_base.mod_timer.sctp_transport_reset_timers.sctp_outq_flush

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  4.31 ± 2% -99.3%   0.03 ± 0%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
 10.60 ± 2% -99.7%   0.03 ±14%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
 14.92 ± 2% -99.6%   0.06 ± 7%  TOTAL 
perf-profile.cpu-cycles.sctp_transport_timeout.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  4.42 ± 2% -99.5%   0.02 ±18%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  4.42 ± 2% -99.5%   0.02 ±18%  TOTAL 
perf-profile.cpu-cycles.lock_timer_base.isra.34.mod_timer.sctp_transport_reset_timers.sctp_outq_flush.sctp_outq_uncork

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  1.77 ± 4% -78.8%   0.38 ± 4%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  1.77 ± 4% -78.8%   0.38 ± 4%  TOTAL 
perf-profile.cpu-cycles.sctp_outq_flush.sctp_outq_uncork.sctp_cmd_interpreter.sctp_do_sm.sctp_assoc_bh_rcv

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
131114 ± 5% -71.1%  37873 ± 3%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
131114 ± 5% -71.1%  37873 ± 3%  TOTAL cpuidle.C1E-SNB.usage

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  14540720 ±17%+162.1%   38114453 ±15%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  14540720 ±17%+162.1%   38114453 ±15%  TOTAL cpuidle.C1-NHM.time

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  4.37 ± 1% +36.5%   5.96 ± 1%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
  3.42 ±11%+196.0%  10.11 ± 5%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  7.78 ± 5%+106.5%  16.07 ± 4%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock.free_one_page.__free_pages_ok.__free_pages.__free_kmem_pages

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
  4.04 ± 1% +32.3%   5.35 ± 1%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
  3.52 ±10%+174.1%   9.64 ± 6%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  7.56 ± 6% +98.3%  14.99 ± 4%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.get_page_from_freelist.__alloc_pages_nodemask.alloc_kmem_pages_node.kmalloc_large_node

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
 26132 ± 1% +45.8%  38103 ±25%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
 26132 ± 1% +45.8%  38103 ±25%  TOTAL 
numa-vmstat.node2.nr_file_pages

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
104532 ± 1% +45.8% 152358 ±25%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
104532 ± 1% +45.8% 152358 ±25%  TOTAL numa-meminfo.node2.FilePages

eb1ac820c61d0d8  8f61059a96c2a29c1cc5a39df  
---  -  
643556 ± 9% +56.2%1005209 ± 5%  
lkp-sbx04/netperf/300s-200%-10K-SCTP_STREAM_MANY
643556 ± 9% +56.2%1005209 ± 5%  TOTAL 

Re: [PATCH] Documentation: DocBook: Rename drm_stub.c to drm_drv.c cause 'make xmldocs' failed

[Fabio Estevam]

On Tue, Aug 12, 2014 at 2:30 PM, Randy Dunlap  wrote:
> This patch fixed 'make xmldocs' failed on linus's tree and
> linux-next as of 8th/Aug,2014.
>
> When drm merge for 3.17-rc1 happen,  a file was renamed from
> drm_stub.c to drm_drv.c.
> But Documentation/DocBook/drm.tmpl still have an old file name.
>
> Signed-off-by: Masanari Iida 
> Signed-off-by: Randy Dunlap 

Isn't the From field missing to indicate Masanari's authorship of this patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 07/20] x86/MSI: Use msi_chip instead of arch func to configure MSI/MSI-X

[Yijing Wang]

On 2014/8/13 3:09, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 12, 2014 at 03:26:00PM +0800, Yijing Wang wrote:
>> Introduce a new struct msi_chip apic_msi_chip instead of weak arch
>> functions to configure MSI/MSI-X in x86.
> 
> Why not 'x86_msi_ops' (see  arch/x86/kernel/x86_init.c)

Hi Konrad, I think currently lots of weak arch functions make MSI code
complex, we have following weak arch functions

arch_setup_msi_irqs
arch_setup_msi_irq
arch_msi_check_device
arch_teardown_msi_irqs
arch_teardown_msi_irq
arch_restore_msi_irqs
arch_msi_mask_irq
arch_msix_mask_irq

And Thierry Reding and Thomas Petazzoni introduce a new MSI chip infrastructure 
which
is used in arm platform now. Use msi_chip let us focus on implementing msi_chip 
ops functions(no need to implement all),
but now, we should know much of MSI enable flow, then override the weak 
functions.
I think use the unified MSI framework in all platforms is better.
Also this series is preparation to support Non-PCI MSI device use common MSI 
framework in linux. Non-PCI MSI devices
include hpet, dmar and the coming consolidator(introduced in ARM GICv3 spec, 
which is similar to MSI relay device).


Thanks!
Yijing.

>>
>> Signed-off-by: Yijing Wang 
>> ---
>>  arch/x86/include/asm/pci.h |1 +
>>  arch/x86/kernel/apic/io_apic.c |   20 
>>  2 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
>> index 0892ea0..878a06d 100644
>> --- a/arch/x86/include/asm/pci.h
>> +++ b/arch/x86/include/asm/pci.h
>> @@ -101,6 +101,7 @@ void native_teardown_msi_irq(unsigned int irq);
>>  void native_restore_msi_irqs(struct pci_dev *dev);
>>  int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>>unsigned int irq_base, unsigned int irq_offset);
>> +extern struct msi_chip *x86_msi_chip;
>>  #else
>>  #define native_setup_msi_irqs   NULL
>>  #define native_teardown_msi_irq NULL
>> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
>> index 2609dcd..eb8ab7c 100644
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -3077,24 +3077,25 @@ int setup_msi_irq(struct pci_dev *dev, struct 
>> msi_desc *msidesc,
>>  return 0;
>>  }
>>  
>> -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>> +int native_setup_msi_irqs(struct device *dev, int nvec, int type)
>>  {
>>  struct msi_desc *msidesc;
>>  unsigned int irq;
>>  int node, ret;
>> +struct pci_dev *pdev = to_pci_dev(dev);
>>  
>>  /* Multiple MSI vectors only supported with interrupt remapping */
>>  if (type == PCI_CAP_ID_MSI && nvec > 1)
>>  return 1;
>>  
>> -node = dev_to_node(>dev);
>> +node = dev_to_node(dev);
>>  
>> -list_for_each_entry(msidesc, >msi_list, list) {
>> +list_for_each_entry(msidesc, >msi_list, list) {
>>  irq = irq_alloc_hwirq(node);
>>  if (!irq)
>>  return -ENOSPC;
>>  
>> -ret = setup_msi_irq(dev, msidesc, irq, 0);
>> +ret = setup_msi_irq(pdev, msidesc, irq, 0);
>>  if (ret < 0) {
>>  irq_free_hwirq(irq);
>>  return ret;
>> @@ -3214,6 +3215,17 @@ int default_setup_hpet_msi(unsigned int irq, unsigned 
>> int id)
>>  }
>>  #endif
>>  
>> +struct msi_chip apic_msi_chip = {
>> +.setup_irqs = native_setup_msi_irqs,
>> +.teardown_irq = native_teardown_msi_irq,
>> +};
>> +
>> +struct msi_chip *arch_get_match_msi_chip(struct device *dev)
>> +{
>> +return x86_msi_chip;
>> +}
>> +
>> +struct msi_chip *x86_msi_chip = _msi_chip;
>>  #endif /* CONFIG_PCI_MSI */
>>  /*
>>   * Hypertransport interrupt support
>> -- 
>> 1.7.1
>>
> 
> .
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm64: smp: Update the topology masks before calling CPU_STARTING notifiers

[Rohit Vaswani]

Currently, the CPU_STARTING notifiers would observe an incorrect sibling
mask since the notifier chain is called before the topology masks are updated
for the new cpu.
Update the topology masks before calling the notifier chain to fix this
problem.

Signed-off-by: Rohit Vaswani 
---
 arch/arm/kernel/smp.c   | 4 ++--
 arch/arm64/kernel/smp.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada..0e2237c 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -363,12 +363,12 @@ asmlinkage void secondary_start_kernel(void)
if (smp_ops.smp_secondary_init)
smp_ops.smp_secondary_init(cpu);
 
+   smp_store_cpu_info(cpu);
+
notify_cpu_starting(cpu);
 
calibrate_delay();
 
-   smp_store_cpu_info(cpu);
-
/*
 * OK, now it's safe to let the boot CPU continue.  Wait for
 * the CPU migration code to notice that the CPU is online
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 3e2f5eb..4ae78fe 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -163,10 +163,10 @@ asmlinkage void secondary_start_kernel(void)
/*
 * Enable GIC and timers.
 */
-   notify_cpu_starting(cpu);
-
smp_store_cpu_info(cpu);
 
+   notify_cpu_starting(cpu);
+
/*
 * OK, now it's safe to let the boot CPU continue.  Wait for
 * the CPU migration code to notice that the CPU is online
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/