Re: [PATCH] perf stat: Do not show stats if workload fails

[Ingo Molnar]

* David Ahern  wrote:

> Currently perf-stat attempts to show counter stats even if the workload
> is bogus:
> 
> $ perf stat -- foo
> foo: No such file or directory
> 
>  Performance counter stats for 'foo':
> 
>task-clock
>context-switches
>cpu-migrations
>page-faults
>cycles
>stalled-cycles-frontend
>stalled-cycles-backend
>instructions
>branches
>branch-misses
> 
>0.009769943 seconds time elapsed
> 
> It is impossible to differentiate all the failure modes, but it seems
> reasonable that if the workload handling fails, perf-stat should not try
> to print stats.
> 
> With this change:
> 
> $ perf stat  -v -- foo
> Failed to start workload
> 
> Signed-off-by: David Ahern 
> Cc: Ingo Molnar 
> Cc: Stephane Eranian 

Nice!

Acked-by: Ingo Molnar 

Thanks,

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/

[PATCH 3/7] perf tools: Set event->header.misc to PERF_RECORD_MISC_GUEST_USER if machine is guest.

[Dongsheng Yang]

When we synthesize the mmap events of user space, if machine is guest, we should
set the event->header.misc to PERF_RECORD_MISC_GUEST_USER, rather than
PERF_RECORD_MISC_USER.

Signed-off-by: Dongsheng Yang 
---
 tools/perf/util/event.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index c75046f..2d90ed8 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -220,7 +220,10 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
/*
 * Just like the kernel, see __perf_event_mmap in 
kernel/perf_event.c
 */
-   event->header.misc = PERF_RECORD_MISC_USER;
+   if (machine__is_host(machine))
+   event->header.misc = PERF_RECORD_MISC_USER;
+   else
+   event->header.misc = PERF_RECORD_MISC_GUEST_USER;
 
if (prot[2] != 'x') {
if (!mmap_data || prot[0] != 'r')
-- 
1.8.2.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/

[PATCH 5/7] perf tools: Do not synthesize the treads of default guest.

[Dongsheng Yang]

As the default guest is designed to handle orphan kernel symboles
with --guestkallsysms and --guestmoudles, it has no user space. So we
should skip synthesizing threads if machine is default guest.

Signed-off-by: Dongsheng Yang 
---
 tools/perf/util/event.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 93c6701..598b73e 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -133,6 +133,9 @@ static pid_t perf_event__synthesize_comm(struct perf_tool 
*tool,
goto out;
}
 
+   if (machine__is_default_guest(machine))
+   return 0;
+
snprintf(filename, sizeof(filename), "%s/proc/%d/task",
 machine->root_dir, pid);
 
@@ -183,6 +186,9 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
FILE *fp;
int rc = 0;
 
+   if (machine__is_default_guest(machine))
+   return 0;
+
snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
 machine->root_dir, pid);
 
@@ -409,6 +415,9 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
if (mmap_event == NULL)
goto out_free_comm;
 
+   if (machine__is_default_guest(machine))
+   return 0;
+
snprintf(proc_path, sizeof(proc_path), "%s/proc", machine->root_dir);
proc = opendir(proc_path);
 
-- 
1.8.2.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/

[PATCH 7/7] perf tools: Add support of user space symbols for guest in perf kvm record.

[Dongsheng Yang]

# perf kvm --guestmount /tmp/guestmount/ record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.828 MB perf.data.guest (~36163 
samples) ]

# perf kvm --guestmount /tmp/guestmount/ report
Samples: 4K of event 'cycles', Event count (approx.): 2662750816
  8.67%  [guest/9217]  dd[u] 
0x4e90
  6.62%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] fget_light
  6.17%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] system_call
  5.97%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] 
__srcu_read_lock
  5.53%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] 
__srcu_read_unlock
  5.47%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] 
__audit_syscall_exit
  5.38%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] fsnotify
  5.32%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] 
system_call_after_swapgs
  4.45%  [guest/9217]  libc-2.17.so  [u] 
__GI___libc_write
  4.15%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] sys_write
  3.97%  [guest/9217]  [guest.kernel.kallsyms.9217]  [g] vfs_read
  3.78%  [guest/9217]  libc-2.17.so  [u] 
__GI___libc_read

Signed-off-by: Dongsheng Yang 
---
 tools/perf/builtin-record.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c1c1200..ac1e540 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -279,6 +279,9 @@ static void perf_event__synthesize_guest_os(struct machine 
*machine, void *data)
 {
int err;
struct perf_tool *tool = data;
+   struct perf_record *rec = container_of(tool, struct perf_record, tool);
+   struct perf_record_opts *opts = &rec->opts;
+   struct perf_evlist *evsel_list = rec->evlist;
/*
 *As for guest kernel when processing subcommand record&report,
 *we arrange module mmap prior to guest kernel mmap and trigger
@@ -305,6 +308,13 @@ static void perf_event__synthesize_guest_os(struct machine 
*machine, void *data)
if (err < 0)
pr_err("Couldn't record guest kernel [%d]'s reference"
   " relocation symbol.\n", machine->pid);
+
+   err = __machine__synthesize_threads(machine, tool, &opts->target, 
evsel_list->threads,
+   process_synthesized_event, 
opts->sample_address);
+
+   if (err < 0)
+   pr_err("Couldn't record guest userspace [%d]'s reference"
+  " relocation symbol.\n", machine->pid);
 }
 
 static struct perf_event_header finished_round_event = {
-- 
1.8.2.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/

[PATCH 6/7] perf tools: Add support of user space symbols for guest in perf kvm top.

[Dongsheng Yang]

# perf kvm --guestmount /tmp/guestmount/ top
Samples: 1K of event 'cycles', Event count (approx.): 259112905
 17.34%  libcrypto.so.1.0.1e  [u] 0x0007d971
  5.60%  [guest.kernel]   [g] kallsyms_expand_symbol
  5.44%  libcrypto.so.1.0.1e  [u] md5_block_asm_data_order
  4.09%  [guest.kernel]   [g] number.isra.1
  3.59%  [guest.kernel]   [g] vsnprintf
  3.52%  sshd [u] 0x000441c0
  2.37%  [guest.kernel]   [g] format_decode
  2.36%  [guest.kernel]   [g] memcpy
  2.11%  [guest.kernel]   [g] strnlen

Signed-off-by: Dongsheng Yang 
---
 tools/perf/builtin-top.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 03d37a7..670bd0b 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -821,11 +821,9 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
break;
case PERF_RECORD_MISC_GUEST_USER:
++top->guest_us_samples;
-   /*
-* TODO: we don't process guest user from host side
-* except simple counting.
-*/
-   /* Fall thru */
+   machine = perf_session__find_machine(session,
+sample.pid);
+   break;
default:
goto next_event;
}
@@ -912,6 +910,7 @@ static int __cmd_top(struct perf_top *top)
struct perf_record_opts *opts = &top->record_opts;
pthread_t thread;
int ret;
+   struct rb_node *nd;
 
top->session = perf_session__new(NULL, false, NULL);
if (top->session == NULL)
@@ -931,6 +930,12 @@ static int __cmd_top(struct perf_top *top)
 
machine__synthesize_threads(&top->session->machines.host, &opts->target,
top->evlist->threads, false);
+
+   for (nd = rb_first(&top->session->machines.guests); nd; nd = 
rb_next(nd)) {
+   struct machine *pos = rb_entry(nd, struct machine, rb_node);
+   machine__synthesize_threads(pos, &opts->target, 
top->evlist->threads, false);
+   }
+
ret = perf_top__start_counters(top);
if (ret)
goto out_delete;
-- 
1.8.2.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: checkpatch.pl error might be false positive

[Josh Triplett]

On Thu, Dec 19, 2013 at 02:15:48PM -0800, Joe Perches wrote:
> On Thu, 2013-12-19 at 13:01 -0800, Ravi Patel wrote:
> > My name is Ravi Patel and I am working for AppliedMicro.
> > I am planning to submit APM X-Gene SoC QMTM drivers to open source after
> > running checkpatch.pl
> > I am seeing following error saying remove FSF address from my patch, which
> > I don't have in my source/header files.
> > 
> > ERROR: Do not include the paragraph about writing to the Free Software
> > Foundation's mailing address from the sample GPL notice. The FSF has
> > changed addresses in the past, and may do so again. Linux already includes
> > a copy of the GPL.
> > #1580: FILE: include/misc/xgene/xgene_qmtm.h:19:
> > + * You should have received a copy of the GNU General Public License$
> > 
> > Here is my License banner in xgene_qmtm.h
> > There are no tabs in my banner
> > 
> > /*
> >  * AppliedMicro X-Gene SOC Queue Manager/Traffic Manager driver
> >  *
> >  * Copyright (c) 2013 Applied Micro Circuits Corporation.
> >  * Author: Ravi Patel 
> >  * Keyur Chudgar 
> >  * Fushen Chen 
> >  *
> >  * This program is free software; you can redistribute  it and/or modify it
> >  * under  the terms of  the GNU General  Public License as published by the
> >  * Free Software Foundation;  either version 2 of the  License, or (at your
> >  * option) any later version.
> >  *
> >  * This program is distributed in the hope that it will be useful,
> >  * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >  * GNU General Public License for more details.
> >  *
> >  * You should have received a copy of the GNU General Public License
> >  * along with this program.  If not, see .
> >  *
> >  */
> > 
> > Can you please check if the error is false positive.
> 
> Josh?
> 
> Is the intent that the "copy of the GNU General Public License"
> statement should also be removed?

While it does seem preferable to drop that paragraph, it isn't nearly as
important as dropping the mailing address.  The match on "You should
have received a copy" should probably be reduced to CHK level or
dropped.

> Jesse had a question recently about the appropriateness of the
> removal given the license text.
> 
> http://www.spinics.net/lists/netdev/msg262152.html

Changing the license text is not OK (though the FSF has said it's OK to
make new licenses based on the legal text minus the preamble and sample
instructions, but that doesn't apply here).

But that's not the same as the license *notice*, to which the "but
changing it is not allowed" does not apply.

- Josh Triplett
--
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/7] perf tools: Add support for PERF_RECORD_MISC_GUEST_USER in thread__find_addr_map().

[Dongsheng Yang]

This patch remove a TODO in thread__find_addr_map() and add support of 
PERF_RECORD_MISC_GUEST_USER.

