Re: [RFC PATCH] futex: Remove requirement for lock_page in get_futex_key
On Tue, Oct 29, 2013 at 02:48:27PM -0400, Chris Mason wrote:
Quoting Mel Gorman (2013-10-29 13:38:14)
Thomas Gleixner and Peter Zijlstra discussed off-list that real-time users
currently have a problem with the page lock being contended for unbounded
periods of time during futex operations. The three of us discussed the
possibiltity that the page lock is unnecessary in this case because we are
not concerned with the usual races with reclaim and page cache updates. For
anonymous pages, the associated futex object is the mm_struct which does
not require the page lock. For inodes, we should be able to check under
RCU read lock if the page mapping is still valid to take a reference to
the inode. This just leaves one rare race that requires the page lock
in the slow path. This patch does not completely eliminate the page lock
but it should reduce contention in the majority of cases.
Patch boots and futextest did not explode but I did no comparison
performance tests. Thomas, do you have details of the workload that
drove you to examine this problem? Alternatively, can you test it and
see does it help you? I added Chris to the To list because he mentioned
that some filesystems might already be doing tricks similar to this
patch that are worth copying.
Unfortunately, all the special cases I see in the filesystems either
have an inode ref or are trylocking the page to safety.
Ok, at the time of the futex call there is an implicit ref due to the
mapping but it can be torn away underneath us at any time. I *think* I
have the right ordering to not make a mistake in this case but more eyes
the better.
XFS is a special case because they have their own inode cache, but by my
reading they are still using i_count and free by rcu.
Good, that's what I expected.
The iput in here is a little tricky:
+ /* Should be impossible but lets be paranoid for now */
+ if (WARN_ON(inode-i_mapping != mapping)) {
+ rcu_read_unlock();
+ iput(inode);
+ put_page(page_head);
+ goto again;
+ }
+
Once you call iput, you add the potential to call the filesystem unlink
operation if i_nlink had gone to zero. This shouldn't be a problem
since you've dropped the rcu lock, but just for fun I'd move the
put_page up a line.
Or, change it to a BUG_ON instead, it really should be impossible.
I'll do that. It'll blow up with the RCU lock still held so the system
is going to have a bad day but we're already in hell at this point.
Thanks Chris
--
Mel Gorman
SUSE Labs
--
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 tool: remove an unnecessary function call while process pipe events
From: Chenggang Qin chenggang@taobao.com
perf_session_free_sample_buffers() can be removed from
__perf_session__process_pipe_events(), since the ordered_samples buffer is not
used while samples are read from the pipe.
__perf_session__process_pipe_events() is only used while process the events from
pipe. While the sample are read from pipe, the ordered_samples is forbidden.
Refer to the following code in perf_session__new():
150 if (tool tool-ordering_requires_timestamps
151 tool-ordered_samples
!perf_evlist__sample_id_all(self-evlist)) {
152 dump_printf(WARNING: No sample_id_all support, falling
back to unordered processing\n);
153 tool-ordered_samples = false;
154 }
If pipe is used, perf_evlist__sample_id_all(self-evlist) always return 0.
Because
session-evlist is empty util a attr_event is read.
Thanks
Chenggang Qin
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/util/session.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 568b750..b69c28a 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1251,7 +1251,6 @@ done:
out_err:
free(buf);
perf_session__warn_about_errors(self, tool);
- perf_session_free_sample_buffers(self);
return err;
}
--
1.7.8.rc2.5.g815b
--
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: perf events ring buffer memory barrier on powerpc
On Thu, Oct 31, 2013 at 04:19:55PM +0100, Peter Zijlstra wrote:
On Thu, Oct 31, 2013 at 08:07:56AM -0700, Paul E. McKenney wrote:
On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
Before C/C++11, the closest thing to such a prohibition is use of
volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
use atomics to get anything resembing this prohibition.
If you just use normal variables, the compiler is within its rights
to transform something like the following:
if (a)
b = 1;
else
b = 42;
Into:
b = 42;
if (a)
b = 1;
Many other similar transformations are permitted. Some are used to all
vector instructions to be used -- the compiler can do a write with an
overly wide vector instruction, then clean up the clobbered variables
later, if it wishes. Again, if the variables are not marked volatile,
or, in C/C++11, atomic.
While I've heard you tell this story before, my mind keeps boggling how
we've been able to use shared memory at all, all these years.
It seems to me stuff should have broken left, right and center if
compilers were really aggressive about this.
Sometimes having stupid compilers is a good thing. But they really are
getting more aggressive.
But surely we cannot go mark all data structures lodged in shared memory
as volatile, that's insane.
I'm sure you're quite worried about this as well. Suppose we have:
struct foo {
unsigned long value;
void *ptr;
unsigned long value1;
};
And our ptr member is RCU managed. Then while the assignment using:
rcu_assign_ptr() will use the volatile cast, what stops the compiler
from wrecking ptr while writing either of the value* members and
'fixing' her up after?
Nothing at all!
We can reduce the probability by putting the pointer at one end or the
other, so that if the compiler uses (say) vector instructions to aggregate
individual assignments to the other fields, it will be less likely to hit
ptr. But yes, this is ugly and it would be really hard to get all
this right, and would often conflict with cache-locality needs.
This is a completely untenable position.
Indeed it is!
C/C++ never was intended to be used for parallel programming, and this is
but one of the problems that can arise when we nevertheless use it for
parallel programming. As compilers get smarter (for some definition of
smarter) and as more systems have special-purpose hardware (such as
vector units) that are visible to the compiler, we can expect more of
this kind of trouble.
This was one of many reasons that I decided to help with the C/C++11
effort, whatever anyone might think about the results.
How do the C/C++ people propose to deal with this?
By marking ptr as atomic, thus telling the compiler not to mess with it.
And thus requiring that all accesses to it be decorated, which in the
case of RCU could be buried in the RCU accessors.
Thanx, Paul
--
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/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
* Namhyung Kim namhy...@kernel.org wrote: 2) Is it possible to configure the default 'report -g' style, so that people who'd like to use it all the time don't have to type '-g cumulative' all the time? Hmm.. maybe I can add support for the 'report.call-graph' config option. If we display your new 'total' field by default then it's not as pressing to me :) Do you mean -g cumulative without 'self' column? So, if by default we display both 'self' and 'total' and sort by 'total', then I'm personally a happy camper: while it's a change of the default perf report output, it's also a step forward. But some people might complain about it once this hits v3.13 (or v3.14) and might want to hide individual columns and have different sorting preferences. So out of defensive caution you might want to provide toggles for such things, maybe even generalize it a bit to allow arbitrary hiding/display of individual colums in perf report. That would probably also make it easier to do minimal tweaks to the upstream reporting defaults. Btw., if anyone is interested in improving the GTK front-end, it would be _really_ nice if it had a 'start profiling' button like sysprof has today, with a 'samples' field showing the current number of samples. (We could even improve upon sysprof by adding 'stop' functionality as well ;-) Wow, I'm impressed that the sysprof doesn't have one. :) At least I haven't found it: I tried pressing 'start' once more but that doesn't do it, it just keeps collecting data. Still many developers love sysprof, so I think there would be quite some plus in providing a gtk perf top version with the controls Pekka and me listed. 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 0/4] perf report: add parameters 'start' 'end' to specify analysis interval
This patch set introduced a feature to analysis the samples in a specified time interval. After perf.data file was generated by perf record, the user could want to analysis a sub time interval of the whole record period. For some functions, the percent of its samples in a certain sub time interval is different from the percent in the total record period. Showing the scene in a certain time interval could allow users to more easily troubleshoot performance problems. The sample's timestamp are recorded in the perf.data file. The samples are sorted in the ordered_samples by timestamp while perf report processed them. So, it is easily to search the samples whose timestamp are in a certain time interval. We add 2 paramters --start and --end to specify the time interval. perf report --start x --end x The smallest granularity of time interval is millsecond. For example: If the whole record period of a perf.data file is 1 to 2, we can use the following command to analysis the samples between [15000, 16000). perf report --start 15000 --end 16000 The time is the uptime, it start timing from the system starts. Cc: David Ahern dsah...@gmail.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Paul Mackerras pau...@samba.org Cc: Ingo Molnar mi...@redhat.com Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net Cc: Arjan van de Ven ar...@linux.intel.com Cc: Namhyung Kim namhy...@gmail.com Cc: Yanmin Zhang yanmin.zh...@intel.com Cc: Wu Fengguang fengguang...@intel.com Cc: Mike Galbraith efa...@gmx.de Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Chenggang Qin chenggang@taobao.com Chenggang Qin (4): perf tools: add parameter 'start' 'end' to perf report perf tools: relate 'start' 'end' to perf_session perf tools: record min_timestamp of samples queue in ordered_samples perf tools: add the feature to assign analysis interval to perf report tools/perf/builtin-report.c | 14 tools/perf/util/session.c | 49 +- tools/perf/util/session.h |3 ++ 3 files changed, 64 insertions(+), 2 deletions(-) -- 1.7.8.rc2.5.g815b -- 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/4] perf tools: add the feature to assign analysis interval to perf report
Only process the samples whose timestamp is in [start, end).
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/util/session.c | 43 +--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 4e9dd66..d50e29e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -532,6 +532,9 @@ static int flush_sample_queue(struct perf_session *s,
bool show_progress = limit == ULLONG_MAX;
int ret;
+ if (limit s-tend)
+ limit = s-tend;
+
if (!tool-ordered_samples || !limit)
return 0;
@@ -539,6 +542,9 @@ static int flush_sample_queue(struct perf_session *s,
if (session_done())
return 0;
+ if (iter-timestamp s-tstart)
+ continue;
+
if (iter-timestamp limit)
break;
@@ -617,7 +623,26 @@ static int process_finished_round(struct perf_tool *tool,
union perf_event *event __maybe_unused,
struct perf_session *session)
{
- int ret = flush_sample_queue(session, tool);
+ int ret = 0;
+
+ /*
+* The next round should be processed continue.
+* But, this round is skipped.
+*/
+ if (session-ordered_samples.next_flush session-tstart) {
+ session-ordered_samples.next_flush =
session-ordered_samples.max_timestamp;
+ return ret;
+ }
+
+ /*
+* This round all followed rounds are skipped.
+*/
+ if (session-ordered_samples.min_timestamp session-tend) {
+ session-ordered_samples.next_flush = ULLONG_MAX;
+ return ret;
+ }
+
+ ret = flush_sample_queue(session, tool);
if (!ret)
session-ordered_samples.next_flush =
session-ordered_samples.max_timestamp;
@@ -1373,6 +1398,14 @@ more:
goto out_err;
}
+ /*
+* After process a finished round event:
+* The minimal timestamp in os-samples is greater than
+* tend, so, the followed events couldn't be processed.
+*/
+ if (session-ordered_samples.next_flush == ULLONG_MAX)
+ goto out_err;
+
head += size;
file_pos += size;
@@ -1389,8 +1422,14 @@ more:
if (file_pos file_size)
goto more;
+ if (session-ordered_samples.max_timestamp session-tstart)
+ goto out_err;
+
+ if (session-ordered_samples.min_timestamp session-tend)
+ goto out_err;
+
/* do the final flush for ordered samples */
- session-ordered_samples.next_flush = ULLONG_MAX;
+ session-ordered_samples.next_flush = session-tend;
err = flush_sample_queue(session, tool);
out_err:
ui_progress__finish();
--
1.7.8.rc2.5.g815b
--
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/4] perf report: add parameter 'start' 'end' to perf report
perf report --start time1 --end time2
The unit of time1 time2 are millsecond.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/builtin-report.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 72eae74..e9e9d0a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -733,6 +733,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
{
struct perf_session *session;
struct stat st;
+ u64 tstart = 0, tend = 0;
bool has_br_stack = false;
int branch_mode = -1;
int ret = -1;
@@ -843,6 +844,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_BOOLEAN(0, mem-mode, report.mem_mode, mem access profile),
OPT_CALLBACK(0, percent-limit, report, percent,
Don't show entries under that percent,
parse_percent_limit),
+ OPT_U64(0, start, tstart, Start time of analysis interval. (Unit:
ms)),
+ OPT_U64(0, end, tend, End time of analysis interval. (Unit: ms)),
OPT_END()
};
@@ -850,6 +853,12 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
argc = parse_options(argc, argv, options, report_usage, 0);
+ if (tend tstart = tend) {
+ fprintf(stderr, start [% PRIu64 ] is greater than end [%
+ PRIu64 ].\n, tstart, tend);
+ return -1;
+ }
+
if (report.use_stdio)
use_browser = 0;
else if (report.use_tui)
--
1.7.8.rc2.5.g815b
--
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/4] perf tools: relate 'start' 'end' to perf_session
Copy the value to start and end to struct perf_session.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/builtin-report.c |5 +
tools/perf/util/session.c |3 +++
tools/perf/util/session.h |2 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e9e9d0a..d3c1c8a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -889,6 +889,11 @@ repeat:
if (session == NULL)
return -ENOMEM;
+ if (tstart)
+ session-tstart = tstart * 1e6;
+ if (tend)
+ session-tend = tend * 1e6;
+
report.session = session;
has_br_stack = perf_header__has_feat(session-header,
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 568b750..193bb6a 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -134,6 +134,9 @@ struct perf_session *perf_session__new(const char
*filename, int mode,
INIT_LIST_HEAD(self-ordered_samples.to_free);
machines__init(self-machines);
+ self-tstart = 0;
+ self-tend = ULLONG_MAX;
+
if (mode == O_RDONLY) {
if (perf_session__open(self, force) 0)
goto out_delete;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index 04bf737..c9a6c27 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -37,6 +37,8 @@ struct perf_session {
int fd;
boolfd_pipe;
boolrepipe;
+ u64 tstart;
+ u64 tend;
struct ordered_samples ordered_samples;
charfilename[1];
};
--
1.7.8.rc2.5.g815b
--
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/4] perf tools: record min_timestamp of samples queue in ordered_samples
Add a field 'min_timestamp' in struct ordered_samples to record the minimial
timestamp of the samples in ordered_samples-samples.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/util/session.c |3 +++
tools/perf/util/session.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 193bb6a..4e9dd66 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -708,6 +708,9 @@ int perf_session_queue_event(struct perf_session *s, union
perf_event *event,
new-file_offset = file_offset;
new-event = event;
+ if (list_empty(os-samples) || os-min_timestamp timestamp)
+ os-min_timestamp = timestamp;
+
__queue_event(new, s);
return 0;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index c9a6c27..7d411b9 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -18,6 +18,7 @@ struct ordered_samples {
u64 last_flush;
u64 next_flush;
u64 max_timestamp;
+ u64 min_timestamp;
struct list_headsamples;
struct list_headsample_cache;
struct list_headto_free;
--
1.7.8.rc2.5.g815b
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
* Michel Lespinasse wal...@google.com wrote:
On Fri, Nov 1, 2013 at 1:43 AM, Peter Zijlstra pet...@infradead.org wrote:
AFAICT this isn't correct at all. We used to protect the vma
interval tree with the root lock, now we don't. All we've got
left is the mmap_sem, but anon_vma chains can cross
address-spaces and thus we're up some creek without no paddle.
Yes, that was my first thought as well (though I wanted to double
check at first).
I also want to point out that lately we've seen several changes
sent out that relax locking with no accompanying explanation of
why the relaxed locking would be safe. Please don't do that -
having a lot of performance data is worthless if you can't explain
why the new locking is safe. And I'm not asking to prove a
negative ('lack of any possible races') there, but at least in
this case one could dig out why the root anon vma locking was
introduced and if they think that this reason doesn't apply
anymore, explain why...
By the looks of it it seems to be an unintentional bug, not an
intended feature.
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/
Re: [PATCH] NFC: mei_phy: using kfree_skb() instead of kfree()
Hi Salil, On Thu, Oct 31, 2013 at 11:17:46PM +0530, Salil Kapur wrote: using kfree_skb() instead of kfree() for struct sk_buff Signed-off-by: Salil Kapur salilkapu...@gmail.com --- drivers/nfc/mei_phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to nfc-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/
[PATCH v3] can: c_can: Speed up rx_poll function
This patch speeds up the rx_poll function by reducing the number of
register reads.
Replace the 32bit register read by a 16bit register read. Currently
the 32bit register read is implemented by using 2 16bit reads. This is
inefficient as we only use the lower 16bit in rx_poll.
The for loop reads the pending interrupts in every iteration. This
leads up to 16 reads of pending interrupts. The patch introduces a new
outer loop to read the pending interrupts as long as 'quota' is above 0.
This reduces the total number of reads.
The third change is to replace the for-loop by a ffs loop.
Tested on AM335x. I removed all 'static' and 'inline' from c_can.c to
see the timings for all functions. I used the function tracer with
trace_stats.
125kbit:
Function HitTimeAvg
s^2
------
---
c_can_do_rx_poll 6396010168178 us 158.977 us
1493056 us
With patch:
c_can_do_rx_poll 639413764057 us 58.867 us
776162.2 us
1Mbit:
Function HitTimeAvg
s^2
------
---
c_can_do_rx_poll 6948930049498 us 432.435 us
9271851 us
With patch:
c_can_do_rx_poll20710924322185 us 117.436 us
171469047 us
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Notes:
Changes in v3:
- Update commit message (measurements and ffs)
Changes in v2:
- Small changes, find_next_bit - ffs and other
drivers/net/can/c_can/c_can.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index a668cd4..428681e 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -798,17 +798,19 @@ static int c_can_do_rx_poll(struct net_device *dev, int
quota)
u32 num_rx_pkts = 0;
unsigned int msg_obj, msg_ctrl_save;
struct c_can_priv *priv = netdev_priv(dev);
- u32 val = c_can_read_reg32(priv, C_CAN_INTPND1_REG);
+ u16 val;
+
+ /*
+* It is faster to read only one 16bit register. This is only possible
+* for a maximum number of 16 objects.
+*/
+ BUILD_BUG_ON_MSG(C_CAN_MSG_OBJ_RX_LAST 16,
+ Implementation does not support more message objects
than 16);
+
+ while (quota 0 (val = priv-read_reg(priv, C_CAN_INTPND1_REG))) {
+ while ((msg_obj = ffs(val)) quota 0) {
+ val = ~BIT(msg_obj - 1);
- for (msg_obj = C_CAN_MSG_OBJ_RX_FIRST;
- msg_obj = C_CAN_MSG_OBJ_RX_LAST quota 0;
- val = c_can_read_reg32(priv, C_CAN_INTPND1_REG),
- msg_obj++) {
- /*
-* as interrupt pending register's bit n-1 corresponds to
-* message object n, we need to handle the same properly.
-*/
- if (val (1 (msg_obj - 1))) {
c_can_object_get(dev, 0, msg_obj, IF_COMM_ALL
~IF_COMM_TXRQST);
msg_ctrl_save = priv-read_reg(priv,
--
1.8.4.rc3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 09:43:29AM +0100, Peter Zijlstra wrote:
On Fri, Nov 01, 2013 at 03:54:24PM +0800, Yuanhan Liu wrote:
@@ -497,15 +495,20 @@ static void vma_rb_erase(struct vm_area_struct *vma,
struct rb_root *root)
* anon_vma_interval_tree_post_update_vma().
*
* The entire update must be protected by exclusive mmap_sem and by
- * the root anon_vma's mutex.
+ * the anon_vma's mutex.
*/
static inline void
anon_vma_interval_tree_pre_update_vma(struct vm_area_struct *vma)
{
struct anon_vma_chain *avc;
- list_for_each_entry(avc, vma-anon_vma_chain, same_vma)
- anon_vma_interval_tree_remove(avc, avc-anon_vma-rb_root);
+ list_for_each_entry(avc, vma-anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = avc-anon_vma;
+
+ anon_vma_lock_write(anon_vma);
+ anon_vma_interval_tree_remove(avc, anon_vma-rb_root);
+ anon_vma_unlock_write(anon_vma);
+ }
}
static inline void
@@ -513,8 +516,13 @@ anon_vma_interval_tree_post_update_vma(struct
vm_area_struct *vma)
{
struct anon_vma_chain *avc;
- list_for_each_entry(avc, vma-anon_vma_chain, same_vma)
- anon_vma_interval_tree_insert(avc, avc-anon_vma-rb_root);
+ list_for_each_entry(avc, vma-anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = avc-anon_vma;
+
+ anon_vma_lock_write(anon_vma);
+ anon_vma_interval_tree_insert(avc, anon_vma-rb_root);
+ anon_vma_unlock_write(anon_vma);
+ }
}
static int find_vma_links(struct mm_struct *mm, unsigned long addr,
@@ -781,7 +789,6 @@ again: remove_next = 1 + (end
next-vm_end);
if (anon_vma) {
VM_BUG_ON(adjust_next next-anon_vma
anon_vma != next-anon_vma);
- anon_vma_lock_write(anon_vma);
anon_vma_interval_tree_pre_update_vma(vma);
if (adjust_next)
anon_vma_interval_tree_pre_update_vma(next);
@@ -845,7 +852,6 @@ again: remove_next = 1 + (end
next-vm_end);
anon_vma_interval_tree_post_update_vma(vma);
if (adjust_next)
anon_vma_interval_tree_post_update_vma(next);
- anon_vma_unlock_write(anon_vma);
}
if (mapping)
mutex_unlock(mapping-i_mmap_mutex);
AFAICT this isn't correct at all. We used to protect the vma interval
tree with the root lock, now we don't.
We still use lock to protect anon_vma interval tree, but we lock our own
interval tree this time.
All we've got left is the
mmap_sem, but anon_vma chains can cross address-spaces and thus we're up
some creek without no paddle.
Yep, however, you still need acquire the address-space crossed anon_vma's lock
to modify something.
Say, here is a chart: http://people.freedesktop.org/~yliu/anon_vma.png.
Let's take the 3rd chart as example. And assume we will unlink vma C.
And the steps are:
- lock c, and remove avc between c and C
- lock b, and remove avc between b and C
- lock a, and remove avc between a and C
Thanks.
--yliu
--
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 net-next V3 1/2] net: introduce skb_coalesce_rx_frag()
On Fri, 2013-11-01 at 14:07 +0800, Jason Wang wrote: Sometimes we need to coalesce the rx frags to avoid frag list. One example is virtio-net driver which tries to use small frags for both MTU sized packet and GSO packet. So this patch introduce skb_coalesce_rx_frag() to do this. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Michael S. Tsirkin m...@redhat.com Cc: Michael Dalton mwdal...@google.com Cc: Eric Dumazet eduma...@google.com Acked-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Jason Wang jasow...@redhat.com --- Changes from V2: - remove the skb_frag_unref() and let the called to put the page reference Changes from V1: - remove the useless off parameter. --- Acked-by: Eric Dumazet eduma...@google.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 v4 0/4] Add dual-fifo mode support of i.MX ssi
On Fri, Nov 01, 2013 at 05:11:58PM +0800, Shawn Guo wrote: Nicolin, The dmaengine maintainer Vinod Koul should be copied on the series. (Just added). Ah, I was careless last night when I sent these patches. My VPN connection was pretty laggy :( Please forgive me, Vinod. Thank Shawn for adding for me. Much obliged. On Thu, Oct 31, 2013 at 09:44:12PM +0800, Nicolin Chen wrote: Nicolin Chen (4): dma: imx-sdma: Add sdma firmware version 2 support dma: imx-sdma: Add new dma type for ssi dual fifo script ASoC: fsl_ssi: Add dual fifo mode support ARM: dts: imx: use dual-fifo sdma script for ssi Vinod, To keep git bisect, the series has to be merged through single tree. Since Mark has ACK-ed patch #3, I think it's easier to merge the series through your tree, so for patch #4: Acked-by: Shawn Guo shawn@linaro.org -- 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] perf report: add parameters 'start' 'end' to specify analysis interval
* Chenggang Qin chenggang@gmail.com wrote: This patch set introduced a feature to analysis the samples in a specified time interval. After perf.data file was generated by perf record, the user could want to analysis a sub time interval of the whole record period. For some functions, the percent of its samples in a certain sub time interval is different from the percent in the total record period. Showing the scene in a certain time interval could allow users to more easily troubleshoot performance problems. The sample's timestamp are recorded in the perf.data file. The samples are sorted in the ordered_samples by timestamp while perf report processed them. So, it is easily to search the samples whose timestamp are in a certain time interval. We add 2 paramters --start and --end to specify the time interval. perf report --start x --end x The smallest granularity of time interval is millsecond. For example: If the whole record period of a perf.data file is 1 to 2, we can use the following command to analysis the samples between [15000, 16000). perf report --start 15000 --end 16000 The time is the uptime, it start timing from the system starts. Cc: David Ahern dsah...@gmail.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Paul Mackerras pau...@samba.org Cc: Ingo Molnar mi...@redhat.com Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net Cc: Arjan van de Ven ar...@linux.intel.com Cc: Namhyung Kim namhy...@gmail.com Cc: Yanmin Zhang yanmin.zh...@intel.com Cc: Wu Fengguang fengguang...@intel.com Cc: Mike Galbraith efa...@gmx.de Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Chenggang Qin chenggang@taobao.com Chenggang Qin (4): perf tools: add parameter 'start' 'end' to perf report perf tools: relate 'start' 'end' to perf_session perf tools: record min_timestamp of samples queue in ordered_samples perf tools: add the feature to assign analysis interval to perf report tools/perf/builtin-report.c | 14 tools/perf/util/session.c | 49 +- tools/perf/util/session.h |3 ++ 3 files changed, 64 insertions(+), 2 deletions(-) Looks useful - but right now this has to be used 'blindly', without knowing _which_ portion of the perf.data is 'interesting'. That problem could be resolved by allowing direct manipulation of the start/end interval via the GTK front end: a small graph could show the 'sample graph', with two sliders specifying the reported interval? Something like this, at the top of the window: --- | | |.| | .. ..... . | | . .... ... | |. .. .. .. | | [1] [2]| --- | | Usual perf report GTK output | | | The 'graph' might be anything that visualizes the time axis of the perf.data: a sample frequency visualization for example, or maybe a simple task activity graph based on fork/exec/exit data, with some simple time display included as well (a vertical marker every minute/second or so). The [1] and [2] markers demark the two sliders, which in the above mockup example show an 'interesting' portion of the profile with a lot of samples. With such a solution the feature you add would be very useful indeed, I'd even argue for the data file time-axis visualization to be enabled by default, with the initial start/end interval covering the whole perf.data, but the sliders being just a mouse-drag away from being changed. 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/
Re: [PATCH net-next V3 2/2] virtio-net: coalesce rx frags when possible during rx
On Fri, 2013-11-01 at 14:07 +0800, Jason Wang wrote: Commit 2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable rx buffers to page frag allocators) try to increase the payload/truesize for MTU-sized traffic. But this will introduce the extra overhead for GSO packets received because of the frag list. This commit tries to reduce this issue by coalesce the possible rx frags when possible during rx. Test result shows the about 15% improvement on full size GSO packet receiving (and even better than before commit 2613af0ed18a11d5c566a81f9a6510b73180660a). Before this commit: ./netperf -H 192.168.100.4 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.4 () port 0 AF_INET : demo Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0020303.87 After this commit: ./netperf -H 192.168.100.4 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.100.4 () port 0 AF_INET : demo Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0023841.26 Cc: Rusty Russell ru...@rustcorp.com.au Cc: Michael S. Tsirkin m...@redhat.com Cc: Michael Dalton mwdal...@google.com Cc: Eric Dumazet eduma...@google.com Acked-by: Michael S. Tsirkin m...@redhat.com Acked-by: Eric Dumazet eduma...@google.com Signed-off-by: Jason Wang jasow...@redhat.com --- Changes from V2: - call put_page() instead of depending on skb_coalesce_rx_frag() --- Yes, very nice improvement, thanks again ! Acked-by: Eric Dumazet eduma...@google.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 net] net: flow_dissector: fail on evil iph-ihl
On Fri, 2013-11-01 at 15:01 +0800, Jason Wang wrote: We don't validate iph-ihl which may lead a dead loop if we meet a IPIP skb whose iph-ihl is zero. Fix this by failing immediately when iph-ihl is evil (less than 5). This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae (rps: support IPIP encapsulation). Cc: Eric Dumazet eduma...@google.com Cc: Petr Matousek pmato...@redhat.com Cc: Michael S. Tsirkin m...@redhat.com Cc: Daniel Borkmann dbork...@redhat.com Signed-off-by: Jason Wang jasow...@redhat.com --- This patch is needed for stable. --- Acked-by: Eric Dumazet eduma...@google.com Thanks Jason ! -- 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] extcon-gpio: add devicetree support.
As this device is not vendor specific, I haven't included any vendor,
prefixes. For my model I used regulator-gpio which takes a similar
approach.
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index ..2346b61cc620
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,26 @@
+* EXTCON detector using GPIO
+
+Required Properties:
+ - compatible: extcon-gpio
+ - gpios: gpio line that detects connector
+ - interrupts: interrupt generated by that gpio
+ - debounce-delay-ms: debouncing delay
+
+Optional Properties:
+ - label: name for connector. If not given, device name is used.
+ - state-on: string to report when GPIO is high (else '0')
+ - state-off: string to report when GPIO is low (else '1')
+
+Example:
+
+antenna-detect {
+ compatible = extcon-gpio;
+ label = gps_antenna;
+ interrupt-parent = gpio5;
+ interrupts = 16 IRQ_TYPE_EDGE_BOTH;
+ gpios = gpio5 16 0;
+ debounce-delay-ms = 10;
+ state-on = external;
+ state-off = internal;
+};
+
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index f874c30ddbff..a683d2b99213 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -30,6 +30,9 @@
#include linux/gpio.h
#include linux/extcon.h
#include linux/extcon/extcon-gpio.h
+#include linux/of_platform.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
struct gpio_extcon_data {
struct extcon_dev edev;
@@ -76,6 +79,45 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
return -EINVAL;
}
+#ifdef CONFIG_OF
+static struct gpio_extcon_platform_data *
+gpio_extcon_parse(struct device *dev)
+{
+ struct gpio_extcon_platform_data *pdata;
+ struct device_node *np = dev-of_node;
+ u32 num;
+ int irq;
+
+ if (!np)
+ return NULL;
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+ pdata-name = dev_name(dev);
+ of_property_read_string(np, label, pdata-name);
+ irq = irq_of_parse_and_map(np, 0);
+ pdata-irq_flags = irq_get_trigger_type(irq);
+ pdata-gpio = of_get_named_gpio(np, gpios, 0);
+ if (pdata-gpio 0)
+ return ERR_PTR(pdata-gpio);
+ if (irq != gpio_to_irq(pdata-gpio)) {
+ dev_err(dev, IRQ doesn't match GPIO\n);
+ return ERR_PTR(-EINVAL);
+ }
+ if (of_property_read_u32(np, debounce-delay-ms, num) == 0)
+ pdata-debounce = num;
+ of_property_read_string(np, state-on, pdata-state_on);
+ of_property_read_string(np, state-off, pdata-state_off);
+ return pdata;
+}
+#else
+static inline struct gpio_extcon_platform_data *
+gpio_extcon_parse(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int gpio_extcon_probe(struct platform_device *pdev)
{
struct gpio_extcon_platform_data *pdata = pdev-dev.platform_data;
@@ -83,7 +125,11 @@ static int gpio_extcon_probe(struct platform_device *pdev)
int ret = 0;
if (!pdata)
+ pdata = gpio_extcon_parse(pdev-dev);
+ if (!pdata)
return -EBUSY;
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
if (!pdata-irq_flags) {
dev_err(pdev-dev, IRQ flag is not specified.\n);
return -EINVAL;
@@ -148,12 +194,19 @@ static int gpio_extcon_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id gpio_extcon_match[] = {
+ { .compatible = extcon-gpio },
+ {}
+};
+MODULE_DEVICE_TABLE(of, gpio_extcon_mastch);
+
static struct platform_driver gpio_extcon_driver = {
.probe = gpio_extcon_probe,
.remove = gpio_extcon_remove,
.driver = {
.name = extcon-gpio,
.owner = THIS_MODULE,
+ .of_match_table = gpio_extcon_match,
},
};
signature.asc
Description: PGP signature
[tip:sched/core] sched/wait: Fix __wait_event_interruptible_lock_irq_timeout()
Commit-ID: 7d716456a0ee4e9bd63be9234f886d20382ac950
Gitweb: http://git.kernel.org/tip/7d716456a0ee4e9bd63be9234f886d20382ac950
Author: Heiko Carstens heiko.carst...@de.ibm.com
AuthorDate: Thu, 31 Oct 2013 12:48:14 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 1 Nov 2013 08:42:44 +0100
sched/wait: Fix __wait_event_interruptible_lock_irq_timeout()
__wait_event_interruptible_lock_irq_timeout() needs the timeout
parameter passed instead of ret.
This magically compiled since the only user has a local ret
variable. Luckily we got a build warning:
CC drivers/s390/scsi/zfcp_qdio.o
drivers/s390/scsi/zfcp_qdio.c: In function 'zfcp_qdio_sbal_get':
include/linux/wait.h:780:15: warning: 'ret' may be used uninitialized
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Link: http://lkml.kernel.org/r/20131031114814.GB5551@osiris
Signed-off-by: Ingo Molnar mi...@kernel.org
---
include/linux/wait.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 3b23afa..61939ba 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -739,7 +739,7 @@ do {
\
#define __wait_event_interruptible_lock_irq_timeout(wq, condition, \
lock, timeout) \
___wait_event(wq, ___wait_cond_timeout(condition), \
- TASK_INTERRUPTIBLE, 0, ret, \
+ TASK_INTERRUPTIBLE, 0, timeout, \
spin_unlock_irq(lock); \
__ret = schedule_timeout(__ret); \
spin_lock_irq(lock));
--
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/
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: e8a923cc1fff6e627f906655ad52ee694ef2f6d7 perf/x86: Fix NMI
measurements
Two fixes:
- Fix 'NMI handler took too long to run' false positives. [ Genuine
NMI overhead speedups will come for v3.13, this commit only fixes
a measurement bug. ]
- Fix perf ring-buffer missed barrier causing (rare) ring-buffer
data corruption on ppc64.
Thanks,
Ingo
--
Peter Zijlstra (2):
perf: Fix perf ring buffer memory ordering
perf/x86: Fix NMI measurements
arch/x86/kernel/cpu/perf_event.c | 6 +++---
arch/x86/kernel/nmi.c| 4 ++--
include/uapi/linux/perf_event.h | 12 +++-
kernel/events/ring_buffer.c | 31 +++
4 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 9d84491..8a87a32 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1276,16 +1276,16 @@ void perf_events_lapic_init(void)
static int __kprobes
perf_event_nmi_handler(unsigned int cmd, struct pt_regs *regs)
{
- int ret;
u64 start_clock;
u64 finish_clock;
+ int ret;
if (!atomic_read(active_events))
return NMI_DONE;
- start_clock = local_clock();
+ start_clock = sched_clock();
ret = x86_pmu.handle_irq(regs);
- finish_clock = local_clock();
+ finish_clock = sched_clock();
perf_sample_event_took(finish_clock - start_clock);
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index ba77ebc..6fcb49c 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -113,10 +113,10 @@ static int __kprobes nmi_handle(unsigned int type, struct
pt_regs *regs, bool b2
u64 before, delta, whole_msecs;
int remainder_ns, decimal_msecs, thishandled;
- before = local_clock();
+ before = sched_clock();
thishandled = a-handler(type, regs);
handled += thishandled;
- delta = local_clock() - before;
+ delta = sched_clock() - before;
trace_nmi_handler(a-handler, (int)delta, thishandled);
if (delta nmi_longest_ns)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 009a655..2fc1602 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -456,13 +456,15 @@ struct perf_event_mmap_page {
/*
* Control data for the mmap() data buffer.
*
-* User-space reading the @data_head value should issue an rmb(), on
-* SMP capable platforms, after reading this value -- see
-* perf_event_wakeup().
+* User-space reading the @data_head value should issue an smp_rmb(),
+* after reading this value.
*
* When the mapping is PROT_WRITE the @data_tail value should be
-* written by userspace to reflect the last read data. In this case
-* the kernel will not over-write unread data.
+* written by userspace to reflect the last read data, after issueing
+* an smp_mb() to separate the data read from the -data_tail store.
+* In this case the kernel will not over-write unread data.
+*
+* See perf_output_put_handle() for the data ordering.
*/
__u64 data_head; /* head in the data section */
__u64 data_tail; /* user-space written tail */
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index cd55144..9c2ddfb 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -87,10 +87,31 @@ again:
goto out;
/*
-* Publish the known good head. Rely on the full barrier implied
-* by atomic_dec_and_test() order the rb-head read and this
-* write.
+* Since the mmap() consumer (userspace) can run on a different CPU:
+*
+* kernel user
+*
+* READ -data_tail READ -data_head
+* smp_mb() (A) smp_rmb() (C)
+* WRITE $dataREAD $data
+* smp_wmb() (B) smp_mb()(D)
+* STORE -data_head WRITE -data_tail
+*
+* Where A pairs with D, and B pairs with C.
+*
+* I don't think A needs to be a full barrier because we won't in fact
+* write data until we see the store from userspace. So we simply don't
+* issue the data WRITE until we observe it. Be conservative for now.
+*
+* OTOH, D needs to be a full barrier since it separates the data READ
+* from the tail WRITE.
+
Subject: [PATCH 0/2] wm8962: Add ALC and EQ coefficients
Two patches to expose the coefficient blocks for the ALC and EQ filters. Richard Fitzgerald (2): ASoC: wm8962: Add ALC coefficient support ASoC: wm8962: Add EQ coefficient support sound/soc/codecs/wm8962.c |8 1 files changed, 8 insertions(+), 0 deletions(-) -- 1.7.2.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 1/2] ASoC: wm8962: Add ALC coefficient support
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
---
sound/soc/codecs/wm8962.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index c9ff713..2b04497 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -1774,6 +1774,11 @@ WM8962_DSP2_ENABLE(HPF2 Switch, WM8962_HPF2_ENA_SHIFT),
SND_SOC_BYTES(HPF Coefficients, WM8962_LHPF2, 1),
WM8962_DSP2_ENABLE(HD Bass Switch, WM8962_HDBASS_ENA_SHIFT),
SND_SOC_BYTES(HD Bass Coefficients, WM8962_HDBASS_AI_1, 30),
+
+SOC_DOUBLE(ALC Switch, WM8962_ALC1, WM8962_ALCL_ENA_SHIFT,
+ WM8962_ALCR_ENA_SHIFT, 1, 0),
+SND_SOC_BYTES_MASK(ALC Coefficients, WM8962_ALC1, 4,
+ WM8962_ALCL_ENA_MASK | WM8962_ALCR_ENA_MASK),
};
static const struct snd_kcontrol_new wm8962_spk_mono_controls[] = {
--
1.7.2.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] drivers/net: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong duanj.f...@cn.fujitsu.com
---
drivers/net/appletalk/ipddp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/appletalk/ipddp.c b/drivers/net/appletalk/ipddp.c
index 10d0dba..78f06cb 100644
--- a/drivers/net/appletalk/ipddp.c
+++ b/drivers/net/appletalk/ipddp.c
@@ -312,9 +312,7 @@ module_param(ipddp_mode, int, 0);
static int __init ipddp_init_module(void)
{
dev_ipddp = ipddp_init();
-if (IS_ERR(dev_ipddp))
-return PTR_ERR(dev_ipddp);
- return 0;
+return PTR_ERR_OR_ZERO(dev_ipddp);
}
static void __exit ipddp_cleanup_module(void)
--
1.8.3.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/2] ASoC: wm8962: Add EQ coefficient support
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com --- sound/soc/codecs/wm8962.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 2b04497..150d003 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -1757,6 +1757,9 @@ SOC_DOUBLE_R_TLV(EQ4 Volume, WM8962_EQ3, WM8962_EQ23, WM8962_EQL_B4_GAIN_SHIFT, 31, 0, eq_tlv), SOC_DOUBLE_R_TLV(EQ5 Volume, WM8962_EQ3, WM8962_EQ23, WM8962_EQL_B5_GAIN_SHIFT, 31, 0, eq_tlv), +SND_SOC_BYTES(EQL Coefficients, WM8962_EQ4, 18), +SND_SOC_BYTES(EQR Coefficients, WM8962_EQ24, 18), + SOC_SINGLE(3D Switch, WM8962_THREED1, 0, 1, 0), SND_SOC_BYTES_MASK(3D Coefficients, WM8962_THREED1, 4, WM8962_THREED_ENA), -- 1.7.2.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/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 02:22:25AM -0700, Michel Lespinasse wrote:
On Fri, Nov 1, 2013 at 1:43 AM, Peter Zijlstra pet...@infradead.org wrote:
AFAICT this isn't correct at all. We used to protect the vma interval
tree with the root lock, now we don't. All we've got left is the
mmap_sem, but anon_vma chains can cross address-spaces and thus we're up
some creek without no paddle.
Yes, that was my first thought as well (though I wanted to double
check at first).
I also want to point out that lately we've seen several changes sent
out that relax locking with no accompanying explanation of why the
relaxed locking would be safe. Please don't do that - having a lot of
performance data is worthless if you can't explain why the new locking
is safe.
Agreed.
And I'm not asking to prove a negative ('lack of any possible
races') there, but at least in this case one could dig out why the
root anon vma locking was introduced and if they think that this
reason doesn't apply anymore, explain why...
It was introduced by commit 2b575eb6(And, BTW, I'm sorry that this commit log
about bb4aa39676f is wrong)
commit 2b575eb64f7a9c701fb4bfdb12388ac547f6c2b6
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Tue May 24 17:12:11 2011 -0700
mm: convert anon_vma-lock to a mutex
Straightforward conversion of anon_vma-lock to a mutex.
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Acked-by: Hugh Dickins hu...@google.com
Reviewed-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: David Miller da...@davemloft.net
Cc: Martin Schwidefsky schwidef...@de.ibm.com
Cc: Russell King r...@arm.linux.org.uk
Cc: Paul Mundt let...@linux-sh.org
Cc: Jeff Dike jd...@addtoit.com
Cc: Richard Weinberger rich...@nod.at
Cc: Tony Luck tony.l...@intel.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Mel Gorman m...@csn.ul.ie
Cc: Nick Piggin npig...@kernel.dk
Cc: Namhyung Kim namhy...@gmail.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
As you can see, Peter didn't tell why before. Honestly speaking, that
was my originaly concern as well. I tried to find some possible races;
I guess I may miss something.
Thanks.
--yliu
--
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/
[GIT PULL] sound fixes #2 for 3.12-final
Linus,
please pull another sound fixes for v3.12-final from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.12
The topmost commit is a4461f41b94cb52e0141af717dcf4ef6558c8e2e
sound fixes #2 for 3.12-final
The fixes for random bugs that have been reported lately in the game:
a few fixes in ASoC dpam and wm_hubs bugs spotted by Coverity, a
one-liner HD-audio fixup, and a fix for Oops with DPCM.
They are not so critically urgent bugs, but all small and safe.
Thanks!
Takashi
Russell King (1):
ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM
Takashi Iwai (4):
ASoC: dapm: Fix source list debugfs outputs
ASoC: dapm: Return -ENOMEM in snd_soc_dapm_new_dai_widgets()
ALSA: hda - Add a fixup for ASUS N76VZ
ASoC: wm_hubs: Add missing break in hp_supply_event()
---
sound/core/pcm.c | 4
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/codecs/wm_hubs.c| 1 +
sound/soc/soc-dapm.c | 4 +++-
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/sound/core/pcm.c b/sound/core/pcm.c
index 17f45e8aa89c..e1e9e0c999fe 100644
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -49,6 +49,8 @@ static struct snd_pcm *snd_pcm_get(struct snd_card *card, int
device)
struct snd_pcm *pcm;
list_for_each_entry(pcm, snd_pcm_devices, list) {
+ if (pcm-internal)
+ continue;
if (pcm-card == card pcm-device == device)
return pcm;
}
@@ -60,6 +62,8 @@ static int snd_pcm_next(struct snd_card *card, int device)
struct snd_pcm *pcm;
list_for_each_entry(pcm, snd_pcm_devices, list) {
+ if (pcm-internal)
+ continue;
if (pcm-card == card pcm-device device)
return pcm-device;
else if (pcm-card-number card-number)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bf313bea7085..8ad554312b69 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4623,6 +4623,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = {
SND_PCI_QUIRK(0x1028, 0x05db, Dell,
ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1632, HP RP5800, ALC662_FIXUP_HP_RP5800),
SND_PCI_QUIRK(0x1043, 0x1477, ASUS N56VZ, ALC662_FIXUP_ASUS_MODE4),
+ SND_PCI_QUIRK(0x1043, 0x1bf3, ASUS N76VZ, ALC662_FIXUP_ASUS_MODE4),
SND_PCI_QUIRK(0x1043, 0x8469, ASUS mobo, ALC662_FIXUP_NO_JACK_DETECT),
SND_PCI_QUIRK(0x105b, 0x0cd6, Foxconn, ALC662_FIXUP_ASUS_MODE2),
SND_PCI_QUIRK(0x144d, 0xc051, Samsung R720, ALC662_FIXUP_IDEAPAD),
diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c
index 8b50e5958de5..01daf655e20b 100644
--- a/sound/soc/codecs/wm_hubs.c
+++ b/sound/soc/codecs/wm_hubs.c
@@ -530,6 +530,7 @@ static int hp_supply_event(struct snd_soc_dapm_widget *w,
hubs-hp_startup_mode);
break;
}
+ break;
case SND_SOC_DAPM_PRE_PMD:
snd_soc_update_bits(codec, WM8993_CHARGE_PUMP_1,
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c17c14c394df..b2949aed1ac2 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1949,7 +1949,7 @@ static ssize_t dapm_widget_power_read_file(struct file
*file,
w-active ? active : inactive);
list_for_each_entry(p, w-sources, list_sink) {
- if (p-connected !p-connected(w, p-sink))
+ if (p-connected !p-connected(w, p-source))
continue;
if (p-connect)
@@ -3495,6 +3495,7 @@ int snd_soc_dapm_new_dai_widgets(struct
snd_soc_dapm_context *dapm,
if (!w) {
dev_err(dapm-dev, ASoC: Failed to create %s widget\n,
dai-driver-playback.stream_name);
+ return -ENOMEM;
}
w-priv = dai;
@@ -3513,6 +3514,7 @@ int snd_soc_dapm_new_dai_widgets(struct
snd_soc_dapm_context *dapm,
if (!w) {
dev_err(dapm-dev, ASoC: Failed to create %s widget\n,
dai-driver-capture.stream_name);
+ return -ENOMEM;
}
w-priv = dai;
--
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] drivers: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong duanj.f...@cn.fujitsu.com
---
drivers/misc/carma/carma-fpga.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 08b18f3..9a32e98 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -956,10 +956,7 @@ static int data_debugfs_init(struct fpga_device *priv)
{
priv-dbg_entry = debugfs_create_file(drv_name, S_IRUGO, NULL, priv,
data_debug_fops);
- if (IS_ERR(priv-dbg_entry))
- return PTR_ERR(priv-dbg_entry);
-
- return 0;
+ return PTR_ERR_OR_ZERO(priv-dbg_entry);
}
static void data_debugfs_exit(struct fpga_device *priv)
--
1.8.3.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] fs/buffer.c: exit if already confirmed page has dirty and writeback buffers
Stop the loop of iterating bh if we have confirmed page has dirty and writeback buffers. Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com --- fs/buffer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index 6024877..519cc5c 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -112,7 +112,7 @@ void buffer_check_dirty_writeback(struct page *page, *dirty = true; bh = bh-b_this_page; - } while (bh != head); + } while ((bh != head) !(*writeback *dirty)); } EXPORT_SYMBOL(buffer_check_dirty_writeback); -- 1.7.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/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 06:07:07PM +0800, Yuanhan Liu wrote:
I also want to point out that lately we've seen several changes sent
out that relax locking with no accompanying explanation of why the
relaxed locking would be safe. Please don't do that - having a lot of
performance data is worthless if you can't explain why the new locking
is safe.
Agreed.
And I'm not asking to prove a negative ('lack of any possible
races') there, but at least in this case one could dig out why the
root anon vma locking was introduced and if they think that this
reason doesn't apply anymore, explain why...
It was introduced by commit 2b575eb6(And, BTW, I'm sorry that this commit log
about bb4aa39676f is wrong)
commit 2b575eb64f7a9c701fb4bfdb12388ac547f6c2b6
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Tue May 24 17:12:11 2011 -0700
mm: convert anon_vma-lock to a mutex
Straightforward conversion of anon_vma-lock to a mutex.
As you can see, Peter didn't tell why before. Honestly speaking, that
was my originaly concern as well. I tried to find some possible races;
I guess I may miss something.
Bullshit; I didn't change the locking. I only changed the lock primitive
from a spinlock to a mutex. The anon_vma-root-lock is completely
unrelated to this change.
--
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] per anon_vma lock and turn anon_vma rwsem lock to rwlock_t
On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
* Yuanhan Liu yuanhan@linux.intel.com wrote:
Btw., another _really_ interesting comparison would be against
the latest rwsem patches. Mind doing such a comparison?
Sure. Where can I get it? Are they on some git tree?
I've Cc:-ed Tim Chen who might be able to point you to the latest
version.
The last on-lkml submission was in this thread:
Subject: [PATCH v8 0/9] rwsem performance optimizations
Thanks.
I queued bunchs of tests about one hour ago, and already got some
results(If necessary, I can add more data tomorrow when those tests are
finished):
v3.12-rc7 fe001e3de090e179f95d
-9.3% brickland1/micro/aim7/shared
+4.3%
lkp-ib03/micro/aim7/fork_test
+2.2% lkp-ib03/micro/aim7/shared
-2.6% TOTAL aim7.2000.jobs-per-min
v3.12-rc7 fe001e3de090e179f95d
204056.67 -23.5%156082.33 brickland1/micro/aim7/shared
79248.00 +144.3%193617.25
lkp-ib03/micro/aim7/fork_test
298355.33 -25.2%223084.67 lkp-ib03/micro/aim7/shared
581660.00-1.5%572784.25 TOTAL
time.involuntary_context_switches
v3.12-rc7 fe001e3de090e179f95d
22487.33-4.7% 21429.33 brickland1/micro/aim7/dbase
61412.67 -29.1% 43511.00 brickland1/micro/aim7/shared
531142.00 -27.7%383818.75
lkp-ib03/micro/aim7/fork_test
20158.33 -50.9% 9899.67 lkp-ib03/micro/aim7/shared
635200.33 -27.8%458658.75 TOTAL vmstat.system.in
v3.12-rc7 fe001e3de090e179f95d
6408.67-4.5% 6117.33 brickland1/micro/aim7/dbase
87856.00 -39.5% 53170.67 brickland1/micro/aim7/shared
1043620.00 -28.0%751214.75
lkp-ib03/micro/aim7/fork_test
47152.33 -38.0% 29245.33 lkp-ib03/micro/aim7/shared
1185037.00 -29.1%839748.08 TOTAL vmstat.system.cs
v3.12-rc7 fe001e3de090e179f95d
13295.00 -10.0% 11960.00 brickland1/micro/aim7/dbase
1901175.00 -35.5% 1226787.33 brickland1/micro/aim7/shared
13951.00-6.5% 13051.00 lkp-ib03/micro/aim7/dbase
239773251.17 -30.9% 165727820.75
lkp-ib03/micro/aim7/fork_test
1014933.67 -31.1%699259.67 lkp-ib03/micro/aim7/shared
242716605.83 -30.9% 167678878.75 TOTAL
time.voluntary_context_switches
v3.12-rc7 fe001e3de090e179f95d
9.56-1.0% 9.46 brickland1/micro/aim7/dbase
11.01 -10.1% 9.90 brickland1/micro/aim7/shared
36.23 +15.3%41.77
lkp-ib03/micro/aim7/fork_test
10.51 -11.9% 9.26 lkp-ib03/micro/aim7/shared
67.31+4.6%70.39 TOTAL iostat.cpu.system
v3.12-rc7 fe001e3de090e179f95d
36.39-3.6%35.09 brickland1/micro/aim7/dbase
34.97-8.1%32.13 brickland1/micro/aim7/shared
20.34+6.7%21.70 lkp-ib03/micro/aim7/shared
91.70-3.0%88.92 TOTAL boottime.dhcp
v3.12-rc7 fe001e3de090e179f95d
60.00+6.7%64.00 brickland1/micro/aim7/shared
60.83-9.2%55.25
lkp-ib03/micro/aim7/fork_test
120.83-1.3% 119.25 TOTAL vmstat.cpu.id
v3.12-rc7 fe001e3de090e179f95d
345.50-1.1% 341.73 brickland1/micro/aim7/dbase
3788.80 +11.5% 4223.15
lkp-ib03/micro/aim7/fork_test
108.29-7.1% 100.62 lkp-ib03/micro/aim7/shared
4242.59 +10.0% 4665.50 TOTAL time.system_time
v3.12-rc7 fe001e3de090e179f95d
7481.33-0.4% 7454.00
Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.
On Fri, Nov 01, 2013 at 03:04:52PM +0800, Xiubo Li wrote:
On VF610 series there are no regulators used, and now whether the
CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio
micro? or macro?
patch series, the board cannot be probe successfully.
And this patch will solve this issue.
I finally got your idea about what this patch does. But it seems to
be more likely a work around. Maybe I here can't think it through
comprehensively, but I think you can try to add a fixed regulator to
sgtl5000 in the devicetree, rather than disabling common functions
even if not breaking others.
Signed-off-by: Xiubo Li li.xi...@freescale.com
---
sound/soc/codecs/sgtl5000.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 1f4093f..c2f6d86 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -61,6 +61,7 @@ static const struct reg_default sgtl5000_reg_defaults[] = {
{ SGTL5000_DAP_AVC_DECAY, 0x0050 },
};
+#ifdef CONFIG_REGULATOR
/* regulator supplies for sgtl5000, VDDD is an optional external supply */
enum sgtl5000_regulator_supplies {
VDDA,
@@ -93,6 +94,9 @@ static struct regulator_init_data ldo_init_data = {
.num_consumer_supplies = 1,
.consumer_supplies = ldo_consumer[0],
};
+#else
+#define SGTL5000_SUPPLY_NUM 0
+#endif
/*
* sgtl5000 internal ldo regulator,
@@ -112,7 +116,9 @@ struct sgtl5000_priv {
int master; /* i2s master or not */
int fmt;/* i2s data format */
struct regulator_bulk_data supplies[SGTL5000_SUPPLY_NUM];
+#ifdef CONFIG_REGULATOR
struct ldo_regulator *ldo;
+#endif
struct regmap *regmap;
struct clk *mclk;
};
@@ -879,6 +885,7 @@ static int ldo_regulator_remove(struct snd_soc_codec
*codec)
return 0;
}
#else
+#ifndef CONFIG_SND_SOC_FSL_SGTL5000_VF610
Checking a platform or SoC specific define here is just a bit
Could you pls find a better solution? Like I said at first, use fixed regulator
or figure out why your System would hang with current sgtl5000 driver. If it
really has a critical bug in its regulator-related code, I think you can then
make a greater contribution by fixing the bug rather than bypassing it.
Best regards,
Nicolin Chen
static int ldo_regulator_register(struct snd_soc_codec *codec,
struct regulator_init_data *init_data,
int voltage)
@@ -886,6 +893,7 @@ static int ldo_regulator_register(struct snd_soc_codec
*codec,
dev_err(codec-dev, this setup needs regulator support in the
kernel\n);
return -EINVAL;
}
+#endif
static int ldo_regulator_remove(struct snd_soc_codec *codec)
{
@@ -1137,6 +1145,7 @@ static int sgtl5000_resume(struct snd_soc_codec *codec)
#define sgtl5000_resume NULL
#endif /* CONFIG_SUSPEND */
+#ifdef CONFIG_REGULATOR
/*
* sgtl5000 has 3 internal power supplies:
* 1. VAG, normally set to vdda/2
@@ -1373,6 +1382,7 @@ err_regulator_free:
return ret;
}
+#endif
static int sgtl5000_probe(struct snd_soc_codec *codec)
{
@@ -1387,6 +1397,7 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)
return ret;
}
+#ifdef CONFIG_REGULATOR
ret = sgtl5000_enable_regulators(codec);
if (ret)
return ret;
@@ -1395,6 +1406,7 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)
ret = sgtl5000_set_power_regs(codec);
if (ret)
goto err;
+#endif
/* enable small pop, introduce 400ms delay in turning off */
snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL,
--
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 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 05:38:44PM +0800, Yuanhan Liu wrote:
On Fri, Nov 01, 2013 at 09:43:29AM +0100, Peter Zijlstra wrote:
On Fri, Nov 01, 2013 at 03:54:24PM +0800, Yuanhan Liu wrote:
@@ -497,15 +495,20 @@ static void vma_rb_erase(struct vm_area_struct
*vma, struct rb_root *root)
* anon_vma_interval_tree_post_update_vma().
*
* The entire update must be protected by exclusive mmap_sem and by
- * the root anon_vma's mutex.
+ * the anon_vma's mutex.
*/
static inline void
anon_vma_interval_tree_pre_update_vma(struct vm_area_struct *vma)
{
struct anon_vma_chain *avc;
- list_for_each_entry(avc, vma-anon_vma_chain, same_vma)
- anon_vma_interval_tree_remove(avc, avc-anon_vma-rb_root);
+ list_for_each_entry(avc, vma-anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = avc-anon_vma;
+
+ anon_vma_lock_write(anon_vma);
+ anon_vma_interval_tree_remove(avc, anon_vma-rb_root);
+ anon_vma_unlock_write(anon_vma);
+ }
}
static inline void
@@ -513,8 +516,13 @@ anon_vma_interval_tree_post_update_vma(struct
vm_area_struct *vma)
{
struct anon_vma_chain *avc;
- list_for_each_entry(avc, vma-anon_vma_chain, same_vma)
- anon_vma_interval_tree_insert(avc, avc-anon_vma-rb_root);
+ list_for_each_entry(avc, vma-anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = avc-anon_vma;
+
+ anon_vma_lock_write(anon_vma);
+ anon_vma_interval_tree_insert(avc, anon_vma-rb_root);
+ anon_vma_unlock_write(anon_vma);
+ }
}
static int find_vma_links(struct mm_struct *mm, unsigned long addr,
@@ -781,7 +789,6 @@ again:remove_next = 1 + (end
next-vm_end);
if (anon_vma) {
VM_BUG_ON(adjust_next next-anon_vma
anon_vma != next-anon_vma);
- anon_vma_lock_write(anon_vma);
anon_vma_interval_tree_pre_update_vma(vma);
if (adjust_next)
anon_vma_interval_tree_pre_update_vma(next);
@@ -845,7 +852,6 @@ again:remove_next = 1 + (end
next-vm_end);
anon_vma_interval_tree_post_update_vma(vma);
if (adjust_next)
anon_vma_interval_tree_post_update_vma(next);
- anon_vma_unlock_write(anon_vma);
}
if (mapping)
mutex_unlock(mapping-i_mmap_mutex);
AFAICT this isn't correct at all. We used to protect the vma interval
tree with the root lock, now we don't.
We still use lock to protect anon_vma interval tree, but we lock our own
interval tree this time.
Which lock? What protects the chain you're iterating in
anon_vma_interval_tree_{pre,post}_update_vma() ?
All we've got left is the
mmap_sem, but anon_vma chains can cross address-spaces and thus we're up
some creek without no paddle.
Yep, however, you still need acquire the address-space crossed anon_vma's lock
to modify something.
-ENOPARSE.
--
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] quota: info leak in quota_getquota()
The if_dqblk struct has a 4 byte hole at the end of the struct so
uninitialized stack information is leaked to user space.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/fs/quota/quota.c b/fs/quota/quota.c
index dea86e8..2b363e2 100644
--- a/fs/quota/quota.c
+++ b/fs/quota/quota.c
@@ -117,6 +117,7 @@ static int quota_setinfo(struct super_block *sb, int type,
void __user *addr)
static void copy_to_if_dqblk(struct if_dqblk *dst, struct fs_disk_quota *src)
{
+ memset(dst, 0, sizeof(*dst));
dst-dqb_bhardlimit = src-d_blk_hardlimit;
dst-dqb_bsoftlimit = src-d_blk_softlimit;
dst-dqb_curspace = src-d_bcount;
--
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: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote:
This is a completely untenable position.
Indeed it is!
C/C++ never was intended to be used for parallel programming,
And yet pretty much all kernels ever written for SMP systems are written
in it; what drugs are those people smoking?
Furthermore there's a gazillion parallel userspace programs.
and this is
but one of the problems that can arise when we nevertheless use it for
parallel programming. As compilers get smarter (for some definition of
smarter) and as more systems have special-purpose hardware (such as
vector units) that are visible to the compiler, we can expect more of
this kind of trouble.
This was one of many reasons that I decided to help with the C/C++11
effort, whatever anyone might think about the results.
Well, I applaud your efforts, but given the results I think the C/C++
people are all completely insane.
How do the C/C++ people propose to deal with this?
By marking ptr as atomic, thus telling the compiler not to mess with it.
And thus requiring that all accesses to it be decorated, which in the
case of RCU could be buried in the RCU accessors.
This seems contradictory; marking it atomic would look like:
struct foo {
unsigned long value;
__atomic void *ptr;
unsigned long value1;
};
Clearly we cannot hide this definition in accessors, because then
accesses to value* won't see the annotation.
That said; mandating we mark all 'shared' data with __atomic is
completely untenable and is not backwards compatible.
To be safe we must assume all data shared unless indicated otherwise.
--
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] xfs: simplify kmem_{zone_}zalloc
Introduce flag KM_ZERO which is used to alloc zeroed entry, and convert
kmem_{zone_}zalloc to call kmem_{zone_}alloc() with KM_ZERO directly,
in order to avoid the setting to zero step.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
fs/xfs/kmem.c | 14 ++
fs/xfs/kmem.h |7 ++-
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
index a02cfb9..d56fcc9 100644
--- a/fs/xfs/kmem.c
+++ b/fs/xfs/kmem.c
@@ -65,12 +65,7 @@ kmem_alloc(size_t size, xfs_km_flags_t flags)
void *
kmem_zalloc(size_t size, xfs_km_flags_t flags)
{
- void*ptr;
-
- ptr = kmem_alloc(size, flags);
- if (ptr)
- memset((char *)ptr, 0, (int)size);
- return ptr;
+ return kmem_alloc(size, flags | KM_ZERO);
}
void *
@@ -132,10 +127,5 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags)
void *
kmem_zone_zalloc(kmem_zone_t *zone, xfs_km_flags_t flags)
{
- void*ptr;
-
- ptr = kmem_zone_alloc(zone, flags);
- if (ptr)
- memset((char *)ptr, 0, kmem_cache_size(zone));
- return ptr;
+ return kmem_zone_alloc(zone, flags | KM_ZERO);
}
diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h
index 3a7371c..8ea21fd 100644
--- a/fs/xfs/kmem.h
+++ b/fs/xfs/kmem.h
@@ -32,6 +32,7 @@ typedef unsigned __bitwise xfs_km_flags_t;
#define KM_NOSLEEP ((__force xfs_km_flags_t)0x0002u)
#define KM_NOFS((__force xfs_km_flags_t)0x0004u)
#define KM_MAYFAIL ((__force xfs_km_flags_t)0x0008u)
+#define KM_ZERO((__force xfs_km_flags_t)0x0010u)
/*
* We use a special process flag to avoid recursive callbacks into
@@ -43,7 +44,7 @@ kmem_flags_convert(xfs_km_flags_t flags)
{
gfp_t lflags;
- BUG_ON(flags ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL));
+ BUG_ON(flags ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL|KM_ZERO));
if (flags KM_NOSLEEP) {
lflags = GFP_ATOMIC | __GFP_NOWARN;
@@ -52,6 +53,10 @@ kmem_flags_convert(xfs_km_flags_t flags)
if ((current-flags PF_FSTRANS) || (flags KM_NOFS))
lflags = ~__GFP_FS;
}
+
+ if (flags KM_ZERO)
+ lflags |= __GFP_ZERO;
+
return lflags;
}
--
1.7.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/
Re: [ANNOUNCE] Git v1.8.5-rc0
On Thu, Oct 31, 2013 at 5:17 AM, Junio C Hamano gits...@pobox.com wrote: * Magic pathspecs like :(icase)makefile that matches both Makefile and makefile can be used in more places. :(glob)foo/**/bar is another nice thing that could be announced. -- Duy -- 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 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
Hi Xiubo,
On Fri, Nov 01, 2013 at 03:04:53PM +0800, Xiubo Li wrote:
This is the SGTL5000 codec based audio driver supported with both
playback and capture dai link implemention.
This implementation is only compatible with device tree definition.
Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Xiubo Li li.xi...@freescale.com
Conflicts:
sound/soc/fsl/Makefile
---
sound/soc/fsl/Kconfig | 10 ++
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/fsl-sgtl5000-vf610.c | 208
+
I just doubt if this file naming is appropriate. Even if we might not have
rigor rule for the file names, according to existing ones, they are all in
a same pattern: [SoC name]-[codec name].c
imx-sgtl5000.c for example
I think it would make user less confused about what this file exactly is if
this machine driver also follow the pattern: vf610-sgtl5000.c
@Shawn
What do you think about the file name?
3 files changed, 220 insertions(+)
create mode 100644 sound/soc/fsl/fsl-sgtl5000-vf610.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 9a8851e..1b835ba 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -228,4 +228,14 @@ config SND_SOC_FSL_SAI
tristate
select SND_SOC_GENERIC_DMAENGINE_PCM
+config SND_SOC_FSL_SGTL5000_VF610
Same problem with the this define.
+ tristate SoC Audio support for FSL boards with sgtl5000
And 'FSL' here confuses me a lot. Because those boards based on i.MX series
also could be called FSL boards.
+ depends on OF I2C
+ select SND_SOC_FSL_SAI
+ select SND_SOC_FSL_PCM
+ select SND_SOC_SGTL5000
+ help
+ Say Y if you want to add support for SoC audio on an FSL board with
+ a sgtl5000 codec.
+
endif # SND_FSL_SOC
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index e5acc03..26fc551 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -59,5 +59,7 @@ obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o
# FSL ARM SAI/SGT15000 Platform Support
snd-soc-fsl-sai-objs := fsl-sai.o
+snd-soc-fsl-sgtl5000-vf610-objs := fsl-sgtl5000-vf610.o
obj-$(CONFIG_SND_SOC_FSL_SAI) += snd-soc-fsl-sai.o
+obj-$(CONFIG_SND_SOC_FSL_SGTL5000_VF610) += snd-soc-fsl-sgtl5000-vf610.o
diff --git a/sound/soc/fsl/fsl-sgtl5000-vf610.c
b/sound/soc/fsl/fsl-sgtl5000-vf610.c
new file mode 100644
index 000..f535b42
--- /dev/null
+++ b/sound/soc/fsl/fsl-sgtl5000-vf610.c
@@ -0,0 +1,208 @@
+/*
+ * Freeacale ALSA SoC Audio using SGT1500 as codec.
+ *
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/i2c.h
+#include linux/clk.h
+
+#include ../codecs/sgtl5000.h
+#include fsl-sai.h
+
+static unsigned int sysclk_rate;
+
+static int fsl_sgtl5000_dai_init(struct snd_soc_pcm_runtime *rtd)
Naming issue here again.
At least from my point of view, if you actually merged imx-sgtl5000 with
vf610-sgtl5000 and made it also compatible to other freescale SoCs, you
could then fairly call it fsl_sgtl5000_.
Well, I might be a little picky here because it's a static function and
won't conflict others. Just the name here doesn't look so explicit to me.
Please reconsider about this whole file's naming.
Best regards,
Nicolin Chen
+{
+ int ret;
+ struct device *dev = rtd-card-dev;
+
+ ret = snd_soc_dai_set_sysclk(rtd-codec_dai, SGTL5000_SYSCLK,
+ sysclk_rate, SND_SOC_CLOCK_IN);
+ if (ret) {
+ dev_err(dev, could not set codec driver clock params :%d\n,
+ ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_sysclk(rtd-cpu_dai, FSL_SAI_CLK_BUS,
+ sysclk_rate, SND_SOC_CLOCK_OUT);
+ if (ret) {
+ dev_err(dev, could not set cpu dai driver clock params :%d\n,
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int sgtl5000_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ unsigned int channels = params_channels(params);
+
+ /* TODO: The SAI driver should figure this out for us */
+ switch (channels) {
+ case 2:
+ snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffc, 0xfffc, 2, 0);
+ break;
+ case 1:
+ snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffe, 0xfffe, 1, 0);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+
Re: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
Not that it would improve functionality, but: On Fri, Nov 01, 2013 at 15:04:53 +0800, Xiubo Li wrote: [...] diff --git a/sound/soc/fsl/fsl-sgtl5000-vf610.c b/sound/soc/fsl/fsl-sgtl5000-vf610.c new file mode 100644 index 000..f535b42 --- /dev/null +++ b/sound/soc/fsl/fsl-sgtl5000-vf610.c @@ -0,0 +1,208 @@ +/* + * Freeacale ALSA SoC Audio using SGT1500 as codec. ^ ^ ^ FreescaleSGTL5000 regards, Oskar -- 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 net-next RFC 0/5] xen-netback: TX grant mapping instead of copy
On Wed, 2013-10-30 at 00:50 +, Zoltan Kiss wrote: This patch series use SKBTX_DEV_ZEROCOPY flags to tell the stack it needs to know when the skb is freed up. Does this always avoid copying when bridging/openvswitching/forwarding (e.g. masquerading etc)? For both domU-domU and domU-physical NIC? How does it deal with broadcast traffic? That is the way KVM solved the same problem, and based on my initial tests it can do the same for us. Avoiding the extra copy boosted up TX throughput from 6.8 Gbps to 7.9 (I used a slower Interlagos box, both Dom0 and guest on upstream kernel, on the same NUMA node, running iperf 2.0.5, and the remote end was a bare metal box on the same 10Gb switch) Do you have any numbers for the dom0 cpu usage impact? Aggregate throughput for many guests would be a useful datapoint too. Based on my investigations the packet get only copied if it is delivered to Dom0 stack, which is due to this patch: https://lkml.org/lkml/2012/7/20/363 That's a bit unfortunate, but as far as I know for the huge majority this use case is not too important. Likely to be true, but it would still be interesting to know how badly this use case suffers with this change, and any increase in CPU usage would be interesting to know about as well. There are a couple of things which need more polishing, see the FIXME comments. I will run some more extensive tests, but in the meantime I would like to hear comments about what I've done so far. I've tried to broke it down to smaller patches, with mixed results, so I welcome suggestions on that part as well: 1/5: Introduce TX grant map definitions 2/5: Change TX path from grant copy to mapping 3/5: Remove old TX grant copy definitons 4/5: Fix indentations 5/5: Change RX path for mapped SKB fragments Signed-off-by: Zoltan Kiss zoltan.k...@citrix.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 v4 2/4] perf stat: add event unit and scale support
On Thu, Oct 31, 2013 at 03:59:40PM +0100, Stephane Eranian wrote:
This patch adds perf stat support fo rhandling event units and
scales as exported by the kernel.
The kernel can export PMU events actual unit and scaling factor
via sysfs:
$ ls -1 /sys/devices/power/events/energy-*
/sys/devices/power/events/energy-cores
/sys/devices/power/events/energy-cores.scale
/sys/devices/power/events/energy-cores.unit
/sys/devices/power/events/energy-pkg
/sys/devices/power/events/energy-pkg.scale
/sys/devices/power/events/energy-pkg.unit
$ cat /sys/devices/power/events/energy-cores.scale
2.3e-10
$ cat cat /sys/devices/power/events/energy-cores.unit
Joules
This patch modifies the pmu event alias code to check
for the presence of the .unit and .scale files to load
the corresponding values. They are then used by perf stat
transparentely:
wrt our previous conversation, attached patch is what
I meant (based on your changes)
you could get rid of following functions:
pmu_event_unit
pmu_event_scale
pmu_get_event_unit_scale
and have the unit/scale processing within the alias code
the name that matters is the term name which is available
in the parse_events_add_pmu as one of the terms
jirka
---
tools/perf/util/parse-events.c | 29 -
tools/perf/util/pmu.c | 92 +++---
tools/perf/util/pmu.h | 6 +--
3 files changed, 53 insertions(+), 74 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index be7eba8..90ae328 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -269,9 +269,10 @@ const char *event_type(int type)
-static int __add_event(struct list_head *list, int *idx,
- struct perf_event_attr *attr,
- char *name, struct cpu_map *cpus)
+static struct perf_evsel *
+__add_event(struct list_head *list, int *idx,
+ struct perf_event_attr *attr,
+ char *name, struct cpu_map *cpus)
{
struct perf_evsel *evsel;
@@ -279,19 +280,19 @@ static int __add_event(struct list_head *list, int *idx,
evsel = perf_evsel__new(attr, (*idx)++);
if (!evsel)
- return -ENOMEM;
+ return NULL;
evsel-cpus = cpus;
if (name)
evsel-name = strdup(name);
list_add_tail(evsel-node, list);
- return 0;
+ return evsel;
}
static int add_event(struct list_head *list, int *idx,
struct perf_event_attr *attr, char *name)
{
- return __add_event(list, idx, attr, name, NULL);
+ return __add_event(list, idx, attr, name, NULL) ? 0 : -ENOMEM;
}
static int parse_aliases(char *str, const char
*names[][PERF_EVSEL__MAX_ALIASES], int size)
@@ -633,6 +634,9 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
{
struct perf_event_attr attr;
struct perf_pmu *pmu;
+ struct perf_evsel *evsel;
+ char *unit;
+ double scale;
pmu = perf_pmu__find(name);
if (!pmu)
@@ -640,7 +644,7 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
memset(attr, 0, sizeof(attr));
- if (perf_pmu__check_alias(pmu, head_config))
+ if (perf_pmu__check_alias(pmu, head_config, unit, scale))
return -EINVAL;
/*
@@ -652,8 +656,14 @@ int parse_events_add_pmu(struct list_head *list, int *idx,
if (perf_pmu__config(pmu, attr, head_config))
return -EINVAL;
- return __add_event(list, idx, attr, pmu_event_name(head_config),
- pmu-cpus);
+ evsel = __add_event(list, idx, attr, pmu_event_name(head_config),
+ pmu-cpus);
+ if (evsel) {
+ evsel-unit = unit;
+ evsel-scale = scale;
+ }
+
+ return evsel ? 0 : -ENOMEM;
}
int parse_events__modifier_group(struct list_head *list,
@@ -838,7 +848,6 @@ int parse_events_name(struct list_head *list, char *name)
list_for_each_entry(evsel, list, node) {
if (!evsel-name)
evsel-name = strdup(name);
- pmu_get_event_unit_scale(evsel);
}
return 0;
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index e18ef87..df68d43 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -620,16 +620,42 @@ static struct perf_pmu_alias *pmu_find_alias(struct
perf_pmu *pmu,
return NULL;
}
+
+static int check_unit_scale(struct perf_pmu_alias *alias,
+ char **unit, double *scale)
+{
+ /*
+* Only one term in event definition can
+* define unit and scale, fail if there's
+* more than one.
+*/
+ if ((*unit alias-unit) ||
+ (*scale alias-scale))
+ return -EINVAL;
+
+ if (alias-unit)
+ *unit = alias-unit;
+
+ if (alias-scale)
+ *scale =
Re: [PATCH] KVM: x86: fix emulation of movzbl %bpl, %eax
On Thu, Oct 31, 2013 at 11:05:24PM +0100, Paolo Bonzini wrote:
When I was looking at RHEL5.9's failure to start with
unrestricted_guest=0/emulate_invalid_guest_state=1, I got it working with a
slightly older tree than kvm.git. I now debugged the remaining failure,
which was introduced by commit 660696d1 (KVM: X86 emulator: fix
source operand decoding for 8bit mov[zs]x instructions, 2013-04-24)
introduced a similar mis-emulation to the one in commit 8acb4207 (KVM:
fix sil/dil/bpl/spl in the mod/rm fields, 2013-05-30). The incorrect
decoding occurs in 8-bit movzx/movsx instructions whose 8-bit operand
is sil/dil/bpl/spl.
Needless to say, movzbl %bpl, %eax does occur in RHEL5.9's decompression
prolog, just a handful of instructions before finally giving control to
the decompressed vmlinux and getting out of the invalid guest state.
Because OpMem8 bypasses decode_modrm, the same handling of the REX prefix
must be applied to OpMem8.
Reported-by: Michele Baldessari mich...@redhat.com
Cc: sta...@vger.kernel.org
Cc: Gleb Natapov g...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 16c037e7db7d..282d28cb9931 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4117,7 +4117,10 @@ static int decode_operand(struct x86_emulate_ctxt
*ctxt, struct operand *op,
case OpMem8:
ctxt-memop.bytes = 1;
if (ctxt-memop.type == OP_REG) {
- ctxt-memop.addr.reg = decode_register(ctxt,
ctxt-modrm_rm, 1);
+ int highbyte_regs = ctxt-rex_prefix == 0;
+
+ ctxt-memop.addr.reg = decode_register(ctxt,
ctxt-modrm_rm,
+highbyte_regs);
fetch_register_operand(ctxt-memop);
}
goto mem_common;
--
1.8.3.1
--
Gleb.
--
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] fix race between stop_two_cpus and stop_cpus
On Thu, Oct 31, 2013 at 04:31:44PM -0400, Rik van Riel wrote:
There is a race between stop_two_cpus, and the global stop_cpus.
What was the trigger for this? I want to see what was missing from my own
testing. I'm going to go out on a limb and guess that CPU hotplug was also
running in the background to specifically stress this sort of rare condition.
Something like running a standard test with the monitors/watch-cpuoffline.sh
from mmtests running in parallel.
It is possible for two CPUs to get their stopper functions queued
backwards from one another, resulting in the stopper threads
getting stuck, and the system hanging. This can happen because
queuing up stoppers is not synchronized.
This patch adds synchronization between stop_cpus (a rare operation),
and stop_two_cpus.
Signed-off-by: Rik van Riel r...@redhat.com
---
Prarit is running a test with this patch. By now the kernel would have
crashed already, yet it is still going. I expect Prarit will add his
Tested-by: some time tomorrow morning.
kernel/stop_machine.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 32a6c44..46cb4c2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -40,8 +40,10 @@ struct cpu_stopper {
};
static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
+static DEFINE_PER_CPU(bool, stop_two_cpus_queueing);
static DEFINE_PER_CPU(struct task_struct *, cpu_stopper_task);
static bool stop_machine_initialized = false;
+static bool stop_cpus_queueing = false;
static void cpu_stop_init_done(struct cpu_stop_done *done, unsigned int
nr_todo)
{
@@ -261,16 +263,37 @@ int stop_two_cpus(unsigned int cpu1, unsigned int cpu2,
cpu_stop_fn_t fn, void *
cpu_stop_init_done(done, 2);
set_state(msdata, MULTI_STOP_PREPARE);
+ wait_for_global:
+ /* If a global stop_cpus is queuing up stoppers, wait. */
+ while (unlikely(stop_cpus_queueing))
+ cpu_relax();
+
This partially serialises callers to migrate_swap() while it is checked
if the pair of CPUs are being affected at the moment. It's two-stage
locking. The global lock is short-lived while the per-cpu data is updated
and the per-cpu values allow a degree of parallelisation on call_cpu which
could not be done with a spinlock held anyway. Why not make protection
of the initial update a normal spinlock? i.e.
spin_lock(stop_cpus_queue_lock);
this_cpu_write(stop_two_cpus_queueing, true);
spin_unlock(stop_cpus_queue_lock);
and get rid of the barriers and gogo wait_for_global loop entirely? I'm not
seeing the hidden advantage. The this_cpu_write(stop_two_cpus_queueing, false)
would also need to be within the lock as would the checks in
queue_stop_cpus_work.
The locks look bad but it's not clear to me why the barriers and retries
are better.
--
Mel Gorman
SUSE Labs
--
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: perf events ring buffer memory barrier on powerpc
On Thu, Oct 31, 2013 at 11:59:21AM +0200, Victor Kaplansky wrote: Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/31/2013 06:32:58 AM: If you want to play the omit memory barriers game, then proving a negative is in fact the task before you. Generally it is not fair. Otherwise, anyone could put an smp_mb() at a random place, and expect others to prove that it is not needed. It is not fair also because it should be virtually impossible to prove lack of any problem. OTH, if a problem exists, it should be easy for proponents of a memory barrier to build a test case or design a scenario demonstrating the problem. I really don't care about fair -- I care instead about the kernel working reliably. And it should also be easy for proponents of removing memory barriers to clearly articulate what orderings their code does and does not need. Actually, advocates of the memory barrier in our case do have an argument - - the rule of thumb saying that barriers should be paired. I consider this rule only as a general recommendation to look into potentially risky places. And indeed, in our case if the store to circular wasn't conditional, it would require a memory barrier to prevent the store to be performed before the read of @tail. But in our case the store is conditional, so no memory barrier is required. You are assuming control dependencies that the C language does not provide. Now, for all I know right now, there might well be some other reason why a full barrier is not required, but the if statement cannot be that reason. Please review section 1.10 of the C++11 standard (or the corresponding section of the C11 standard, if you prefer). The point is that the C/C++11 covers only data dependencies, not control dependencies. And the correctness of this code has been called into question. :-( An embarrassingly long time ago -- I need to get this either proven or fixed. I agree. Glad we agree on something! Before C/C++11, the closest thing to such a prohibition is use of volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to use atomics to get anything resembing this prohibition. If you just use normal variables, the compiler is within its rights to transform something like the following: if (a) b = 1; else b = 42; Into: b = 42; if (a) b = 1; Many other similar transformations are permitted. Some are used to all vector instructions to be used -- the compiler can do a write with an overly wide vector instruction, then clean up the clobbered variables later, if it wishes. Again, if the variables are not marked volatile, or, in C/C++11, atomic. All this can justify only compiler barrier() which is almost free from performance point of view, since current gcc anyway doesn't perform store hoisting optimization in our case. If the above example doesn't get you to give up your incorrect assumption about if statements having much effect on ordering, you need more help than I can give you just now. (And I'm not getting into philosophical discussion whether kernel code should consider future possible bugs/features in gcc or C/C++11 standard). Should you wish to get into that discussion in the near future, you will need to find someone else to discuss it with. The compilers don't always know as much as they might about the underlying hardware's memory model. That's correct in general. But can you point out a problem that really exists? We will see. In the meantime, can you summarize the ordering requirements of your code? Of course, if this code is architecture specific, it can avoid DEC Alpha's fun and games, which could also violate your assumptions in the above paragraph: http://www.openvms.compaq.com/wizard/wiz_2637.html Are you talking about this paragraph from above link: For instance, your producer must issue a memory barrier instruction after writing the data to shared memory and before inserting it on the queue; likewise, your consumer must issue a memory barrier instruction after removing an item from the queue and before reading from its memory. Otherwise, you risk seeing stale data, since, while the Alpha processor does provide coherent memory, it does not provide implicit ordering of reads and writes. (That is, the write of the producer's data might reach memory after the write of the queue, such that the consumer might read the new item from the queue but get the previous values from the item's memory. If yes, I don't think it explains the need of memory barrier on Alpha in our case (we all agree about the need of smp_wmb() right before @head update by producer). If not, could you please point to specific paragraph? Did you miss the following passage in the paragraph you quoted? ... likewise, your consumer must issue a memory barrier instruction after removing an item from the queue
Re: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 12:25:26PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 02:27:25AM -0700, Paul E. McKenney wrote:
On Mon, Oct 28, 2013 at 10:58:58PM +0200, Victor Kaplansky wrote:
Oleg Nesterov o...@redhat.com wrote on 10/28/2013 10:17:35 PM:
mb(); // : do we really need it? I think yes.
Oh, it is hard to argue with feelings. Also, it is easy to be on
conservative side and put the barrier here just in case.
But I still insist that the barrier is redundant in your example.
If you were to back up that insistence with a description of the orderings
you are relying on, why other orderings are not important, and how the
important orderings are enforced, I might be tempted to pay attention
to your opinion.
OK, so let me try.. a slightly less convoluted version of the code in
kernel/events/ring_buffer.c coupled with a userspace consumer would look
something like the below.
One important detail is that the kbuf part and the kbuf_writer() are
strictly per cpu and we can thus rely on implicit ordering for those.
Only the userspace consumer can possibly run on another cpu, and thus we
need to ensure data consistency for those.
struct buffer {
u64 size;
u64 tail;
u64 head;
void *data;
};
struct buffer *kbuf, *ubuf;
/*
* Determine there's space in the buffer to store data at @offset to
* @head without overwriting data at @tail.
*/
bool space(u64 tail, u64 offset, u64 head)
{
offset = (offset - tail) % kbuf-size;
head = (head - tail) % kbuf-size;
return (s64)(head - offset) = 0;
}
/*
* If there's space in the buffer; store the data @buf; otherwise
* discard it.
*/
void kbuf_write(int sz, void *buf)
{
u64 tail = ACCESS_ONCE(ubuf-tail); /* last location userspace read */
u64 offset = kbuf-head; /* we already know where we last wrote */
u64 head = offset + sz;
if (!space(tail, offset, head)) {
/* discard @buf */
return;
}
/*
* Ensure that if we see the userspace tail (ubuf-tail) such
* that there is space to write @buf without overwriting data
* userspace hasn't seen yet, we won't in fact store data before
* that read completes.
*/
smp_mb(); /* A, matches with D */
write(kbuf-data + offset, buf, sz);
kbuf-head = head % kbuf-size;
/*
* Ensure that we write all the @buf data before we update the
* userspace visible ubuf-head pointer.
*/
smp_wmb(); /* B, matches with C */
ubuf-head = kbuf-head;
}
/*
* Consume the buffer data and update the tail pointer to indicate to
* kernel space there's 'free' space.
*/
void ubuf_read(void)
{
u64 head, tail;
tail = ACCESS_ONCE(ubuf-tail);
head = ACCESS_ONCE(ubuf-head);
/*
* Ensure we read the buffer boundaries before the actual buffer
* data...
*/
smp_rmb(); /* C, matches with B */
while (tail != head) {
obj = ubuf-data + tail;
/* process obj */
tail += obj-size;
tail %= ubuf-size;
}
/*
* Ensure all data reads are complete before we issue the
* ubuf-tail update; once that update hits, kbuf_write() can
* observe and overwrite data.
*/
smp_mb(); /* D, matches with A */
ubuf-tail = tail;
}
Now the whole crux of the question is if we need barrier A at all, since
the STORES issued by the @buf writes are dependent on the ubuf-tail
read.
The dependency you are talking about is via the if statement?
Even C/C++11 is not required to respect control dependencies.
This one is a bit annoying. The x86 TSO means that you really only
need barrier(), ARM (recent ARM, anyway) and Power could use a weaker
barrier, and so on -- but smp_mb() emits a full barrier.
Perhaps a new smp_tmb() for TSO semantics, where reads are ordered
before reads, writes before writes, and reads before writes, but not
writes before reads? Another approach would be to define a per-arch
barrier for this particular case.
If the read shows no available space, we simply will not issue those
writes -- therefore we could argue we can avoid the memory barrier.
Proving that means iterating through the permitted combinations of
compilers and architectures... There is always hand-coded assembly
language, I suppose.
However, that leaves D unpaired and me confused. We must have D because
otherwise the CPU could reorder that write into the reads previous and
the kernel could start overwriting data we're still reading.. which
seems like a bad deal.
Yep. If you were hand-coding only for x86 and s390, D would pair with
the required barrier() asm.
Also, I'm not entirely sure on C, that too seems like a dependency, we
simply cannot read the buffer @tail before we've
Re: perf events ring buffer memory barrier on powerpc
On Wed, Oct 30, 2013 at 04:52:05PM +0200, Victor Kaplansky wrote: Peter Zijlstra pet...@infradead.org wrote on 10/30/2013 01:25:26 PM: Also, I'm not entirely sure on C, that too seems like a dependency, we simply cannot read the buffer @tail before we've read the tail itself, now can we? Similarly we cannot compare tail to head without having the head read completed. No, this one we cannot omit, because our problem on consumer side is not with @tail, which is written exclusively by consumer, but with @head. BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only around @head read. If you omit the ACCESS_ONCE() calls around @tail, the compiler is within its rights to combine adjacent operations and also to invent loads and stores, for example, in cases of register pressure. It is also within its rights to do piece-at-a-time loads and stores, which might sound unlikely, but which can actually has happened when the compiler figures out exactly what is to be stored at compile time, especially on hardware that only allows small immediate values. So the ACCESS_ONCE() calls are not optional, the current contents of Documentation/circular-buffers.txt notwithstanding. Thanx, Paul -- 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 v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Hi,
On Mon, Oct 14, 2013 at 02:46:49PM +0200, Maxime COQUELIN wrote:
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports I2C Standard and Fast modes.
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
---
Documentation/devicetree/bindings/i2c/i2c-st.txt | 38 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-st.c | 867
++
4 files changed, 916 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
create mode 100644 drivers/i2c/busses/i2c-st.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt
b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000..8b2fd0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,38 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be st,comms-i2c
I personally don't care about naming here. Has there been a solution
now?
+- reg : Offset and length of the register set for the device
+- interrupts : the interrupt specifier
+- clock-names: Must contain ssc.
+- clocks: Must contain an entry for each name in clock-names. See the common
+ clock bindings.
+- A pinctrl state named default must be defined, using the bindings in
+ ../pinctrl/pinctrl-binding.txt
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 10 and 40.
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+ allowed through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+ allowed through the deglitch circuit. In units of us.
Okay, so we had lots of dt bindings discussions at kernel summit. Since
we don't have unstable bindings yet, I have been convinced that it is
okay two have one or two vendor specific bindings before introducing a
generic one. That will create a little bit of cruft, but increases
chances that the generic bindings are proper. So, really sorry for going
back and forth, but it was important for the process. Vendor binding is
it now. Period.
...
+/**
+ * struct st_i2c_deglitch - Anti-glitch filter configuration
+ * @scl_min_width_us: SCL line minimum pulse width in ns
+ * @sda_min_width_us: SDA line minimum pulse width in ns
+ */
+struct st_i2c_deglitch {
+ u32 scl_min_width_us;
+ u32 sda_min_width_us;
+};
Minor: Why a seperate struct?
+/**
+ * st_i2c_handle_write() - Handle FIFO enmpty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void st_i2c_handle_read(struct st_i2c_dev *i2c_dev)
+{
+ struct st_i2c_client *c = i2c_dev-client;
+ u32 ien;
+
+ /* Trash the address read back */
+ if (!c-xfered) {
+ readl(i2c_dev-base + SSC_RBUF);
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_TXENB);
+ } else
+ st_i2c_read_rx_fifo(i2c_dev);
Braces around else branch.
+
+ if (!c-count) {
+ /* End of xfer, send stop or repstart */
+ st_i2c_terminate_xfer(i2c_dev);
+ } else if (c-count == 1) {
+ /* Penultimate byte to xfer, disable ACK gen. */
+ st_i2c_clr_bits(i2c_dev-base + SSC_I2C, SSC_I2C_ACKG);
+
+ /* Last received byte is to be handled by NACK interrupt */
+ ien = SSC_IEN_NACKEN | SSC_IEN_ARBLEN;
+ writel(ien, i2c_dev-base + SSC_IEN);
+
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count);
+ } else
+ st_i2c_rd_fill_tx_fifo(i2c_dev, c-count - 1);
Braces around else branch.
+}
+static int st_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct st_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ int ret;
+
+ i2c_dev = devm_kzalloc(pdev-dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(i2c_dev-base))
+ return PTR_ERR(i2c_dev-base);
+
+ i2c_dev-irq = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev-irq) {
+ dev_err(pdev-dev, IRQ missing or invalid\n);
+ return -EINVAL;
+ }
+
+ i2c_dev-clk = of_clk_get_by_name(np, ssc);
+ if (IS_ERR(i2c_dev-clk)) {
+ dev_err(pdev-dev, Unable to request clock\n);
+ return PTR_ERR(i2c_dev-clk);
+
[Suggestion] about latest commit for scripts/get_maintainers.pl
Hello Joe:
I meet a failure about scripts/get_maintainers.pl, it is about the
commit 750432d get_maintainer.pl incomplete output, if use original
scripts/get_maintainer.pl, it will be OK.
Please help check, thanks.
The related information:
-information begin---
[root@gchenlinux linux-next]# ./scripts/get_maintainer.pl
/tmp/0001-hexagon-kernel-remove-useless-variables-dn-r-and-err.patch
Can't use string (GitAuthor: Chen Gang gang.chen@...) as an ARRAY ref
while strict refs in use at ./scripts/get_maintainer.pl line 1883.
[root@gchenlinux linux-next]# cat
/tmp/0001-hexagon-kernel-remove-useless-variables-dn-r-and-err.patch
From ef7384078bacdc5151039ea710943e5710d7c5ed Mon Sep 17 00:00:00 2001
From: Chen Gang gang.c...@asianux.com
Date: Fri, 1 Nov 2013 18:58:18 +0800
Subject: [PATCH] hexagon: kernel: remove useless variables 'dn', 'r' and
'err' in time_init_deferred() in time.c
Remove them, since they are useless. The related warnings (with allmodconfig
for v4):
CC arch/hexagon/kernel/time.o
arch/hexagon/kernel/time.c: In function 'time_init_deferred':
arch/hexagon/kernel/time.c:196: warning: unused variable 'err'
arch/hexagon/kernel/time.c:195: warning: unused variable 'r'
arch/hexagon/kernel/time.c:194: warning: unused variable 'dn'
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/hexagon/kernel/time.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index 9903fad..d0c4f5a 100644
--- a/arch/hexagon/kernel/time.c
+++ b/arch/hexagon/kernel/time.c
@@ -191,9 +191,6 @@ void __init time_init_deferred(void)
{
struct resource *resource = NULL;
struct clock_event_device *ce_dev = hexagon_clockevent_dev;
- struct device_node *dn;
- struct resource r;
- int err;
ce_dev-cpumask = cpu_all_mask;
--
1.7.7.6
-information end-
Thanks.
--
Chen Gang
--
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 -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
Prohibit probing on func_ptr_is_kernel_text().
Since the func_ptr_is_kernel_text() is called from
notifier_call_chain() which is called from int3 handler,
probing it may cause double int3 fault and kernel will
reboot.
This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Borislav Petkov b...@suse.de
Cc: Ingo Molnar mi...@kernel.org
---
kernel/extable.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/extable.c b/kernel/extable.c
index 832cb28..022fb25 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
* pointer is part of the kernel text, we need to do some
* special dereferencing first.
*/
-int func_ptr_is_kernel_text(void *ptr)
+int nokprobe func_ptr_is_kernel_text(void *ptr)
{
unsigned long addr;
addr = (unsigned long) dereference_function_descriptor(ptr);
--
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 -tip v2 2/3] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_*
Prohibit probing on debug_stack_reset and debug_stack_set_zero.
Since the both functions are called from TRACE_IRQS_ON/OFF_DEBUG
macros which run in int3 ist entry, probing it may cause a soft
lockup.
This happens when the kernel built with CONFIG_DYNAMIC_FTRACE=y
and CONFIG_TRACE_IRQFLAGS=y.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Borislav Petkov b...@suse.de
Cc: Fenghua Yu fenghua...@intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
---
arch/x86/kernel/cpu/common.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1789b06..928a4fd 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1157,7 +1157,7 @@ DEFINE_PER_CPU(struct orig_ist, orig_ist);
static DEFINE_PER_CPU(unsigned long, debug_stack_addr);
DEFINE_PER_CPU(int, debug_stack_usage);
-int is_debug_stack(unsigned long addr)
+int nokprobe is_debug_stack(unsigned long addr)
{
return __get_cpu_var(debug_stack_usage) ||
(addr = __get_cpu_var(debug_stack_addr)
@@ -1166,13 +1166,13 @@ int is_debug_stack(unsigned long addr)
DEFINE_PER_CPU(u32, debug_idt_ctr);
-void debug_stack_set_zero(void)
+void nokprobe debug_stack_set_zero(void)
{
this_cpu_inc(debug_idt_ctr);
load_current_idt();
}
-void debug_stack_reset(void)
+void nokprobe debug_stack_reset(void)
{
if (WARN_ON(!this_cpu_read(debug_idt_ctr)))
return;
--
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 -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions
Instead of __kprobes annotation, introduce 'nokprobe' new annotation to annotate that the function is not probed by kprobes. Previously the '__kprobes' is used just for avoiding probes on kprobes-related functions which will be used from kprobes. However nowadays we use it for prohibiting probing the functions implicitly invoked from kprobes int3 handler, since that causes infinit-loop lockup or sudden reboot. In this case, the annotated functions are not limited in the kprobes-related functions, and __kprobes looks very confusing. (Moreover, actually, most of control-side kprobes functions like as register_kprobes() are safely probed by kprobes) Thus, we decide to introduce 'nokprobe' new annotation. We leave __kprobes just for compatibility but it should be replaced or removed eventually. New commits must use 'nokprobe' for this purpose. Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com Cc: Ingo Molnar mi...@kernel.org Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com Cc: David S. Miller da...@davemloft.net --- include/linux/compiler.h |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 92669cd..173c64e 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -353,8 +353,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); /* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */ #ifdef CONFIG_KPROBES -# define __kprobes __attribute__((__section__(.kprobes.text))) +# define nokprobe __attribute__((__section__(.kprobes.text))) #else -# define __kprobes +# define nokprobe #endif +#define __kprobes nokprobe + #endif /* __LINUX_COMPILER_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 -tip v2 0/3] kprobes: introduce nokprobe and updating blacklist
According to Ingo's suggestion, I've introduced 'nokprobe' new annotation as like as 'notrace' annotation, since __kprobes annotation is too confusing to mark non-kprobe able functions. I took 'nokprobe' instead of 'noprobe' since we already have irq_set_noprobe() etc. Also, I've found that putting probes on some functions could lock or reboot the kernel. These two patches fix those bugs by prohibiting probing such functions by adding those to blacklist(kprobes.text). In both cases, those functions are related to int3 handling execution path. One is related to irqoff-tracer and the other is related to notifier debug option. Thank you, Changes in the latest version: - introduce nokprobe annotation - change __kprobes to nokprobe in bugfixes - remove unneeded linux/kprobes.h includings. --- Masami Hiramatsu (3): kprobes: Introduce nokprobe annotation for non-probe-able functions [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_* [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text arch/x86/kernel/cpu/common.c |6 +++--- include/linux/compiler.h |6 -- kernel/extable.c |2 +- 3 files changed, 8 insertions(+), 6 deletions(-) -- 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: kernel 3.11.6 general protection fault
On Fri, Nov 01, 2013 at 10:18:49AM +0100, MPhil. Emanoil Kotsev wrote: On Thursday 31 October 2013 17:44:03 you wrote: Please do not top-post. Sorry for top posting No probs :). Btw, one more thing: when you reply, make sure you hit reply-to-all so that CC list remains intact. I tried with no success. I remember that I also tested this with an older version 3.3.8 which was working fine before, but now it dies (it was not locked however, so I could reboot) If you notice this kernel was not tainted. Right, the fact that you're triggering it with different kernels could point at a hardware issue, maybe DIMMs going bad. You could try taking out DIMMs one by one and see whether it still happens. Somewhere it said the BIOS version is from 2006 so it is kinda of an older box so I can imagine stuff going kaputtski :) And the #GP below doesn't point at DRM anywhere which strengthens the suspicion of a hw issue. Oct 17 14:40:36 maistor kernel: general protection fault: [#1] PREEMPT SMP Oct 17 14:40:36 maistor kernel: CPU 0 Oct 17 14:40:36 maistor kernel: Modules linked in: snd_hrtimer nfs lockd nfs_acl sunrpc iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 acpi _cpufreq mperf iptable_mangle iptable_filter ip_tables x_tables cpufreq_ondemand cpufreq_powersave cpufreq_performance cpufreq_stats freq_table cpufreq_conse rvative parport_pc ppdev lp parport bnep rfcomm bluetooth crc16 acpi_ipmi ipmi_msghandler acpi_pad sbs sbshc pci_slot fan binfmt_misc uinput fuse af_packet i pv6 firewire_sbp2 uvcvideo videobuf2_core snd_usb_audio videodev snd_usbmidi_lib v4l2_compat_ioctl32 videobuf2_vmalloc videobuf2_memops snd_hda_codec_idt snd _hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi yenta_socket snd_rawmidi snd_seq_midi_event snd_s eq snd_timer snd_seq_device snd pcmcia_rsrc iTCO_wdt iTCO_vendor_support arc4 iwl3945 iwlegacy mac80211 soundcore cfg80211 rfkill i2c_i801 8250_pnp dell_wmi sparse_keymap processor snd_page_alloc wmi dcdbas rtc_cmos 8250 evdev joydev battery a Oct 17 14:40:36 maistor kernel: c serial_core sha256_generic cryptd aes_x86_64 aes_generic cbc usbhid hid loop dm_crypt dm_mod usb_storage usb_libusual uas i 915 cfbfillrect cfbimgblt thermal sd_mod sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t b44 ssb mmc_core mii video uhci_hcd pcmcia pcmcia_core ehci_hc d button cfbcopyarea i2c_algo_bit drm_kms_helper usbcore intel_agp intel_gtt drm usb_common agpgart i2c_core thermal_sys hwmon [last unloaded: scsi_wait_scan ] Oct 17 14:40:36 maistor kernel: Oct 17 14:40:36 maistor kernel: Pid: 6082, comm: firefox Not tainted 3.3.8eko2 #4 Dell Inc. Latitude D520 /0NF743 Oct 17 14:40:36 maistor kernel: RIP: 0010:[8117076f] [8117076f] plist_del+0x3b/0x66 Oct 17 14:40:36 maistor kernel: RSP: 0018:880032025ce0 EFLAGS: 00010246 Oct 17 14:40:36 maistor kernel: RAX: 880032131cf0 RBX: 8800322212f0 RCX: fcff880032131cf0 Oct 17 14:40:36 maistor kernel: RDX: 880032131cf0 RSI: 8150f338 RDI: 880032131ce8 Oct 17 14:40:36 maistor kernel: RBP: 880032131ce8 R08: fcff880032131cf0 R09: 880032025f08 Oct 17 14:40:36 maistor kernel: R10: 7fff R11: 0283 R12: 8150f330 Oct 17 14:40:36 maistor kernel: R13: 8150fdf8 R14: R15: Oct 17 14:40:36 maistor kernel: FS: 7fc2ec3e4740() GS:88007f40() knlGS: Oct 17 14:40:36 maistor kernel: CS: 0010 DS: ES: CR0: 80050033 Oct 17 14:40:36 maistor kernel: CR2: 2ac4fd23b000 CR3: 3221e000 CR4: 06f0 Oct 17 14:40:36 maistor kernel: DR0: DR1: DR2: Oct 17 14:40:36 maistor kernel: DR3: DR6: 0ff0 DR7: 0400 Oct 17 14:40:36 maistor kernel: Process firefox (pid: 6082, threadinfo 880032024000, task 8800320cb2b0) Oct 17 14:40:36 maistor kernel: Stack: Oct 17 14:40:36 maistor kernel: 8105f7cd 880032131ce8 Oct 17 14:40:36 maistor kernel: 81060d51 525fdac4 880032025d58 8801 Oct 17 14:40:36 maistor kernel: 55aa3e58 8150f320 00010001 8150f338 Oct 17 14:40:36 maistor kernel: Call Trace: Oct 17 14:40:36 maistor kernel: [8105f7cd] ? wake_futex+0x16/0x45 Oct 17 14:40:36 maistor kernel: [81060d51] ? futex_requeue+0x4a2/0x690 Oct 17 14:40:36 maistor kernel: [81061042] ? do_futex+0x103/0x8be Oct 17 14:40:36 maistor kernel: [810c303e] ? do_sync_read+0xb1/0xea Oct 17 14:40:36 maistor kernel: [81253289] ? sys_recvfrom+0x113/0x12b Oct 17 14:40:36 maistor kernel: [81061927] ? sys_futex+0x12a/0x142 Oct 17 14:40:36 maistor kernel:
Re: [PATCH 1/4] ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support
2013/11/1 Anssi Hannula anssi.hann...@iki.fi: Both are working for me. I've tested it using 2 movies: 1) English TrueHD.5.1 @ 1417 kbps 2) Audio Codec: DTSHD-MA Bitrate..: 3718 kbps kHz/bit..: 24-bit Channels.: 5.1 Language.: English Which makes it even stranger, since HBR packets look exactly like ASP packets with a few flipped bits. Hm, the earlier non-working speaker-test commands were with -c6. What about -c8? Side right behaves just like rear right Side left behaves just like a rear left No other differences. -- Rafał -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
On Fri, Nov 01, 2013 at 09:18:25AM +0800, Dave Young wrote: Great, thank you. BTW, I have managed to test original patch set on a Macboot Air of my friend with usb boot, it works ok. Ok, that's actually a very good news - the apples tend to be special wrt uefi implementation. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 v12] i2c: exynos5: add High Speed I2C controller driver
On Wed, Oct 16, 2013 at 11:00:42AM +0530, Naveen Krishna Chatradhi wrote: Adds support for High Speed I2C driver found in Exynos5 and later SoCs from Samsung. Driver only supports Device Tree method. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Taekgyun Ko taeggyun...@samsung.com Reviewed-by: Simon Glass s...@google.com Tested-by: Andrew Bresticker abres...@google.com Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com Signed-off-by: Andrew Bresticker abres...@google.com Rebased to v3.12-rc4 and Applied to for-next, thanks! signature.asc Description: Digital signature
[PATCH 1/8] lib/genalloc: add a helper function for DMA buffer allocation
When using pool space for DMA buffer, there might be duplicated calling
of gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
Thus it's better to add a simple helper function, a compatible one to
the common dma_alloc_coherent(), to save some code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
include/linux/genalloc.h | 2 ++
lib/genalloc.c | 28
2 files changed, 30 insertions(+)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index f8d41cb..1eda33d 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -94,6 +94,8 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 26cf20b..dda3116 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -313,6 +313,34 @@ retry:
EXPORT_SYMBOL(gen_pool_alloc);
/**
+ * gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ unsigned long vaddr;
+
+ if (!pool)
+ return NULL;
+
+ vaddr = gen_pool_alloc(pool, size);
+ if (!vaddr)
+ return NULL;
+
+ *dma = gen_pool_virt_to_phys(pool, vaddr);
+
+ return (void *)vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_alloc);
+
+/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
* @addr: starting address of memory to free back to pool
--
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 0/8] Add and implement gen_pool_dma_alloc()
Previously, we don't have a specific gen_pool_alloc() for DMA usage; Instead, we need to use gen_pool_virt_to_phys() to convert the addr returned from gen_pool_alloc(). So each implementation of this has duplicated code. Thus add new helper function -- gen_pool_dma_alloc(). After gen_pool_dma_alloc() is introduced, we can replace the original combination of gen_pool_alloc()+gen_pool_virt_to_phys() with this new helper function. Thus this patch implement the helper function to all the current drivers which use gen_pool_virt_to_phys(). !!---important--!! The later 7 patches need all related driver owner to test. We can here define a simple rule: 1, If one driver owner or maintainer doesn't like the mofication to his/her driver, just let me know. I would drop that patch. 2, If there's a bug and issue found after patch-testing, please reply the mail so that I can fix and refine the patch. 3, If one driver owner or maintainer is too busy and doesn't have bandwidth to test the patch, I would drop that patch from this series. We can reimplement it till there's someone test it. !!---current progress---!! lib/genalloc: [Okay] ARM: davinci: [Untested] dma: mmp_tdma: [Untested] [media] coda: [Untested] uio: uio_pruss: [Untested] ALSA: memalloc: [Tested] by Nicolin Chen with i.MX6Q SabreSD ASoC: davinci: [Untested] ASoC: pxa: use [Untested] Nicolin Chen (8): lib/genalloc: add a helper function for DMA buffer allocation ARM: davinci: use gen_pool_dma_alloc() to sram.c dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor [media] coda: use gen_pool_dma_alloc() to allocate iram buffer uio: uio_pruss: use gen_pool_dma_alloc() to allocate sram memory ALSA: memalloc: use gen_pool_dma_alloc() to allocate iram buffer ASoC: davinci: use gen_pool_dma_alloc() in davinci-pcm.c ASoC: pxa: use gen_pool_dma_alloc() to allocate dma buffer arch/arm/mach-davinci/sram.c| 9 + drivers/dma/mmp_tdma.c | 7 +-- drivers/media/platform/coda.c | 5 ++--- drivers/uio/uio_pruss.c | 6 ++ include/linux/genalloc.h| 2 ++ lib/genalloc.c | 28 sound/core/memalloc.c | 6 +- sound/soc/davinci/davinci-pcm.c | 3 +-- sound/soc/pxa/mmp-pcm.c | 3 +-- 9 files changed, 39 insertions(+), 30 deletions(-) -- 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] fix race between stop_two_cpus and stop_cpus
On 11/01/2013 07:08 AM, Mel Gorman wrote:
On Thu, Oct 31, 2013 at 04:31:44PM -0400, Rik van Riel wrote:
There is a race between stop_two_cpus, and the global stop_cpus.
What was the trigger for this? I want to see what was missing from my own
testing. I'm going to go out on a limb and guess that CPU hotplug was also
running in the background to specifically stress this sort of rare condition.
Something like running a standard test with the monitors/watch-cpuoffline.sh
from mmtests running in parallel.
AFAIK the trigger was a test that continuously loads and
unloads kernel modules, while doing other stuff.
It is possible for two CPUs to get their stopper functions queued
backwards from one another, resulting in the stopper threads
getting stuck, and the system hanging. This can happen because
queuing up stoppers is not synchronized.
This patch adds synchronization between stop_cpus (a rare operation),
and stop_two_cpus.
Signed-off-by: Rik van Riel r...@redhat.com
---
Prarit is running a test with this patch. By now the kernel would have
crashed already, yet it is still going. I expect Prarit will add his
Tested-by: some time tomorrow morning.
kernel/stop_machine.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 32a6c44..46cb4c2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -40,8 +40,10 @@ struct cpu_stopper {
};
static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
+static DEFINE_PER_CPU(bool, stop_two_cpus_queueing);
static DEFINE_PER_CPU(struct task_struct *, cpu_stopper_task);
static bool stop_machine_initialized = false;
+static bool stop_cpus_queueing = false;
static void cpu_stop_init_done(struct cpu_stop_done *done, unsigned int
nr_todo)
{
@@ -261,16 +263,37 @@ int stop_two_cpus(unsigned int cpu1, unsigned int
cpu2, cpu_stop_fn_t fn, void *
cpu_stop_init_done(done, 2);
set_state(msdata, MULTI_STOP_PREPARE);
+ wait_for_global:
+/* If a global stop_cpus is queuing up stoppers, wait. */
+while (unlikely(stop_cpus_queueing))
+cpu_relax();
+
This partially serialises callers to migrate_swap() while it is checked
if the pair of CPUs are being affected at the moment. It's two-stage
Not really. This only serializes migrate_swap if there is a global
stop_cpus underway.
If there is no global stop_cpus, migrate_swap will continue the way
it did before, without locking.
locking. The global lock is short-lived while the per-cpu data is updated
and the per-cpu values allow a degree of parallelisation on call_cpu which
could not be done with a spinlock held anyway. Why not make protection
of the initial update a normal spinlock? i.e.
spin_lock(stop_cpus_queue_lock);
this_cpu_write(stop_two_cpus_queueing, true);
spin_unlock(stop_cpus_queue_lock);
Because that would result in all migrate_swap instances serializing
with each other.
--
All rights reversed
--
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/8] uio: uio_pruss: use gen_pool_dma_alloc() to allocate sram memory
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
drivers/uio/uio_pruss.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index f519da9..96c4a19 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -158,14 +158,12 @@ static int pruss_probe(struct platform_device *dev)
if (pdata-sram_pool) {
gdev-sram_pool = pdata-sram_pool;
gdev-sram_vaddr =
- gen_pool_alloc(gdev-sram_pool, sram_pool_sz);
+ (unsigned long)gen_pool_dma_alloc(gdev-sram_pool,
+ sram_pool_sz, gdev-sram_paddr);
if (!gdev-sram_vaddr) {
dev_err(dev-dev, Could not allocate SRAM pool\n);
goto out_free;
}
- gdev-sram_paddr =
- gen_pool_virt_to_phys(gdev-sram_pool,
- gdev-sram_vaddr);
}
gdev-ddr_vaddr = dma_alloc_coherent(dev-dev, extram_pool_sz,
--
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 4/8] [media] coda: use gen_pool_dma_alloc() to allocate iram buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
drivers/media/platform/coda.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index ed4998c..bd72fb9 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -3298,13 +3298,12 @@ static int coda_probe(struct platform_device *pdev)
dev-iram_size = CODA7_IRAM_SIZE;
break;
}
- dev-iram_vaddr = gen_pool_alloc(dev-iram_pool, dev-iram_size);
+ dev-iram_vaddr = (unsigned long)gen_pool_dma_alloc(dev-iram_pool,
+ dev-iram_size, (dma_addr_t *)dev-iram_paddr);
if (!dev-iram_vaddr) {
dev_err(pdev-dev, unable to alloc iram\n);
return -ENOMEM;
}
- dev-iram_paddr = gen_pool_virt_to_phys(dev-iram_pool,
- dev-iram_vaddr);
platform_set_drvdata(pdev, dev);
--
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 V5 net-next 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
Oliver Neukum oneu...@suse.de writes:
On Mon, 2013-09-30 at 04:50 +, Enrico Mioso wrote:
+static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
+{
+struct huawei_cdc_ncm_state *drvstate = (void *)usbnet_dev-data;
+int rv = 0;
+
+if ((on atomic_add_return(1, drvstate-pmcount) == 1) ||
+(!on atomic_dec_and_test(drvstate-pmcount))) {
+rv = usb_autopm_get_interface(usbnet_dev-intf);
+if (rv 0)
+goto err;
The error case corrupts drvstate-pmcount
+usbnet_dev-intf-needs_remote_wakeup = on;
+usb_autopm_put_interface(usbnet_dev-intf);
+}
+err:
+return rv;
+}
Hello Oliver,
I finally got around to looking closer at this and you are of course
correct. This is all my fault when I initially wrapped the
needs_remote_wakeup update in usb_autopm_{get,put}_interface,
And the problem is not only here in this new driver, but *everywhere* I
did this, including in cdc-wdm. That driver doesn't have the counter to
corrupt, but failing to update intf-needs_remote_wakeup if
usb_autopm_get_interface fails is still wrong. The get/put were only
added to make the change take effect immediately. Things sort of worked
fine before that, and ignoring a get error would only revert to that
older behaviour.
So I believe we should do the update unconditionally, and but skip
usb_autopm_put_interface if the get failed. Accordingly, these
functions should always return 0 (not that there is anything currently
checking the return anyway).
I'll prepare patches for cdc-wdm, qmi_wwan and cdc_mbim.
Bjørn
--
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/8] ALSA: memalloc: use gen_pool_dma_alloc() to allocate iram buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/core/memalloc.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c index 9d93f02..5e1c7bc 100644 --- a/sound/core/memalloc.c +++ b/sound/core/memalloc.c @@ -184,11 +184,7 @@ static void snd_malloc_dev_iram(struct snd_dma_buffer *dmab, size_t size) /* Assign the pool into private_data field */ dmab-private_data = pool; - dmab-area = (void *)gen_pool_alloc(pool, size); - if (!dmab-area) - return; - - dmab-addr = gen_pool_virt_to_phys(pool, (unsigned long)dmab-area); + dmab-area = gen_pool_dma_alloc(pool, size, dmab-addr); } /** -- 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 7/8] ASoC: davinci: use gen_pool_dma_alloc() in davinci-pcm.c
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/soc/davinci/davinci-pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index 84a63c6..fa64cd8 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -267,10 +267,9 @@ static int allocate_sram(struct snd_pcm_substream *substream, return 0; ppcm-period_bytes_max = size; - iram_virt = (void *)gen_pool_alloc(sram_pool, size); + iram_virt = gen_pool_dma_alloc(sram_pool, size, iram_phys); if (!iram_virt) goto exit1; - iram_phys = gen_pool_virt_to_phys(sram_pool, (unsigned)iram_virt); iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL); if (!iram_dma) goto exit2; -- 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 8/8] ASoC: pxa: use gen_pool_dma_alloc() to allocate dma buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/soc/pxa/mmp-pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/pxa/mmp-pcm.c b/sound/soc/pxa/mmp-pcm.c index 8235e23..7929e19 100644 --- a/sound/soc/pxa/mmp-pcm.c +++ b/sound/soc/pxa/mmp-pcm.c @@ -201,10 +201,9 @@ static int mmp_pcm_preallocate_dma_buffer(struct snd_pcm_substream *substream, if (!gpool) return -ENOMEM; - buf-area = (unsigned char *)gen_pool_alloc(gpool, size); + buf-area = gen_pool_dma_alloc(gpool, size, buf-addr); if (!buf-area) return -ENOMEM; - buf-addr = gen_pool_virt_to_phys(gpool, (unsigned long)buf-area); buf-bytes = size; return 0; } -- 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 3/8] dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- drivers/dma/mmp_tdma.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c index 2b4026d..3ddacc1 100644 --- a/drivers/dma/mmp_tdma.c +++ b/drivers/dma/mmp_tdma.c @@ -378,12 +378,7 @@ struct mmp_tdma_desc *mmp_tdma_alloc_descriptor(struct mmp_tdma_chan *tdmac) if (!gpool) return NULL; - tdmac-desc_arr = (void *)gen_pool_alloc(gpool, size); - if (!tdmac-desc_arr) - return NULL; - - tdmac-desc_arr_phys = gen_pool_virt_to_phys(gpool, - (unsigned long)tdmac-desc_arr); + tdmac-desc_arr = gen_pool_dma_alloc(gpool, size, tdmac-desc_arr_phys); return tdmac-desc_arr; } -- 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 2/8] ARM: davinci: use gen_pool_dma_alloc() to sram.c
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
arch/arm/mach-davinci/sram.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index f18928b..8540ddd 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -25,7 +25,6 @@ struct gen_pool *sram_get_gen_pool(void)
void *sram_alloc(size_t len, dma_addr_t *dma)
{
- unsigned long vaddr;
dma_addr_t dma_base = davinci_soc_info.sram_dma;
if (dma)
@@ -33,13 +32,7 @@ void *sram_alloc(size_t len, dma_addr_t *dma)
if (!sram_pool || (dma !dma_base))
return NULL;
- vaddr = gen_pool_alloc(sram_pool, len);
- if (!vaddr)
- return NULL;
-
- if (dma)
- *dma = gen_pool_virt_to_phys(sram_pool, vaddr);
- return (void *)vaddr;
+ return gen_pool_dma_alloc(sram_pool, len, dma);
}
EXPORT_SYMBOL(sram_alloc);
--
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] fix race between stop_two_cpus and stop_cpus
On 11/01/2013 07:08 AM, Mel Gorman wrote:
On Thu, Oct 31, 2013 at 04:31:44PM -0400, Rik van Riel wrote:
There is a race between stop_two_cpus, and the global stop_cpus.
What was the trigger for this? I want to see what was missing from my own
testing. I'm going to go out on a limb and guess that CPU hotplug was also
running in the background to specifically stress this sort of rare condition.
Something like running a standard test with the monitors/watch-cpuoffline.sh
from mmtests running in parallel.
I have a test that loads and unloads each module in /lib/modules/3.*/...
Each run typically takes a few minutes. After running 4-5 times, the system
issues a soft lockup warning with a CPU in multi_cpu_stop(). Unfortunately,
kdump isn't working on this particular system (due to another bug) so I modified
the code with (sorry for the cut-and-paste):
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 05039e3..4a8c9f9 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -323,8 +323,10 @@ static enum hrtimer_restart watchdog_timer_fn(struct hrtime
else
dump_stack();
- if (softlockup_panic)
+ if (softlockup_panic) {
+ show_state();
panic(softlockup: hung tasks);
+ }
__this_cpu_write(soft_watchdog_warn, true);
} else
__this_cpu_write(soft_watchdog_warn, false);
and then 'echo 1 /proc/sys/kernel/softlockup_panic' to get a full trace of all
tasks.
When I did this and ran the kernel module load unload test ...
[prarit@prarit tmp]$ cat /tmp/intel.log | grep RIP
[ 678.081168] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.156180] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.230190] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.244186] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.259194] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.274192] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.288195] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.303197] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.318200] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.333203] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.349206] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.364208] RIP: 0010:[810d328b] [810d328b]
multi_cpu_stop+0x7b/0xf0
[ 678.379211] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.394212] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.409215] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.424217] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.438219] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.452221] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.466228] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.481228] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.496230] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.511234] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.526236] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.541238] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.556244] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.571243] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.586247] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
[ 678.601248] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.616251] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 678.632254] RIP: 0010:[810d328b] [810d328b]
multi_cpu_stop+0x7b/0xf0
[ 678.647257] RIP: 0010:[810d3292] [810d3292]
multi_cpu_stop+0x82/0xf0
[ 687.570464] RIP: 0010:[810d3296] [810d3296]
multi_cpu_stop+0x86/0xf0
and,
[prarit@prarit tmp]$ cat /tmp/intel.log | grep RIP | wc -l
32
which shows all 32 cpus are correctly in the cpu stop threads. After some
investigation, Rik came up with his patch.
Hope this explains things,
P.
--
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 v10 00/20] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Mon, Oct 07, 2013 at 10:52:12AM +0900, Cho KyongHo wrote: Patch summary: [PATCH 01/20] iommu/exynos: do not include removed header [PATCH 02/20] iommu/exynos: add missing cache flush for removed page table entries [PATCH 03/20] iommu/exynos: change error handling when page table update is failed [PATCH 04/20] iommu/exynos: fix L2TLB invalidation [PATCH 05/20] iommu/exynos: allocate lv2 page table from own slab [PATCH 06/20] iommu/exynos: always enable runtime PM [PATCH 07/20] iommu/exynos: always use a single clock descriptor [PATCH 08/20] iommu/exynos: remove dbgname from drvdata of a System MMU [PATCH 09/20] iommu/exynos: use managed device helper functions [PATCH 10/20] clk: exynos: add gate clock descriptions of System MMU [PATCH 11/20] ARM: dts: Add description of System MMU of Exynos SoCs [PATCH 12/20] iommu/exynos: support for device tree [PATCH 13/20] iommu/exynos: gating clocks of master H/W [PATCH 14/20] iommu/exynos: remove custom fault handler [PATCH 15/20] iommu/exynos: remove calls to Runtime PM API functions [PATCH 16/20] iommu/exynos: turn on useful configuration options [PATCH 17/20] iommu/exynos: add support for power management subsystems. [PATCH 18/20] iommu/exynos: change rwlock to spinlock [PATCH 19/20] iommu/exynos: return 0 if iommu_attach_device() successes [PATCH 20/20] iommu/exynos: add devices attached to the System MMU to an IOMMU group Diffstats: .../devicetree/bindings/clock/exynos5250-clock.txt | 28 + .../devicetree/bindings/clock/exynos5420-clock.txt |3 + .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 76 ++ arch/arm/boot/dts/exynos4.dtsi | 105 ++ arch/arm/boot/dts/exynos4210.dtsi | 21 + arch/arm/boot/dts/exynos4x12.dtsi | 82 ++ arch/arm/boot/dts/exynos5250.dtsi | 262 + arch/arm/boot/dts/exynos5420.dtsi | 296 ++ drivers/clk/samsung/clk-exynos5250.c | 49 +- drivers/clk/samsung/clk-exynos5420.c | 12 +- drivers/iommu/Kconfig |5 +- drivers/iommu/exynos-iommu.c | 1033 +--- 12 files changed, 1585 insertions(+), 387 deletions(-) What is the state of this series? It would be good to have some Acked-bys and/or Reviewed-bys on it. Joerg -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 11:15:14AM +0100, Peter Zijlstra wrote:
On Fri, Nov 01, 2013 at 06:07:07PM +0800, Yuanhan Liu wrote:
I also want to point out that lately we've seen several changes sent
out that relax locking with no accompanying explanation of why the
relaxed locking would be safe. Please don't do that - having a lot of
performance data is worthless if you can't explain why the new locking
is safe.
Agreed.
And I'm not asking to prove a negative ('lack of any possible
races') there, but at least in this case one could dig out why the
root anon vma locking was introduced and if they think that this
reason doesn't apply anymore, explain why...
It was introduced by commit 2b575eb6(And, BTW, I'm sorry that this commit
log
about bb4aa39676f is wrong)
commit 2b575eb64f7a9c701fb4bfdb12388ac547f6c2b6
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Tue May 24 17:12:11 2011 -0700
mm: convert anon_vma-lock to a mutex
Straightforward conversion of anon_vma-lock to a mutex.
As you can see, Peter didn't tell why before. Honestly speaking, that
was my originaly concern as well. I tried to find some possible races;
I guess I may miss something.
Bullshit; I didn't change the locking. I only changed the lock primitive
from a spinlock to a mutex. The anon_vma-root-lock is completely
unrelated to this change.
Oops, sorry for that. Just made a *horrible* mistake: it was commit
012f18004da33ba672e3c60838cc4898126174d3.
commit 012f18004da33ba672e3c60838cc4898126174d3
Author: Rik van Riel r...@redhat.com
Date: Mon Aug 9 17:18:40 2010 -0700
mm: always lock the root (oldest) anon_vma
Always (and only) lock the root (oldest) anon_vma whenever we do something
in an anon_vma. The recently introduced anon_vma scalability is due to
the rmap code scanning only the VMAs that need to be scanned. Many common
operations still took the anon_vma lock on the root anon_vma, so always
taking that lock is not expected to introduce any scalability issues.
However, always taking the same lock does mean we only need to take one
lock, which means rmap_walk on pages from any anon_vma in the vma is
excluded from occurring during an munmap, expand_stack or other operation
that needs to exclude rmap_walk and similar functions.
Also add the proper locking to vma_adjust.
Signed-off-by: Rik van Riel r...@redhat.com
Tested-by: Larry Woodman lwood...@redhat.com
Acked-by: Larry Woodman lwood...@redhat.com
Reviewed-by: Minchan Kim minchan@gmail.com
Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Acked-by: Mel Gorman m...@csn.ul.ie
Acked-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
--
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] efifb: prevent null-deref when iterating dmi_list
On 17:17 Thu 31 Oct , David Herrmann wrote: Hi On Thu, Oct 31, 2013 at 11:45 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 18:40 Wed 02 Oct , David Herrmann wrote: The dmi_list array is initialized using gnu designated initializers, and therefore may contain fewer explicitly defined entries as there are elements in it. This is because the enum above with M_xyz constants contains more items than the designated initializer. Those elements not explicitly initialized are implicitly set to 0. Now efifb_setup() loops through all these array elements, and performs a strcmp on each item. For non explicitly initialized elements this will be a null pointer: This patch swaps the check order in the if statement, thus checks first whether dmi_list[i].base is null. Signed-off-by: James Bates james.h.ba...@yahoo.com Signed-off-by: David Herrmann dh.herrm...@gmail.com with the simpleDRM arriving next merge I'm wondering if we need to keep it? SimpleDRM is not coming next merge-window. It's basically finished, but I'm still working on the user-space side as its KMS api is highly reduced compared to fully-featured DRM/KMS drivers. Maybe 3.13 will work out. do you have a git tree for the simpleDRM that I can pull? Anyhow, this patch is still needed as it fixes a serious bug for simplefb. ok Thanks 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][RESEND 0/8] Add and implement gen_pool_dma_alloc()
Previously, we don't have a specific gen_pool_alloc() for DMA usage; Instead, we need to use gen_pool_virt_to_phys() to convert the addr returned from gen_pool_alloc(). So each implementation of this has duplicated code. Thus add new helper function -- gen_pool_dma_alloc(). After gen_pool_dma_alloc() is introduced, we can replace the original combination of gen_pool_alloc()+gen_pool_virt_to_phys() with this new helper function. Thus this patch implement the helper function to all the current drivers which use gen_pool_virt_to_phys(). !!---important--!! The later 7 patches need all related driver owner to test. We can here define a simple rule: 1, If one driver owner or maintainer doesn't like the mofication to his/her driver, just let me know. I would drop that patch. 2, If there's a bug and issue found after patch-testing, please reply the mail so that I can fix and refine the patch. 3, If one driver owner or maintainer is too busy and doesn't have bandwidth to test the patch, I would drop that patch from this series. We can reimplement it till there's someone test it. !!---current progress---!! lib/genalloc: [Okay] ARM: davinci: [Untested] dma: mmp_tdma: [Untested] [media] coda: [Untested] uio: uio_pruss: [Untested] ALSA: memalloc: [Tested] by Nicolin Chen with i.MX6Q SabreSD ASoC: davinci: [Untested] ASoC: pxa: use [Untested] Nicolin Chen (8): lib/genalloc: add a helper function for DMA buffer allocation ARM: davinci: use gen_pool_dma_alloc() to sram.c dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor [media] coda: use gen_pool_dma_alloc() to allocate iram buffer uio: uio_pruss: use gen_pool_dma_alloc() to allocate sram memory ALSA: memalloc: use gen_pool_dma_alloc() to allocate iram buffer ASoC: davinci: use gen_pool_dma_alloc() in davinci-pcm.c ASoC: pxa: use gen_pool_dma_alloc() to allocate dma buffer arch/arm/mach-davinci/sram.c| 9 + drivers/dma/mmp_tdma.c | 7 +-- drivers/media/platform/coda.c | 5 ++--- drivers/uio/uio_pruss.c | 6 ++ include/linux/genalloc.h| 2 ++ lib/genalloc.c | 28 sound/core/memalloc.c | 6 +- sound/soc/davinci/davinci-pcm.c | 3 +-- sound/soc/pxa/mmp-pcm.c | 3 +-- 9 files changed, 39 insertions(+), 30 deletions(-) -- 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][RESEND 1/8] lib/genalloc: add a helper function for DMA buffer allocation
When using pool space for DMA buffer, there might be duplicated calling
of gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
Thus it's better to add a simple helper function, a compatible one to
the common dma_alloc_coherent(), to save some code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
include/linux/genalloc.h | 2 ++
lib/genalloc.c | 28
2 files changed, 30 insertions(+)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index f8d41cb..1eda33d 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -94,6 +94,8 @@ static inline int gen_pool_add(struct gen_pool *pool,
unsigned long addr,
}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
+extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
+ dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 26cf20b..dda3116 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -313,6 +313,34 @@ retry:
EXPORT_SYMBOL(gen_pool_alloc);
/**
+ * gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ */
+void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ unsigned long vaddr;
+
+ if (!pool)
+ return NULL;
+
+ vaddr = gen_pool_alloc(pool, size);
+ if (!vaddr)
+ return NULL;
+
+ *dma = gen_pool_virt_to_phys(pool, vaddr);
+
+ return (void *)vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_alloc);
+
+/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
* @addr: starting address of memory to free back to pool
--
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][RESEND 2/8] ARM: davinci: use gen_pool_dma_alloc() to sram.c
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
arch/arm/mach-davinci/sram.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
index f18928b..8540ddd 100644
--- a/arch/arm/mach-davinci/sram.c
+++ b/arch/arm/mach-davinci/sram.c
@@ -25,7 +25,6 @@ struct gen_pool *sram_get_gen_pool(void)
void *sram_alloc(size_t len, dma_addr_t *dma)
{
- unsigned long vaddr;
dma_addr_t dma_base = davinci_soc_info.sram_dma;
if (dma)
@@ -33,13 +32,7 @@ void *sram_alloc(size_t len, dma_addr_t *dma)
if (!sram_pool || (dma !dma_base))
return NULL;
- vaddr = gen_pool_alloc(sram_pool, len);
- if (!vaddr)
- return NULL;
-
- if (dma)
- *dma = gen_pool_virt_to_phys(sram_pool, vaddr);
- return (void *)vaddr;
+ return gen_pool_dma_alloc(sram_pool, len, dma);
}
EXPORT_SYMBOL(sram_alloc);
--
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][RESEND 3/8] dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- drivers/dma/mmp_tdma.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c index 2b4026d..3ddacc1 100644 --- a/drivers/dma/mmp_tdma.c +++ b/drivers/dma/mmp_tdma.c @@ -378,12 +378,7 @@ struct mmp_tdma_desc *mmp_tdma_alloc_descriptor(struct mmp_tdma_chan *tdmac) if (!gpool) return NULL; - tdmac-desc_arr = (void *)gen_pool_alloc(gpool, size); - if (!tdmac-desc_arr) - return NULL; - - tdmac-desc_arr_phys = gen_pool_virt_to_phys(gpool, - (unsigned long)tdmac-desc_arr); + tdmac-desc_arr = gen_pool_dma_alloc(gpool, size, tdmac-desc_arr_phys); return tdmac-desc_arr; } -- 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][RESEND 5/8] uio: uio_pruss: use gen_pool_dma_alloc() to allocate sram memory
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
drivers/uio/uio_pruss.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index f519da9..96c4a19 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -158,14 +158,12 @@ static int pruss_probe(struct platform_device *dev)
if (pdata-sram_pool) {
gdev-sram_pool = pdata-sram_pool;
gdev-sram_vaddr =
- gen_pool_alloc(gdev-sram_pool, sram_pool_sz);
+ (unsigned long)gen_pool_dma_alloc(gdev-sram_pool,
+ sram_pool_sz, gdev-sram_paddr);
if (!gdev-sram_vaddr) {
dev_err(dev-dev, Could not allocate SRAM pool\n);
goto out_free;
}
- gdev-sram_paddr =
- gen_pool_virt_to_phys(gdev-sram_pool,
- gdev-sram_vaddr);
}
gdev-ddr_vaddr = dma_alloc_coherent(dev-dev, extram_pool_sz,
--
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][RESEND 7/8] ASoC: davinci: use gen_pool_dma_alloc() in davinci-pcm.c
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/soc/davinci/davinci-pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index 84a63c6..fa64cd8 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -267,10 +267,9 @@ static int allocate_sram(struct snd_pcm_substream *substream, return 0; ppcm-period_bytes_max = size; - iram_virt = (void *)gen_pool_alloc(sram_pool, size); + iram_virt = gen_pool_dma_alloc(sram_pool, size, iram_phys); if (!iram_virt) goto exit1; - iram_phys = gen_pool_virt_to_phys(sram_pool, (unsigned)iram_virt); iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL); if (!iram_dma) goto exit2; -- 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][RESEND 8/8] ASoC: pxa: use gen_pool_dma_alloc() to allocate dma buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/soc/pxa/mmp-pcm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/pxa/mmp-pcm.c b/sound/soc/pxa/mmp-pcm.c index 8235e23..7929e19 100644 --- a/sound/soc/pxa/mmp-pcm.c +++ b/sound/soc/pxa/mmp-pcm.c @@ -201,10 +201,9 @@ static int mmp_pcm_preallocate_dma_buffer(struct snd_pcm_substream *substream, if (!gpool) return -ENOMEM; - buf-area = (unsigned char *)gen_pool_alloc(gpool, size); + buf-area = gen_pool_dma_alloc(gpool, size, buf-addr); if (!buf-area) return -ENOMEM; - buf-addr = gen_pool_virt_to_phys(gpool, (unsigned long)buf-area); buf-bytes = size; return 0; } -- 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][RESEND 6/8] ALSA: memalloc: use gen_pool_dma_alloc() to allocate iram buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Signed-off-by: Nicolin Chen b42...@freescale.com --- sound/core/memalloc.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c index 9d93f02..5e1c7bc 100644 --- a/sound/core/memalloc.c +++ b/sound/core/memalloc.c @@ -184,11 +184,7 @@ static void snd_malloc_dev_iram(struct snd_dma_buffer *dmab, size_t size) /* Assign the pool into private_data field */ dmab-private_data = pool; - dmab-area = (void *)gen_pool_alloc(pool, size); - if (!dmab-area) - return; - - dmab-addr = gen_pool_virt_to_phys(pool, (unsigned long)dmab-area); + dmab-area = gen_pool_dma_alloc(pool, size, dmab-addr); } /** -- 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][RESEND 4/8] [media] coda: use gen_pool_dma_alloc() to allocate iram buffer
Since gen_pool_dma_alloc() is introduced, we implement it to simplify code.
Signed-off-by: Nicolin Chen b42...@freescale.com
---
drivers/media/platform/coda.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index ed4998c..bd72fb9 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -3298,13 +3298,12 @@ static int coda_probe(struct platform_device *pdev)
dev-iram_size = CODA7_IRAM_SIZE;
break;
}
- dev-iram_vaddr = gen_pool_alloc(dev-iram_pool, dev-iram_size);
+ dev-iram_vaddr = (unsigned long)gen_pool_dma_alloc(dev-iram_pool,
+ dev-iram_size, (dma_addr_t *)dev-iram_paddr);
if (!dev-iram_vaddr) {
dev_err(pdev-dev, unable to alloc iram\n);
return -ENOMEM;
}
- dev-iram_paddr = gen_pool_virt_to_phys(dev-iram_pool,
- dev-iram_vaddr);
platform_set_drvdata(pdev, dev);
--
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] vfio, iommu: Fixed interaction of VFIO_IOMMU_MAP_DMA with IOMMU address limits
On Wed, Oct 09, 2013 at 10:03:52AM +0200, Julian Stecklina wrote: The BUG_ON in drivers/iommu/intel-iommu.c:785 can be triggered from userspace via VFIO by calling the VFIO_IOMMU_MAP_DMA ioctl on a vfio device with any address beyond the addressing capabilities of the IOMMU. The problem is that the ioctl code calls iommu_iova_to_phys before it calls iommu_map. iommu_map handles the case that it gets addresses beyond the addressing capabilities of its IOMMU. intel_iommu_iova_to_phys does not. This patch fixes iommu_iova_to_phys to return NULL for addresses beyond what the IOMMU can handle. This in turn causes the ioctl call to fail in iommu_map and (correctly) return EFAULT to the user with a helpful warning message in the kernel log. Signed-off-by: Julian Stecklina jstec...@os.inf.tu-dresden.de Acked-by: Alex Williamson alex.william...@redhat.com Applied, 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 01/14] perf tools: Consolidate __hists__add_*entry()
On Thu, Oct 31, 2013 at 03:56:03PM +0900, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
The __hists__add_{branch,mem}_entry() did almost same thing that
__hists__add_entry() does. Consolidate them into one.
Cc: Jiri Olsa jo...@redhat.com
Acked-by: Jiri Olsa jo...@redhat.com
jirka
--
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: RFE?: why no 'bind' info in /proc/mounts?
On Fri, Nov 01, 2013 at 01:49:08AM -0700, Linda Walsh wrote: Ah... didn't know about the other format file... thanks! Or use more user friendly findmnt(8) command: # mount --bind /usr/local/bin /mnt/test # findmnt /mnt/test TARGETSOURCEFSTYPE OPTIONS /mnt/test /dev/sda4[/usr/local/bin] ext4 rw,relatime,data=ordered Karel On 10/31/2013 9:15 PM, NeilBrown wrote: Take a look in /proc/self/mountinfo. It contains more useful stuff about the mount table which couldn't be put in /proc/mounts without breaking compatibility. NeilBrown -- Karel Zak k...@redhat.com http://karelzak.blogspot.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: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
On Fri, Nov 01, 2013 at 06:28:05PM +0800, Nicolin Chen wrote: sound/soc/fsl/fsl-sgtl5000-vf610.c | 208 + I just doubt if this file naming is appropriate. Even if we might not have rigor rule for the file names, according to existing ones, they are all in a same pattern: [SoC name]-[codec name].c imx-sgtl5000.c for example I think it would make user less confused about what this file exactly is if this machine driver also follow the pattern: vf610-sgtl5000.c @Shawn What do you think about the file name? Yeah, it would be better to name the file following the existing the pattern. Shawn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 01, 2013 at 07:44:29PM +0800, Yuanhan Liu wrote: commit 012f18004da33ba672e3c60838cc4898126174d3 Author: Rik van Riel r...@redhat.com Date: Mon Aug 9 17:18:40 2010 -0700 mm: always lock the root (oldest) anon_vma Always (and only) lock the root (oldest) anon_vma whenever we do something in an anon_vma. The recently introduced anon_vma scalability is due to the rmap code scanning only the VMAs that need to be scanned. Many common operations still took the anon_vma lock on the root anon_vma, so always taking that lock is not expected to introduce any scalability issues. However, always taking the same lock does mean we only need to take one lock, which means rmap_walk on pages from any anon_vma in the vma is excluded from occurring during an munmap, expand_stack or other operation that needs to exclude rmap_walk and similar functions. Also add the proper locking to vma_adjust. Signed-off-by: Rik van Riel r...@redhat.com Tested-by: Larry Woodman lwood...@redhat.com Acked-by: Larry Woodman lwood...@redhat.com Reviewed-by: Minchan Kim minchan@gmail.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Acked-by: Mel Gorman m...@csn.ul.ie Acked-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Right that commit did. I'm still not sure why you change both the locking proper and the locking primitive used in one patch set. Also, changing the locking proper requires a very detailed explanation on why it is correct; we've had far too many 'fun' issues with the anon_vma locking in the past. -- 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 02/14] perf tools: Introduce struct add_entry_iter
On Thu, Oct 31, 2013 at 03:56:04PM +0900, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
SNIP
+
+static int
+perf_evsel__add_entry(struct perf_evsel *evsel, struct addr_location *al,
+ struct perf_sample *sample, struct machine *machine,
+ struct add_entry_iter *iter)
+{
+ int err;
+
+ if ((sort__has_parent || symbol_conf.use_callchain)
sample-callchain) {
+ err = machine__resolve_callchain(machine, evsel, al-thread,
+ sample, iter-parent, al,
+ iter-rep-max_stack);
+ if (err)
+ return err;
+ }
+
+ err = iter-prepare_entry(iter, machine, evsel, al, sample);
+ if (err)
+ return err;
+
+ err = iter-add_single_entry(iter, al);
+ if (err)
+ return err;
+
+ while (iter-next_entry(iter, al)) {
+ err = iter-add_next_entry(iter, al);
+ if (err)
+ break;
+ }
+
+ err = iter-finish_entry(iter, al);
+
+ return err;
return iter-finish_entry(iter, al); ?
--
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] fix race between stop_two_cpus and stop_cpus
On 11/01/2013 07:36 AM, Rik van Riel wrote: On 11/01/2013 07:08 AM, Mel Gorman wrote: On Thu, Oct 31, 2013 at 04:31:44PM -0400, Rik van Riel wrote: There is a race between stop_two_cpus, and the global stop_cpus. What was the trigger for this? I want to see what was missing from my own testing. I'm going to go out on a limb and guess that CPU hotplug was also running in the background to specifically stress this sort of rare condition. Something like running a standard test with the monitors/watch-cpuoffline.sh from mmtests running in parallel. AFAIK the trigger was a test that continuously loads and unloads kernel modules, while doing other stuff. With this patch in place the module load/unload test ran for ~16 hours without failure. Without the patch the test usually fails in 5-10 minutes. Tested-by: Prarit Bhargava pra...@redhat.com P. -- 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] efifb: prevent null-deref when iterating dmi_list
Hi On Fri, Nov 1, 2013 at 12:10 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 17:17 Thu 31 Oct , David Herrmann wrote: Hi On Thu, Oct 31, 2013 at 11:45 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 18:40 Wed 02 Oct , David Herrmann wrote: The dmi_list array is initialized using gnu designated initializers, and therefore may contain fewer explicitly defined entries as there are elements in it. This is because the enum above with M_xyz constants contains more items than the designated initializer. Those elements not explicitly initialized are implicitly set to 0. Now efifb_setup() loops through all these array elements, and performs a strcmp on each item. For non explicitly initialized elements this will be a null pointer: This patch swaps the check order in the if statement, thus checks first whether dmi_list[i].base is null. Signed-off-by: James Bates james.h.ba...@yahoo.com Signed-off-by: David Herrmann dh.herrm...@gmail.com with the simpleDRM arriving next merge I'm wondering if we need to keep it? SimpleDRM is not coming next merge-window. It's basically finished, but I'm still working on the user-space side as its KMS api is highly reduced compared to fully-featured DRM/KMS drivers. Maybe 3.13 will work out. do you have a git tree for the simpleDRM that I can pull? Sure, I usually push it to my fdo tree: http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=simpledrm But note that you shouldn't be using it right now. User-space fails on it as SimpleDRM only provides a single KMS-FB. It also needs to be adjusted to the new x86-sysfb changes and I am reworking the handover to real drivers. Cheers David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/14] perf tools: Introduce struct add_entry_iter
On Thu, Oct 31, 2013 at 03:56:04PM +0900, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
SNIP
+}
+
+static int
+iter_add_next_nop_entry(struct add_entry_iter *iter __maybe_unused,
+ struct addr_location *al __maybe_unused)
+{
+ return 0;
+}
+
+static int
+iter_prepare_mem_entry(struct add_entry_iter *iter, struct machine *machine,
+struct perf_evsel *evsel, struct addr_location *al,
+struct perf_sample *sample)
+{
+ union perf_event *event = iter-priv;
+ struct mem_info *mi;
+ u8 cpumode;
+
+ BUG_ON(event == NULL);
the priv does not get assigned.. 'perf mem rep' aborts
[jolsa@krava perf]$ ./perf mem rep --stdio
Aborted
perf: builtin-report.c:120: iter_prepare_mem_entry: Assertion `!(event ==
((void *)0))' failed.
jirka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support
01.11.2013 13:29, Rafał Miłecki kirjoitti: 2013/11/1 Anssi Hannula anssi.hann...@iki.fi: Both are working for me. I've tested it using 2 movies: 1) English TrueHD.5.1 @ 1417 kbps 2) Audio Codec: DTSHD-MA Bitrate..: 3718 kbps kHz/bit..: 24-bit Channels.: 5.1 Language.: English Which makes it even stranger, since HBR packets look exactly like ASP packets with a few flipped bits. Hm, the earlier non-working speaker-test commands were with -c6. What about -c8? Side right behaves just like rear right Side left behaves just like a rear left No other differences. Strange. One other thing to check (in addition to trying fglrx) would be to try 192kHz 8ch audio with a different (non-ATI/AMD) card altogether, to see if this is a receiver issue. -- Anssi Hannula -- 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] ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would de-active and en-active pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX - SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen b42...@freescale.com
---
Changelog:
v3:
* Add pinctrl_pm() for codec_dai/codec
* Add more proper active check for each pinctrl_pm_select_xx()
v2:
* Add cpu_dai-active check
sound/soc/soc-core.c | 33 +
sound/soc/soc-pcm.c | 10 ++
2 files changed, 43 insertions(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index bdc1d74..4e53d87 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -662,6 +662,8 @@ int snd_soc_suspend(struct device *dev)
codec-cache_sync = 1;
if (codec-using_regmap)
regcache_mark_dirty(codec-control_data);
+ /* deactivate pins to sleep state */
+ pinctrl_pm_select_sleep_state(codec-dev);
break;
default:
dev_dbg(codec-dev,
@@ -679,6 +681,9 @@ int snd_soc_suspend(struct device *dev)
if (cpu_dai-driver-suspend cpu_dai-driver-ac97_control)
cpu_dai-driver-suspend(cpu_dai);
+
+ /* deactivate pins to sleep state */
+ pinctrl_pm_select_sleep_state(cpu_dai-dev);
}
if (card-suspend_post)
@@ -807,6 +812,16 @@ int snd_soc_resume(struct device *dev)
if (list_empty(card-codec_dev_list))
return 0;
+ /* activate pins from sleep state */
+ for (i = 0; i card-num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card-rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card-rtd[i].codec_dai;
+ if (cpu_dai-active)
+ pinctrl_pm_select_default_state(cpu_dai-dev);
+ if (codec_dai-active)
+ pinctrl_pm_select_default_state(codec_dai-dev);
+ }
+
/* AC97 devices might have other drivers hanging off them so
* need to resume immediately. Other drivers don't have that
* problem and may take a substantial amount of time to resume
@@ -1929,6 +1944,14 @@ int snd_soc_poweroff(struct device *dev)
snd_soc_dapm_shutdown(card);
+ /* deactivate pins to sleep state */
+ for (i = 0; i card-num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card-rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card-rtd[i].codec_dai;
+ pinctrl_pm_select_sleep_state(codec_dai-dev);
+ pinctrl_pm_select_sleep_state(cpu_dai-dev);
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(snd_soc_poweroff);
@@ -3767,6 +3790,16 @@ int snd_soc_register_card(struct snd_soc_card *card)
if (ret != 0)
soc_cleanup_card_debugfs(card);
+ /* deactivate pins to sleep state */
+ for (i = 0; i card-num_rtd; i++) {
+ struct snd_soc_dai *cpu_dai = card-rtd[i].cpu_dai;
+ struct snd_soc_dai *codec_dai = card-rtd[i].codec_dai;
+ if (!codec_dai-active)
+ pinctrl_pm_select_sleep_state(codec_dai-dev);
+ if (!cpu_dai-active)
+ pinctrl_pm_select_sleep_state(cpu_dai-dev);
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(snd_soc_register_card);
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index d81b792..1f0aeea 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -183,6 +183,8 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
struct snd_soc_dai_driver *codec_dai_drv = codec_dai-driver;
int ret = 0;
+ pinctrl_pm_select_default_state(cpu_dai-dev);
+
Re: [PATCH 08/14] perf report: Cache cumulative callchains
On Thu, Oct 31, 2013 at 03:56:10PM +0900, Namhyung Kim wrote:
SNIP
* double accounting.
@@ -501,8 +528,29 @@ iter_add_next_cumulative_entry(struct add_entry_iter
*iter,
{
struct perf_evsel *evsel = iter-evsel;
struct perf_sample *sample = iter-sample;
+ struct cumulative_cache *ccache = iter-priv;
struct hist_entry *he;
int err = 0;
+ int i;
+
+ /*
+ * Check if there's duplicate entries in the callchain.
+ * It's possible that it has cycles or recursive calls.
+ */
+ for (i = 0; i iter-curr; i++) {
+ if (sort__has_sym) {
+ if (ccache[i].sym == al-sym)
+ return 0;
+ } else {
+ /* Not much we can do - just compare the dso. */
+ if (ccache[i].dso == al-map-dso)
+ return 0;
+ }
+ }
hum, do we want to prevent recursion totaly?
how about intended recursion?
also should the dso be checked together with sym?
because the symbol is defined like dso::sym
jirka
--
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: comedi: fix coding style issues in unioxx5.c
This is a patch which fixes coding style issues in unioxx5.c found
by checkpatch.pl
1) Replaced printk with pr_info and pr_err
2) Reinitialized n_subd before for loop to fix over 80 character
warning
3) Reworded comment to fix 80 character warning
Signed-off-by: Conrad Gomes conrad.s.j.go...@gmail.com
---
drivers/staging/comedi/drivers/unioxx5.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/unioxx5.c
b/drivers/staging/comedi/drivers/unioxx5.c
index 93eec2f..de68e3a 100644
--- a/drivers/staging/comedi/drivers/unioxx5.c
+++ b/drivers/staging/comedi/drivers/unioxx5.c
@@ -96,7 +96,7 @@ static void __unioxx5_digital_config(struct unioxx5_subd_priv
*usp, int mode)
int i, mask;
mask = (mode == ALL_2_OUTPUT) ? 0xFF : 0x00;
- printk(COMEDI: mode = %d\n, mask);
+ pr_info(COMEDI: mode = %d\n, mask);
outb(1, usp-usp_iobase + 0);
@@ -185,7 +185,7 @@ static int __unioxx5_analog_read(struct unioxx5_subd_priv
*usp,
/* if four bytes readding error occurs - return 0(false) */
if ((control Rx4CA_ERR_MASK)) {
- printk(COMEDI: 4 bytes error\n);
+ pr_err(COMEDI: 4 bytes error\n);
return 0;
}
@@ -436,8 +436,10 @@ static int unioxx5_attach(struct comedi_device *dev,
dev-iobase = iobase;
iobase += UNIOXX5_SUBDEV_BASE;
- /* defining number of subdevices and getting they types (it must be
'g01') */
- for (i = n_subd = 0, ba = iobase; i 4; i++, ba +=
UNIOXX5_SUBDEV_ODDS) {
+ n_subd = 0;
+
+ /* getting number of subdevices with types 'g01'*/
+ for (i = 0, ba = iobase; i 4; i++, ba += UNIOXX5_SUBDEV_ODDS) {
id = inb(ba + 0xE);
num = inb(ba + 0xF);
--
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/
Re: [PATCH] vexpress: remove declaration of vexpress_clk_of_init()
On Tue, 2013-10-29 at 03:40 +, Kefeng Wang wrote: After commit:6e973d2c(clk: vexpress: Add separate SP810 driver), vexpress_clk_of_init() is unnecessary and removed, so kill it. Signed-off-by: Kefeng Wang wangkefeng.w...@huawei.com --- include/linux/vexpress.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h index 617c01b..0e65172 100644 --- a/include/linux/vexpress.h +++ b/include/linux/vexpress.h @@ -122,6 +122,5 @@ struct clk *vexpress_osc_setup(struct device *dev); void vexpress_osc_of_setup(struct device_node *node); void vexpress_clk_init(void __iomem *sp810_base); -void vexpress_clk_of_init(void); #endif I've got this covered by some other patches, but thanks for pointing it out anyway. Cheers! Pawel -- 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/
VT-d and x2apic: broken resume after suspend to ram
I have one notebook that is failing to resume after suspend to ram. I've filled a bug report back on the 2.6.41 days: https://bugzilla.redhat.com/show_bug.cgi?id=787299 The issue is that trying to resume after suspending to ram freezes the computer. The resume starts well, but then it hangs. Yesterday I found that this may be related to VT-d / x2apic. If I disable VT-d on the BIOS, suspend / resume works fine. If I enable VT-d and pass nox2apic as boot parameter to Kernel suspend and resume works fine. I would like some pointers to fix this issue. Can you help me? Only when I have VT-d enabled, dmesg gives me additional output: [0.023913] IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 [0.024080] Enabled IRQ remapping in x2apic mode [0.024081] Enabling x2apic [0.024082] Enabled x2apic [0.024087] Switched APIC routing to cluster x2apic. The notebook is Toshiba R830-10p with i7-2620M. Thanks! -- Peter -- 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 v10 00/20] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Fri, 01 Nov 2013 12:42:24 +0100, Joerg Roedel wrote: On Mon, Oct 07, 2013 at 10:52:12AM +0900, Cho KyongHo wrote: Patch summary: [PATCH 01/20] iommu/exynos: do not include removed header [PATCH 02/20] iommu/exynos: add missing cache flush for removed page table entries [PATCH 03/20] iommu/exynos: change error handling when page table update is failed [PATCH 04/20] iommu/exynos: fix L2TLB invalidation [PATCH 05/20] iommu/exynos: allocate lv2 page table from own slab [PATCH 06/20] iommu/exynos: always enable runtime PM [PATCH 07/20] iommu/exynos: always use a single clock descriptor [PATCH 08/20] iommu/exynos: remove dbgname from drvdata of a System MMU [PATCH 09/20] iommu/exynos: use managed device helper functions [PATCH 10/20] clk: exynos: add gate clock descriptions of System MMU [PATCH 11/20] ARM: dts: Add description of System MMU of Exynos SoCs [PATCH 12/20] iommu/exynos: support for device tree [PATCH 13/20] iommu/exynos: gating clocks of master H/W [PATCH 14/20] iommu/exynos: remove custom fault handler [PATCH 15/20] iommu/exynos: remove calls to Runtime PM API functions [PATCH 16/20] iommu/exynos: turn on useful configuration options [PATCH 17/20] iommu/exynos: add support for power management subsystems. [PATCH 18/20] iommu/exynos: change rwlock to spinlock [PATCH 19/20] iommu/exynos: return 0 if iommu_attach_device() successes [PATCH 20/20] iommu/exynos: add devices attached to the System MMU to an IOMMU group Diffstats: .../devicetree/bindings/clock/exynos5250-clock.txt | 28 + .../devicetree/bindings/clock/exynos5420-clock.txt |3 + .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 76 ++ arch/arm/boot/dts/exynos4.dtsi | 105 ++ arch/arm/boot/dts/exynos4210.dtsi | 21 + arch/arm/boot/dts/exynos4x12.dtsi | 82 ++ arch/arm/boot/dts/exynos5250.dtsi | 262 + arch/arm/boot/dts/exynos5420.dtsi | 296 ++ drivers/clk/samsung/clk-exynos5250.c | 49 +- drivers/clk/samsung/clk-exynos5420.c | 12 +- drivers/iommu/Kconfig |5 +- drivers/iommu/exynos-iommu.c | 1033 +--- 12 files changed, 1585 insertions(+), 387 deletions(-) What is the state of this series? It would be good to have some Acked-bys and/or Reviewed-bys on it. I am preparing next patches to apply Alex Williamson's comment that description of IOMMU's masters must be aligned with ARM SMMU. It is delayed due to my jobs in the office. I will post the next patche series in two weeks. Thanks. Joerg -- 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: mei: cancel stall timers in mei_reset
Hi, In case my previous mail went to /dev/null, it is all about the flood of error messages in the system log, like these: mei_me :00:16.0: reset: wrong host start response mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS mei_me :00:16.0: reset: unexpected enumeration response hbm. mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS Even after the patches (https://lkml.org/lkml/2013/9/2/162) that went into kernel 3.10.15, the problem still shows up occasionally on my Lenovo X230 laptop with kernels 3.10.15, 3.10.16 and 3.11.6. It seems to be retated to IRQ handling now. When the problem occurs, mei_reset() is called repeatedly and the system logs grow rapidly until they consume all free disk space. Most of the messages are output by mei_hbm_dispatch(). I added debug prints to the code of mei_hbm_dispatch() and found the following: 1. When HOST_START_RES_CMD response is being handled, dev-hbm_state is 0x2 sometimes, that is, MEI_HBM_ENUM_CLIENTS (!) rather than MEI_HBM_START what it probably should be. That's why the error message is printed and mei_reset() is called again. 2. When HOST_ENUM_RES_CMD response is being handled, dev-hbm_state is 0x1 (MEI_HBM_START) while it should be MEI_HBM_ENUM_CLIENTS. This also results in an error message and mei_reset(). That is, dev-hbm_state contains a wrong value in both cases. I haven't figured out so far why it happens. Do you know how to fix that? Messages from the system log related to MEI: - 13:30:42 systemd-sleep[9364]: System resumed. 13:30:42 kernel: mei_me :00:16.0: reset: properties response hbm wrong status. 13:30:42 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS ... 13:30:47 kernel: mei_me :00:16.0: wait hw ready failed. status = -110 ... 13:31:17 kernel: mei_me :00:16.0: reset: init clients timeout hbm_state = 1. 13:31:17 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS 13:31:17 kernel: mei_me :00:16.0: reset: wrong host start response (dev_state: 0x1, hbm_state: 0x2) 13:31:17 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS 13:31:17 kernel: mei_me :00:16.0: reset: unexpected enumeration response hbm (dev_state: 0x1, hbm_state: 0x1) 13:31:17 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS 13:31:17 kernel: mei_me :00:16.0: reset: wrong host start response (dev_state: 0x1, hbm_state: 0x2) 13:31:17 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS 13:31:17 kernel: mei_me :00:16.0: reset: unexpected enumeration response hbm (dev_state: 0x1, hbm_state: 0x1) 13:31:17 kernel: mei_me :00:16.0: unexpected reset: dev_state = INIT_CLIENTS - By the way, here is MEI hw info from lspci output: - 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Lenovo Device [17aa:21fa] Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f2535000 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel modules: mei_me - If you need other info, please let me know. Regards, Eugene -- Eugene Shatokhin, ROSA Laboratory. www.rosalab.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: [RESEND PATCH 1/4] i2c: i2c-bcm-kona: Introduce Broadcom I2C Driver
On Wed, Oct 16, 2013 at 03:01:46PM -0700, Tim Kryger wrote:
Introduce support for Broadcom Serial Controller (BSC) I2C bus found
in the Kona family of Mobile SoCs. FIFO hardware is utilized but only
standard mode (100kHz), fast mode (400kHz), and fast mode plus (1MHz)
bus speeds are supported.
Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Matt Porter matt.por...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
Looks mostly good, some remarks:
+struct bcm_kona_i2c_dev {
+ /* Pointer to linux device struct */
+ struct device *device;
+
+ /* Virtual address where registers are mapped */
+ void __iomem *base;
+
+ /* Interrupt */
+ int irq;
+
+ /* Standard Speed configuration */
+ const struct bus_speed_cfg *std_cfg;
+
+ /* Linux I2C adapter struct */
+ struct i2c_adapter adapter;
+
+ /* Lock for the I2C device */
+ struct mutex i2c_bcm_lock;
+
+ /* Completion to signal an operation finished */
+ struct completion done;
+
+ /* Handle for external clock */
+ struct clk *external_clk;
+};
IMO most of the comments could go. Kind of stating the obvious :)
+/* Read any amount of data using the RX FIFO from the i2c bus */
+static int bcm_kona_i2c_read_fifo(struct bcm_kona_i2c_dev *dev,
+ struct i2c_msg *msg)
+{
+ unsigned int bytes_to_read = MAX_RX_FIFO_SIZE;
+ unsigned int last_byte_nak = 0;
+ unsigned int bytes_read = 0;
+ unsigned int rc;
Should be signed.
+/* Write any amount of data using TX FIFO to the i2c bus */
+static int bcm_kona_i2c_write_fifo(struct bcm_kona_i2c_dev *dev,
+struct i2c_msg *msg)
+{
+ unsigned int bytes_to_write = MAX_TX_FIFO_SIZE;
+ unsigned int bytes_written = 0;
+ unsigned int rc;
Ditto signed.
+/* Master transfer function */
+static int bcm_kona_i2c_xfer(struct i2c_adapter *adapter,
+ struct i2c_msg msgs[], int num)
+{
+ struct bcm_kona_i2c_dev *dev = i2c_get_adapdata(adapter);
+ struct i2c_msg *pmsg;
+ int rc = 0;
+ int i;
+
+ mutex_lock(dev-i2c_bcm_lock);
Huh? Why do you need that? The core has locks per bus.
+static int bcm_kona_i2c_assign_bus_speed(struct bcm_kona_i2c_dev *dev)
+{
+ unsigned int bus_speed;
+ int ret = of_property_read_u32(dev-device-of_node, clock-frequency,
+bus_speed);
+ if (ret 0) {
+ dev_err(dev-device, missing clock-frequency property\n);
+ return -ENODEV;
+ }
+
+ switch (bus_speed) {
+ case 10:
+ dev-std_cfg = std_cfg_table[BCM_SPD_100K];
+ break;
+ case 40:
+ dev-std_cfg = std_cfg_table[BCM_SPD_400K];
+ break;
+ case 100:
+ dev-std_cfg = std_cfg_table[BCM_SPD_1MHZ];
+ break;
+ default:
+ pr_err(%d hz bus speed not supported\n, bus_speed);
+ return -EINVAL;
+ };
Unneeded semicolon.
+
+ return 0;
+}
+
+static int bcm_kona_i2c_probe(struct platform_device *pdev)
+{
+ int rc = 0;
+ struct bcm_kona_i2c_dev *dev;
+ struct i2c_adapter *adap;
+ struct resource *iomem;
+
+ /* Allocate memory for private data structure */
+ dev = devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ rc = -ENOMEM;
+ goto probe_return;
I'd prefer simply return -Esomething. The printout at probe_return is
also available via driver core.
...
+ /* Add the i2c adapter */
+ adap = dev-adapter;
+ i2c_set_adapdata(adap, dev);
+ adap-owner = THIS_MODULE;
+ adap-class = UINT_MAX; /* can be used by any I2C device */
Why do you need class based instantiation. It will most likely cost
boot-time and you have devicetree means for doing instantiation.
+ strlcpy(adap-name, Broadcom I2C adapter, sizeof(adap-name));
+ adap-algo = bcm_algo;
+ adap-dev.parent = pdev-dev;
+ adap-nr = pdev-id;
+ adap-dev.of_node = pdev-dev.of_node;
+
+ rc = i2c_add_numbered_adapter(adap);
Maybe you want simply i2c_add_adapter here since the core has no
built-in support for of aliases?
+
+MODULE_AUTHOR(Broadcom);
Some email address please.
+MODULE_DESCRIPTION(Broadcom Kona I2C Driver);
+MODULE_LICENSE(GPL v2);
Thanks,
Wolfram
signature.asc
Description: Digital signature
Re: [PATCH 10/11] EFI: Runtime services virtual mapping
On Fri, 01 Nov, at 11:35:08AM, Dave Young wrote: The conflict is caused by missing one commit in matt's efi next tree: commit 700870119f49084da004ab588ea2b799689efaf7 Author: Josh Boyer jwbo...@redhat.com Date: Thu Apr 18 07:51:34 2013 -0700 x86, efi: Don't map Boot Services on i386 Add patch to fix 32bit EFI service mapping (rhbz 726701) Multiple people are reporting hitting the following WARNING on i386, WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440() Modules linked in: Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95 Rethinking about above commit, it is actually a workaround for mapping boot service, I suspect the problem connect to the off-by-one problem in boot service reserve function. Matt, idea? No, it's not the same problem. And just to make absolutely sure I reverted the above commit and applied your patch, but I still see the WARN_ON() described above. -- Matt Fleming, Intel Open Source Technology Center -- 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 07/14] perf tools: Update cpumode for each cumulative entry
On Thu, Oct 31, 2013 at 03:56:09PM +0900, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
The cpumode and level in struct addr_localtion was set for a sample
and but updated as cumulative callchains were added. This led to have
non-matching symbol and cpumode in the output.
Update it accordingly based on the fact whether the map is a part of
the kernel or not.
Cc: Arun Sharma asha...@fb.com
Cc: Frederic Weisbecker fweis...@gmail.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-report.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 92cbd5cd1ab1..1b152a8b7f51 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -80,6 +80,7 @@ struct add_entry_iter {
struct perf_report *rep;
struct perf_evsel *evsel;
struct perf_sample *sample;
+ struct machine *machine;
struct hist_entry *he;
struct symbol *parent;
void *priv;
@@ -388,7 +389,7 @@ iter_finish_normal_entry(struct add_entry_iter *iter,
struct addr_location *al)
static int
iter_prepare_cumulative_entry(struct add_entry_iter *iter,
- struct machine *machine __maybe_unused,
+ struct machine *machine,
struct perf_evsel *evsel,
struct addr_location *al __maybe_unused,
struct perf_sample *sample)
@@ -404,6 +405,7 @@ iter_prepare_cumulative_entry(struct add_entry_iter *iter,
iter-evsel = evsel;
iter-sample = sample;
+ iter-machine = machine;
return 0;
}
@@ -468,6 +470,27 @@ iter_next_cumulative_entry(struct add_entry_iter *iter
__maybe_unused,
if (al-sym == NULL)
return 0;
+ if (al-map-groups == iter-machine-kmaps) {
+ if (machine__is_host(iter-machine)) {
+ al-cpumode = PERF_RECORD_MISC_KERNEL;
+ al-level = 'k';
+ } else {
+ al-cpumode = PERF_RECORD_MISC_GUEST_KERNEL;
+ al-level = 'g';
+ }
+ } else {
+ if (machine__is_host(iter-machine)) {
+ al-cpumode = PERF_RECORD_MISC_USER;
+ al-level = '.';
+ } else if (perf_guest) {
+ al-cpumode = PERF_RECORD_MISC_GUEST_USER;
+ al-level = 'u';
+ } else {
+ al-cpumode = PERF_RECORD_MISC_HYPERVISOR;
+ al-level = 'H';
+ }
+ }
+
Looks like this is what thread__find_addr_map does as well.
Could above code go into a function used by both places?
jirka
--
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/