Signed-off-by: Dongsheng Yang 
---
 tools/perf/util/event.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 6948768..44992ed 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -658,15 +658,10 @@ void thread__find_addr_map(struct thread *thread,
al->level = 'g';
mg = &machine->kmaps;
load_map = true;
+   } else if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest) {
+   al->level = 'u';
} else {
-   /*
-* 'u' means guest os user space.
-* TODO: We don't support guest user space. Might support late.
-*/
-   if (cpumode == PERF_RECORD_MISC_GUEST_USER && perf_guest)
-   al->level = 'u';
-   else
-   al->level = 'H';
+   al->level = 'H';
al->map = NULL;
 
if ((cpumode == PERF_RECORD_MISC_GUEST_USER ||
-- 
1.8.2.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/

[PATCH 0/7 V2] Add support of user space symboles for guest.

[Dongsheng Yang]

Hi Arnaldo:
Please help to review this patchset.

Changelog:
- v2:
* splite the first commit.

Dongsheng Yang (7):
  perf tools: Add support for PERF_RECORD_MISC_GUEST_USER in
thread__find_addr_map().
  perf tools: Find the proc info under machine->root_dir.
  perf tools: Set event->header.misc to PERF_RECORD_MISC_GUEST_USER if
machine is guest.
  perf tools: Use machine->pid for tgid if mahicne is guest.
  perf tools: Do not synthesize the treads of default guest.
  perf tools: Add support of user space symbols for guest in perf kvm
top.
  perf tools: Add support of user space symbols for guest in perf kvm
record.

 tools/perf/builtin-record.c | 10 ++
 tools/perf/builtin-top.c| 15 ++-
 tools/perf/util/event.c | 44 ++--
 3 files changed, 50 insertions(+), 19 deletions(-)

-- 
1.8.2.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/

[PATCH 2/7] perf tools: Find the proc info under machine->root_dir.

[Dongsheng Yang]

When we synthesize the threads, we are looking for the infomation
under /proc. But it is only for host.

This patch look for the path of proc under machine->root_dir, then
XXX__synthesize_threads() functions can support guest machines.

Signed-off-by: Dongsheng Yang 
---
 tools/perf/util/event.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 44992ed..c75046f 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -129,7 +129,8 @@ static pid_t perf_event__synthesize_comm(struct perf_tool 
*tool,
goto out;
}
 
-   snprintf(filename, sizeof(filename), "/proc/%d/task", pid);
+   snprintf(filename, sizeof(filename), "%s/proc/%d/task",
+machine->root_dir, pid);
 
tasks = opendir(filename);
if (tasks == NULL) {
@@ -178,7 +179,8 @@ static int perf_event__synthesize_mmap_events(struct 
perf_tool *tool,
FILE *fp;
int rc = 0;
 
-   snprintf(filename, sizeof(filename), "/proc/%d/maps", pid);
+   snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
+machine->root_dir, pid);
 
fp = fopen(filename, "r");
if (fp == NULL) {
@@ -387,6 +389,7 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
   struct machine *machine, bool mmap_data)
 {
DIR *proc;
+   char proc_path[PATH_MAX];
struct dirent dirent, *next;
union perf_event *comm_event, *mmap_event;
int err = -1;
@@ -399,7 +402,9 @@ int perf_event__synthesize_threads(struct perf_tool *tool,
if (mmap_event == NULL)
goto out_free_comm;
 
-   proc = opendir("/proc");
+   snprintf(proc_path, sizeof(proc_path), "%s/proc", machine->root_dir);
+   proc = opendir(proc_path);
+
if (proc == NULL)
goto out_free_mmap;
 
-- 
1.8.2.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/

[PATCH 4/7] perf tools: Use machine->pid for tgid if mahicne is guest.

[Dongsheng Yang]

When we synthesize an comm event, if machine is guest, we should
use the pid of machine as the event->comm.pid, rather than tgid
of thread.

Signed-off-by: Dongsheng Yang 
---
 tools/perf/util/event.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 2d90ed8..93c6701 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -106,8 +106,12 @@ static pid_t perf_event__synthesize_comm(struct perf_tool 
*tool,
 
memset(&event->comm, 0, sizeof(event->comm));
 
-   tgid = perf_event__get_comm_tgid(pid, event->comm.comm,
-sizeof(event->comm.comm));
+   if (machine__is_host(machine))
+   tgid = perf_event__get_comm_tgid(pid, event->comm.comm,
+sizeof(event->comm.comm));
+   else
+   tgid = machine->pid;
+
if (tgid < 0)
goto out;
 
-- 
1.8.2.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/

[PATCH] oprofile: check whether oprofile perf enabled in op_overflow_handler()

[Weng Meiling]

From: Weng Meiling 

There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
op_overflow_handler() will print the warning. During the time, if unregistered
event is triggered again, the cpu will print again. This may make cpu keeping
on printing and trigger softlockup. So check whether events register finished
in op_overflow_handler().

The problem was once triggered on kernel 2.6.34, the main information:
<3>BUG: soft lockup - CPU#0 stuck for 60005ms! [opcontrol:8673]

Pid: 8673, comm:opcontrol
=SOFTLOCKUP INFO BEGIN===
[CPU#0] the task [opcontrol] is not waiting for a lock,maybe a delay or 
deadcricle!
<6>opcontrol R running  0  8673   7603 0x0002
locked:
bf0e1928   mutex0  [] oprofile_start+0x10/0x68 [oprofile]
bf0e1a24   mutex0  [] op_arm_start+0x10/0x48 [oprofile]
c0628020   &ctx->mutex  0  [] 
perf_event_create_kernel_counter+0xa4/0x14c
[] (unwind_backtrace+0x0/0x164) from [] 
(show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] 
(show_lock_info+0x9c/0x168)
[] (show_lock_info+0x9c/0x168) from [] 
(softlockup_tick+0x1c4/0x234)
[] (softlockup_tick+0x1c4/0x234) from [] 
(update_process_times+0x2c/0x50)
[] (update_process_times+0x2c/0x50) from [] 
(tick_sched_timer+0x268/0x2c4)
[] (tick_sched_timer+0x268/0x2c4) from [] 
(__run_hrtimer+0x158/0x25c)
[] (__run_hrtimer+0x158/0x25c) from [] 
(hrtimer_interrupt+0x13c/0x2f8)
[] (hrtimer_interrupt+0x13c/0x2f8) from [] 
(timer64_timer_interrupt+0x20/0x2c)
[] (timer64_timer_interrupt+0x20/0x2c) from [] 
(handle_IRQ_event+0x144/0x2ec)
[] (handle_IRQ_event+0x144/0x2ec) from [] 
(handle_level_irq+0xc0/0x13c)
[] (handle_level_irq+0xc0/0x13c) from [] 
(asm_do_IRQ+0x80/0xbc)
[] (asm_do_IRQ+0x80/0xbc) from [] (__irq_svc+0x4c/0xe4)
Exception stack(0xc4099db8 to 0xc4099e00)
9da0:   c0357538 
9dc0:  c0380cc0 c4098000 0202 0028 c4098000 3fca9fbc c4098000
9de0: c0028b08  c4098000 c4099e00 c005eb50 c005e544 2113 
[] (__irq_svc+0x4c/0xe4) from [] (__do_softirq+0x64/0x25c)
[] (__do_softirq+0x64/0x25c) from [] (irq_exit+0x48/0x5c)
[] (irq_exit+0x48/0x5c) from [] (asm_do_IRQ+0x84/0xbc)
[] (asm_do_IRQ+0x84/0xbc) from [] (__irq_svc+0x4c/0xe4)
Exception stack(0xc4099e58 to 0xc4099ea0)
9e40:   c0628010 2093
9e60: 0001   6013 c00aff24 cc4f6c00 0001 c4098000
9e80:    c4099ea0 c0084fa0 c0084fa4 6013 
[] (__irq_svc+0x4c/0xe4) from [] 
(smp_call_function_single+0xc0/0x1d8)
[] (smp_call_function_single+0xc0/0x1d8) from [] 
(perf_event_create_kernel_counter+0xb4/0x14c)
[] (perf_event_create_kernel_counter+0xb4/0x14c) from [] 
(op_perf_start+0x54/0xf0 [oprofile])
[] (op_perf_start+0x54/0xf0 [oprofile]) from [] 
(op_arm_start+0x20/0x48 [oprofile])
[] (op_arm_start+0x20/0x48 [oprofile]) from [] 
(oprofile_start+0x38/0x68 [oprofile])
[] (oprofile_start+0x38/0x68 [oprofile]) from [] 
(enable_write+0x34/0x54 [oprofile])
[] (enable_write+0x34/0x54 [oprofile]) from [] 
(vfs_write+0xa8/0x150)
[] (vfs_write+0xa8/0x150) from [] (sys_write+0x3c/0x100)
[] (sys_write+0x3c/0x100) from [] 
(ret_fast_syscall+0x0/0x30)
=SOFTLOCKUP INFO END=
<0>Kernel panic - not syncing: softlockup: hung tasks

Cc:  # 2.6.34+
Signed-off-by: Weng Meiling 
---
 drivers/oprofile/oprofile_perf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/oprofile/oprofile_perf.c b/drivers/oprofile/oprofile_perf.c
index d5b2732..a9e5761 100644
--- a/drivers/oprofile/oprofile_perf.c
+++ b/drivers/oprofile/oprofile_perf.c
@@ -38,6 +38,9 @@ static void op_overflow_handler(struct perf_event *event,
int id;
u32 cpu = smp_processor_id();

+   if (!oprofile_perf_enabled)
+   return;
+
for (id = 0; id < num_counters; ++id)
if (per_cpu(perf_events, cpu)[id] == event)
break;
-- 
1.8.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: [Xen-devel] [PATCH v2 0/2] xen: vnuma introduction for pv guest

[Elena Ufimtseva]

On Fri, Dec 20, 2013 at 2:39 AM, Elena Ufimtseva  wrote:
> On Wed, Dec 4, 2013 at 8:13 PM, Dario Faggioli
>  wrote:
>> On mer, 2013-12-04 at 01:20 -0500, Elena Ufimtseva wrote:
>>> On Tue, Dec 3, 2013 at 7:35 PM, Elena Ufimtseva  wrote:
>>> > Oh guys, I feel really bad about not replying to these emails... Somehow 
>>> > these
>>> > replies all got deleted.. wierd.
>>> >
>> No worries... You should see *my* backlog. :-P
>>
>>> > Ok, about that automatic balancing. At the moment of the last patch
>>> > automatic numa balancing seem to
>>> > work, but after rebasing on the top of 3.12-rc2 I see similar issues.
>>> > I will try to figure out what commits broke and will contact Ingo
>>> > Molnar and Mel Gorman.
>>> >
>>> As of now I have patch v4 for reviewing. Not sure if it will be
>>> beneficial to post it for review
>>> or look closer at the current problem.
>>>
>> You mean the Linux side? Perhaps stick somewhere a reference to the git
>> tree/branch where it lives, but, before re-sending, let's wait for it to
>> be as issue free as we can tell?
>>
>>> The issue I am seeing right now is defferent from what was happening before.
>>> The corruption happens when on change_prot_numa way :
>>>
>> Ok, so, I think I need to step back a bit from the actual stack trace
>> and look at the big picture. Please, Elena or anyone, correct me if I'm
>> saying something wrong about how Linux's autonuma works and interacts
>> with Xen.
>>
>> The way it worked when I last looked at it was sort of like this:
>>  - there was a kthread scanning all the pages, removing the PAGE_PRESENT
>>bit from actually present pages, and adding a new special one
>>(PAGE_NUMA or something like that);
>>  - when a page fault is triggered and the PAGE_NUMA flag is found, it
>>figures out the page is actually there, so no swap or anything.
>>However, it tracks from what node the access to that page came from,
>>matches it with the node where the page actually is and collect some
>>statistics about that;
>>  - at some point (and here I don't remember the exact logic, since it
>>changed quite a few times) pages ranking badly in the stats above are
>>moved from one node to another.
>
> Hello Dario, Konrad.
>
> - Yes, there is a kernel worker that runs on each node and scans some
> pages stats and
> marks them as _PROT_NONE and resets _PAGE_PRESENT.
> The page fault at this moment is triggered and control is being
> returned back to the linux pv kernel
> to process with handle_mm_fault and page numa fault handler if
> discovered if that was a numa pmd/pte with
> present flag cleared.
> About the stats, I will have to collect some sensible information.
>
>>
>> Is this description still accurate? If yes, here's what I would (double)
>> check, when running this in a PV guest on top of Xen:
>>
>>  1. the NUMA hinting page fault, are we getting and handling them
>> correctly in the PV guest? Are the stats in the guest kernel being
>> updated in a sensible way, i.e., do they make sense and properly
>> relate to the virtual topology of the guest?
>> At some point we thought it would have been necessary to intercept
>> these faults and make sure the above is true with some help from the
>> hypervisor... Is this the case? Why? Why not?
>
> The real healp needed from hypervisor is to allow _PAGE_NUMA flags on
> pte/pmd entries.
> I have done so in hypervisor by utilizing same _PAGE_NUMA bit and
> including into the allowed bit mask.
> As this bit is the same as PAGE_GLOBAL in hypervisor, that may induce
> some other errors. So far I have not seen any
> and I will double check on this.
>
>>
>>  2. what happens when autonuma tries to move pages from one node to
>> another? For us, that would mean in moving from one virtual node
>> to another... Is there a need to do anything at all? I mean, is
>> this, from our perspective, just copying the content of an MFN from
>> node X into another MFN on node Y, or do we need to update some of
>> our vnuma tracking data structures in Xen?
>>
>> If we have this figured out already, then I think we just chase bugs and
>> repost the series. If not, well, I think we should. :-D
>>
> here is the best part :)
>
> After a fresh look at the numa autobalancing, applying recent patches,
> talking some to riel who works now on mm numa autobalancing and
> running some tests including dd, ltp, kernel compiling and my own
> tests, autobalancing now is working
> correctly with vnuma. Now I can see sucessfully migrated pages in 
> /proc/vmstat:
>
> numa_pte_updates 39
> numa_huge_pte_updates 0
> numa_hint_faults 36
> numa_hint_faults_local 23
> numa_pages_migrated 4
> pgmigrate_success 4
> pgmigrate_fail 0
>
> I will be running some tests with transparent huge pages as the
> migration of such will be failing.
> Probably it is possible to find all the patches related to numa
> autobalancing and figure out possible reasons
> of why previously balancing was not workin

[PATCH] fs/nilfs2: Integer overflow in nilfs_ioctl_wrap_copy()

[Wenliang Fan]

The local variable 'pos' comes from userspace. If a large number was
passed, there would be an integer overflow in the following line:
pos += n;

Signed-off-by: Wenliang Fan 
---
 fs/nilfs2/ioctl.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/nilfs2/ioctl.c b/fs/nilfs2/ioctl.c
index b44bdb2..b2bac9a 100644
--- a/fs/nilfs2/ioctl.c
+++ b/fs/nilfs2/ioctl.c
@@ -90,8 +90,13 @@ static int nilfs_ioctl_wrap_copy(struct the_nilfs *nilfs,
total += nr;
if ((size_t)nr < n)
break;
-   if (pos == ppos)
+   if (pos == ppos) {
+   if (pos > ULONG_MAX - n) {
+   ret = -EINVAL;
+   break;
+   }
pos += n;
+   }
}
argv->v_nmembs = total;
 
-- 
1.8.5.rc1.28.g7061504

--
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 2/2] mtd: Fix the behavior of otp write if there is not enough room for data

[Christian Riesch]

An OTP write shall write as much data as possible to the OTP memory
and return the number of bytes that have actually been written.
If no data could be written at all due to lack of OTP memory,
return -ENOSPC.

Signed-off-by: Christian Riesch 
Cc: Artem Bityutskiy 
Cc: Kyungmin Park 
Cc: Amul Kumar Saha 
---
 drivers/mtd/chips/cfi_cmdset_0001.c |   13 +++--
 drivers/mtd/devices/mtd_dataflash.c |   13 +
 drivers/mtd/mtdchar.c   |7 +++
 drivers/mtd/onenand/onenand_base.c  |   10 +-
 4 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
b/drivers/mtd/chips/cfi_cmdset_0001.c
index 7aa581f..cf423a6 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2387,8 +2387,17 @@ static int cfi_intelext_write_user_prot_reg(struct 
mtd_info *mtd, loff_t from,
size_t len, size_t *retlen,
 u_char *buf)
 {
-   return cfi_intelext_otp_walk(mtd, from, len, retlen,
-buf, do_otp_write, 1);
+   int ret;
+
+   ret = cfi_intelext_otp_walk(mtd, from, len, retlen,
+   buf, do_otp_write, 1);
+
+   /* if no data could be written due to lack of OTP memory,
+  return ENOSPC */
+   if (!ret && len && !(*retlen))
+   return -ENOSPC;
+
+   return ret;
 }
 
 static int cfi_intelext_lock_user_prot_reg(struct mtd_info *mtd,
diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 09c69ce..5236d85 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -545,14 +545,11 @@ static int dataflash_write_user_otp(struct mtd_info *mtd,
struct dataflash*priv = mtd->priv;
int status;
 
-   if (len > 64)
-   return -EINVAL;
-
-   /* Strictly speaking, we *could* truncate the write ... but
-* let's not do that for the only write that's ever possible.
-*/
-   if ((from + len) > 64)
-   return -EINVAL;
+   if ((from + len) > 64) {
+   len = 64 - from;
+   if (len <= 0)
+   return -ENOSPC;
+   }
 
/* OUT: OP_WRITE_SECURITY, 3 zeroes, 64 data-or-zero bytes
 * IN:  ignore all
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 0edb0ca..db99031 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -323,6 +323,13 @@ static ssize_t mtdchar_write(struct file *file, const char 
__user *buf, size_t c
default:
ret = mtd_write(mtd, *ppos, len, &retlen, kbuf);
}
+   /* return -ENOSPC only if no data was written */
+   if ((ret == -ENOSPC) && (total_retlen)) {
+   ret = 0;
+   retlen = 0;
+   /* drop the remaining data */
+   count = 0;
+   }
if (!ret) {
*ppos += retlen;
total_retlen += retlen;
diff --git a/drivers/mtd/onenand/onenand_base.c 
b/drivers/mtd/onenand/onenand_base.c
index 419c538..6c49a6f 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -3316,7 +3316,15 @@ static int onenand_read_user_prot_reg(struct mtd_info 
*mtd, loff_t from,
 static int onenand_write_user_prot_reg(struct mtd_info *mtd, loff_t from,
size_t len, size_t *retlen, u_char *buf)
 {
-   return onenand_otp_walk(mtd, from, len, retlen, buf, do_otp_write, 
MTD_OTP_USER);
+   int ret;
+   ret = onenand_otp_walk(mtd, from, len, retlen, buf, do_otp_write, 
MTD_OTP_USER);
+
+   /* if no data could be written due to lack of OTP memory,
+  return ENOSPC */
+   if (!ret && len && !(*retlen))
+   return -ENOSPC;
+
+   return ret;
 }
 
 /**
-- 
1.7.9.5

--
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 0/2] mtd: Harmonize implementations of OTP write and _get_{fact,user}_prot_info

[Christian Riesch]

Hi all,

In the discussion on my patchset for the OTP support for
drivers/mtd/chips/cfi_cmdset_0002.c [1-5], Artem requested two changes in the
current code of the OTP write functions and the _get_{fact,user}_prot_info
code.

These two patches are an attempt to make the requested changes.

The first patch adds a retlen parameter to the _get_fact_prot_info and
_get_user_prot_info functions and thus harmonizes the implementation
with those of the write and read functions.

The second patch fixes a problem that I earlier addressed in [1]. After
the discussion about this patch on the mtd mailing list, I think that the
correct behavior of the write function should be the one specified in [6]:
Try to write as many bytes as possible and return the number of bytes
that were written. If no data could be written due to lack of OTP memory,
return -ENOSPC.

Artem, would you please have a look at these patches? I would like to know
if I understood you correctly, or if I missed something here. Please note
that I cannot test these patches since I do not have the hardware. The
patches are compile tested only. If these patches are ok, I will also
respin the OTP support patches for cfi_cmdset_0002.

Changes for v2:
- Fixed buggy cfi_intelext_get_fact_prot_info

Thank you!

Best regards,
Christian

[1] http://patchwork.ozlabs.org/patch/239897/
[2] http://patchwork.ozlabs.org/patch/240010/
[3] http://patchwork.ozlabs.org/patch/240007/
[4] http://patchwork.ozlabs.org/patch/240008/
[5] http://patchwork.ozlabs.org/patch/240009/
[6] http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html

Cc: Artem Bityutskiy 
Cc: Kyungmin Park 
Cc: Amul Kumar Saha 
Cc: Brian Norris 

Christian Riesch (2):
  mtd: Add a retlen parameter to _get_{fact,user}_prot_info
  mtd: Fix the behavior of otp write if there is not enough room for
data

 drivers/mtd/chips/cfi_cmdset_0001.c |   44 +++
 drivers/mtd/devices/mtd_dataflash.c |   20 +++-
 drivers/mtd/mtdchar.c   |   18 ++
 drivers/mtd/mtdcore.c   |   12 +-
 drivers/mtd/mtdpart.c   |   14 ++-
 drivers/mtd/onenand/onenand_base.c  |   40 ---
 include/linux/mtd/mtd.h |   16 ++---
 7 files changed, 89 insertions(+), 75 deletions(-)

-- 
1.7.9.5

--
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 1/2] mtd: Add a retlen parameter to _get_{fact,user}_prot_info

[Christian Riesch]

Signed-off-by: Christian Riesch 
Cc: Artem Bityutskiy 
Cc: Brian Norris 
---
 drivers/mtd/chips/cfi_cmdset_0001.c |   31 +--
 drivers/mtd/devices/mtd_dataflash.c |7 ---
 drivers/mtd/mtdchar.c   |   11 ++-
 drivers/mtd/mtdcore.c   |   12 ++--
 drivers/mtd/mtdpart.c   |   14 --
 drivers/mtd/onenand/onenand_base.c  |   30 --
 include/linux/mtd/mtd.h |   16 
 7 files changed, 57 insertions(+), 64 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
b/drivers/mtd/chips/cfi_cmdset_0001.c
index 7751443..7aa581f 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -69,10 +69,10 @@ static int cfi_intelext_read_fact_prot_reg (struct mtd_info 
*, loff_t, size_t, s
 static int cfi_intelext_read_user_prot_reg (struct mtd_info *, loff_t, size_t, 
size_t *, u_char *);
 static int cfi_intelext_write_user_prot_reg (struct mtd_info *, loff_t, 
size_t, size_t *, u_char *);
 static int cfi_intelext_lock_user_prot_reg (struct mtd_info *, loff_t, size_t);
-static int cfi_intelext_get_fact_prot_info (struct mtd_info *,
-   struct otp_info *, size_t);
-static int cfi_intelext_get_user_prot_info (struct mtd_info *,
-   struct otp_info *, size_t);
+static int cfi_intelext_get_fact_prot_info(struct mtd_info *, size_t,
+  size_t *, struct otp_info *);
+static int cfi_intelext_get_user_prot_info(struct mtd_info *, size_t,
+  size_t *, struct otp_info *);
 #endif
 static int cfi_intelext_suspend (struct mtd_info *);
 static void cfi_intelext_resume (struct mtd_info *);
@@ -2399,24 +2399,19 @@ static int cfi_intelext_lock_user_prot_reg(struct 
mtd_info *mtd,
 NULL, do_otp_lock, 1);
 }
 
-static int cfi_intelext_get_fact_prot_info(struct mtd_info *mtd,
-  struct otp_info *buf, size_t len)
-{
-   size_t retlen;
-   int ret;
+static int cfi_intelext_get_fact_prot_info(struct mtd_info *mtd, size_t len,
+  size_t *retlen, struct otp_info *buf)
 
-   ret = cfi_intelext_otp_walk(mtd, 0, len, &retlen, (u_char *)buf, NULL, 
0);
-   return ret ? : retlen;
+{
+   return cfi_intelext_otp_walk(mtd, 0, len, retlen, (u_char *)buf,
+NULL, 0);
 }
 
-static int cfi_intelext_get_user_prot_info(struct mtd_info *mtd,
-  struct otp_info *buf, size_t len)
+static int cfi_intelext_get_user_prot_info(struct mtd_info *mtd, size_t len,
+  size_t *retlen, struct otp_info *buf)
 {
-   size_t retlen;
-   int ret;
-
-   ret = cfi_intelext_otp_walk(mtd, 0, len, &retlen, (u_char *)buf, NULL, 
1);
-   return ret ? : retlen;
+   return cfi_intelext_otp_walk(mtd, 0, len, retlen, (u_char *)buf,
+NULL, 1);
 }
 
 #endif
diff --git a/drivers/mtd/devices/mtd_dataflash.c 
b/drivers/mtd/devices/mtd_dataflash.c
index 28779b6..09c69ce 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -442,8 +442,8 @@ static int dataflash_write(struct mtd_info *mtd, loff_t to, 
size_t len,
 
 #ifdef CONFIG_MTD_DATAFLASH_OTP
 
-static int dataflash_get_otp_info(struct mtd_info *mtd,
-   struct otp_info *info, size_t len)
+static int dataflash_get_otp_info(struct mtd_info *mtd, size_t len,
+ size_t *retlen, struct otp_info *info)
 {
/* Report both blocks as identical:  bytes 0..64, locked.
 * Unless the user block changed from all-ones, we can't
@@ -452,7 +452,8 @@ static int dataflash_get_otp_info(struct mtd_info *mtd,
info->start = 0;
info->length = 64;
info->locked = 1;
-   return sizeof(*info);
+   *retlen = sizeof(*info);
+   return 0;
 }
 
 static ssize_t otp_read(struct spi_device *spi, unsigned base,
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 684bfa3..0edb0ca 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -888,25 +888,26 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, 
u_long arg)
case OTPGETREGIONINFO:
{
struct otp_info *buf = kmalloc(4096, GFP_KERNEL);
+   size_t retlen;
if (!buf)
return -ENOMEM;
switch (mfi->mode) {
case MTD_FILE_MODE_OTP_FACTORY:
-   ret = mtd_get_fact_prot_info(mtd, buf, 4096);
+   ret = mtd_get_fact_prot_info(mtd, 4096, &retlen, buf);
break;
case MTD_FILE_MODE_OTP_USER:
-   ret = mtd_get_user_prot_info(mtd, 

Re: [Xen-devel] [PATCH v2 0/2] xen: vnuma introduction for pv guest

[Elena Ufimtseva]

On Wed, Dec 4, 2013 at 8:13 PM, Dario Faggioli
 wrote:
> On mer, 2013-12-04 at 01:20 -0500, Elena Ufimtseva wrote:
>> On Tue, Dec 3, 2013 at 7:35 PM, Elena Ufimtseva  wrote:
>> > Oh guys, I feel really bad about not replying to these emails... Somehow 
>> > these
>> > replies all got deleted.. wierd.
>> >
> No worries... You should see *my* backlog. :-P
>
>> > Ok, about that automatic balancing. At the moment of the last patch
>> > automatic numa balancing seem to
>> > work, but after rebasing on the top of 3.12-rc2 I see similar issues.
>> > I will try to figure out what commits broke and will contact Ingo
>> > Molnar and Mel Gorman.
>> >
>> As of now I have patch v4 for reviewing. Not sure if it will be
>> beneficial to post it for review
>> or look closer at the current problem.
>>
> You mean the Linux side? Perhaps stick somewhere a reference to the git
> tree/branch where it lives, but, before re-sending, let's wait for it to
> be as issue free as we can tell?
>
>> The issue I am seeing right now is defferent from what was happening before.
>> The corruption happens when on change_prot_numa way :
>>
> Ok, so, I think I need to step back a bit from the actual stack trace
> and look at the big picture. Please, Elena or anyone, correct me if I'm
> saying something wrong about how Linux's autonuma works and interacts
> with Xen.
>
> The way it worked when I last looked at it was sort of like this:
>  - there was a kthread scanning all the pages, removing the PAGE_PRESENT
>bit from actually present pages, and adding a new special one
>(PAGE_NUMA or something like that);
>  - when a page fault is triggered and the PAGE_NUMA flag is found, it
>figures out the page is actually there, so no swap or anything.
>However, it tracks from what node the access to that page came from,
>matches it with the node where the page actually is and collect some
>statistics about that;
>  - at some point (and here I don't remember the exact logic, since it
>changed quite a few times) pages ranking badly in the stats above are
>moved from one node to another.

Hello Dario, Konrad.

- Yes, there is a kernel worker that runs on each node and scans some
pages stats and
marks them as _PROT_NONE and resets _PAGE_PRESENT.
The page fault at this moment is triggered and control is being
returned back to the linux pv kernel
to process with handle_mm_fault and page numa fault handler if
discovered if that was a numa pmd/pte with
present flag cleared.
About the stats, I will have to collect some sensible information.

>
> Is this description still accurate? If yes, here's what I would (double)
> check, when running this in a PV guest on top of Xen:
>
>  1. the NUMA hinting page fault, are we getting and handling them
> correctly in the PV guest? Are the stats in the guest kernel being
> updated in a sensible way, i.e., do they make sense and properly
> relate to the virtual topology of the guest?
> At some point we thought it would have been necessary to intercept
> these faults and make sure the above is true with some help from the
> hypervisor... Is this the case? Why? Why not?

The real healp needed from hypervisor is to allow _PAGE_NUMA flags on
pte/pmd entries.
I have done so in hypervisor by utilizing same _PAGE_NUMA bit and
including into the allowed bit mask.
As this bit is the same as PAGE_GLOBAL in hypervisor, that may induce
some other errors. So far I have not seen any
and I will double check on this.

>
>  2. what happens when autonuma tries to move pages from one node to
> another? For us, that would mean in moving from one virtual node
> to another... Is there a need to do anything at all? I mean, is
> this, from our perspective, just copying the content of an MFN from
> node X into another MFN on node Y, or do we need to update some of
> our vnuma tracking data structures in Xen?
>
> If we have this figured out already, then I think we just chase bugs and
> repost the series. If not, well, I think we should. :-D
>
here is the best part :)

After a fresh look at the numa autobalancing, applying recent patches,
talking some to riel who works now on mm numa autobalancing and
running some tests including dd, ltp, kernel compiling and my own
tests, autobalancing now is working
correctly with vnuma. Now I can see sucessfully migrated pages in /proc/vmstat:

numa_pte_updates 39
numa_huge_pte_updates 0
numa_hint_faults 36
numa_hint_faults_local 23
numa_pages_migrated 4
pgmigrate_success 4
pgmigrate_fail 0

I will be running some tests with transparent huge pages as the
migration of such will be failing.
Probably it is possible to find all the patches related to numa
autobalancing and figure out possible reasons
of why previously balancing was not working. Giving the amount of work
kernel folks spent recently to fix
issues with numa and the significance of the changes itself, I might
need few more attempts to understand it.

I am going to test THP and if t

[GUT PULL] ARC fix for 3.13-rc5

[Vineet Gupta]

Hi Linus,

This fixes a regression introduced in prev rc. Please merge.

Thx,
-Vineet
-->
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:

  Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
tags/arc-fixes-for-3.13-rc5

for you to fetch changes up to 1e01c7eb7c431a74437d73fe54670398b4d2b222:

  ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h (2013-12-19
19:44:12 +0530)


syscall table busted due to unistd header inclusion issue


Vineet Gupta (1):
  ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h

 arch/arc/include/uapi/asm/unistd.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)
--
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] x86: Add check for number of available vectors before CPU down [v2]

[Chen, Gong]

On Thu, Dec 19, 2013 at 01:11:32PM -0500, Prarit Bhargava wrote:
> 
> Yep.  The question really is this: is the irq mapped to a single vector or
> multiple vectors. (I think)
> 
> P.
> 
Yes, this is the original thought I want to express on the bugzilla. On an
ideal environment, without irq balance, all vector_irq should own same
values, say, 0x. So when one CPU is off-lined, your patch will
considers no places to contain these to-be-migrated irqs but the fact is
they are shared on different CPUs. So if we can answer this question,
the answer will be clear :-).


signature.asc
Description: Digital signature

Re: [PATCH] Tracing events with GPIOs

[Alexandre Courbot]

On Thu, Dec 19, 2013 at 8:38 PM, Jean-Jacques Hiblot
 wrote:
> 2013/12/19 Alexandre Courbot :
>> The problems I can see so far:
>>
>> - Using gpiod, GPIOs are not specified as integers, but are typically
>> mapped to a given (device, function) pair (device can be NULL) using
>> device tree/platform data/ACPI and obtained by the corresponding
>> device driver through gpiod_get(). You would need to find a different
>> way to specify GPIOs, maybe using the gpio_chip's label and the GPIO
>> hardware number.
>>
>> - Even if you do so, there is currently no way to arbitrarily obtain a
>> GPIO that has not been explicitly mapped to a (device, function), and
>> IIUC you need to specify the tracing GPIO freely from user-space. This
>> hints that we will need to add a function that is sensibly the same as
>> gpio_request_one() to the gpiod API, but I wonder if that does not
>> defeats the purpose somehow.
>
> This is something I was wondering about for another reason. In many
> cases the GPIOs that are physically available for probing will be
> limited to the GPIOs already assigned a function (backlight control
> for example), others are usually not routed except in eval boards or
> early prototypes. And consequently those GPIOs will be requested by a
> driver long before a probe is set.
> It would be nice not to have to remove the driver to be able to use
> this GPIO  as a probe. Maybe a gpiod_steal() interface and a flag
> indicating that the GPIO can be safely stolen?

Mmm an explicit way to hijack a GPIO does not sound very safe. Do you
have concrete cases where you need to do so? I guess most boards you
may want to use this patch with would have at least some spare GPIOs
with pins somewhere on the board for this kind of purpose.
--
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] ASoC: simple-card: Add cpu_dai and codec_dai names NULL check

[Xiubo Li]

The name of cpu DAI maybe omitted, and then strlen() will lead
kernel panic.

Signed-off-by: Xiubo Li 
---
 sound/soc/generic/simple-card.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 3d190d0..1d87db8 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -142,6 +142,9 @@ static int asoc_simple_card_parse_of(struct device_node 
*node,
if (ret < 0)
return ret;
 
+   if (!info->cpu_dai.name || !info->codec_dai.name)
+   return -EINVAL;
+
/* card name is created from CPU/CODEC dai name */
name = devm_kzalloc(dev,
strlen(info->cpu_dai.name)   +
-- 
1.8.4


--
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] ASoC: soc-core: Fix the DAI name getting.

[Xiubo Li]

>From "ASoC: make snd_soc_dai_link more symmetrical", can we see that
the name of CPU DAI maybe omitted. If the DAI name is omitted, try to
use the component name instead.

Signed-off-by: Xiubo Li 
---
 sound/soc/soc-core.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index a66783e..be88df5 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4617,10 +4617,14 @@ int snd_soc_of_get_dai_name(struct device_node *of_node,
 
if (id < 0 || id >= pos->num_dai) {
ret = -EINVAL;
-   } else {
-   *dai_name = pos->dai_drv[id].name;
-   ret = 0;
+   break;
}
+
+   ret = 0;
+
+   *dai_name = pos->dai_drv[id].name;
+   if (!*dai_name)
+   *dai_name = pos->name;
}
 
break;
-- 
1.8.4


--
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] fs/btrfs: Integer overflow in btrfs_ioctl_resize()

[Wenliang Fan]

The local variable 'new_size' comes from userspace. If a large number
was passed, there would be an integer overflow in the following line:
new_size = old_size + new_size;

Signed-off-by: Wenliang Fan 
---
 fs/btrfs/ioctl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 21da576..92f7707 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1466,6 +1466,10 @@ static noinline int btrfs_ioctl_resize(struct file *file,
}
new_size = old_size - new_size;
} else if (mod > 0) {
+   if (new_size > ULLONG_MAX - old_size) {
+   ret = -EINVAL;
+   goto out_free;
+   }
new_size = old_size + new_size;
}
 
-- 
1.8.5.rc1.28.g7061504

--
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: [PATCHv2 4/6] Crashdump-Accepting-Active-IOMMU-Copy-Translations

[Baoquan He]

On 12/20/13 at 02:04pm, Baoquan He wrote:
> On 12/19/13 at 07:49pm, Bill Sumner wrote:
> 
> > +static int copy_page_addr(u64 page_addr, u32 shift, u32 bus, u32 devfn,
> > +   u64 pte, struct dmar_domain *domain,
> > +   void *parms)
> > +{
> > +   struct copy_page_addr_parms *ppap = parms;
> > +
> > +   u64 page_size = ((u64)1 << shift);  /* page_size */
> > +   u64 pfn_lo; /* For reserving IOVA range */
> > +   u64 pfn_hi; /* For reserving IOVA range */
> > +   struct iova *iova_p;/* For reserving IOVA range */
> > +
> > +   if (!ppap) {
> > +   pr_err("ERROR: ppap is NULL: 0x%3.3x(%3.3d) DevFn: 
> > 0x%3.3x(%3.3d) Page: 0x%16.16llx Size: 0x%16.16llx(%lld)\n",
> > +   bus, bus, devfn, devfn,  page_addr,
> > +   page_size, page_size);
> > +   return 0;
> > +   }
> > +
> 
> > +   /* Prepare for a new page */
> > +   ppap->first = 0;/* Not first-time anymore */
> > +   ppap->bus   = bus;
> > +   ppap->devfn = devfn;
> > +   ppap->shift = shift;
> > +   ppap->pte   = pte;
> > +   ppap->next_addr = page_addr + page_size; /* Next-expected page_addr */
> > +
> > +   ppap->page_addr = page_addr;/* Addr(new page) */
> > +   ppap->page_size = page_size;/* Size(new page) */
> > +
> > +   ppap->domain= domain;   /* adr(domain for the new range) */
> 
> Here I am confused, ppap is used to collect the copied ranges and
> necessary information. To my understanding, this domain is the
> dmar_domain which the 1st device is on. When ppat->last is set to 1,
> among the whole collected range, there may be many domains. I just feel
> not good for this. Is it OK to define a specific lock for ppap
> structure, possibly? Please correct me if I am wrong.

Well, check it again. It's not about the lock. Just all address is
recorded in one dmar_domain.
--
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 0/6] Generic WorkQueue Engine (GenWQE) device driver (v10)

[Frank Haverkamp]

Hi Greg,

Am Mittwoch, den 18.12.2013, 16:52 -0800 schrieb Greg KH:
> On Wed, Dec 18, 2013 at 04:51:17PM +0100, Frank Haverkamp wrote:
> > ping
> 
> Looks good, now applied, thanks for all of the revisions.
> 
> Now the real work starts :)
> 

thank you very much for reviewing and integrating our code. I think the
review helped to improve the code and even to reduce it by a couple of
lines, which I think is positive too.

Regards

Frank


--
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 02/13] ACPI, extlog: replace open-coded _DSM specific code with helper functions

[Chen, Gong]

On Thu, Dec 19, 2013 at 08:47:46PM +0800, Jiang Liu wrote:
> Subject: [Patch v2 02/13] ACPI, extlog: replace open-coded _DSM specific
>  code with helper functions
> X-Mailer: git-send-email 1.7.10.4
> 
> Use helper functions to simplify _DSM related code in acpi_extlog driver.
> Also mark initialization data and functions with __init and __initdata
> to reduce memory footprint.
> 
> Signed-off-by: Jiang Liu 
> Cc: Chen Gong 

Tested-by: Chen, Gong 
Reviewed-by: Chen, Gong 



signature.asc
Description: Digital signature

[PATCH] drivers/staging/bcm: Integer overflow

[Wenliang Fan]

The checking condition in 'validateFlash2xReadWrite()' is not sufficient.
A large number invalid would cause an integer overflow and pass
the condition, which could cause further integer overflows in
'Bcmchar.c:bcm_char_ioctl()'.

Signed-off-by: Wenliang Fan 
---
 drivers/staging/bcm/nvm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/bcm/nvm.c b/drivers/staging/bcm/nvm.c
index 9e5f955..0615609 100644
--- a/drivers/staging/bcm/nvm.c
+++ b/drivers/staging/bcm/nvm.c
@@ -3945,7 +3945,9 @@ int validateFlash2xReadWrite(struct bcm_mini_adapter 
*Adapter, struct bcm_flash2
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, NVM_RW, DBG_LVL_ALL, "End 
offset :%x\n", uiSectEndOffset);
 
/* Checking the boundary condition */
-   if ((uiSectStartOffset + psFlash2xReadWrite->offset + uiNumOfBytes) <= 
uiSectEndOffset)
+   if (((uiSectStartOffset + psFlash2xReadWrite->offset + uiNumOfBytes) <= 
uiSectEndOffset)
+   && (uiSectStartOffset + psFlash2xReadWrite->offset > 
uiSectStartOffset)
+   && (uiSectStartOffset + psFlash2xReadWrite->offset + 
uiNumBytes > uiNumBytes))
return TRUE;
else {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_PRINTK, 0, 0, "Invalid 
Request");
-- 
1.8.5.rc1.28.g7061504

--
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] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs

[Keith Packard]

Keith Packard  writes:

> When FB_EVENT_FB_UNBIND is sent, fbcon has two paths, one path taken
> when there is another frame buffer to switch any affected vcs to and
> another path when there isn't.

What I meant to attach to this bug report but clearly failed was that I think
this case essentially *always* occurs if you have a generic frame buffer
driver loaded before a 'real' driver is loaded. In my case, this is
efifb. So, we have a reference to freed memory hanging out on a timer
list.

I'm really unsure why this hasn't caused more grief, but I can say that
it was greatly aggravated by adding 'fbcon=vc:2-6' to the kernel command
line, which limits fbcon to supporting consoles only on vt 2-6.

Definitely one of those 'how could this ever have worked, and why hasn't
my machine been crashing every day' moments when I read through the
code.

As the patch indicates, I'm not sure this patch is actually what we
want, but I'd love to know if I've isolated the root cause correctly and
then figure out what patch we actually want.

For my own part, I've got a happy customer with the patch, which is
definitely a nice way to end the day.

-- 
keith.pack...@intel.com


pgpyJkI0eXVHu.pgp
Description: PGP signature

Re: [PATCH v5][RESEND] X86 platform: New BayTrail IOSF-SB MBI driver

[David E. Box]

On Fri, Dec 20, 2013 at 02:59:29AM +0100, Rafael J. Wysocki wrote:
> On Thursday, December 19, 2013 02:37:46 PM David E. Box wrote:
> > From: "David E. Box" 
> > 
> > Current Intel SOC cores use a MailBox Interface (MBI) to provide access to 
> > unit
> > devices connected to the system fabric. This driver implements access to 
> > this
> > interface on BayTrail platforms. This is a requirement for drivers that need
> > access to unit registers on the platform (e.g. accessing the PUNIT for power
> > management features such as RAPL). Serialized access is handled by all 
> > exported
> > routines with spinlocks.
> > 
> > The API includes 3 functions for access to unit registers:
> > 
> > int bt_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
> > int bt_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
> > int bt_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
> > 
> > port:   indicating the unit being accessed
> > opcode: the read or write port specific opcode
> > offset: the register offset within the port
> > mdr:the register data to be read, written, or modified
> > mask:   bit locations in mdr to change
> > 
> > Returns nonzero on error
> > 
> > Note: GPU code handles access to the GFX unit. Therefore access to that unit
> > with this driver is disallowed to avoid conflicts.
> > 
> > Signed-off-by: David E. Box 
> > ---
> > v5: Converted from pnpacpi/mmio driver to pci/config_space driver as
> > necessitated by firmware change.
> > 
> > v4: Define driver as platform specific to BayTrail as some platforms cannot
> > enumerate the MBI using ACPI as noted by Bin Gao 
> > 
> > Renamed register macros and API funcitons to platform specific names.
> > Changed dependency to PNPACPI as sugessted by Rafael Wysocki 
> > 
> > 
> > v3: Converted to PNP ACPI driver as sugessted by Rafael Wysocki 
> > 
> > Removed config visibility to user as suggested by Andi Kleen 
> > 
> > 
> > v2: Made modular since there was no longer a reason not to
> > Moved to x86 platform as suggested by Mathhew Garrett 
> > 
> > Added probe to init to cause driver load to fail if device not detected.
> > 
> >  drivers/platform/x86/Kconfig  |8 ++
> >  drivers/platform/x86/Makefile |1 +
> >  drivers/platform/x86/intel_baytrail.c |  224 
> > +
> >  drivers/platform/x86/intel_baytrail.h |   90 +
> >  4 files changed, 323 insertions(+)
> >  create mode 100644 drivers/platform/x86/intel_baytrail.c
> >  create mode 100644 drivers/platform/x86/intel_baytrail.h
> > 
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index b51a746..b482e22 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -819,4 +819,12 @@ config PVPANIC
> >   a paravirtualized device provided by QEMU; it lets a virtual machine
> >   (guest) communicate panic events to the host.
> >  
> > +config INTEL_BAYTRAIL_MBI
> > +   tristate
> > +   depends on PCI
> > +   ---help---
> > + Needed on Baytrail platforms for access to the IOSF Sideband Mailbox
> > + Interface. This is a requirement for systems that need to configure
> > + the PUNIT for power management features such as RAPL.
> > +
> >  endif # X86_PLATFORM_DEVICES
> > diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> > index 5dbe193..b3d4cfd 100644
> > --- a/drivers/platform/x86/Makefile
> > +++ b/drivers/platform/x86/Makefile
> > @@ -55,3 +55,4 @@ obj-$(CONFIG_INTEL_RST)   += intel-rst.o
> >  obj-$(CONFIG_INTEL_SMARTCONNECT)   += intel-smartconnect.o
> >  
> >  obj-$(CONFIG_PVPANIC)   += pvpanic.o
> > +obj-$(CONFIG_INTEL_BAYTRAIL_MBI)   += intel_baytrail.o
> > diff --git a/drivers/platform/x86/intel_baytrail.c 
> > b/drivers/platform/x86/intel_baytrail.c
> > new file mode 100644
> > index 000..f96626b
> > --- /dev/null
> > +++ b/drivers/platform/x86/intel_baytrail.c
> > @@ -0,0 +1,224 @@
> > +/*
> > + * Baytrail IOSF-SB MailBox Interface Driver
> > + * Copyright (c) 2013, Intel Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms and conditions of the GNU General Public License,
> > + * version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope it will be useful, but WITHOUT
> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
> > for
> > + * more details.
> > + *
> > + *
> > + * The IOSF-SB is a fabric bus available on Atom based SOC's that uses a
> > + * mailbox interface (MBI) to communicate with mutiple devices. This
> > + * driver implements BayTrail-specific access to this interface.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "intel_baytrail.h"
> > +
> > +static DEFINE_SPINLO

Re: [PATCH v3] cpufreq: imx6q: add of_init_opp_table

[Shawn Guo]

On Thu, Dec 19, 2013 at 10:56:28PM -0800, John Tobias wrote:
> Add a routine check to see if the platform supplied the OPP table.
> Incase there's no OPP table exist, it will try to initialise it.
> 
> It's been tested on iMX6SL board where the platform doesn't have
> an OPP table.
> 
> Signed-off-by: John Tobias 

Acked-by: Shawn Guo 

> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 4b3f18e..e125aed 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -187,12 +187,25 @@ static int imx6q_cpufreq_probe(struct platform_device 
> *pdev)
>   goto put_node;
>   }
>  
> - /* We expect an OPP table supplied by platform */
> + /*
> +  * We expect an OPP table supplied by platform.
> +  * Just, incase the platform did not supply the OPP
> +  * table, it will try to get it.
> +  */
>   num = dev_pm_opp_get_opp_count(cpu_dev);
>   if (num < 0) {
> - ret = num;
> - dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
> - goto put_node;
> + ret = of_init_opp_table(cpu_dev);
> + if (ret < 0) {
> + dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
> + goto put_node;
> + }
> +
> + num = dev_pm_opp_get_opp_count(cpu_dev);
> + if (num < 0) {
> + ret = num;
> + dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
> + goto put_node;
> + }
>   }
>  
>   ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> -- 
> 1.8.3.2
> 

--
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 v3] cpufreq: imx6q: add of_init_opp_table

[John Tobias]

Add a routine check to see if the platform supplied the OPP table.
Incase there's no OPP table exist, it will try to initialise it.

It's been tested on iMX6SL board where the platform doesn't have
an OPP table.

Signed-off-by: John Tobias 
---
 drivers/cpufreq/imx6q-cpufreq.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 4b3f18e..e125aed 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -187,12 +187,25 @@ static int imx6q_cpufreq_probe(struct platform_device 
*pdev)
goto put_node;
}
 
-   /* We expect an OPP table supplied by platform */
+   /*
+* We expect an OPP table supplied by platform.
+* Just, incase the platform did not supply the OPP
+* table, it will try to get it.
+*/
num = dev_pm_opp_get_opp_count(cpu_dev);
if (num < 0) {
-   ret = num;
-   dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
-   goto put_node;
+   ret = of_init_opp_table(cpu_dev);
+   if (ret < 0) {
+   dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
+   goto put_node;
+   }
+
+   num = dev_pm_opp_get_opp_count(cpu_dev);
+   if (num < 0) {
+   ret = num;
+   dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
+   goto put_node;
+   }
}
 
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
-- 
1.8.3.2

--
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: [alsa-devel] [RFC PATCH 15/15] ACPI/thinkpad: Fix wrong inclusion in Thinkpad ACPI users.

[Takashi Iwai]

At Fri, 20 Dec 2013 00:28:02 +,
Zheng, Lv wrote:
> 
> Hi, Takashi and Henrique
> 
> Thanks for reviewing and commenting.
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Takashi Iwai
> > Sent: Wednesday, December 18, 2013 9:06 PM
> > 
> > At Wed, 18 Dec 2013 09:41:17 -0200,
> > Henrique de Moraes Holschuh wrote:
> > >
> > > On Wed, 18 Dec 2013, Lv Zheng wrote:
> > > > CONFIG_ACPI dependent code should include  instead of
> > > > directly including .  This patch cleans up such wrong
> > > > inclusions for Thinkpad ACPI users.
> > >
> > > ...
> > >
> > > >  drivers/platform/x86/thinkpad_acpi.c |1 -
> > > >  include/linux/thinkpad_acpi.h|2 ++
> > > >  sound/pci/hda/patch_conexant.c   |1 -
> > > >  sound/pci/hda/patch_realtek.c|1 -
> > >
> > > I'd prefer if you left the include outside of thinkpad_acpi.h, and just 
> > > fix
> > > the include in the two ALSA users.
> > 
> > Agreed.
> > 
> > > We might add some extra stuff to thinkpad_acpi.h someday, and not 
> > > everything
> > > thinkpad_acpi does that might be useful to export to other areas of the
> > > kernel would require acpi.h.
> > >
> > > Looking at patch_conexant and patch_realtek, it might be better to 
> > > actually
> > > move the "am I running on a thinkpad" stuff they use acpi.h for into
> > > thinkpad_acpi, and provide a prototype for that in thinkpad_acpi.h.
> > 
> > True, but we don't want to bind with thinkpad_acpi before identified
> > that it's a thinkpad, so the code needs to be in hd-audio codec
> > driver.
> > 
> 
> It looks to me like that there is a relationship between two Henrique's 
> suggestions.
> His opinion is all ACPI stuff should be bound into thinkpad_acpi.c, that's 
> why he suggested not to include  in .
> So we might address both of them in order to follow.
> 
> I'm not sure if your opinion is: the hd-audio codec driver's needs cannot be 
> met by addressing the second comment.

My position is that some acpi code is needed in hd-audio codec driver
because we need to probe thinkpad before binding with thinkpad_acpi.
The codec driver is used by all machines with the same codec chips,
and only few are thinkpads, so it's better not to bind statically for
the rest others.

> And I'm not the right person that is able to test such code restructuring 
> work.
> The target of this patchset is cleaning up wrong  inclusions, so 
> let me focus on the first comment.
> 
> Can I just update this patch with  inclusions replaced by 
>  inclusions?

Yes, that suffices.


Takashi
--
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 2/2] ARM: tegra: add ams AS3722 device to Venice2 DT

[Laxman Dewangan]

On Thursday 19 December 2013 11:53 PM, Stephen Warren wrote:

On 12/19/2013 12:28 AM, Laxman Dewangan wrote:

On Thursday 19 December 2013 02:25 AM, Stephen Warren wrote:

On 12/18/2013 05:52 AM, Laxman Dewangan wrote:

Add ams AS3722 entry for gpio/pincontrol and regulators
to venice2 DT.

This patch still causes:


[0.726545] as3722-pinctrl as3722-pinctrl: pin gpio0 already
requested by as3722-pinctrl; cannot claim for as3722-regulator
[0.737681] as3722-pinctrl as3722-pinctrl: pin-0
(as3722-regulator) status -22
[0.744895] as3722-pinctrl as3722-pinctrl: could not request pin 0
(gpio0) from group gpio0  on device as3722-pinctrl
[0.755500] as3722-regulator as3722-regulator: Error applying
setting, reverse things back

This error is nothing related to the ams dt or driver. This came from
the framework from the driver/base for adding pinmux call before calling
any diver's probe.

OK, after reverting the problematic MFD commit (which I assume will
happen upstream too), I see no errors caused by this patch.

As such, I've applied the series to Tegra's for-3.14/dt branch.

Thanks for taking care.



Note that I couldn't verify if the pinctrl setup in patch 1/2 matched
the ChromeOS kernel, since the node order is different there, and the
property values don't use named constants there. I'll have to trust you.
I'll be annoyed if it turns out we need to churn the pinctrl
configuration in the future...


I referred the configuration from chrome branch. I assume that good 
amount of testing has already been done on this configuration.
I manually check all configuration and run chrome on this change which 
works properly. Did not see any abnormal behavior.
So if something missed then it is just human error which did not catch 
on 2 level of self review.


Again  any change on this configuration can be expected based on new 
testing or bringung new modules.



--
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] fuse: Fix IOC_[GS]ETFLAGS argument size brokenness

[Richard Hansen]

On 2013-12-19 18:27, Darrick J. Wong wrote:
> The IOC_[GS]ETFLAGS ioctls, despite being defined to take a "long"
> parameter, actually take "int" parameters.  FUSE unfortunately assumed
> that the ioctl definitions never lie, and transfers a long's worth of
> data in and out of userspace, which causes stack smashing in chattr,
> and other bugs elsewhere.
> 
> So, special-case this in FUSE, and document this int/long quirk in
> include/uapi/linux/fs.h.
> 
> Signed-off-by: Darrick J. Wong 
> ---
>  fs/fuse/file.c  |   11 +++
>  include/uapi/linux/fs.h |1 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 7e70506..5fa8181 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -2385,6 +2385,17 @@ long fuse_do_ioctl(struct file *file, unsigned int 
> cmd, unsigned long arg,
>   iov->iov_base = (void __user *)arg;
>   iov->iov_len = _IOC_SIZE(cmd);
>  
> + /*
> +  * The IOC_[GS]ETFLAGS ioctls take int parameters even though
> +  * the ioctl definition specifies long.  Userland has been
> +  * expecting int for ages (and chattr segfaults on FUSE
> +  * filesystems), so special case that here.  The IOC32
> +  * variants were declared with int, so they don't need this.
> +  */
> + if (cmd == FS_IOC_GETFLAGS || cmd == FS_IOC_SETFLAGS) {
> + iov->iov_len = sizeof(int);
> + }
> +
>   if (_IOC_DIR(cmd) & _IOC_WRITE) {
>   in_iov = iov;
>   in_iovs = 1;
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 6c28b61..bc8aa8e 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -154,6 +154,7 @@ struct inodes_stat_t {
>  #define FITHAW   _IOWR('X', 120, int)/* Thaw */
>  #define FITRIM   _IOWR('X', 121, struct fstrim_range)/* Trim 
> */
>  
> +/* IOC_[GS]ETFLAGS take an int argument despite being defined to take long. 
> */
>  #define  FS_IOC_GETFLAGS _IOR('f', 1, long)
>  #define  FS_IOC_SETFLAGS _IOW('f', 2, long)
>  #define  FS_IOC_GETVERSION   _IOR('v', 1, long)

This change to include/uapi/linux/fs.h is similar to but not as thorough as:

http://mid.gmane.org/1385548839-16617-1-git-send-email-aurel...@aurel32.net
https://lkml.org/lkml/2013/11/27/93

(The above linked patch is the patch Aurelien referenced in the
"Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls" thread on
linux-fsdevel; see
.)

-Richard
--
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/

linux-next: Tree for Dec 20

[Stephen Rothwell]

Hi all,

Changes since 20131219:

New tree: clockevents

The powerpc tree still had its build failure for which I applied a
supplied patch.

The sound-asoc tree gained a conflict against the slave-dma tree.

The net-next tree lost its new build failure.

The mmc tree still had its build failure so I used the version from
next-20131212.

The spi tree gained a conflict against the mpc5xxx tree.

The clockevents tree gained a conflict against Linus' tree.

The usb-gadget lost its build failure.

The akpm-current tree still had its build failures for which I applied
patches.

Non-merge commits (relative to Linus' tree): 5223
 5421 files changed, 250649 insertions(+), 134680 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" as mentioned in the FAQ on the wiki
(see below).

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 (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 29 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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell 

$ git checkout master
$ git reset --hard stable
Merging origin/master (f7556698a369 Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (319e2e3f63c3 Linux 3.13-rc4)
Merging arm-current/fixes (b713aa0b1501 ARM: fix asm/memory.h build error)
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (803c2d2f84da powerpc/powernv: Fix OPAL LPC access 
in Little Endian)
Merging sparc/master (1de425c7b271 sparc64: Fix build regression)
Merging net/master (c047e0707307 bnx2x: downgrade "valid ME register value" 
message level)
Merging ipsec/master (239c78db9c41 net: clear local_df when passing skb between 
namespaces)
Merging sound-current/for-linus (356f402da0f9 Merge tag 'asoc-v3.13-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, 
Armada, R-Car PCI host maintainers)
Merging wireless/master (b7e047358449 Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging driver-core.current/driver-core-linus (a8b14744429f sysfs: give 
different locking key to regular and bin files)
Merging tty.current/tty-linus (c2db11eca089 tty: xuartps: Properly guard sysrq 
specific code)
Merging usb.current/usb-linus (fb5f1834c322 usb: ohci-at91: fix irq and iomem 
resource retrieval)
Merging staging.current/staging-linus (fd6040ed57d8 imx-drm: imx-drm-core: 
improve safety of imx_drm_add_crtc())
Merging char-misc.current/char-misc-linus (319e2e3f63c3 Linux 3.13-rc4)
Merging input-current/for-linus (2a4d81547b88 Input: define KEY_WWAN for 
Wireless WAN)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (389a5390583a crypto: scatterwalk - Use 
sg_chain_ptr on chain entries)
Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary 
pci_set_drvdata())
Merging dwmw2/m

Re: [PATCH] apparmor: remove the "task" arg from may_change_ptraced_domain()

[John Johansen]

On 12/19/2013 08:36 PM, Richard Guy Briggs wrote:
> On 13/12/18, Oleg Nesterov wrote:
>> On 12/18, Richard Guy Briggs wrote:
>>>
>>> Bcc: r...@redhat.com
>>> Subject: Re: [PATCH] apparmor: remove the "task" arg from
>>>  may_change_ptraced_domain()
>>> Reply-To:
>>> In-Reply-To: <20130926132519.gy13...@madcap2.tricolour.ca>
>>
>> The subject is empty ;) I changed it to match the above.
> 
> HTH?!?  Thanks for adding it.  (more below...)
> 
>>> On 13/09/26, Richard Guy Briggs wrote:
 On Tue, Sep 24, 2013 at 06:44:42PM +0200, Oleg Nesterov wrote:
> On 09/23, Richard Guy Briggs wrote:
>>
>> On Mon, Sep 16, 2013 at 04:20:35PM +0200, Oleg Nesterov wrote:
>>> Unless task == current ptrace_parent(task) is not safe even under
>>> rcu_read_lock() and most of the current users are not right.
>>
>> Could you point to an explanation of this?
>
> If this task exits before rcu_read_lock() ->parent can point to the
> already freed/reused memory.

 Ok, understood.  So even though the task may have exited, the task
 struct pointer is still valid, but not the contents of the task struct
 to which it points.
>>>
>>> [The thread also relates to the patch
>>> "pid: get ppid pid_t of task in init_pid_ns safely"
>>> in which sys_getppid() (which appears safe) is replaced with something that
>>> references the init_pid_ns rather than current's pid_ns.]
>>>
>>> So, in the general case, that call is not safe, and we should at least
>>> remove the task_struct argument.
>>
>> I changed my mind, please see the recent discussion with Paul:
>>
>>  http://marc.info/?t=13862628191
>>
>> instead we should document why ptrace_parent() is safe without pid_alive().
> 
> Interesting.  I wasn't aware of pid_alive(), but that would certainly
> help.
> 
>> I hope that the change in apparmor was fine anyway.
> 
> Yes, I'm fine with apparmor change, if it was deemed that the ppid
> wasn't needed.  If it is, then it should use this new task_ppid_nr().
it wasn't needed, changes where made years ago to allow us to get rid of
using the parent pid. Its was left in for a transition period and just
had never been removed.

> Better yet I think to generalize it to anticipate auditd in containers.
> 
yep, that is the way to go

--
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:x86/mm] x86/mm/numa: Fix 32-bit kernel NUMA boot

[Yinghai Lu]

On Thu, Dec 19, 2013 at 6:17 PM, Lans Zhang  wrote:
> On 12/20/2013 12:44 AM, Yinghai Lu wrote:
>>
>> On Thu, Dec 19, 2013 at 7:42 AM, tip-bot for Lans Zhang
>>   wrote:
>>>
>>> Commit-ID:  f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
>>> Gitweb:
>>> http://git.kernel.org/tip/f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
>>> Author: Lans Zhang
>>> AuthorDate: Fri, 6 Dec 2013 12:18:30 +0800
>>> Committer:  Ingo Molnar
>>> CommitDate: Thu, 19 Dec 2013 13:58:36 +0100
>>>
>>> x86/mm/numa: Fix 32-bit kernel NUMA boot
>>>
>>> When booting a 32-bit x86 kernel on a NUMA machine, node data
>>> cannot be allocated from local node if the account of memory for
>>> node 0 covers the low memory space entirely:
>>>
>>>[0.00] Initmem setup node 0 [mem 0x-0x83fff]
>>>[0.00]   NODE_DATA [mem 0x367ed000-0x367edfff]
>>>[0.00] Initmem setup node 1 [mem 0x84000-0xf]
>>>[0.00] Cannot find 4096 bytes in node 1
>>>[0.00] 64664MB HIGHMEM available.
>>>[0.00] 871MB LOWMEM available.
>>>
>>> To fix this issue, node data is allowed to be allocated from
>>> other nodes if the memory of local node is still not mapped. The
>>> expected result looks like this:
>>>
>>>[0.00] Initmem setup node 0 [mem 0x-0x83fff]
>>>[0.00]   NODE_DATA [mem 0x367ed000-0x367edfff]
>>>[0.00] Initmem setup node 1 [mem 0x84000-0xf]
>>>[0.00]   NODE_DATA [mem 0x367ec000-0x367ecfff]
>>>[0.00] NODE_DATA(1) on node 0
>>>[0.00] 64664MB HIGHMEM available.
>>>[0.00] 871MB LOWMEM available.
>>>
>>> Signed-off-by: Lans Zhang
>>> Cc:
>>> Cc: Yinghai Lu
>>> Link:
>>> http://lkml.kernel.org/r/1386303510-18574-1-git-send-email-jia.zh...@windriver.com
>>> Signed-off-by: Ingo Molnar
>>> ---
>>>   arch/x86/mm/numa.c | 10 +++---
>>>   1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
>>> index 24aec58..c85da7b 100644
>>> --- a/arch/x86/mm/numa.c
>>> +++ b/arch/x86/mm/numa.c
>>> @@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64
>>> start, u64 end)
>>>   */
>>>  nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
>>>  if (!nd_pa) {
>>> -   pr_err("Cannot find %zu bytes in node %d\n",
>>> -  nd_size, nid);
>>> -   return;
>>> +   nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
>>> + MEMBLOCK_ALLOC_ACCESSIBLE);
>>> +   if (!nd_pa) {
>>> +   pr_err("Cannot find %zu bytes in node %d\n",
>>> +  nd_size, nid);
>>> +   return;
>>> +   }
>>>  }
>>>  nd = __va(nd_pa);
>>>
>>
>> Can you just use memblock_alloc_try_nid instead memblock_alloc_nid?
>
>
> But memblock_alloc_base() inside memblock_alloc_try_nid() may cause kernel
> panic
> if __memblock_alloc_base() inside it fails. In current stage, it is allowed
> if
> node data fails to be allocated.
>

that take MEMBLOCK_ALLOC_ACCESSIBLE, and it should not happen.

BTW it happens wrongly, should panic. as it can not alloc any.

Thanks

Yinghai
--
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 32/38] pcie: add missing put_device call

[Yinghai Lu]

On Thu, Dec 19, 2013 at 2:10 PM, Bjorn Helgaas  wrote:
> [+cc Greg, Yinghai]
>
> On Thu, Dec 19, 2013 at 04:06:46PM +0100, Levente Kurusa wrote:
>> This is required so that we give up the last reference to the device.
>> Removed the kfree() as put_device will result in release_pcie_device being
>> called and hence the container of the device will be kfree'd.
>>
>> Signed-off-by: Levente Kurusa 
>
> Thanks, I applied a slightly modified version of this to my pci/deletion
> branch for v3.14.
>
> I think the get_device() after device_register() succeeds and the
> put_device() before device_unregister() are superfluous, so I propose the
> series included below.  Any comments?

Nice cleanup.

Thanks

Yinghai
--
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 4/4] futex: Avoid taking hb lock if nothing to wakeup

[Davidlohr Bueso]

On Thu, 2013-12-19 at 19:13 -0800, Linus Torvalds wrote:
> On Thu, Dec 19, 2013 at 6:22 PM, Davidlohr Bueso  wrote:
> >
> > Ok so when I replied I was thinking about the plist really and not the
> > hb->lock ticket counter. Yeah, what you propose does make sense for
> > waiters. However in wake paths we have to decrement  the counter nwake
> > times (per each call to __unqueue_futex()), and if we rely on the
> > ticket, then we do it only once, in the unlock, so the counter doesn't
> > reflect the actual waitqueue size. Or am I missing something with ticket
> > spinlocks (I'm not very familiar with that code)?
> 
> So that's why I suggested checking the ticket lock _and_ the state of
> the node list.
> 
> The ticket lock state gives you the racy window before the entry has
> actually been added to the node list, and then after the lock has been
> released, the fact that the list isn't empty gives you the rest.

Yep, I'm starting to get around the idea now.

> I think we might have to order the two reads with an smp_rmb - making
> sure that we check the lock state first - but I think it should be
> otherwise pretty solid.

Yes, I don't see any guarantees otherwise.

> 
> And maybe there is some reason it doesn't work, but I'd really like to
> understand it (and I'd like to avoid the extra atomics for the waiters
> count if it at all can be avoided)

Other than the lock_ptr assignment I don't see much difference with what
you suggest. Since no wake paths use lock_ptr until after plist_del, and
we've already taken the lock way before then, it doesn't play a role in
what we're discussing.

I've put you suggestion (now corrected with spin_is_locked) and works
just as fine as with atomics. It's surviving my laptop and benchmarks on
a large system. I will wait to see if there are any concerns other might
have before sending another version of this patchset.

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 2/2] cpufreq: imx6q: add of_init_opp_table

[Shawn Guo]

On Thu, Dec 19, 2013 at 08:15:29PM -0800, John Tobias wrote:
> Add a routine check to see if the platform supplied the OPP table.
> Incase there's not OPP table exist, it will try to get it.
> 
> Signed-off-by: John Tobias 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 4b3f18e..f261a88 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -187,12 +187,25 @@ static int imx6q_cpufreq_probe(struct platform_device 
> *pdev)
>   goto put_node;
>   }
>  
> - /* We expect an OPP table supplied by platform */
> + /* We expect an OPP table supplied by platform.
> +  * Just, incase the platform did not supply the OPP
> +  * table, it will try to get it.
> +  */

/*
 * Multi-lines comment
 */

>   num = dev_pm_opp_get_opp_count(cpu_dev);
>   if (num < 0) {
> - ret = num;
> - dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
> - goto put_node;
> + ret = of_init_opp_table(cpu_dev);
> + if (ret < 0) {
> + dev_err(cpu_dev, "failed to init OPP table\n");

It should be good to print the error code, i.e. 'ret', here.

> + ret = -ENODEV;

There is no need to make up an error code, and just return what you get
from of_init_opp_table().

Shawn

> + goto put_node;
> + }
> +
> + num = dev_pm_opp_get_opp_count(cpu_dev);
> + if (num < 0) {
> + ret = num;
> + dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
> + goto put_node;
> + }
>   }
>  
>   ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> -- 
> 1.8.3.2
> 

--
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: [PATCHv2 4/6] Crashdump-Accepting-Active-IOMMU-Copy-Translations

[Baoquan He]

On 12/19/13 at 07:49pm, Bill Sumner wrote:

> +static int copy_page_addr(u64 page_addr, u32 shift, u32 bus, u32 devfn,
> + u64 pte, struct dmar_domain *domain,
> + void *parms)
> +{
> + struct copy_page_addr_parms *ppap = parms;
> +
> + u64 page_size = ((u64)1 << shift);  /* page_size */
> + u64 pfn_lo; /* For reserving IOVA range */
> + u64 pfn_hi; /* For reserving IOVA range */
> + struct iova *iova_p;/* For reserving IOVA range */
> +
> + if (!ppap) {
> + pr_err("ERROR: ppap is NULL: 0x%3.3x(%3.3d) DevFn: 
> 0x%3.3x(%3.3d) Page: 0x%16.16llx Size: 0x%16.16llx(%lld)\n",
> + bus, bus, devfn, devfn,  page_addr,
> + page_size, page_size);
> + return 0;
> + }
> +

> + /* Prepare for a new page */
> + ppap->first = 0;/* Not first-time anymore */
> + ppap->bus   = bus;
> + ppap->devfn = devfn;
> + ppap->shift = shift;
> + ppap->pte   = pte;
> + ppap->next_addr = page_addr + page_size; /* Next-expected page_addr */
> +
> + ppap->page_addr = page_addr;/* Addr(new page) */
> + ppap->page_size = page_size;/* Size(new page) */
> +
> + ppap->domain= domain;   /* adr(domain for the new range) */

Here I am confused, ppap is used to collect the copied ranges and
necessary information. To my understanding, this domain is the
dmar_domain which the 1st device is on. When ppat->last is set to 1,
among the whole collected range, there may be many domains. I just feel
not good for this. Is it OK to define a specific lock for ppap
structure, possibly? Please correct me if I am wrong.

> +
> + return 0;
> +}
> +

> +
> +
> +
> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 devfn,
> +   void *ppap, struct context_entry *ce)
> +{
> + int ret = 0;/* Integer Return Code */
> + u32 shift = 0;  /* bits to shift page_addr  */
> + u64 page_addr = 0;  /* Address of translated page */
> + struct dma_pte *pgt_old_phys;   /* Adr(page_table in the old kernel) */
> + struct dma_pte *pgt_new_phys;   /* Adr(page_table in the new kernel) */
> + unsigned long asr;  /* New asr value for new context */
> + u8  t;  /* Translation-type from context */
> + u8  aw; /* Address-width from context */
> + u32 aw_shift[8] = {
> + 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
> + 12+9+9+9,   /* [001b] 39-bit AGAW (3-level page table) */
> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
> + 12+9+9+9+9+9,   /* [011b] 57-bit AGAW (5-level page table) */
> + 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
> + 0,  /* [111b] Reserved */
> + 0,  /* [110b] Reserved */
> + 0,  /* [111b] Reserved */
> + };
> +
> + struct dmar_domain *domain = NULL;  /* To hold domain & device */
> + /*values from old kernel */
> + struct device_domain_info *info = NULL; /* adr(new for this device) */
> + struct device_domain_info *i = NULL;/* iterator for foreach */
> +
> +
 +  /* info->segment = segment;  May need this later */
> + info->bus = bus;
> + info->devfn = devfn;
> + info->iommu = iommu;
> +
> + list_for_each_entry(i, &device_domain_values_list[iommu->seq_id],
> + global) {
> + if (i->domain->id == (int) context_get_did(ce)) {
> + domain = i->domain;
> + pr_debug("CTXT B:D:F:%2.2x:%2.2x:%1.1x Found 
> did=0x%4.4x\n",
> + bus, devfn >> 3, devfn & 0x7, i->domain->id);
> + break;
> + }
> + }
> +
> + if (!domain) {
> + domain = alloc_domain();
> + if (!domain) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> + INIT_LIST_HEAD(&domain->devices);
> + domain->id = (int) context_get_did(ce);
> + domain->agaw = (int) context_get_aw(ce);
> + domain->pgd = NULL;

Here the domain is created and initialized, but its member iovad is not
initialized. This will cause domain->iovad.iova_rbtree_lock deadlock
because its initial value is random. And the rbtree operation will
crash. This happen in reserve_iova invoked in copy_page_addr in high
frequency.

I add 1 line of code as below and it works well.

init_iova_domain(&domain->iovad, DMA_32BIT_PFN);
> +
> + pr_debug("CTXT Allocated new list entry, did:%d\n",
>

Re: [PATCH v3 1/2] ARM: imx6sl: Add cpu frequency scaling support

[Shawn Guo]

On Thu, Dec 19, 2013 at 08:15:28PM -0800, John Tobias wrote:
> Re-use imx6q cpufreq driver to support cpu
> frequency scaling on imx6sl.
> 
> Signed-off-by: John Tobias 

This one is already applied, so you do not have to resend.

Shawn

> ---
>  arch/arm/mach-imx/mach-imx6sl.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mach-imx6sl.c b/arch/arm/mach-imx/mach-imx6sl.c
> index 2f952e3..3072e15 100644
> --- a/arch/arm/mach-imx/mach-imx6sl.c
> +++ b/arch/arm/mach-imx/mach-imx6sl.c
> @@ -34,6 +34,13 @@ static void __init imx6sl_fec_init(void)
>   }
>  }
>  
> +static void __init imx6sl_init_late(void)
> +{
> + /* imx6sl reuses imx6q cpufreq driver */
> + if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ))
> + platform_device_register_simple("imx6q-cpufreq", -1, NULL, 0);
> +}
> +
>  static void __init imx6sl_init_machine(void)
>  {
>   struct device *parent;
> @@ -70,6 +77,7 @@ DT_MACHINE_START(IMX6SL, "Freescale i.MX6 SoloLite (Device 
> Tree)")
>   .map_io = debug_ll_io_init,
>   .init_irq   = imx6sl_init_irq,
>   .init_machine   = imx6sl_init_machine,
> + .init_late  = imx6sl_init_late,
>   .dt_compat  = imx6sl_dt_compat,
>   .restart= mxc_restart,
>  MACHINE_END
> -- 
> 1.8.3.2
> 

--
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] perf stat: Do not show stats if workload fails

[David Ahern]

Currently perf-stat attempts to show counter stats even if the workload
is bogus:

$ perf stat -- foo
foo: No such file or directory

 Performance counter stats for 'foo':

   task-clock
   context-switches
   cpu-migrations
   page-faults
   cycles
   stalled-cycles-frontend
   stalled-cycles-backend
   instructions
   branches
   branch-misses

   0.009769943 seconds time elapsed

It is impossible to differentiate all the failure modes, but it seems
reasonable that if the workload handling fails, perf-stat should not try
to print stats.

With this change:

$ perf stat  -v -- foo
Failed to start workload

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Stephane Eranian 
---
 tools/perf/builtin-stat.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index dab98b50c9fe..d6e6a0b031d9 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -586,7 +586,11 @@ static int __run_perf_stat(int argc, const char **argv)
clock_gettime(CLOCK_MONOTONIC, &ref_time);
 
if (forks) {
-   perf_evlist__start_workload(evsel_list);
+   if (perf_evlist__start_workload(evsel_list) != 0) {
+   pr_err("Failed to start workload\n");
+   return -1;
+   }
+
handle_initial_delay();
 
if (interval) {
@@ -1793,7 +1797,10 @@ int cmd_stat(int argc, const char **argv, const char 
*prefix __maybe_unused)
run_idx + 1);
 
status = run_perf_stat(argc, argv);
-   if (forever && status != -1) {
+   if (status < 0)
+   break;
+
+   if (forever) {
print_stat(argc, argv);
perf_stat__reset_stats(evsel_list);
}
-- 
1.8.3.4 (Apple Git-47)

--
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] perf tools: Fix bug for perf kvm report without guestmount.

[David Ahern]

Arnaldo:

This should go into all stable releases from v3.3 up.


On 12/20/13, 11:41 AM, Dongsheng Yang wrote:

Currently, if we use perf kvm --guestkallsyms --guestmodules report,
we can not get the perf information from perf data file. The all sample
are shown as unknown.

Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 
samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
report |grep %
   100.00%  [guest/6471]  [unknown] [g] 0x8164f330

This bug was introduced by 207b57926 (perf kvm: Fix regression with guest 
machine creation).
In original code, it uses perf_session__find_machine(), it means we deliver 
symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But 
if we use
perf_session__findnew_machine() here, if no machine was found, new machine with 
pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.

And because the new machine initialized here has no kernel map created, the 
symbol delivered to
it will be marked as "unknown".

This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in 
another way.

Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 
samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules report |grep %
22.64%:6471  [guest.kernel.kallsyms]  [g] 
update_rq_clock.part.70
19.99%:6471  [guest.kernel.kallsyms]  [g] d_free
18.46%:6471  [guest.kernel.kallsyms]  [g] bio_phys_segments
16.25%:6471  [guest.kernel.kallsyms]  [g] dequeue_task
12.78%:6471  [guest.kernel.kallsyms]  [g] __switch_to
 7.91%:6471  [guest.kernel.kallsyms]  [g] scheduler_tick
 1.75%:6471  [guest.kernel.kallsyms]  [g] native_apic_mem_write
 0.21%:6471  [guest.kernel.kallsyms]  [g] apic_timer_interrupt

Signed-off-by: Dongsheng Yang 
Acked-by: David Ahern 
---
  tools/perf/util/session.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 989b2e3..a12dfdd 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -830,6 +830,7 @@ static struct machine *
   struct perf_sample *sample)
  {
const u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+   struct machine *machine;

if (perf_guest &&
((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -842,7 +843,11 @@ static struct machine *
else
pid = sample->pid;

-   return perf_session__findnew_machine(session, pid);
+   machine = perf_session__find_machine(session, pid);
+   if (!machine)
+   machine = perf_session__findnew_machine(session,
+   DEFAULT_GUEST_KERNEL_ID);
+   return machine;
}

return &session->machines.host;



--
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 V3] perf tools: Fix bug for perf kvm report without guestmount.

[Dongsheng Yang]

Currently, if we use perf kvm --guestkallsyms --guestmodules report,
we can not get the perf information from perf data file. The all sample
are shown as unknown.

Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 
samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
report |grep %
   100.00%  [guest/6471]  [unknown] [g] 0x8164f330

This bug was introduced by 207b57926 (perf kvm: Fix regression with guest 
machine creation).
In original code, it uses perf_session__find_machine(), it means we deliver 
symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But 
if we use
perf_session__findnew_machine() here, if no machine was found, new machine with 
pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.

And because the new machine initialized here has no kernel map created, the 
symbol delivered to
it will be marked as "unknown".

This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in 
another way.

Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 
samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules report |grep %
22.64%:6471  [guest.kernel.kallsyms]  [g] 
update_rq_clock.part.70
19.99%:6471  [guest.kernel.kallsyms]  [g] d_free
18.46%:6471  [guest.kernel.kallsyms]  [g] bio_phys_segments
16.25%:6471  [guest.kernel.kallsyms]  [g] dequeue_task
12.78%:6471  [guest.kernel.kallsyms]  [g] __switch_to
 7.91%:6471  [guest.kernel.kallsyms]  [g] scheduler_tick
 1.75%:6471  [guest.kernel.kallsyms]  [g] native_apic_mem_write
 0.21%:6471  [guest.kernel.kallsyms]  [g] apic_timer_interrupt

Signed-off-by: Dongsheng Yang 
Acked-by: David Ahern 
---
 tools/perf/util/session.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 989b2e3..a12dfdd 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -830,6 +830,7 @@ static struct machine *
   struct perf_sample *sample)
 {
const u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+   struct machine *machine;
 
if (perf_guest &&
((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -842,7 +843,11 @@ static struct machine *
else
pid = sample->pid;
 
-   return perf_session__findnew_machine(session, pid);
+   machine = perf_session__find_machine(session, pid);
+   if (!machine)
+   machine = perf_session__findnew_machine(session,
+   DEFAULT_GUEST_KERNEL_ID);
+   return machine;
}
 
return &session->machines.host;
-- 
1.8.2.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: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

[joeyli]

於 四，2013-12-19 於 07:22 -0800，H. Peter Anvin 提到：
> On 12/18/2013 11:51 PM, Lee, Chun-Yi wrote:
> > This patch add the driver of Time and Alarm Device in ACPI 5.0.
> > Currently it only implemented get/set time functions and grab
> > the capabilities of device when driver initial.
> > 
> > This driver also register rtc-acpitad platform device for RTC ACPITAD
> > stub driver using.
> > 
> > Signed-off-by: Lee, Chun-Yi 
> 
> What platform do you have that has TAD support?  I am wondering how this
> was tested.
> 
>   -hpa
> 

It's a testing platform that's only support get/set time functions of
ACPI TAD.


Thanks
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/

Re: [PATCHv2 0/6] Crashdump Accepting Active IOMMU

[Baoquan He]

I have reviewed and tested this patchset. Without it the DMAR error
always occured as below. With this patchset, no error is reported and
kdump can work successfully.

This patchset is awesome, it get to the root of the problem when enable
intel-iommu in kdump and fix it. And from code no harm would come to 1st
kernel, surely people's review can guarantee this better and is very
important.

Hi Bill,

Thanks a lot for your effort. 

I have several comments. I think for a formal patch the debug print
need be erased. Or you can split it from this patchset and post it
separately. Then people who review and test your patchset can use the
debug utility.

A bug is found when I test it. please see the inline comment.

Baoquan
Thanks


On 12/19/13 at 07:49pm, Bill Sumner wrote:
> 
> Changes from previous submission:
> 1. Moved up to Linux kernel top-of-tree of this week.
> 2. Expanded the comments section of each patch so that the documentation
>will appear in the commit logs. (Requested by Alex Williamson and one
>internal reviewer)
> 3. Corrected one line in the table which drives the diagnostic printing
>of the IOMMU registers (Requested by one internal reviewer)
> 
> Notes:
> 1. This patch set is ready for extensive testing by the Linux community,
>for discussion, and hopefully for acceptance into Linux mainstream.
> 2. In order to support this testing, I have left a modest amount of
>debug print enabled.  For testing, the amount of print can be increased
>or decreased easily; and for production, can be completely turned-off.
>Please see the bit-flags in struct 'pr_dbg'
> 
> Testing:
> 1. This patch set was re-tested on the machine that reproduced the problem
>a. Without this patch set, crashdump console sees a large number of:
>   "dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr fff69000
>   "DMAR:[fault reason 01] Present bit in root entry is clear"
>b. With this patch set, none of the above messages are seen.
> 2. This patch set has not yet been tested with hardware pass-through enabled.
> 
> 
> Patch 0 file from previous submission:
> The following series implements a fix for:
> A kdump problem about DMA that has been discussed for a long time. That is,
> when a kernel panics and boots into the kdump kernel, DMA started by the 
> panicked kernel is not stopped before the kdump kernel is booted and the 
> kdump kernel disables the IOMMU while this DMA continues.  This causes the
> IOMMU to stop translating the DMA addresses as IOVAs and begin to treat them 
> as physical memory addresses -- which causes the DMA to either:
> (1) generate DMAR errors or (2) generate PCI SERR errors or (3) transfer  
> data to or from incorrect areas of memory. Often this causes the dump to fail.
> 
> This patch set modifies the behavior of the iommu in the (new) crashdump 
> kernel: 
> 1. to accept the iommu hardware in an active state, 
> 2. to leave the current translations in-place so that legacy DMA will continue
>using its current buffers until the device drivers in the crashdump kernel
>initialize and initialize their devices,
> 3. to use different portions of the iova address ranges for the device drivers
>in the crashdump kernel than the iova ranges that were in-use at the time
>of the panic.  
> 
> Advantages of this approach:
> 1. All manipulation of the IO-device is done by the Linux device-driver
>for that device.
> 2. This approach behaves in a manner very similar to operation without an
>active iommu.
> 3. Any activity between the IO-device and its RMRR areas is handled by the
>device-driver in the same manner as during a non-kdump boot.
> 4. If an IO-device has no driver in the kdump kernel, it is simply left alone.
>This supports the practice of creating a special kdump kernel without
>drivers for any devices that are not required for taking a crashdump. 
> 
> Changes since the RFC version of this patch:
> 1. Consolidated all of the operational code into the "copy..." functions.
>The "process..." functions were primarily used for diagnostics and
>exploration; however, there was a small amount of operational code that
>used the "process..." functions.
>This operational code has been moved into the "copy..." functions.
> 
> 2. Removed the "Process ..." functions and the diagnostic code that ran
>on that function set.  This removed about 1/4 of the code -- which this
>operational patch set no longer needs.  These portions of the RFC patch
>could be formatted as a separate patch and submitted independently
>at a later date. 
> 
> 3. Re-formatted the code to the Linux Coding Standards.
>The checkpatch script still finds some lines to complain about;
>however most of these lines are either (1) lines that I did not change,
>or (2) lines that only changed by adding a level of indent which pushed
>them over 80-characters, or (3) new lines whose intent is far clearer when
>longer

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[joeyli]

於 四，2013-12-19 於 20:22 -0800，H. Peter Anvin 提到：
> On 12/19/2013 08:05 PM, joeyli wrote:
> > 
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
> > 
> 
> According to the Microsoft requirements documents, such a platform is
> broken and shouldn't exist.

OK~~

> 
> > I look forward to Borislav's "EFI runtime mapping" to fix the physical
> > address accessing issue of EFI time service on x86_64 machines. I tested
> > his patches on a issue machine and it works for walk around BIOS bug.
> > 
> > Can we use EFI time services on x86_64 after Borislav's patches accepted
> > to mainline?
> > 
> 
> No.
> 
>   -hpa

If don't use EFI time, then the first priority is using ACPI TAD if it
present. Due to ACPI TAD is a generic acpi device that's need OS parsing
DSDT table before set system time.

Either move DSDT parser from subsystem initial stage to start_kernel or
move timekeeping initial to after DSDT be parsed. Which one you think is
more possible and risk less? Then I will try that way.


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/

Re: [PATCH V2] perf tools: Fix bug for perf kvm report without guestmount.

[Dongsheng Yang]

On 12/20/2013 12:31 AM, David Ahern wrote:

On 12/16/13, 9:26 AM, Dongsheng Yang wrote:

Currently, if we use perf kvm --guestkallsyms --guestmodules report,
we can not get the perf information from perf data file. The all sample
are shown as unknown.

Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules 
/tmp/modules record -a sleep 1

[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest 
(~27260 samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules 
/tmp/modules report |grep %

   100.00%  [guest/6471]  [unknown] [g] 0x8164f330

This bug was introduced by 207b57926 (perf kvm: Fix regression with 
guest machine creation).


commit 207b5792696206663a38e525b9793644895bad3b
Author: David Ahern 
Date:   Sun Jul 1 16:11:37 2012 -0600

 perf kvm: Fix regression with guest machine creation

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index c3e399b..56142d0 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -926,7 +926,7 @@ static struct machine *
 else
 pid = event->ip.pid;

-   return perf_session__find_machine(session, pid);
+   return perf_session__findnew_machine(session, pid);
 }

 return perf_session__find_host_machine(session);


Adding the diff to the commit message confuses git-am. Resubmit the 
patch with just the commit id that introduced the change.


In original code, it uses perf_session__find_machine(), it means we 
deliver symbol to machine
which has the same pid, if no machine found, deliver it to *default* 
guest. But if we use
perf_session__findnew_machine() here, if no machine was found, new 
machine with pid will be built
and added. Then the default guest which with pid == 0 will never get 
a symbol.


And because the new machine initialized here has no kernel map 
created, the symbol delivered to

it will be marked as "unknown".

This patch here is to revert commit 207b57926 and fix the SEGFAULT 
bug in another way.


Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules record -a sleep 1

[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest 
(~28437 samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules report |grep %
22.64%:6471  [guest.kernel.kallsyms]  [g] 
update_rq_clock.part.70

19.99%:6471  [guest.kernel.kallsyms]  [g] d_free
18.46%:6471  [guest.kernel.kallsyms]  [g] bio_phys_segments
16.25%:6471  [guest.kernel.kallsyms]  [g] dequeue_task
12.78%:6471  [guest.kernel.kallsyms]  [g] __switch_to
 7.91%:6471  [guest.kernel.kallsyms]  [g] scheduler_tick
 1.75%:6471  [guest.kernel.kallsyms]  [g] 
native_apic_mem_write
 0.21%:6471  [guest.kernel.kallsyms]  [g] 
apic_timer_interrupt


Signed-off-by: Dongsheng Yang 
---
 Changelog since V1:
 * More commit message.

  tools/perf/util/session.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 989b2e3..a12dfdd 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -830,6 +830,7 @@ static struct machine *
 struct perf_sample *sample)
  {
  const u8 cpumode = event->header.misc & 
PERF_RECORD_MISC_CPUMODE_MASK;

+struct machine *machine;

  if (perf_guest &&
  ((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -842,7 +843,11 @@ static struct machine *
  else
  pid = sample->pid;

-return perf_session__findnew_machine(session, pid);
+machine = perf_session__find_machine(session, pid);
+if (!machine)
+machine = perf_session__findnew_machine(session,
+DEFAULT_GUEST_KERNEL_ID);
+return machine;
  }

  return &session->machines.host;



And for this change you can add an
Acked-by: David Ahern 

So this patch fixes the behavior for defaulting to a guest machine 
with the --guestkallsyms / --guestmodules options. And for the 
curious, last properly working version of perf-kvm for --guestkallsyms 
+ --guestmodules options is v3.2. Thanks for digging into it the 
regression.


With this patch the only degradation for these options appears to be 
the comm change. I'd like to see it stay [guest/], but was not 
able to find a quick solution for that.




Thank you, David. I will send a v3 soon.

- Yang

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/



--
To unsubscribe from this list: send the line "unsubscribe linu

[PATCH 2/2] x86: intel-mid: sfi_handle_*_dev() should check for pdata error code

[David Cohen]

Prevent sfi_handle_*_dev() to register device in case
intel_mid_sfi_get_pdata() failed to execute.

Since 'NULL' is a valid return value, this patch makes
sfi_handle_*_dev() functions to use IS_ERR() to validate returned pdata.

Signed-off-by: David Cohen 
---
 arch/x86/platform/intel-mid/sfi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/platform/intel-mid/sfi.c 
b/arch/x86/platform/intel-mid/sfi.c
index c67b9a2f48a1..438306ebed05 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -337,6 +337,8 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *pentry,
pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
pentry->name, pentry->irq);
pdata = intel_mid_sfi_get_pdata(dev, pentry);
+   if (IS_ERR(pdata))
+   return;
 
pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
@@ -370,6 +372,8 @@ static void __init sfi_handle_spi_dev(struct 
sfi_device_table_entry *pentry,
spi_info.chip_select);
 
pdata = intel_mid_sfi_get_pdata(dev, &spi_info);
+   if (IS_ERR(pdata))
+   return;
 
spi_info.platform_data = pdata;
if (dev->delay)
@@ -395,6 +399,8 @@ static void __init sfi_handle_i2c_dev(struct 
sfi_device_table_entry *pentry,
i2c_info.addr);
pdata = intel_mid_sfi_get_pdata(dev, &i2c_info);
i2c_info.platform_data = pdata;
+   if (IS_ERR(pdata))
+   return;
 
if (dev->delay)
intel_scu_i2c_device_register(pentry->host_num, &i2c_info);
-- 
1.8.4.2

--
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/2] x86: intel-mid: return proper error code from get_gpio_by_name()

[David Cohen]

get_gpio_by_name() should return an error code instead of hardcoded -1.

Signed-off-by: David Cohen 
---
 arch/x86/platform/intel-mid/sfi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/intel-mid/sfi.c 
b/arch/x86/platform/intel-mid/sfi.c
index 80a52288555c..c67b9a2f48a1 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -224,7 +224,7 @@ int get_gpio_by_name(const char *name)
if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
return pentry->pin_no;
}
-   return -1;
+   return -EINVAL;
 }
 
 void __init intel_scu_device_register(struct platform_device *pdev)
-- 
1.8.4.2

--
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] perf tools: Fix bug for perf kvm report without guestmount.

[David Ahern]

On 12/16/13, 9:26 AM, Dongsheng Yang wrote:

Currently, if we use perf kvm --guestkallsyms --guestmodules report,
we can not get the perf information from perf data file. The all sample
are shown as unknown.

Reproducing steps:
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.624 MB perf.data.guest (~27260 
samples) ]
# perf kvm --guestkallsyms /tmp/kallsyms --guestmodules /tmp/modules 
report |grep %
   100.00%  [guest/6471]  [unknown] [g] 0x8164f330

This bug was introduced by 207b57926 (perf kvm: Fix regression with guest 
machine creation).

commit 207b5792696206663a38e525b9793644895bad3b
Author: David Ahern 
Date:   Sun Jul 1 16:11:37 2012 -0600

 perf kvm: Fix regression with guest machine creation

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index c3e399b..56142d0 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -926,7 +926,7 @@ static struct machine *
 else
 pid = event->ip.pid;

-   return perf_session__find_machine(session, pid);
+   return perf_session__findnew_machine(session, pid);
 }

 return perf_session__find_host_machine(session);


Adding the diff to the commit message confuses git-am. Resubmit the 
patch with just the commit id that introduced the change.



In original code, it uses perf_session__find_machine(), it means we deliver 
symbol to machine
which has the same pid, if no machine found, deliver it to *default* guest. But 
if we use
perf_session__findnew_machine() here, if no machine was found, new machine with 
pid will be built
and added. Then the default guest which with pid == 0 will never get a symbol.

And because the new machine initialized here has no kernel map created, the 
symbol delivered to
it will be marked as "unknown".

This patch here is to revert commit 207b57926 and fix the SEGFAULT bug in 
another way.

Verification steps:
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules record -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.651 MB perf.data.guest (~28437 
samples) ]
# ./perf kvm --guestkallsyms /home/kallsyms --guestmodules 
/home/modules report |grep %
22.64%:6471  [guest.kernel.kallsyms]  [g] 
update_rq_clock.part.70
19.99%:6471  [guest.kernel.kallsyms]  [g] d_free
18.46%:6471  [guest.kernel.kallsyms]  [g] bio_phys_segments
16.25%:6471  [guest.kernel.kallsyms]  [g] dequeue_task
12.78%:6471  [guest.kernel.kallsyms]  [g] __switch_to
 7.91%:6471  [guest.kernel.kallsyms]  [g] scheduler_tick
 1.75%:6471  [guest.kernel.kallsyms]  [g] native_apic_mem_write
 0.21%:6471  [guest.kernel.kallsyms]  [g] apic_timer_interrupt

Signed-off-by: Dongsheng Yang 
---
 Changelog since V1:
 * More commit message.

  tools/perf/util/session.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 989b2e3..a12dfdd 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -830,6 +830,7 @@ static struct machine *
   struct perf_sample *sample)
  {
const u8 cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
+   struct machine *machine;

if (perf_guest &&
((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -842,7 +843,11 @@ static struct machine *
else
pid = sample->pid;

-   return perf_session__findnew_machine(session, pid);
+   machine = perf_session__find_machine(session, pid);
+   if (!machine)
+   machine = perf_session__findnew_machine(session,
+   DEFAULT_GUEST_KERNEL_ID);
+   return machine;
}

return &session->machines.host;



And for this change you can add an
Acked-by: David Ahern 

So this patch fixes the behavior for defaulting to a guest machine with 
the --guestkallsyms / --guestmodules options. And for the curious, last 
properly working version of perf-kvm for --guestkallsyms + 
--guestmodules options is v3.2. Thanks for digging into it the regression.


With this patch the only degradation for these options appears to be the 
comm change. I'd like to see it stay [guest/], but was not able to 
find a quick solution for that.


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/

[PATCH] ASoC: fsl-sai: Use snd_soc_dai_init_dma_data()

[Xiubo Li]

Makes the code slightly shorter

Signed-off-by: Xiubo Li 
---
 sound/soc/fsl/fsl_sai.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 50a797e..9c89f97 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -377,8 +377,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
 {
struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
 
-   cpu_dai->playback_dma_data = &sai->dma_params_tx;
-   cpu_dai->capture_dma_data = &sai->dma_params_rx;
+   snd_soc_dai_init_dma_data(cpu_dai, &sai->dma_params_tx,
+   &sai->dma_params_rx);
 
snd_soc_dai_set_drvdata(cpu_dai, sai);
 
-- 
1.8.4


--
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] ASoC: fsl-sai: Use devm_snd_dmaengine_pcm_register()

[Xiubo Li]

Makes the code slightly shorter

Signed-off-by: Xiubo Li 
---
 sound/soc/fsl/fsl_sai.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 50a797e..39cb9ee 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -454,19 +454,8 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = snd_dmaengine_pcm_register(&pdev->dev, NULL,
+   return devm_snd_dmaengine_pcm_register(&pdev->dev, NULL,
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
-   if (ret)
-   return ret;
-
-   return 0;
-}
-
-static int fsl_sai_remove(struct platform_device *pdev)
-{
-   snd_dmaengine_pcm_unregister(&pdev->dev);
-
-   return 0;
 }
 
 static const struct of_device_id fsl_sai_ids[] = {
@@ -476,8 +465,6 @@ static const struct of_device_id fsl_sai_ids[] = {
 
 static struct platform_driver fsl_sai_driver = {
.probe = fsl_sai_probe,
-   .remove = fsl_sai_remove,
-
.driver = {
.name = "fsl-sai",
.owner = THIS_MODULE,
-- 
1.8.4


--
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.1 7/7] perf ui/tui: Filter messages in log window

[Namhyung Kim]

From: Namhyung Kim 

Press '/' key to input filter string like main hist browser does.

Requested-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
Fixed some memory leaks.  I also updated my perf/tui-v2 branch.

 tools/perf/ui/browsers/log.c | 70 ++--
 1 file changed, 68 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/log.c b/tools/perf/ui/browsers/log.c
index 592e2774e919..9ff1bcb1c972 100644
--- a/tools/perf/ui/browsers/log.c
+++ b/tools/perf/ui/browsers/log.c
@@ -25,7 +25,7 @@ static void ui_browser__file_write(struct ui_browser *browser,
char empty[] = " ";
FILE *fp = perf_log.fp;
bool current_entry = ui_browser__is_current_entry(browser, row);
-   off_t *linemap = perf_log.linemap;
+   off_t *linemap = browser->entries;
unsigned int idx = *(unsigned int *)entry;
unsigned long offset = (unsigned long)browser->priv;
 
@@ -59,9 +59,60 @@ static unsigned int ui_browser__file_refresh(struct 
ui_browser *browser)
return row;
 }
 
+static void log_menu__filter(struct ui_browser *menu, char *filter)
+{
+   char buf[1024];
+   off_t *linemap = NULL;
+   u32 lines = 0;
+   u32 alloc = 0;
+   u32 i;
+
+   if (*filter == '\0') {
+   linemap = perf_log.linemap;
+   lines = perf_log.lines;
+   goto out;
+   }
+
+   for (i = 0; i < perf_log.lines; i++) {
+   fseek(perf_log.fp, perf_log.linemap[i], SEEK_SET);
+   if (fgets(buf, sizeof(buf), perf_log.fp) == NULL)
+   goto error;
+
+   if (strstr(buf, filter) == NULL)
+   continue;
+
+   if (lines == alloc) {
+   off_t *map;
+
+   map = realloc(linemap, (alloc + 128) * 
sizeof(*linemap));
+   if (map == NULL)
+   goto error;
+
+   linemap = map;
+   alloc += 128;
+   }
+
+   linemap[lines++] = perf_log.linemap[i];
+   }
+out:
+   if (menu->entries != perf_log.linemap)
+   free(menu->entries);
+
+   menu->entries = linemap;
+   menu->nr_entries = lines;
+
+   menu->top_idx = 0;
+   menu->index = 0;
+   return;
+
+error:
+   free(linemap);
+}
+
 static int log_menu__run(struct ui_browser *menu)
 {
int key;
+   char buf[64];
unsigned long offset;
 
if (ui_browser__show(menu, "Log messages", "Press 'q' to exit") < 0)
@@ -82,6 +133,14 @@ static int log_menu__run(struct ui_browser *menu)
offset -= 10;
menu->priv = (void *)offset;
continue;
+   case '/':
+   if (ui_browser__input_window("Symbol to show",
+   "Please enter the name of symbol you 
want to see",
+   buf, "ENTER: OK, ESC: Cancel",
+   0) == K_ENTER) {
+   log_menu__filter(menu, buf);
+   }
+   continue;
case K_ESC:
case 'q':
case CTRL('c'):
@@ -104,8 +163,15 @@ int tui__log_window(void)
.refresh= ui_browser__file_refresh,
.seek   = ui_browser__file_seek,
.write  = ui_browser__file_write,
+   .entries= perf_log.linemap,
.nr_entries = perf_log.lines,
};
+   int key;
+
+   key = log_menu__run(&log_menu);
 
-   return log_menu__run(&log_menu);
+   if (log_menu.entries != perf_log.linemap)
+   free(log_menu.entries);
+
+   return key;
 }
-- 
1.7.11.7

--
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/7] perf report: Use pr_*() functions if possible

[Namhyung Kim]

From: Namhyung Kim 

There're some places printing a message to stdout/err directly.  It
should be converted to use proper error printing functions instead.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-report.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 8424053b399a..dcaab5e0bfa7 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -251,8 +251,8 @@ static int process_sample_event(struct perf_tool *tool,
int ret;
 
if (perf_event__preprocess_sample(event, machine, &al, sample) < 0) {
-   fprintf(stderr, "problem processing %d event, skipping it.\n",
-   event->header.type);
+   pr_debug("problem processing %d event, skipping it.\n",
+event->header.type);
return -1;
}
 
@@ -650,7 +650,7 @@ parse_callchain_opt(const struct option *opt, const char 
*arg, int unset)
return -1;
 setup:
if (callchain_register_param(&callchain_param) < 0) {
-   fprintf(stderr, "Can't register callchain params\n");
+   pr_err("Can't register callchain params\n");
return -1;
}
return 0;
@@ -872,7 +872,7 @@ repeat:
}
if (report.mem_mode) {
if (sort__mode == SORT_MODE__BRANCH) {
-   fprintf(stderr, "branch and mem mode incompatible\n");
+   pr_err("branch and mem mode incompatible\n");
goto error;
}
sort__mode = SORT_MODE__MEMORY;
-- 
1.7.11.7

--
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/7] perf tools: Introduce struct perf_log

[Namhyung Kim]

From: Namhyung Kim 

Add new functions to save error messages in a temp file.  It'll be
used by some UI front-ends to see the messages.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile.perf |   1 +
 tools/perf/perf.c|   3 ++
 tools/perf/util/debug.h  |  15 +++
 tools/perf/util/log.c| 105 +++
 4 files changed, 124 insertions(+)
 create mode 100644 tools/perf/util/log.c

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 97a2145e4cc6..ec8184014a76 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -372,6 +372,7 @@ LIB_OBJS += $(OUTPUT)util/stat.o
 LIB_OBJS += $(OUTPUT)util/record.o
 LIB_OBJS += $(OUTPUT)util/srcline.o
 LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/log.o
 
 LIB_OBJS += $(OUTPUT)ui/setup.o
 LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 431798a4110d..bdf7bd8e4394 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -10,6 +10,7 @@
 
 #include "util/exec_cmd.h"
 #include "util/cache.h"
+#include "util/debug.h"
 #include "util/quote.h"
 #include "util/run-command.h"
 #include "util/parse-events.h"
@@ -524,6 +525,7 @@ int main(int argc, const char **argv)
 */
pthread__block_sigwinch();
 
+   perf_log_init();
while (1) {
static int done_help;
int was_alias = run_argv(&argc, &argv);
@@ -543,6 +545,7 @@ int main(int argc, const char **argv)
} else
break;
}
+   perf_log_exit();
 
fprintf(stderr, "Failed to run command '%s': %s\n",
cmd, strerror(errno));
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index 443694c36b03..ea160abc2ae0 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -19,4 +19,19 @@ int ui__warning(const char *format, ...) 
__attribute__((format(printf, 1, 2)));
 
 void pr_stat(const char *fmt, ...);
 
+struct perf_log {
+   FILE *fp;
+   off_t *linemap;
+   u32 lines;
+   u32 nr_alloc;
+   bool seen_newline;
+};
+
+extern struct perf_log perf_log;
+
+int perf_log_init(void);
+int perf_log_exit(void);
+void perf_log_add(const char *msg);
+void perf_log_addv(const char *fmt, va_list ap);
+
 #endif /* __PERF_DEBUG_H */
diff --git a/tools/perf/util/log.c b/tools/perf/util/log.c
new file mode 100644
index ..4a34bed2af44
--- /dev/null
+++ b/tools/perf/util/log.c
@@ -0,0 +1,105 @@
+#include 
+#include 
+#include "util/debug.h"
+
+#define LINEMAP_GROW  128
+
+struct perf_log perf_log = {
+   .seen_newline = true,
+};
+
+int perf_log_init(void)
+{
+   FILE *fp;
+   char name[] = "/tmp/perf-tui-log-XX";
+   int fd = mkstemp(name);
+
+   if (fd < 0)
+   return -1;
+
+   fp = fdopen(fd, "r+");
+   if (fp == NULL) {
+   close(fd);
+   return -1;
+   }
+
+   perf_log.fp = fp;
+
+   return 0;
+}
+
+int perf_log_exit(void)
+{
+   FILE *fp = perf_log.fp;
+   if (fp)
+   fclose(fp);
+
+   free(perf_log.linemap);
+
+   perf_log.fp = NULL;
+   perf_log.linemap = NULL;
+   return 0;
+}
+
+static int grow_linemap(struct perf_log *log)
+{
+   off_t *newmap;
+   int newsize = log->nr_alloc + LINEMAP_GROW;
+
+   newmap = realloc(log->linemap, newsize * sizeof(*log->linemap));
+   if (newmap == NULL)
+   return -1;
+
+   log->nr_alloc = newsize;
+   log->linemap = newmap;
+   return 0;
+}
+
+static int __add_to_linemap(struct perf_log *log, off_t index)
+{
+   if (log->lines == log->nr_alloc)
+   if (grow_linemap(log) < 0)
+   return -1;
+
+   log->linemap[log->lines++] = index;
+   return 0;
+}
+
+static void add_to_linemap(struct perf_log *log, const char *msg, off_t base)
+{
+   const char *pos;
+
+   if (strlen(msg) == 0)
+   return;
+
+   if (log->seen_newline) {
+   if (__add_to_linemap(log, base) < 0)
+   return;
+   }
+
+   if ((pos = strchr(msg, '\n')) != NULL) {
+   log->seen_newline = true;
+   pos++;
+   add_to_linemap(log, pos, base + (pos - msg));
+   } else {
+   log->seen_newline = false;
+   }
+}
+
+void perf_log_add(const char *msg)
+{
+   FILE *fp = perf_log.fp;
+   off_t offset = ftello(fp);
+
+   add_to_linemap(&perf_log, msg, offset);
+
+   fwrite(msg, 1, strlen(msg), fp);
+}
+
+void perf_log_addv(const char *fmt, va_list ap)
+{
+   char buf[4096];
+
+   vsnprintf(buf, sizeof(buf), fmt, ap);
+   perf_log_add(buf);
+}
-- 
1.7.11.7

--
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/

[PATCHSET 0/7] perf tools: A couple of TUI improvements (v2)

[Namhyung Kim]

Hello,

I was playing with TUI code and added two new windows.  One for
showing log messages and another for showing header information.
(Maybe they can be implemented on the GTK code too someday.)

 * changes from v1)
  - fix segfault on perf top (Ingo)
  - split print function handling patch (Arnaldo)
  - add filtering support on log window (Jiri, Ingo)


I put the patches on 'perf/tui-v2' branch in my tree:

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Any feedbacks are more than welcome, thanks
Namhyung


Namhyung Kim (7):
  perf report: Use pr_*() functions if possible
  perf report: Print session information only if --stdio is given
  perf tools: Introduce struct perf_log
  perf tools: Save message when pr_*() was called
  perf ui/tui: Implement log window
  perf ui/tui: Implement header window
  perf ui/tui: Filter messages in log window

 tools/perf/Makefile.perf|   3 +
 tools/perf/builtin-report.c |  24 +++---
 tools/perf/perf.c   |   3 +
 tools/perf/ui/browser.h |   3 +
 tools/perf/ui/browsers/header.c | 116 +++
 tools/perf/ui/browsers/hists.c  |  10 +++
 tools/perf/ui/browsers/log.c| 171 
 tools/perf/util/debug.c |   6 ++
 tools/perf/util/debug.h |  15 
 tools/perf/util/log.c   | 105 
 10 files changed, 445 insertions(+), 11 deletions(-)
 create mode 100644 tools/perf/ui/browsers/header.c
 create mode 100644 tools/perf/ui/browsers/log.c
 create mode 100644 tools/perf/util/log.c

-- 
1.7.11.7

--
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 7/7] perf ui/tui: Filter messages in log window

[Namhyung Kim]

From: Namhyung Kim 

Press '/' key to input filter string like main hist browser does.

Requested-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/log.c | 62 +++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/tools/perf/ui/browsers/log.c b/tools/perf/ui/browsers/log.c
index 592e2774e919..84b708073441 100644
--- a/tools/perf/ui/browsers/log.c
+++ b/tools/perf/ui/browsers/log.c
@@ -25,7 +25,7 @@ static void ui_browser__file_write(struct ui_browser *browser,
char empty[] = " ";
FILE *fp = perf_log.fp;
bool current_entry = ui_browser__is_current_entry(browser, row);
-   off_t *linemap = perf_log.linemap;
+   off_t *linemap = browser->entries;
unsigned int idx = *(unsigned int *)entry;
unsigned long offset = (unsigned long)browser->priv;
 
@@ -59,9 +59,60 @@ static unsigned int ui_browser__file_refresh(struct 
ui_browser *browser)
return row;
 }
 
+static void log_menu__filter(struct ui_browser *menu, char *filter)
+{
+   char buf[1024];
+   off_t *linemap = NULL;
+   u32 lines = 0;
+   u32 alloc = 0;
+   u32 i;
+
+   if (*filter == '\0') {
+   linemap = perf_log.linemap;
+   lines = perf_log.lines;
+   goto out;
+   }
+
+   if (menu->entries != perf_log.linemap)
+   free(menu->entries);
+
+   for (i = 0; i < perf_log.lines; i++) {
+   fseek(perf_log.fp, perf_log.linemap[i], SEEK_SET);
+   if (fgets(buf, sizeof(buf), perf_log.fp) == NULL)
+   goto error;
+
+   if (strstr(buf, filter) == NULL)
+   continue;
+
+   if (lines == alloc) {
+   off_t *map;
+
+   map = realloc(linemap, (alloc + 128) * 
sizeof(*linemap));
+   if (map == NULL)
+   goto error;
+
+   linemap = map;
+   alloc += 128;
+   }
+
+   linemap[lines++] = perf_log.linemap[i];
+   }
+out:
+   menu->entries = linemap;
+   menu->nr_entries = lines;
+
+   menu->top_idx = 0;
+   menu->index = 0;
+   return;
+
+error:
+   free(linemap);
+}
+
 static int log_menu__run(struct ui_browser *menu)
 {
int key;
+   char buf[64];
unsigned long offset;
 
if (ui_browser__show(menu, "Log messages", "Press 'q' to exit") < 0)
@@ -82,6 +133,14 @@ static int log_menu__run(struct ui_browser *menu)
offset -= 10;
menu->priv = (void *)offset;
continue;
+   case '/':
+   if (ui_browser__input_window("Symbol to show",
+   "Please enter the name of symbol you 
want to see",
+   buf, "ENTER: OK, ESC: Cancel",
+   0) == K_ENTER) {
+   log_menu__filter(menu, buf);
+   }
+   continue;
case K_ESC:
case 'q':
case CTRL('c'):
@@ -104,6 +163,7 @@ int tui__log_window(void)
.refresh= ui_browser__file_refresh,
.seek   = ui_browser__file_seek,
.write  = ui_browser__file_write,
+   .entries= perf_log.linemap,
.nr_entries = perf_log.lines,
};
 
-- 
1.7.11.7

--
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 6/7] perf ui/tui: Implement header window

[Namhyung Kim]

From: Namhyung Kim 

Implement a simple, full-screen header window which shows session
header (metadata) information.  Press 'i' key to display the header
window.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile.perf|   1 +
 tools/perf/ui/browser.h |   2 +
 tools/perf/ui/browsers/header.c | 116 
 tools/perf/ui/browsers/hists.c  |   6 +++
 4 files changed, 125 insertions(+)
 create mode 100644 tools/perf/ui/browsers/header.c

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 30aabace33a0..4d046e97d0e7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -491,6 +491,7 @@ ifndef NO_SLANG
   LIB_OBJS += $(OUTPUT)ui/browsers/map.o
   LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
   LIB_OBJS += $(OUTPUT)ui/browsers/log.o
+  LIB_OBJS += $(OUTPUT)ui/browsers/header.o
   LIB_OBJS += $(OUTPUT)ui/tui/setup.o
   LIB_OBJS += $(OUTPUT)ui/tui/util.o
   LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
diff --git a/tools/perf/ui/browser.h b/tools/perf/ui/browser.h
index fff46942a8c7..b77d8728b3f0 100644
--- a/tools/perf/ui/browser.h
+++ b/tools/perf/ui/browser.h
@@ -60,6 +60,8 @@ bool ui_browser__dialog_yesno(struct ui_browser *browser, 
const char *text);
 int ui_browser__input_window(const char *title, const char *text, char *input,
 const char *exit_msg, int delay_sec);
 int tui__log_window(void);
+struct perf_session_env;
+int tui__header_window(struct perf_session_env *env);
 
 void ui_browser__argv_seek(struct ui_browser *browser, off_t offset, int 
whence);
 unsigned int ui_browser__argv_refresh(struct ui_browser *browser);
diff --git a/tools/perf/ui/browsers/header.c b/tools/perf/ui/browsers/header.c
new file mode 100644
index ..b5f0961bf793
--- /dev/null
+++ b/tools/perf/ui/browsers/header.c
@@ -0,0 +1,116 @@
+#include "util/cache.h"
+#include "util/debug.h"
+#include "ui/browser.h"
+#include "ui/ui.h"
+#include "ui/util.h"
+#include "ui/libslang.h"
+#include "util/header.h"
+#include "util/session.h"
+
+static void ui_browser__argv_write(struct ui_browser *browser,
+  void *entry, int row)
+{
+   char **arg = entry;
+   char *str = *arg;
+   char empty[] = " ";
+   bool current_entry = ui_browser__is_current_entry(browser, row);
+   unsigned long offset = (unsigned long)browser->priv;
+
+   if (offset >= strlen(str))
+   str = empty;
+   else
+   str = str + offset;
+
+   ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
+  HE_COLORSET_NORMAL);
+
+   slsmg_write_nstring(str, browser->width);
+}
+
+static int list_menu__run(struct ui_browser *menu)
+{
+   int key;
+   unsigned long offset;
+
+   if (ui_browser__show(menu, "Header information", "Press 'q' to exit") < 
0)
+   return -1;
+
+   while (1) {
+   key = ui_browser__run(menu, 0);
+
+   switch (key) {
+   case K_RIGHT:
+   offset = (unsigned long)menu->priv;
+   offset += 10;
+   menu->priv = (void *)offset;
+   continue;
+   case K_LEFT:
+   offset = (unsigned long)menu->priv;
+   if (offset >= 10)
+   offset -= 10;
+   menu->priv = (void *)offset;
+   continue;
+   case K_ESC:
+   case 'q':
+   case CTRL('c'):
+   key = -1;
+   break;
+   default:
+   continue;
+   }
+
+   break;
+   }
+
+   ui_browser__hide(menu);
+   return key;
+}
+
+static int ui__list_menu(int argc, char * const argv[])
+{
+   struct ui_browser menu = {
+   .entries= (void *)argv,
+   .refresh= ui_browser__argv_refresh,
+   .seek   = ui_browser__argv_seek,
+   .write  = ui_browser__argv_write,
+   .nr_entries = argc,
+   };
+
+   return list_menu__run(&menu);
+}
+
+int tui__header_window(struct perf_session_env *env)
+{
+   int i, argc = 0;
+   char **argv;
+   struct perf_session *session;
+   char *ptr, *pos;
+   size_t size;
+   FILE *fp = open_memstream(&ptr, &size);
+
+   session = container_of(env, struct perf_session, header.env);
+   perf_header__fprintf_info(session, fp, true);
+   fclose(fp);
+
+   for (pos = ptr, argc = 0; (pos = strchr(pos, '\n')) != NULL; pos++)
+   argc++;
+
+   argv = calloc(argc + 1, sizeof(*argv));
+   if (argv == NULL)
+   goto out;
+
+   argv[0] = pos = ptr;
+   for (i = 1; (pos = strchr(pos, '\n')) != NULL; i++) {
+   *pos++ = '\0';
+   argv[i] = pos;
+   }
+
+   

[PATCH 5/7] perf ui/tui: Implement log window

[Namhyung Kim]

From: Namhyung Kim 

Implement a simple, full-screen log window which shows error messages
saved so far.  Press 'l' (lower-case 'L') key to display the log
window.  It'll be used usually with -v option.

Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile.perf   |   1 +
 tools/perf/ui/browser.h|   1 +
 tools/perf/ui/browsers/hists.c |   4 ++
 tools/perf/ui/browsers/log.c   | 111 +
 4 files changed, 117 insertions(+)
 create mode 100644 tools/perf/ui/browsers/log.c

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index ec8184014a76..30aabace33a0 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -490,6 +490,7 @@ ifndef NO_SLANG
   LIB_OBJS += $(OUTPUT)ui/browsers/hists.o
   LIB_OBJS += $(OUTPUT)ui/browsers/map.o
   LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
+  LIB_OBJS += $(OUTPUT)ui/browsers/log.o
   LIB_OBJS += $(OUTPUT)ui/tui/setup.o
   LIB_OBJS += $(OUTPUT)ui/tui/util.o
   LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
diff --git a/tools/perf/ui/browser.h b/tools/perf/ui/browser.h
index 7d45d2f53601..fff46942a8c7 100644
--- a/tools/perf/ui/browser.h
+++ b/tools/perf/ui/browser.h
@@ -59,6 +59,7 @@ int ui_browser__help_window(struct ui_browser *browser, const 
char *text);
 bool ui_browser__dialog_yesno(struct ui_browser *browser, const char *text);
 int ui_browser__input_window(const char *title, const char *text, char *input,
 const char *exit_msg, int delay_sec);
+int tui__log_window(void);
 
 void ui_browser__argv_seek(struct ui_browser *browser, off_t offset, int 
whence);
 unsigned int ui_browser__argv_refresh(struct ui_browser *browser);
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a440e03cd8c2..8cc6f5eaa2cf 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1484,6 +1484,9 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
if (is_report_browser(hbt))
goto do_data_switch;
continue;
+   case 'l':
+   tui__log_window();
+   continue;
case K_F1:
case 'h':
case '?':
@@ -1506,6 +1509,7 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
"s Switch to another data 
file in PWD ('perf report' only)\n"
"P Print histograms to 
perf.hist.N\n"
"V Verbose (DSO names in 
callchains, etc)\n"
+   "l Show log messages\n"
"/ Filter symbol by name");
continue;
case K_ENTER:
diff --git a/tools/perf/ui/browsers/log.c b/tools/perf/ui/browsers/log.c
new file mode 100644
index ..592e2774e919
--- /dev/null
+++ b/tools/perf/ui/browsers/log.c
@@ -0,0 +1,111 @@
+#include 
+
+#include "perf.h"
+#include "util/util.h"
+#include "util/cache.h"
+#include "util/debug.h"
+#include "ui/ui.h"
+#include "ui/util.h"
+#include "ui/browser.h"
+#include "ui/libslang.h"
+#include "ui/keysyms.h"
+#include "ui/tui/tui.h"
+
+static void ui_browser__file_seek(struct ui_browser *browser __maybe_unused,
+ off_t offset __maybe_unused,
+ int whence __maybe_unused)
+{
+   /* do nothing */
+}
+
+static void ui_browser__file_write(struct ui_browser *browser,
+  void *entry, int row)
+{
+   char buf[1024];
+   char empty[] = " ";
+   FILE *fp = perf_log.fp;
+   bool current_entry = ui_browser__is_current_entry(browser, row);
+   off_t *linemap = perf_log.linemap;
+   unsigned int idx = *(unsigned int *)entry;
+   unsigned long offset = (unsigned long)browser->priv;
+
+   fseek(fp, linemap[idx], SEEK_SET);
+   if (fgets(buf, sizeof(buf), fp) == NULL)
+   return;
+
+   ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
+  HE_COLORSET_NORMAL);
+
+   if (offset < strlen(buf))
+   slsmg_write_nstring(&buf[offset], browser->width);
+   else
+   slsmg_write_nstring(empty, browser->width);
+}
+
+static unsigned int ui_browser__file_refresh(struct ui_browser *browser)
+{
+   unsigned int row = 0;
+   unsigned int idx = browser->top_idx;
+
+   while (idx < browser->nr_entries) {
+   ui_browser__gotorc(browser, row, 0);
+   browser->write(browser, &idx, row);
+   if (++row == browser->height)
+   break;
+
+   ++idx;
+   }
+
+   return row;
+}
+
+static int log_menu__run(struct ui_browser *menu)
+{
+   int 

[PATCH 4/7] perf tools: Save message when pr_*() was called

[Namhyung Kim]

From: Namhyung Kim 

The message will be saved in a temp file so that it can be shown at a
UI dialog at any time.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/debug.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index 299b55586502..f55b499c93fb 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -19,12 +19,18 @@ bool dump_trace = false, quiet = false;
 static int _eprintf(int level, const char *fmt, va_list args)
 {
int ret = 0;
+   va_list ap;
 
if (verbose >= level) {
+   va_copy(ap, args);
+
if (use_browser >= 1)
ui_helpline__vshow(fmt, args);
else
ret = vfprintf(stderr, fmt, args);
+
+   perf_log_addv(fmt, ap);
+   va_end(ap);
}
 
return ret;
-- 
1.7.11.7

--
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/7] perf report: Print session information only if --stdio is given

[Namhyung Kim]

From: Namhyung Kim 

Move those print functions under "if (use_browser == 0)" so that they
cannot interfere TUI output.  Maybe they can handle other UIs later.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-report.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dcaab5e0bfa7..1a120da6b2cd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -482,15 +482,17 @@ static int __cmd_report(struct perf_report *rep)
desc);
}
 
-   if (verbose > 3)
-   perf_session__fprintf(session, stdout);
+   if (use_browser == 0) {
+   if (verbose > 3)
+   perf_session__fprintf(session, stdout);
 
-   if (verbose > 2)
-   perf_session__fprintf_dsos(session, stdout);
+   if (verbose > 2)
+   perf_session__fprintf_dsos(session, stdout);
 
-   if (dump_trace) {
-   perf_session__fprintf_nr_events(session, stdout);
-   return 0;
+   if (dump_trace) {
+   perf_session__fprintf_nr_events(session, stdout);
+   return 0;
+   }
}
 
nr_samples = 0;
-- 
1.7.11.7

--
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 v12 4/4] ARM: dts: Exynos5420: Add device nodes for TMU blocks

[Naveen Krishna Chatradhi]

Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.

This patch adds the device tree nodes to the DT device list.

Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.

Signed-off-by: Leela Krishna Amudala 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Andrew Bresticker 
---
Changes since v11:
  changed the secondary clock name to "tmu_triminfo_apbif"
from "tmu_apbif_triminfo"

Changes since previous version:
1. used lables instead of comment lines
2. pass the same clock as trimfo_apbif clock for TMU channel 2
3. Fixed a coding style problem pointed by Tomasz

 arch/arm/boot/dts/exynos5420.dtsi |   40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index b1fa334..c62cde6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -402,4 +402,44 @@
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
+
+   tmu_cpu0: tmu@1006 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x1006 0x100>;
+   interrupts = <0 65 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   tmu_cpu1: tmu@10064000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x10064000 0x100>;
+   interrupts = <0 183 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   tmu_cpu2: tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = <&clock 318>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
+
+   tmu_cpu3: tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = <&clock 318>, <&clock 319>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
+
+   tmu_gpu: tmu@100a {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = <&clock 319>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
 };
-- 
1.7.10.4

--
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] ASoC: fsl-sai: Remove fsl_sai_remove()

[Xiubo Li]

There is no need of this function and makes the code slightly shorter

Signed-off-by: Xiubo Li 
---
 sound/soc/fsl/fsl_sai.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 50a797e..1868ec3 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -385,19 +385,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
return 0;
 }
 
-static int fsl_sai_dai_remove(struct snd_soc_dai *cpu_dai)
-{
-   cpu_dai->playback_dma_data = NULL;
-   cpu_dai->capture_dma_data = NULL;
-
-   snd_soc_dai_set_drvdata(cpu_dai, NULL);
-
-   return 0;
-}
-
 static struct snd_soc_dai_driver fsl_sai_dai = {
.probe = fsl_sai_dai_probe,
-   .remove = fsl_sai_dai_remove,
.playback = {
.channels_min = 1,
.channels_max = 2,
-- 
1.8.4


--
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] cpufreq: remove sysfs files for CPU which failed to come back after resume

[Viresh Kumar]

There are cases where cpufreq_add_dev() may fail for some CPUs during resume.
With the current code we will still have sysfs cpufreq files for such CPUs, and
struct cpufreq_policy would be already freed for them. Hence any operation on
those sysfs files would result in kernel warnings.

To fix this, lets remove those sysfs files or put the associated kobject in case
of such errors. Also, to make it simple lets remove the sysfs links from all the
CPUs (except policy->cpu) during suspend as that operation wouldn't result with 
a
loss of sysfs file permissions. And so we will create those links during resume
as well.

Reported-and-tested-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 61 ---
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..cea96c9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -845,8 +845,7 @@ static void cpufreq_init_policy(struct cpufreq_policy 
*policy)
 
 #ifdef CONFIG_HOTPLUG_CPU
 static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy,
- unsigned int cpu, struct device *dev,
- bool frozen)
+ unsigned int cpu, struct device *dev)
 {
int ret = 0;
unsigned long flags;
@@ -877,9 +876,7 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy 
*policy,
}
}
 
-   /* Don't touch sysfs links during light-weight init */
-   if (!frozen)
-   ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
+   ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
 
return ret;
 }
@@ -926,6 +923,27 @@ err_free_policy:
return NULL;
 }
 
+static void cpufreq_policy_put_kobj(struct cpufreq_policy *policy)
+{
+   struct kobject *kobj;
+   struct completion *cmp;
+
+   down_read(&policy->rwsem);
+   kobj = &policy->kobj;
+   cmp = &policy->kobj_unregister;
+   up_read(&policy->rwsem);
+   kobject_put(kobj);
+
+   /*
+* We need to make sure that the underlying kobj is
+* actually not referenced anymore by anybody before we
+* proceed with unloading.
+*/
+   pr_debug("waiting for dropping of refcount\n");
+   wait_for_completion(cmp);
+   pr_debug("wait complete\n");
+}
+
 static void cpufreq_policy_free(struct cpufreq_policy *policy)
 {
free_cpumask_var(policy->related_cpus);
@@ -986,7 +1004,7 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
list_for_each_entry(tpolicy, &cpufreq_policy_list, policy_list) {
if (cpumask_test_cpu(cpu, tpolicy->related_cpus)) {
read_unlock_irqrestore(&cpufreq_driver_lock, flags);
-   ret = cpufreq_add_policy_cpu(tpolicy, cpu, dev, frozen);
+   ret = cpufreq_add_policy_cpu(tpolicy, cpu, dev);
up_read(&cpufreq_rwsem);
return ret;
}
@@ -1096,7 +1114,10 @@ err_get_freq:
if (cpufreq_driver->exit)
cpufreq_driver->exit(policy);
 err_set_policy_cpu:
+   if (frozen)
+   cpufreq_policy_put_kobj(policy);
cpufreq_policy_free(policy);
+
 nomem_out:
up_read(&cpufreq_rwsem);
 
@@ -1118,7 +1139,7 @@ static int cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif)
 }
 
 static int cpufreq_nominate_new_policy_cpu(struct cpufreq_policy *policy,
-  unsigned int old_cpu, bool frozen)
+  unsigned int old_cpu)
 {
struct device *cpu_dev;
int ret;
@@ -1126,10 +1147,6 @@ static int cpufreq_nominate_new_policy_cpu(struct 
cpufreq_policy *policy,
/* first sibling now owns the new sysfs dir */
cpu_dev = get_cpu_device(cpumask_any_but(policy->cpus, old_cpu));
 
-   /* Don't touch sysfs files during light-weight tear-down */
-   if (frozen)
-   return cpu_dev->id;
-
sysfs_remove_link(&cpu_dev->kobj, "cpufreq");
ret = kobject_move(&policy->kobj, &cpu_dev->kobj);
if (ret) {
@@ -1196,7 +1213,7 @@ static int __cpufreq_remove_dev_prepare(struct device 
*dev,
if (!frozen)
sysfs_remove_link(&dev->kobj, "cpufreq");
} else if (cpus > 1) {
-   new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
+   new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu);
if (new_cpu >= 0) {
update_policy_cpu(policy, new_cpu);
 
@@ -1218,8 +1235,6 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
int ret;
unsigned long flags;
struct cpufreq_policy *policy;
-   struct kobject *kobj;
-   struct completion *cmp;
 

[PATCH v2 1/2] phy: phy-core: increment refcounting variables only on 'success'

[Kishon Vijay Abraham I]

Increment 'init_count' only if the 'init' callback succeeded and decrement
'init_count' only if the 'exit' callback succeded. Increment 'power_count'
only if 'power_on' callback succeded and if it failed disable the clocks using
phy_pm_runtime_put_sync(). Also decrement 'power_count' only if 'power_off'
callback succeded and if it failed do not disable the clocks.

Reported-by: George Cherian 
Signed-off-by: Kishon Vijay Abraham I 
---
Changes from v1:
Fixed power_off to call phy_pm_runtime_put only when there is no error in
power_off callback

 drivers/phy/phy-core.c |   22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..27b8f3f 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -155,13 +155,14 @@ int phy_init(struct phy *phy)
return ret;
 
mutex_lock(&phy->mutex);
-   if (phy->init_count++ == 0 && phy->ops->init) {
+   if (phy->init_count == 0 && phy->ops->init) {
ret = phy->ops->init(phy);
if (ret < 0) {
dev_err(&phy->dev, "phy init failed --> %d\n", ret);
goto out;
}
}
+   ++phy->init_count;
 
 out:
mutex_unlock(&phy->mutex);
@@ -179,13 +180,14 @@ int phy_exit(struct phy *phy)
return ret;
 
mutex_lock(&phy->mutex);
-   if (--phy->init_count == 0 && phy->ops->exit) {
+   if (phy->init_count == 1 && phy->ops->exit) {
ret = phy->ops->exit(phy);
if (ret < 0) {
dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
goto out;
}
}
+   --phy->init_count;
 
 out:
mutex_unlock(&phy->mutex);
@@ -203,16 +205,20 @@ int phy_power_on(struct phy *phy)
return ret;
 
mutex_lock(&phy->mutex);
-   if (phy->power_count++ == 0 && phy->ops->power_on) {
+   if (phy->power_count == 0 && phy->ops->power_on) {
ret = phy->ops->power_on(phy);
if (ret < 0) {
dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
goto out;
}
}
+   ++phy->power_count;
+   mutex_unlock(&phy->mutex);
+   return 0;
 
 out:
mutex_unlock(&phy->mutex);
+   phy_pm_runtime_put_sync(phy);
 
return ret;
 }
@@ -223,19 +229,19 @@ int phy_power_off(struct phy *phy)
int ret = -ENOTSUPP;
 
mutex_lock(&phy->mutex);
-   if (--phy->power_count == 0 && phy->ops->power_off) {
+   if (phy->power_count == 1 && phy->ops->power_off) {
ret =  phy->ops->power_off(phy);
if (ret < 0) {
dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
-   goto out;
+   mutex_unlock(&phy->mutex);
+   return ret;
}
}
-
-out:
+   --phy->power_count;
mutex_unlock(&phy->mutex);
phy_pm_runtime_put(phy);
 
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
 
-- 
1.7.10.4

--
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 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user

[Joonsoo Kim]

On Thu, Dec 19, 2013 at 06:15:20PM -0800, Andrew Morton wrote:
> On Fri, 20 Dec 2013 10:58:10 +0900 Joonsoo Kim  wrote:
> 
> > On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote:
> > > On Wed, 18 Dec 2013 15:53:59 +0900 Joonsoo Kim  
> > > wrote:
> > > 
> > > > If parallel fault occur, we can fail to allocate a hugepage,
> > > > because many threads dequeue a hugepage to handle a fault of same 
> > > > address.
> > > > This makes reserved pool shortage just for a little while and this cause
> > > > faulting thread who can get hugepages to get a SIGBUS signal.
> > > > 
> > > 
> > > So if I'm understanding this correctly...  if N threads all generate a
> > > fault against the same address, they will all dive in and allocate a
> > > hugepage, will then do an enormous memcpy into that page and will then
> > > attempt to instantiate the page in pagetables.  All threads except one
> > > will lose the race and will free the page again!  This sounds terribly
> > > inefficient; it would be useful to write a microbenchmark which
> > > triggers this scenario so we can explore the impact.
> > 
> > Yes, you understand correctly, I think.
> > 
> > I have an idea to prevent this overhead. It is that marking page when it
> > is zeroed and unmarking when it is mapped to page table. If page mapping
> > is failed due to current thread, the zeroed page will keep the marker and
> > later we can determine if it is zeroed or not.
> 
> Well OK, but the other threads will need to test that in-progress flag
> and then do .  Where  will involve some form of
> open-coded sleep/wakeup thing.  To avoid all that wheel-reinventing we
> can avoid using an internal flag and use an external flag instead. 
> There's one in struct mutex!

My idea consider only hugetlb_no_page() and doesn't need a sleep.
It just set  page flag after zeroing and if some thread takes
the page with this flag when faulting, simply use it without zeroing.

> 
> I doubt if the additional complexity of the external flag is worth it,
> but convincing performance testing results would sway me ;) Please have
> a think about it all.
> 
> > If you want to include this functionality in this series, I can do it ;)
> > Please let me know your decision.
> > 
> > > I'm wondering if a better solution to all of this would be to make
> > > hugetlb_instantiation_mutex an array of, say, 1024 mutexes and index it
> > > with a hash of the faulting address.  That will 99.9% solve the
> > > performance issue which you believe exists without introducing this new
> > > performance issue?
> > 
> > Yes, that approach would solve the performance issue.
> > IIRC, you already suggested this idea roughly 6 months ago and it is
> > implemented by Davidlohr. I remembered that there is a race issue on
> > COW case with this approach. See following link for more information.
> > https://lkml.org/lkml/2013/8/7/142
> 
> That seems to be unrelated to hugetlb_instantiation_mutex?

Yes, it is related to hugetlb_instantiation_mutex. In the link, I mentioned
about race condition of table mutex patches which is for replacing
hugetlb_instantiation_mutex, although conversation isn't easy to follow-up.

> 
> > And we need 1-3 patches to prevent other theorectical race issue
> > regardless any approaches.
> 
> Yes, I'll be going through patches 1-12 very soon, thanks.

Okay. Thanks :)

> 
> 
> And to reiterate: I'm very uncomfortable mucking around with
> performance patches when we have run no tests to measure their
> magnitude, or even whether they are beneficial at all!

Okay. I will keep in mind it. :)

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: [PATCH 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid

[Richard Guy Briggs]

On 13/12/17, Peter Zijlstra wrote:
> On Mon, Dec 16, 2013 at 05:20:51PM -0500, Richard Guy Briggs wrote:
> 
>  >  static inline bool is_idle_task(const struct task_struct *p)
>  >  {
>  > -  return p->pid == 0;
>  > +  return task_pid(p) == &init_struct_pid;
>  >  }
> 
> > I'll stick with task_pid_nr(p) == 0.
> 
> We're going to probably switch to:
> 
>   return p->flags & PF_IDLE;
> 
> Soon, because people are playing silly tricks and want normal threads
> to temporarily appear to be the idle thread (idle time injection).

Ok, this addresses my concerns.  I'll stay out of the way.

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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] pid: change task_struct::pid to read-only

[Richard Guy Briggs]

On 13/12/17, Peter Zijlstra wrote:
> On Mon, Dec 16, 2013 at 04:03:38PM -0500, Richard Guy Briggs wrote:
> > task->pid is only ever assigned once (well ok, twice).  For system health 
> > and
> > secure logging confidence, make it const to make it much more intentional 
> > when
> > it is being changed.
> > ---
> > 
> > Peter, as you had suggested, does this approach work for you in terms of 
> > making
> > task_struct::pid a lot more difficult to accidentally change to try to 
> > preserve
> > its integrity?
> 
> Yeah, looks good to me.

Ok, who would carry this patch?  You?  AKPM?  Me?

Any opinions about Oleg's macro idea?

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user

[Joonsoo Kim]

Hello, Davidlohr.

On Thu, Dec 19, 2013 at 06:31:21PM -0800, Davidlohr Bueso wrote:
> On Thu, 2013-12-19 at 17:02 -0800, Andrew Morton wrote:
> > On Wed, 18 Dec 2013 15:53:59 +0900 Joonsoo Kim  
> > wrote:
> > 
> > > If parallel fault occur, we can fail to allocate a hugepage,
> > > because many threads dequeue a hugepage to handle a fault of same address.
> > > This makes reserved pool shortage just for a little while and this cause
> > > faulting thread who can get hugepages to get a SIGBUS signal.
> > > 
> > > To solve this problem, we already have a nice solution, that is,
> > > a hugetlb_instantiation_mutex. This blocks other threads to dive into
> > > a fault handler. This solve the problem clearly, but it introduce
> > > performance degradation, because it serialize all fault handling.
> > > 
> > > Now, I try to remove a hugetlb_instantiation_mutex to get rid of
> > > performance degradation.
> > 
> > So the whole point of the patch is to improve performance, but the
> > changelog doesn't include any performance measurements!
> > 
> > Please, run some quantitative tests and include a nice summary of the
> > results in the changelog.
> 
> I was actually spending this afternoon testing these patches with Oracle
> (I haven't seen any issues so far) and unless Joonsoo already did so, I
> want to run these by the libhugetlb test cases - I got side tracked by
> futexes though :/

Really thanks for your time to test these patches.
I already did libhugetlbfs test cases and passed it.

> 
> Please do consider that performance wise I haven't seen much in
> particular. The thing is, I started dealing with this mutex once I
> noticed it as the #1 hot lock in Oracle DB starts, but then once the
> faults are done, it really goes away. So I wouldn't say that the mutex
> is a bottleneck except for the first few minutes.

What I want to be sure is for the first few minutes you mentioned.
If possible, let me know the result like as following link.
https://lkml.org/lkml/2013/7/12/428

Thanks in advance. :)

> > 
> > This is terribly important, because if the performance benefit is
> > infinitesimally small or negative, the patch goes into the bit bucket ;)
> 
> Well, this mutex is infinitesimally ugly and needs to die (as long as
> performance isn't hurt).

Yes, I agreed.

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: [PATCH -tip v6 06/22] [BUGFIX] x86: Prohibit probing on memcpy/memset

[Masami Hiramatsu]

(2013/12/20 12:07), Jovi Zhangwei wrote:
> On Fri, Dec 20, 2013 at 10:37 AM, Masami Hiramatsu
>  wrote:
>> Hi Jovi,
>>
>> (2013/12/19 18:37), Jovi Zhangwei wrote:
>>> Hi Masami,
>>>
>>> On Thu, Dec 19, 2013 at 5:04 PM, Masami Hiramatsu
>>>  wrote:
 memcpy/memset functions are fundamental functions and
 those are involved in kprobe's exception handling.
 Prohibit probing on them to avoid kernel crash.

>>> Would you please let me know the LKML link of that bugfix, I cannot
>>> find it in my LKML fold.
>>
>> Yeah, that was found in my testing environment.
>>
>>> No objection on this patch. :) just want to know more, It seems there
>>> have no problem to probe memcpy in my box, maybe I didn't hit the
>>> crash code path.
>>
>> Ah, I see. Originally the problem happened when I put a probe on
>> __memcpy. And it looks the instances of memcpy and __memcpy are
>> same on x86-64. Thus I decided to blacklist both. (memset/__memset too)
>> Have you ever tried to probe __memcpy on your box?
>>
> Hmm, still no crash, __memcpy and __memset are both tested.
> 
> I use below kprobe related config:
> 
> CONFIG_KPROBES=y
> CONFIG_JUMP_LABEL=y
> CONFIG_OPTPROBES=y
> CONFIG_KPROBES_ON_FTRACE=y

Hmm, I've added some debugging options.

CONFIG_SLUB_DEBUG=y
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PNP_DEBUG_MESSAGES=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_BOOT_PARAMS=y

I guess some of them might cause it.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@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: [PATCH] apparmor: remove the "task" arg from may_change_ptraced_domain()

[Richard Guy Briggs]

On 13/12/18, Oleg Nesterov wrote:
> On 12/18, Richard Guy Briggs wrote:
> >
> > Bcc: r...@redhat.com
> > Subject: Re: [PATCH] apparmor: remove the "task" arg from
> >  may_change_ptraced_domain()
> > Reply-To:
> > In-Reply-To: <20130926132519.gy13...@madcap2.tricolour.ca>
> 
> The subject is empty ;) I changed it to match the above.

HTH?!?  Thanks for adding it.  (more below...)

> > On 13/09/26, Richard Guy Briggs wrote:
> > > On Tue, Sep 24, 2013 at 06:44:42PM +0200, Oleg Nesterov wrote:
> > > > On 09/23, Richard Guy Briggs wrote:
> > > > >
> > > > > On Mon, Sep 16, 2013 at 04:20:35PM +0200, Oleg Nesterov wrote:
> > > > > > Unless task == current ptrace_parent(task) is not safe even under
> > > > > > rcu_read_lock() and most of the current users are not right.
> > > > >
> > > > > Could you point to an explanation of this?
> > > >
> > > > If this task exits before rcu_read_lock() ->parent can point to the
> > > > already freed/reused memory.
> > >
> > > Ok, understood.  So even though the task may have exited, the task
> > > struct pointer is still valid, but not the contents of the task struct
> > > to which it points.
> >
> > [The thread also relates to the patch
> > "pid: get ppid pid_t of task in init_pid_ns safely"
> > in which sys_getppid() (which appears safe) is replaced with something that
> > references the init_pid_ns rather than current's pid_ns.]
> >
> > So, in the general case, that call is not safe, and we should at least
> > remove the task_struct argument.
> 
> I changed my mind, please see the recent discussion with Paul:
> 
>   http://marc.info/?t=13862628191
> 
> instead we should document why ptrace_parent() is safe without pid_alive().

Interesting.  I wasn't aware of pid_alive(), but that would certainly
help.

> I hope that the change in apparmor was fine anyway.

Yes, I'm fine with apparmor change, if it was deemed that the ppid
wasn't needed.  If it is, then it should use this new task_ppid_nr().
Better yet I think to generalize it to anticipate auditd in containers.

> Otherwise I can't understand your email, at least right now... I do not
> know how/where audit uses parent/real_parent.

It uses real_parent to include the ppid number of a process in a couple
of log records.

> But yes, unless tsk == current, the usage of tsk->*parent is not safe even
> under rcu_read_lock() unless you verify that this task was not unhashed.

As I said, the only case I can see is in copy_process() when a signal is
pending when neither CLONE_PARENT nor CLONE_THREAD is passed to it.
Still, that is enough to need to check it.

> ptrace_parent() is safe because it checks ->ptrace. Previously I thought
> we should not rely on this, but the additional pid_alive() looks ugly so
> it would be better to simply document this. I'll send the patch.

So what are you saying?  I should use pid_alive() inside the
rcu_read_lock() to verify it is not unhashed since I don't have anything
to do with ->ptrace or any other task lock?  In fact, the answer is
under my nose in __task_pid_nr_ns(), which already uses this approach.
And rcu_read_lock() can be nested.

> Oleg.

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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 06/14] rtc-efi: register rtc-efi device when EFI enabled

[H. Peter Anvin]

On 12/19/2013 08:24 PM, joeyli wrote:
> 
> I agreed, but userspace application should not be too often to access
> RTC. Maybe only when system boot and set timezone.
> 

This is, quite frankly, an idiotic argument.  Userspace doesn't access
the RTC, the kernel does, and if the underlying implementation is broken
it doesn't matter if it is accessed one time or a thousand.  For the
record, in most cases the RTC gets accessed about every 15 minutes to
update the time based on network time.

-hpa


--
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 06/14] rtc-efi: register rtc-efi device when EFI enabled

[joeyli]

於 四，2013-12-19 於 14:09 +，Matt Fleming 提到：
> On Thu, 19 Dec, at 03:51:47PM, Lee, Chun-Yi wrote:
> > UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() 
> > are also
> > supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
> > 
> > This patch changed RTC_DRV_EFI configuration to depend on EFI but not just 
> > IA64. It
> > checks efi_enabled flag and efi-rtc driver should enabled.
> > 
> > Cc: Matt Fleming 
> > Cc: H. Peter Anvin 
> > Cc: Matthew Garrett 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: Jan Beulich 
> > Signed-off-by: Lee, Chun-Yi 
> > ---
> >  arch/x86/platform/efi/efi.c |   17 +
> >  drivers/rtc/Kconfig |2 +-
> >  2 files changed, 18 insertions(+), 1 deletions(-)
> 
> This patch needs to be justified. Enabling the EFI runtime *Time
> functions just because they're available isn't good enough. We need to
> know why this patch improves things, what use case does it solve?
> 

The main purpose of enable efi-rtc driver is providing interface to
userspace access timezone field in EFI time services.

Currently have two BIOS interfaces provided the timezone field accessing
ability, ACPI TAD and EFI. I hope can enable them on x86_64 machines.

> The general attitude has been that we want to invoke the runtime
> services less, not more, due to the huge variety of runtime
> implementation bugs.
> 

I agreed, but userspace application should not be too often to access
RTC. Maybe only when system boot and set timezone.


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/

Re: [PATCH 2/4] misc: xgene: Add base driver for APM X-Gene SoC Queue Manager/Traffic Manager

[Greg KH]

A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://daringfireball.net/2007/07/on_top

On Thu, Dec 19, 2013 at 07:41:13PM -0800, Ravi Patel wrote:
> There is no need to talk to this driver from userspace.
> It is a device which is used by other IO devices to communicate with each
> other, including CPU.
> For example, if CPU (software) wants to send a message to Ethernet HW (i.e.
> send packet),
> it used this driver to enqueue a message to Ethernet.
> In other direction, if Ethernet HW receives a packet, it uses QM/TM device to
> send message to
> CPU (software) to process packet.

So it's a "bus" type of thing, right?

My question of "why isn't this reflected in the driver model" still
stands.

thanks,

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/

[PATCH] ASoC: fsl-sai: Remove fsl_sai_remove()

[Xiubo Li]

There is no need of this function and makes the code slightly shorter

Signed-off-by: Xiubo Li 
---
 sound/soc/fsl/fsl_sai.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 50a797e..1868ec3 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -385,19 +385,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
return 0;
 }
 
-static int fsl_sai_dai_remove(struct snd_soc_dai *cpu_dai)
-{
-   cpu_dai->playback_dma_data = NULL;
-   cpu_dai->capture_dma_data = NULL;
-
-   snd_soc_dai_set_drvdata(cpu_dai, NULL);
-
-   return 0;
-}
-
 static struct snd_soc_dai_driver fsl_sai_dai = {
.probe = fsl_sai_dai_probe,
-   .remove = fsl_sai_dai_remove,
.playback = {
.channels_min = 1,
.channels_max = 2,
-- 
1.8.4


--
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 v6 00/22] kprobes: introduce NOKPROBE_SYMBOL(), cleanup and fixes crash bugs

[Masami Hiramatsu]

(2013/12/20 5:46), Frank Ch. Eigler wrote:
> 
> Hi, Masami -
> 
> 
> masami.hiramatsu.pt wrote:
> 
>> Here is the version 6 of NOKPROBE_SYMBOL series. :)
>> [...]
> 
> Some preliminary results from building these on top of tip/master on
> x86-64.  
> 
> # stap -te "probe kprobe.function("*") {}"
> 
> starts up OK, without crashes, which looks like great progress.

That's a good news :)

>  But a
> closer look indicates that the insertion of kprobes is taking about
> three (!!) orders of magnitude longer than before, as judged by the
> rate of increase of 'wc -l /sys/kernel/debug/kprobes/list'.

Right, because kprobes are not designed for thousands of probes.

>  So, one
> has to let the thing run for several hours just to get all the kprobes
> inserted, never mind letting stress-testing begin.
> 
> For reference, here's the steady-state "perf top" output during all this
> insertion work:
> 
>  54.81%  [kernel][k] _raw_spin_unlock_irqrestore
>  38.13%  [kernel][k] __slab_alloc
>   1.11%  [kernel][k] kprobe_ftrace_handler
>   0.88%  [kernel][k] _raw_spin_unlock_irq

Hmm, interesting. Those probes are registered as disabled?
Thank you,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@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: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[H. Peter Anvin]

On 12/19/2013 08:05 PM, joeyli wrote:
> 
> Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> Present" flag. ACPI spec doesn't have clear definition on this.
> 

According to the Microsoft requirements documents, such a platform is
broken and shouldn't exist.

> I look forward to Borislav's "EFI runtime mapping" to fix the physical
> address accessing issue of EFI time service on x86_64 machines. I tested
> his patches on a issue machine and it works for walk around BIOS bug.
> 
> Can we use EFI time services on x86_64 after Borislav's patches accepted
> to mainline?
> 

No.

-hpa


--
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 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[H. Peter Anvin]

On 12/19/2013 07:54 PM, joeyli wrote:
> Hi hpa, 
> 
> 於 四，2013-12-19 於 06:38 -0800，H. Peter Anvin 提到：
>> Where did you find a platform with "no CMOS" set and a PNP RTC? I find the 
>> expect behavior in that case to be quite ambiguous and it is not at all 
>> clear to me that what you have here is the right thing.
> 
> Actually there doesn't have the box both with "No CMOS" and PNP device. 
> I choice to totally block rtc-cmos driver when "No CMOS RTC" because the
> definition in ACPI spec:
> 
> CMOS RTC Not Present
> 
> If set, indicates that the CMOS RTC is either not implemented, or
> does not exist at the legacy addresses. OSPM uses the Control
> Method Time and Alarm Namespace device instead.
> ^^
> 
> It suggest us using ACPI TAD interface when this flag present. But, I
> agreed your point for this is ambiguous due to ACPI spec didn't clear
> define the relationship between PNP0B0x.
> 
> Maybe we can do more detail check in cmos_init when "No CMOS RTC" set:
>  + check if have ACPI TAD device, then block rtc-cmos
>  + check if no ACPI TAD device, but have PNP0B0x, then we use PNP0b0x.
> 

I think the only thing we should use that bit for is to inhibit the
last-resort probing of I/O ports 0x70-0x73... if at all.

-hpa


--
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 config: ignore generated files in feature-checks

[Chunwei Chen]

>From 362201bf3259cc01c99531766395fdba0c0f3789 Mon Sep 17 00:00:00 2001
From: Chunwei Chen 
Date: Thu, 19 Dec 2013 15:41:22 +0800
Subject: [PATCH] perf config: ignore generated files in feature-checks

1. Rename the test-* binary files to test-*.bin for easier pattern matching as
   suggested by Ingo.
2. Ignore *.bin and *.d files.

Signed-off-by: Chunwei Chen 
---
 tools/perf/config/Makefile  |   6 +-
 tools/perf/config/feature-checks/.gitignore |   2 +
 tools/perf/config/feature-checks/Makefile   | 114 ++--
 3 files changed, 62 insertions(+), 60 deletions(-)
 create mode 100644 tools/perf/config/feature-checks/.gitignore

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index f7d11a8..40e08d1 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -102,7 +102,7 @@ endif
 
 feature_check = $(eval $(feature_check_code))
 define feature_check_code
-  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS="$(LDFLAGS)" 
LIBUNWIND_LIBS="$(LIBUNWIND_LIBS)" -C config/feature-checks test-$1 >/dev/null 
2>/dev/null && echo 1 || echo 0)
+  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) 
CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS="$(LDFLAGS)" 
LIBUNWIND_LIBS="$(LIBUNWIND_LIBS)" -C config/feature-checks test-$1.bin 
>/dev/null 2>/dev/null && echo 1 || echo 0)
 endef
 
 feature_set = $(eval $(feature_set_code))
@@ -150,7 +150,7 @@ CORE_FEATURE_TESTS =\
 # to skip the print-out of the long features list if the file
 # existed before and after it was built:
 #
-ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all.bin),)
   test-all-failed := 1
 else
   test-all-failed := 0
@@ -180,7 +180,7 @@ ifeq ($(feature-all), 1)
   #
   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
 else
-  $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" 
LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) 
>/dev/null 2>&1)
+  $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" 
LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(addsuffix 
.bin,$(CORE_FEATURE_TESTS)) >/dev/null 2>&1)
   $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
 endif
 
diff --git a/tools/perf/config/feature-checks/.gitignore 
b/tools/perf/config/feature-checks/.gitignore
new file mode 100644
index 000..80f3da0
--- /dev/null
+++ b/tools/perf/config/feature-checks/.gitignore
@@ -0,0 +1,2 @@
+*.d
+*.bin
diff --git a/tools/perf/config/feature-checks/Makefile 
b/tools/perf/config/feature-checks/Makefile
index 87e7900..e2bc0ed 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -1,94 +1,94 @@
 
 FILES= \
-   test-all\
-   test-backtrace  \
-   test-bionic \
-   test-dwarf  \
-   test-fortify-source \
-   test-glibc  \
-   test-gtk2   \
-   test-gtk2-infobar   \
-   test-hello  \
-   test-libaudit   \
-   test-libbfd \
-   test-liberty\
-   test-liberty-z  \
-   test-cplus-demangle \
-   test-libelf \
-   test-libelf-getphdrnum  \
-   test-libelf-mmap\
-   test-libnuma\
-   test-libperl\
-   test-libpython  \
-   test-libpython-version  \
-   test-libslang   \
-   test-libunwind  \
-   test-libunwind-debug-frame  \
-   test-on-exit\
-   test-stackprotector-all \
-   test-stackprotector \
-   test-timerfd
+   test-all.bin\
+   test-backtrace.bin  \
+   test-bionic.bin \
+   test-dwarf.bin  \
+   test-fortify-source.bin \
+   test-glibc.bin  \
+   test-gtk2.bin   \
+   test-gtk2-infobar.bin   \
+   test-hello.bin  \
+   test-libaudit.bin   \
+   test-libbfd.bin \
+   test-liberty.bin\
+   test-liberty-z.bin  \
+   test-cplus-demangle.bin \
+   test-libelf.bin \
+   test-libelf-getphdrnum.bin  \
+   test-libelf-mmap.bin\
+   test-libnuma.bin\
+   test-libperl.bin\
+   test-libpython.bin  \
+   test-libpython-version.bin  \
+   test-libslang.bin   \
+   test-libunwind.bin  \
+   test

[PATCH v3 2/2] cpufreq: imx6q: add of_init_opp_table

[John Tobias]

Add a routine check to see if the platform supplied the OPP table.
Incase there's not OPP table exist, it will try to get it.

Signed-off-by: John Tobias 
---
 drivers/cpufreq/imx6q-cpufreq.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 4b3f18e..f261a88 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -187,12 +187,25 @@ static int imx6q_cpufreq_probe(struct platform_device 
*pdev)
goto put_node;
}
 
-   /* We expect an OPP table supplied by platform */
+   /* We expect an OPP table supplied by platform.
+* Just, incase the platform did not supply the OPP
+* table, it will try to get it.
+*/
num = dev_pm_opp_get_opp_count(cpu_dev);
if (num < 0) {
-   ret = num;
-   dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
-   goto put_node;
+   ret = of_init_opp_table(cpu_dev);
+   if (ret < 0) {
+   dev_err(cpu_dev, "failed to init OPP table\n");
+   ret = -ENODEV;
+   goto put_node;
+   }
+
+   num = dev_pm_opp_get_opp_count(cpu_dev);
+   if (num < 0) {
+   ret = num;
+   dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
+   goto put_node;
+   }
}
 
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
-- 
1.8.3.2

--
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 v3 1/2] ARM: imx6sl: Add cpu frequency scaling support

[John Tobias]

Re-use imx6q cpufreq driver to support cpu
frequency scaling on imx6sl.

Signed-off-by: John Tobias 
---
 arch/arm/mach-imx/mach-imx6sl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-imx/mach-imx6sl.c b/arch/arm/mach-imx/mach-imx6sl.c
index 2f952e3..3072e15 100644
--- a/arch/arm/mach-imx/mach-imx6sl.c
+++ b/arch/arm/mach-imx/mach-imx6sl.c
@@ -34,6 +34,13 @@ static void __init imx6sl_fec_init(void)
}
 }
 
+static void __init imx6sl_init_late(void)
+{
+   /* imx6sl reuses imx6q cpufreq driver */
+   if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ))
+   platform_device_register_simple("imx6q-cpufreq", -1, NULL, 0);
+}
+
 static void __init imx6sl_init_machine(void)
 {
struct device *parent;
@@ -70,6 +77,7 @@ DT_MACHINE_START(IMX6SL, "Freescale i.MX6 SoloLite (Device 
Tree)")
.map_io = debug_ll_io_init,
.init_irq   = imx6sl_init_irq,
.init_machine   = imx6sl_init_machine,
+   .init_late  = imx6sl_init_late,
.dt_compat  = imx6sl_dt_compat,
.restart= mxc_restart,
 MACHINE_END
-- 
1.8.3.2

--
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/

linux-next: manual merge of the clockevents tree with Linus' tree

[Stephen Rothwell]

Hi Daniel,

Today's linux-next merge of the clockevents tree got a conflict in
drivers/clocksource/clksrc-of.c between commit 4c4b053235fa
("clocksource: clksrc-of: Do not drop unheld reference on device node")
from Linus' tree and commit fdca679d87bb ("clocksource: clksrc-of: Warn
if no clock sources are found") from the clockevents tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/clocksource/clksrc-of.c
index b9ddd9e3a2f5,a30b42c3ac3b..
--- a/drivers/clocksource/clksrc-of.c
+++ b/drivers/clocksource/clksrc-of.c
@@@ -35,5 -36,9 +36,8 @@@ void __init clocksource_of_init(void
  
init_func = match->data;
init_func(np);
 -  of_node_put(np);
+   clocksources++;
}
+   if (!clocksources)
+   pr_crit("%s: no matching clocksources found\n", __func__);
  }


pgpp_r1TT_8Kw.pgp
Description: PGP signature

Re: [RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME

[joeyli]

於 四，2013-12-19 於 06:59 -0800，H. Peter Anvin 提到：
> On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote:
> > This patchset add the timezone support of ACPI TAD and EFI TIME, it
> > also add codes for adjusting system time base on the timezone value
> > from EFI TIME services when system boot.
> 
> EFI time is something we used to support and ripped out, because it
> doesn't work well, *at all*.
> 
> I am hyper-skeptical to reintroducing them, and *definitely* will veto
> reintroducing them on a system which has PNP0B0x devices present.
> 
>   -hpa
> 

Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
Present" flag. ACPI spec doesn't have clear definition on this.

I look forward to Borislav's "EFI runtime mapping" to fix the physical
address accessing issue of EFI time service on x86_64 machines. I tested
his patches on a issue machine and it works for walk around BIOS bug.

Can we use EFI time services on x86_64 after Borislav's patches accepted
to mainline?


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/

Re: lockdep: BUG: MAX_LOCKDEP_ENTRIES too low!

[Mike Galbraith]

On Thu, 2013-12-19 at 10:59 -0500, Dave Jones wrote: 
> On Thu, Dec 19, 2013 at 04:51:21PM +0100, Peter Zijlstra wrote:
>  > On Thu, Dec 19, 2013 at 10:39:57AM -0500, Sasha Levin wrote:
>  > > That discusses lockdep classes, which is actually fine in my case. I ran 
> out of
>  > > MAX_LOCKDEP_ENTRIES, which isn't mentioned anywhere in Documentation/ .
>  > 
>  > Yeah, it suffers from the same problem though. Lockdep has static
>  > resource allocation and never frees them.
>  > 
>  > The lock classes are the smallest pool and usually run out first, but
>  > the same could happen for the entries, after all, the more classes we
>  > have the more class connections can happen.
>  > 
>  > Anyway, barring a leak and silly class mistakes like mentioned in the
>  > document there's nothing we can do except raise the number.
> 
> I tried this. When you bump it to 32k, it fares better but then you
> start seeing "BUG: MAX_LOCKDEP_CHAINS too low!" instead.
> I've not tried bumping that yet, as I've stopped seeing these lately
> due to hitting more serious bugs first.

I had the same problem while testdriving a 3.6-rt kernel with lots of
debug enabled.. had to double both ENTRIES/CHAINS to keep lockdep from
running away in a snit.

-Mike

--
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 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

[joeyli]

Hi hpa, 

於 四，2013-12-19 於 06:38 -0800，H. Peter Anvin 提到：
> Where did you find a platform with "no CMOS" set and a PNP RTC? I find the 
> expect behavior in that case to be quite ambiguous and it is not at all clear 
> to me that what you have here is the right thing.

Actually there doesn't have the box both with "No CMOS" and PNP device. 
I choice to totally block rtc-cmos driver when "No CMOS RTC" because the
definition in ACPI spec:

CMOS RTC Not Present

If set, indicates that the CMOS RTC is either not implemented, or
does not exist at the legacy addresses. OSPM uses the Control
Method Time and Alarm Namespace device instead.
^^


It suggest us using ACPI TAD interface when this flag present. But, I
agreed your point for this is ambiguous due to ACPI spec didn't clear
define the relationship between PNP0B0x.

Maybe we can do more detail check in cmos_init when "No CMOS RTC" set:
 + check if have ACPI TAD device, then block rtc-cmos
 + check if no ACPI TAD device, but have PNP0B0x, then we use PNP0b0x.

> 
> "Lee, Chun-Yi"  wrote:
> >We should not acess CMOS address when CMOS RTC Not Present bit set in
> >FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when
> >system support
> >ACPI PNP PNP0B0* devices.
> >So this patch block the registion of rtc-cmos driver to avoid
> >user space access RTC through CMOS interface.
> >
> >Signed-off-by: Lee, Chun-Yi 
> >---
> > arch/x86/kernel/rtc.c  |   20 
> > drivers/rtc/rtc-cmos.c |9 +
> > 2 files changed, 25 insertions(+), 4 deletions(-)
> >
...
> >--- a/drivers/rtc/rtc-cmos.c
> >+++ b/drivers/rtc/rtc-cmos.c
> >@@ -28,6 +28,9 @@
> >  * interrupts disabled, holding the global rtc_lock, to exclude those
> >  * other drivers and utilities on correctly configured systems.
> >  */
> >+
> >+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >+
> > #include 
> > #include 
> > #include 
> >@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
> > {
> > int retval = 0;
> > 
> >+if (acpi_gbl_FADT.header.revision >= 5 &&
> >+acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
> >+pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
> >+return 0;
> >+}
> >+
> > #ifdef  CONFIG_PNP
> > retval = pnp_register_driver(&cmos_pnp_driver);
> > if (retval == 0)
> 

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/

linux-next: manual merge of the spi tree with the mpc5xxx tree

[Stephen Rothwell]

Hi Mark,

Today's linux-next merge of the spi tree got a conflict in
drivers/spi/spi-mpc512x-psc.c between commit 9d37619fb37f ("spi: mpc512x:
adjust to OF based clock lookup") from the mpc5xxx tree and commit
e1d0cd473be4 ("spi: mpc512x: Use devm_*() functions") from the spi tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell 

diff --cc drivers/spi/spi-mpc512x-psc.c
index 2babea28b310,46d2313f7c6f..
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@@ -519,10 -519,12 +518,10 @@@ static int mpc512x_psc_spi_do_probe(str
goto free_master;
init_completion(&mps->txisrdone);
  
 -  psc_num = master->bus_num;
 -  snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
 -  clk = devm_clk_get(dev, clk_name);
 +  clk = devm_clk_get(dev, "mclk");
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
-   goto free_irq;
+   goto free_master;
}
ret = clk_prepare_enable(clk);
if (ret)
@@@ -550,15 -542,9 +549,11 @@@
  
return ret;
  
 -free_clock:
 +free_ipg_clock:
 +  clk_disable_unprepare(mps->clk_ipg);
 +free_mclk_clock:
clk_disable_unprepare(mps->clk_mclk);
- free_irq:
-   free_irq(mps->irq, mps);
  free_master:
-   if (mps->psc)
-   iounmap(mps->psc);
spi_master_put(master);
  
return ret;
@@@ -570,10 -556,6 +565,7 @@@ static int mpc512x_psc_spi_do_remove(st
struct mpc512x_psc_spi *mps = spi_master_get_devdata(master);
  
clk_disable_unprepare(mps->clk_mclk);
 +  clk_disable_unprepare(mps->clk_ipg);
-   free_irq(mps->irq, mps);
-   if (mps->psc)
-   iounmap(mps->psc);
  
return 0;
  }


pgpo9JGe9X6GT.pgp
Description: PGP signature

[BUG] LTP test case readahead01 fails after commit 63d0f0a3c7

[Wanlong Gao]

Hi AKPM and folks,

LTP test readahead syscall return value like this:

=
static void test_invalid_fd(void)
{
int fd[2];

tst_resm(TINFO, "test_invalid_fd pipe");
if (pipe(fd) < 0)
tst_resm(TBROK | TERRNO, "Failed to create pipe");
TEST(ltp_syscall(__NR_readahead, fd[0], 0, getpagesize()));
check_ret(-1);
check_errno(EINVAL);
close(fd[0]);
close(fd[1]);

tst_resm(TINFO, "test_invalid_fd socket");
fd[0] = socket(AF_INET, SOCK_STREAM, 0);
if (fd[0] < 0)
tst_resm(TBROK | TERRNO, "Failed to create socket");
TEST(ltp_syscall(__NR_readahead, fd[0], 0, getpagesize()));
check_ret(-1);
check_errno(EINVAL);
close(fd[0]);
}

FULL case code: 
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/readahead/readahead01.c


This case passed before the following kernel commit[1],
it means kernel will return -1 with errno=EINVAL. But after
this commit[1], kernel will return 0 here.

The different between before and after this commit[1] is that:
BEFORE:
=
do_readahead():
if (!mapping || !mapping->a_ops || !mapping->a_ops->readpage)
return EINVAL;


AFTER:
==
do_readahead():
if (!mapping || !mapping->a_ops)
return EINVAL;

And followed with:

force_page_cache_readahead():
if (unlikely(!mapping->a_ops->readpage && !mapping->a_ops->readpages))
return -EINVAL;
=

I think you must know which is right?




Thanks,
Wanlong Gao



[1]:
commit 63d0f0a3c7e1281fd79268a8d988167eff607fb6
Author: Andrew Morton 
Date:   Tue Nov 12 15:07:09 2013 -0800

mm/readahead.c:do_readhead(): don't check for ->readpage

The callee force_page_cache_readahead() already does this and unlike
do_readahead(), force_page_cache_readahead() remembers to check for
->readpages() as well.

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

diff --git a/mm/readahead.c b/mm/readahead.c
index e4ed041..5024183 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -569,7 +569,7 @@ static ssize_t
 do_readahead(struct address_space *mapping, struct file *filp,
 pgoff_t index, unsigned long nr)
 {
-   if (!mapping || !mapping->a_ops || !mapping->a_ops->readpage)
+   if (!mapping || !mapping->a_ops)
return -EINVAL;
 
force_page_cache_readahead(mapping, filp, index, nr);

--
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] audit: listen in all network namespaces

[Gao feng]

On 12/20/2013 11:11 AM, Eric Paris wrote:
> On Fri, 2013-12-20 at 10:46 +0800, Gao feng wrote:
>> On 12/20/2013 02:40 AM, Eric Paris wrote:
>>> On Thu, 2013-12-19 at 11:59 +0800, Gao feng wrote:
 On 07/17/2013 04:32 AM, Richard Guy Briggs wrote:
> 
 we have to store audit_sock
 into auditns(auditns will be passed to kauditd_send_skb),
 this will cause auditns have to get a reference of netns.
 and for some reason(netfilter audit target), netns will
 get reference of auditns too. this is terrible...
>>>
>>> I'm not sure I agree/understand this entirely...
>>>
>>
>> Yes, the audit_sock is created and destroyed by net namespace,
>> so if auditns wants to use audit_sock, it must prevent netns
>> from being destroyed. so auditns has to get reference of netns.
> 
> Namespace == mind blown.  Ok, so:
> 
>  auditd in audit_ns2 and net_ns2. <--- ONLY process in net_ns2
>  some process in audit_ns2 and net_ns3
> 
> Lets assume that auditd is killed improperly/dies.  Because the last
> process in net_ns2 is gone net_ns2 is invalid/freed.
> 
> Today in the kernel the way we detect auditd is gone is by using the
> socket and getting ECONNREFUSSED.  So here you think that audit_ns2
> should hold a reference on net_ns2, to make sure that socket is always
> valid.
> 
> I instead propose that we could run all audit_ns and reset the audit_pid
> in that namespace and the audit_sock in the namespace to 0/null inside
> audit_net_exit.  Since obviously if the net_ns disappeared, the auditd
> which was running in any audit namespace in that net_ns isn't running
> any more.  We didn't need to hold a reference on the net_ns.  We just
> have to clear the skb_queue, reset the audit_pid to 0, and reset the
> socket to NULL...

multi auditns can share the same netns. it happens if you unshare
auditns. if you want to reset audit_sock to null inside audit_net_exit,
you have to maintain a list in netns, this list contains the auditnss
whose audit_sock is created in this netns. so you can foreach this
list and reset the audit socks of audit nss.

Above is unsharing auditns, consider unsharing netns. auditd is running
in auditns1 and netns1, and then who-know-why the auditd call 
unshare(CLONE_NEWNET)
to change it's netns from netns1 to new netns2. so the netns1 is released
and auditns->audit_sock being reset to NULL. the auditd cannot receive
the audit log. auditd will in chaos, "I'm still alive, why kernel think
I'm die?"

So maybe you will say, we can reset the audit_sock of netns2 to auditns.
ok, this is a way. but how can we decide if we should reset the 
auditns->audit_sock?
when we create the new netns, the old netns is still alive, so the 
auditns->audit_sock
is still valid in that time.

I don't know if there are some other problems we should consider.
it is too complex..

> 
> Maybe the one magic socket is the right answer.  I'm not arguing against
> your solution.  I'm really trying to understand why we are going that
> way...
> 

That's why we should discuss :)

--
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] staging: lustre: fix return value check in capa_hmac()

[Wei Yongjun]

From: Wei Yongjun 

In case of error, the function crypto_alloc_hash() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/staging/lustre/lustre/obdclass/capa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/capa.c 
b/drivers/staging/lustre/lustre/obdclass/capa.c
index 68d797b..039232d 100644
--- a/drivers/staging/lustre/lustre/obdclass/capa.c
+++ b/drivers/staging/lustre/lustre/obdclass/capa.c
@@ -273,10 +273,10 @@ int capa_hmac(__u8 *hmac, struct lustre_capa *capa, __u8 
*key)
alg = &capa_hmac_algs[capa_alg(capa)];
 
tfm = crypto_alloc_hash(alg->ha_name, 0, 0);
-   if (!tfm) {
+   if (IS_ERR(tfm)) {
CERROR("crypto_alloc_tfm failed, check whether your kernel"
   "has crypto support!\n");
-   return -ENOMEM;
+   return PTR_ERR(tfm);
}
keylen = alg->ha_keylen;
 

--
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 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Dec 19, 2013 at 07:27:35PM -0800, Ravi Patel wrote:
> APM X-Gene SoC Ethernet driver is planned to be submitted on Dec 20 2013.
> Ethernet driver will be using these exported API's from QMTM driver.

Please submit a user of the api as part of the series, otherwise we
can't evaluate if it's really the correct thing to do or not.

> The APM X-Gene SoC Ethernet driver is going to live in 
> drivers/net/ethernet/apm
> /xgene.

So this is a "bus"?  How is the ethernet device going to show up in
sysfs as a parent of what as this isn't part of the driver model?

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/

Re: [fs] inode_lru_isolate(): Move counter increment into spinlock section

[Dave Chinner]

On Thu, Dec 19, 2013 at 09:26:12AM -0600, Christoph Lameter wrote:
> On Thu, 19 Dec 2013, Dave Chinner wrote:
> 
> > On Wed, Dec 18, 2013 at 07:24:46PM +, Christoph Lameter wrote:
> > > The counter increment in inode_lru_isolate is happening after
> > > spinlocks have been dropped with preemption on using __count_vm_events
> > > making counter increment races possible.
> >
> > That's a nasty, undocumented problem that __count_vm_events() has.
> 
> AFACIT that is a pretty well established and known issue. It only
> affects cases where the fallback code for the counter increments is used.

Maybe for mm developers. Not so filesystem people, and certainly not
the person who made the last set of modifications, even though I do
spend a fair bit of time around the fringes of the MM code...

> > Nobody who is modifying the fs/inode.c code is likely to know about
> > this, so just moving the code under an unrelated lock is not
> > sufficient to prevent this from happening again. Hence I'd prefer
> > that you just change it to use count_vm_events() rather than try to
> > be tricksy by replacing the landmine in the code that we've already
> > stepped on once.
> 
> I have a patchset here that is supposed to be merged soon that will detect
> these cases.
> 
> Moving the code is IMHO the simplest solution. count_vm_events
> will have to disable interrupts on platforms that do not support fast RMV
> operations otherwise.

If count_vm_events requires irqs to be disabled to behave correctly,
then putting __count_vm_events under a spin lock is still not irq
safe. Either way, this isn't in a performance critical path, so I'd
much prefer the simpler, safer option be used rather than leave a
landmine for other unsuspecting developers.

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: [PATCH v2] misc: Reserve minor for VFIO

[Alex Williamson]

On Thu, 2013-12-19 at 21:38 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 18, 2013 at 02:02:38PM -0800, H. Peter Anvin wrote:
> > On 12/18/2013 01:01 PM, Greg KH wrote:
> > > On Wed, Dec 18, 2013 at 01:56:32PM -0700, Alex Williamson wrote:
> > >> VFIO currently allocates it's own dynamic chardev range, reserving the
> > >> first minor for the control part of the interface (/dev/vfio/vfio) and
> > >> the remainder for VFIO groups (/dev/vfio/$GROUP).  This works, but it
> > >> doesn't support auto loading.  For instance when libvirt checks for
> > >> VFIO support it looks for /dev/vfio/vfio, which currently doesn't
> > >> exist unless the vfio module is loaded.  By converting the control
> > >> device to a misc driver and reserving a static minor, we can enable
> > >> auto loading.
> 
> Why not have libvirt or systemctl try to load vfio first? If it does
> not work it would error out.

Kay Sievers made a pass through the kernel a while back adding devname
support to a number of drivers to "remove a bunch of pretty useless init
scripts and modprobes from init scripts".  So I believe this to be the
preferred approach for systemd.  Besides, the init scripts don't know if
the feature is actually being used, so it's a waste to blindly load the
module because you've installed qemu or libvirt.

libvirt also has little interest in loading the module themselves and
frowned on the approach of them loading the module when I proposed it.
VFIO also has scope beyond libvirt, so solving it there only addresses
one use case, granted it's currently the most prevalent use case of
VFIO.

A number of other drivers have adopted the devname model for
auto-loading, kvm, vhost, fuse, dm, tun, ppp, etc, so why not use it
here too?

> Or perhaps make the loading of modules in /dev/vfio automatic? I thought
> it was based on the name?

I don't think I understand the question, this is an effort to do that
for /dev/vfio/vfio.  I don't wish to force this module to be statically
loaded into the kernel, it's only used by a small fraction of users.  To
support autoloading udev needs to know a static major/minor for the
device entry.  It cannot be done with only a name.  I posted a companion
patch to this last week that converts VFIO's control interface to a misc
driver with this static minor to accomplish that.  Thanks,

Alex

> > >>
> > >> Reserving the minor is a prerequist to that conversion.  Minor 196
> > >> is unused by anything currently in the kernel.
> > >>
> > >> Suggested-by: Paolo Bonzini 
> > >> Signed-off-by: Alex Williamson 
> > >> ---
> > >>
> > >> v2: Plea for ack edition
> > >>
> > >> As Alan suspected, there's been no response from dev...@lanana.org,
> > >> so there's probably nobody monitoring it anymore.  I've done due
> > >> diligence looking at all the callers of misc_register() in linux-next
> > >> and cannot find any conflicts with minor 196.  If anyone wants to toss
> > >> me an ack or sign-off I'll be happy to bring this in through my vfio
> > >> tree, otherwise I'd appreciate if someone wants to take it directly.
> > >> Thanks!
> > >>
> > >>  Documentation/devices.txt  |1 +
> > >>  include/linux/miscdevice.h |1 +
> > >>  2 files changed, 2 insertions(+)
> > > 
> > > Acked-by: Greg Kroah-Hartman 
> > > 
> > 
> > I think Alan Cox was the last person to man ... Alan,
> > are you still doing that?  (Otherwise patching the file in the Linux
> > kernel tree seems eminently sensible... there really isn't any need to
> > reserve numbers for out-of-tree drivers anymore.  Just another perk of
> > being in-tree.)
> > 
> > -hpa
> > 
> > 
> > --
> > 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/


--
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 0/2] mmc: sdhci: Workaround Intel Merrifield issue for HS200

[Dong Aisheng]

On Fri, Dec 20, 2013 at 11:25 AM, David Cohen
 wrote:
> On Fri, Dec 20, 2013 at 11:00:23AM +0800, Dong Aisheng wrote:
>> On Wed, Nov 13, 2013 at 5:49 AM, David Cohen
>>  wrote:
>> > On 10/29/2013 10:58 AM, David Cohen wrote:
>> >>
>> >> Hi,
>> >>
>> >> SDHCI used to work well on Intel Merrifield until this patch was applied:
>> >>
>> >> commit 156e14b126ffb6f040bc6f1aff3c51077e42a744
>> >> Author: Giuseppe CAVALLARO 
>> >> Date:   Wed Jun 12 08:16:38 2013 +0200
>> >>
>> >>  mmc: sdhci: fix caps2 for HS200
>> >>
>> >>  Although the HC supports HS200 (eMMC) the caps2 are always zero; this
>> >>  means there's no way to use the super speed mode (when init the
>> >> card).
>> >>
>> >>  If the HC support SDR104, for SD3.0, so it also supports HS200 for
>> >> eMMC
>> >>  and this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
>> >>
>> >> Looks like there is a hw issue with unknown root cause so far.
>> >>
>> >> Is it acceptable to have the quirk I'm proposing to workaround the issue?
>> >
>> >
>> > Ping. Any comments here?
>> >
>>
>> Chris,
>> Can you pick this one?
>> IMX also needs this quirk for imx6q/dl since it can not meet HS200
>> timing requirement.
>>
>>
>> David,
>> Is the unkonwn hw issue in your patch #2 resolved now?
>> If yes, you may not need this quirk.
>> I could resend it with your sign-off with IMX patches.
>
> Merrifield still needs this quirk to not break MMC support.
> This quirk could be applied to 3.13-rc (since merrifield was added to
> sdhci-pci.c on 3.13-rc1).
>

Okay, thanks for the information.
So please take my ACK:
Acked-by: Dong Aisheng 

I will send IMX patches based on it.

Regards
Dong Aisheng

> Br, David
>
>>
>> Regards
>> Dong Aisheng
>>
>> > Br, David Cohen
>> > --
>> > 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/
--
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 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager

[Greg KH]

On Thu, Dec 19, 2013 at 06:44:59PM -0800, Ravi Patel wrote:
> This patch adds support for APM X-Gene SoC Queue Manager/Traffic Manager.
>  QMTM is required by APM X-Gene SoC Ethernet, PktDMA and Security Engine
>  subsystems. All subsystems communicate with QMTM using messages which
>  include information about the work to be performed and the location of
>  associated data buffers.

And finally, where are the drivers that are going to use these apis you
are creating here?  Where are they going to live, and when are they
going to be submitted?

thanks,

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/

Re: [PATCH 2/4] misc: xgene: Add base driver for APM X-Gene SoC Queue Manager/Traffic Manager

[Greg KH]

On Thu, Dec 19, 2013 at 06:45:01PM -0800, Ravi Patel wrote:
> This patch adds APM X-Gene SoC Queue Manager/Traffic Manager base driver.
>  QMTM is requried by Ethernet, PktDMA and Security Engine subsystems.

How does this driver talk to userspace?  Or is it just a "bus" for
devices to attach to and use to talk to the real devices in the system?
If so, why isn't it represented in the driver model?

thanks,

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/

Re: [RFC/PATCH 0/2] mmc: sdhci: Workaround Intel Merrifield issue for HS200

[David Cohen]

On Fri, Dec 20, 2013 at 11:00:23AM +0800, Dong Aisheng wrote:
> On Wed, Nov 13, 2013 at 5:49 AM, David Cohen
>  wrote:
> > On 10/29/2013 10:58 AM, David Cohen wrote:
> >>
> >> Hi,
> >>
> >> SDHCI used to work well on Intel Merrifield until this patch was applied:
> >>
> >> commit 156e14b126ffb6f040bc6f1aff3c51077e42a744
> >> Author: Giuseppe CAVALLARO 
> >> Date:   Wed Jun 12 08:16:38 2013 +0200
> >>
> >>  mmc: sdhci: fix caps2 for HS200
> >>
> >>  Although the HC supports HS200 (eMMC) the caps2 are always zero; this
> >>  means there's no way to use the super speed mode (when init the
> >> card).
> >>
> >>  If the HC support SDR104, for SD3.0, so it also supports HS200 for
> >> eMMC
> >>  and this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
> >>
> >> Looks like there is a hw issue with unknown root cause so far.
> >>
> >> Is it acceptable to have the quirk I'm proposing to workaround the issue?
> >
> >
> > Ping. Any comments here?
> >
> 
> Chris,
> Can you pick this one?
> IMX also needs this quirk for imx6q/dl since it can not meet HS200
> timing requirement.
> 
> 
> David,
> Is the unkonwn hw issue in your patch #2 resolved now?
> If yes, you may not need this quirk.
> I could resend it with your sign-off with IMX patches.

Merrifield still needs this quirk to not break MMC support.
This quirk could be applied to 3.13-rc (since merrifield was added to
sdhci-pci.c on 3.13-rc1).

Br, David

> 
> Regards
> Dong Aisheng
> 
> > Br, David Cohen
> > --
> > 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/
--
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] misc: xgene: Add base driver for APM X-Gene SoC Queue Manager/Traffic Manager

[Greg KH]

On Thu, Dec 19, 2013 at 06:45:01PM -0800, Ravi Patel wrote:
> --- /dev/null
> +++ b/drivers/misc/xgene/qmtm/Kconfig
> @@ -0,0 +1,8 @@
> +config XGENE_QMTM
> + tristate "APM X-Gene QMTM driver"
> + depends on ARCH_XGENE

What does it need from this arch in order to build?  What would be
needed to get it to build on other arches so that it gets some actualy
build testing?


> --- /dev/null
> +++ b/drivers/misc/xgene/qmtm/xgene_qmtm_main.c
> @@ -0,0 +1,765 @@
> +/*
> + * AppliedMicro X-Gene SOC Queue Manager/Traffic Manager driver
> + *
> + * Copyright (c) 2013 Applied Micro Circuits Corporation.
> + * Author: Ravi Patel 
> + * Keyur Chudgar 
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

Are you _sure_ about "any later version"?  I have to ask.

> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .

No need for this paragraph, the kernel has a copy of the GPL in it
already.

> +/* CSR Address Macros */
> +#define CSR_QM_CONFIG_ADDR   
> 0x0004
> +#define  QM_ENABLE_WR(src)  (((u32)(src)<<31) & 
> 0x8000)
> +
> +#define CSR_PBM_ADDR 
> 0x0008
> +#define  OVERWRITE_WR(src)  (((u32)(src)<<31) & 
> 0x8000)
> +#define  SLVID_PBN_WR(src)  (((u32)(src)) & 
> 0x03ff)
> +#define  SLAVE_ID_SHIFT  
>  6

Interesting way to align #defines, that's going to break badly over
time, please just left align them like the rest of the kernel, using
tabs.

> +EXPORT_SYMBOL(xgene_qmtm_set_qinfo);

EXPORT_SYMBOL_GPL() for this and the other exports perhaps?  (sorry, I
have to ask.)

> +/*
> + * Physical or free pool queue state (pq or fp)
> + */
> +struct storm_qmtm_pq_fp_qstate {
> + /* word 0 31:0 */
> + u32 resize_qid:10;
> + u32 resize_start:1;
> + u32 resize_done:1;
> + u32 cfgtmvqen:1;/* enable pq to belong to vq */
> + u32 cfgtmvq:10; /* parent vq */
> + u32 cfgsaben:1; /* enable SAB broadcasting */
> + u32 cpu_notify:8;   /* cfgcpusab */
> +
> + /* word 1 63:32 */
> + u32 cfgnotifyqne:1; /* enable queue not empty interrupt */
> + u32 nummsg:16;
> + u32 headptr:15;
> +
> + /* word 2 95:64 */
> + u32 cfgcrid:1;
> + u32 rid:3;
> + u32 qcoherent:1;
> + u64 cfgstartaddr:34;/* 27/7 split */
> +
> + /* word 3 127:96 */
> + u32 vc_chanctl:2;
> + u32 vc_chanid:2;
> + u32 slot_pending:6;
> + u32 stashing:1;
> + u32 reserved_0:1;
> + u32 cfgacceptlerr:1;
> + u32 fp_mode:3;  /* free pool mode */
> + u32 cfgqsize:3; /* queue size, see xgene_qmtm_qsize */
> + u32 qstatelock:1;
> + u32 cfgRecombBuf:1;
> + u32 cfgRecombBufTimeoutL:4; /* 4/3 split */
> +
> + /* word 4 159:128 */
> + u32 cfgRecombBufTimeoutH:3; /* 4/3 split */
> + u32 cfgselthrsh:3;  /* associated threshold set */
> + u32 resv2:13;
> + u32 cfgqtype:2; /* queue type, refer xgene_qmtm_qtype */
> + u32 resv1:11;
> +} __packed;

u64 for a bitfield?  Is that even valid C?  This is pretty scary from a
bitfield perspective, what about different endian and addressing modes?

Any chance to just use shifts to access the fields properly, like most
drivers do, in a endian-neutral way to get the data out and into the
structures?

Same goes for the other structures in this file.

thanks,

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/

Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup

[Linus Torvalds]

On Thu, Dec 19, 2013 at 6:22 PM, Davidlohr Bueso  wrote:
>
> Ok so when I replied I was thinking about the plist really and not the
> hb->lock ticket counter. Yeah, what you propose does make sense for
> waiters. However in wake paths we have to decrement  the counter nwake
> times (per each call to __unqueue_futex()), and if we rely on the
> ticket, then we do it only once, in the unlock, so the counter doesn't
> reflect the actual waitqueue size. Or am I missing something with ticket
> spinlocks (I'm not very familiar with that code)?

So that's why I suggested checking the ticket lock _and_ the state of
the node list.

The ticket lock state gives you the racy window before the entry has
actually been added to the node list, and then after the lock has been
released, the fact that the list isn't empty gives you the rest.

I think we might have to order the two reads with an smp_rmb - making
sure that we check the lock state first - but I think it should be
otherwise pretty solid.

And maybe there is some reason it doesn't work, but I'd really like to
understand it (and I'd like to avoid the extra atomics for the waiters
count if it at all can be avoided)

> Btw, I tried using spin_is_contended + plist_head_empty and we run into
> a whole bunch of nasty issues which I have yet to sit down and look
> into.

Yeah, I said "spin_contended()" myself initially, but it needs to be
"spin_is_locked()". It's hopefully unlikely to ever actually be
contended (which in ticket lock terms is "head is _more_ than one away
from the tail").

Linus
--
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/