Re: [RESEND RFC PATCH 3/3] ASoC: mediatek: Add AFE platform driver
On Mon, 2015-04-20 at 21:55 +0100, Mark Brown wrote: On Mon, Apr 20, 2015 at 02:22:24PM +0800, Koro Chen wrote: On Sat, 2015-04-18 at 18:51 +0100, Mark Brown wrote: On Fri, Apr 10, 2015 at 04:14:09PM +0800, Koro Chen wrote: Ah, so the SRAM is directly memory mappable. Nice. But we have a limited amount of it so need to allocate it to a device somehow based on some factor I guess? Yes, actually SRAM is only used for the main playback path (which is memif DL1) to achieve low power in real use case. Maybe you think it's better to not describe this in the device tree, but to choose SRAM automatically if memif DL1 is chosen? Since it's directly memory mappable is there actually any cost in latency terms from using the SRAM in low latency cases (or did I misread what the code was doing there)? If it can only be used with one interface and there's no downside from using it... The SRAM size to be used is defined by params_buffer_bytes(params), not fixed (of course limited by the actual available SRAM size on HW), so the latency should be the same compared to a DRAM having the same size. The SRAM can be used by any memif, and that's why the plan was let DT make the decision. -- 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] mm/slab_common: Support the slub_debug boot option on specific object size
Hi Christoph, On Mon, Apr 20, 2015 at 11:40 PM, Christoph Lameter c...@linux.com wrote: On Sat, 18 Apr 2015, Gavin Guo wrote: The slub_debug=PU,kmalloc-xx cannot work because in the create_kmalloc_caches() the s-name is created after the create_kmalloc_cache() is called. The name is NULL in the create_kmalloc_cache() so the kmem_cache_flags() would not set the slub_debug flags to the s-flags. The fix here set up a temporary kmalloc_names string array for the initialization purpose. After the kmalloc_caches are already it can be used to create s-name in the kasprintf. Ok if you do that then the dynamic creation of the kmalloc hostname can also be removed. This patch should do that as well. Thanks for your reply. I put the kmalloc_names in the __initdata section. And it will be cleaned. Do you think the kmalloc_names should be put in the global data section to avoid the dynamic creation of the kmalloc hostname again? Gavin -- 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 v6] perf: __kmod_path__parse: deal with kernel module names in '[]' correctly.
Before patch ba92732e9808df679ddf75c5ea1c0caae6d7dce2 ('perf kmaps:
Check kmaps to make code more robust'), perf report and perf annotate
will segfault if trace data contains kernel module information like
this:
# perf report -D -i ./perf.data
...
0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffbff1018000(0xf068000) @ 0]:
x [test_module]
...
# perf report -i ./perf.data --objdump=/path/to/objdump
--kallsyms=/path/to/kallsyms
perf: Segmentation fault
backtrace
/path/to/perf[0x503478]
/lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
/path/to/perf[0x499b56]
/path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
/path/to/perf(dso__load+0x72e)[0x49c21e]
/path/to/perf(map__load+0x6e)[0x4ae9ee]
/path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
/path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
/path/to/perf[0x43ad02]
/path/to/perf[0x4b55bc]
/path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
/path/to/perf[0x4b1a01]
/path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
/path/to/perf(cmd_report+0xf11)[0x43bfc1]
/path/to/perf[0x474702]
/path/to/perf(main+0x5f5)[0x42de95]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
/path/to/perf[0x42dfc4]
This is because __kmod_path__parse treats '[' leading names as kernel
name instead of names of kernel module. If perf.data contains build
information and the buildid of such modules can be found, the DSO of
it will be treated as kernel, not kernel module. It will then be passed to
dso__load_kernel_sym() - dso__load_kcore() because of --kallsyms
argument.
The refered patch adds NULL pointer checker to avoid segfault. However,
such kernel modules are still processed incorrectly.
This patch fixes __kmod_path__parse, makes it treat names like
'[test_module]' as kernel modules.
kmod-path.c is also update to reflect the above changes.
Signed-off-by: Wang Nan wangn...@huawei.com
---
Improves commit messages.
Since ba92732e9808df679ddf75c5ea1c0caae6d7dce2 is already in -tip tree,
segfault will not be triggered even without this patch.
---
tools/perf/tests/kmod-path.c | 72
tools/perf/util/dso.c| 42 +++---
tools/perf/util/dso.h| 2 +-
tools/perf/util/header.c | 8 ++---
tools/perf/util/machine.c| 16 +-
5 files changed, 130 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index e8d7cbb..08c433b 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -34,9 +34,21 @@ static int test(const char *path, bool alloc_name, bool
alloc_ext,
return 0;
}
+static int test_is_kernel_module(const char *path, int cpumode, bool expect)
+{
+ TEST_ASSERT_VAL(is_kernel_module,
+ (!!is_kernel_module(path, cpumode)) == (!!expect));
+ pr_debug(%s (cpumode: %d) - is_kernel_module: %s\n,
+ path, cpumode, expect ? true : false);
+ return 0;
+}
+
#define T(path, an, ae, k, c, n, e) \
TEST_ASSERT_VAL(failed, !test(path, an, ae, k, c, n, e))
+#define M(path, c, e) \
+ TEST_ASSERT_VAL(failed, !test_is_kernel_module(path, c, e))
+
int test__kmod_path__parse(void)
{
/* pathalloc_name alloc_ext kmod comp name
ext */
@@ -44,30 +56,90 @@ int test__kmod_path__parse(void)
T(///x-x.ko, false , true , true, false, NULL ,
NULL);
T(///x-x.ko, true , false , true, false, [x_x],
NULL);
T(///x-x.ko, false , false , true, false, NULL ,
NULL);
+ M(///x-x.ko, PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
+ M(///x-x.ko, PERF_RECORD_MISC_KERNEL, true);
+ M(///x-x.ko, PERF_RECORD_MISC_USER, false);
/* pathalloc_name alloc_ext kmod comp name ext */
T(///x.ko.gz, true , true , true, true, [x], gz);
T(///x.ko.gz, false, true , true, true, NULL , gz);
T(///x.ko.gz, true , false , true, true, [x], NULL);
T(///x.ko.gz, false, false , true, true, NULL , NULL);
+ M(///x.ko.gz, PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
+ M(///x.ko.gz, PERF_RECORD_MISC_KERNEL, true);
+ M(///x.ko.gz, PERF_RECORD_MISC_USER, false);
/* path alloc_name alloc_ext kmod comp nameext */
T(///x.gz, true , true , false, true, x.gz ,gz);
T(///x.gz, false , true , false, true, NULL ,gz);
T(///x.gz, true , false, false, true, x.gz , NULL);
T(///x.gz, false , false, false, true, NULL , NULL);
+ M(///x.gz, PERF_RECORD_MISC_CPUMODE_UNKNOWN, false);
+ M(///x.gz, PERF_RECORD_MISC_KERNEL, false);
+ M(///x.gz, PERF_RECORD_MISC_USER, false);
[PATCH 3/6] perf kmem: Add --live option for current allocation stat
Currently perf kmem shows total (page) allocation stat by default, but
sometimes one might want to see live (total alloc-only) requests/pages
only. The new --live option does this by subtracting freed allocation
from the stat.
Acked-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/Documentation/perf-kmem.txt | 5 ++
tools/perf/builtin-kmem.c | 110 -
2 files changed, 73 insertions(+), 42 deletions(-)
diff --git a/tools/perf/Documentation/perf-kmem.txt
b/tools/perf/Documentation/perf-kmem.txt
index 69e181272c51..ff0f433b3fce 100644
--- a/tools/perf/Documentation/perf-kmem.txt
+++ b/tools/perf/Documentation/perf-kmem.txt
@@ -56,6 +56,11 @@ OPTIONS
--page::
Analyze page allocator events
+--live::
+ Show live page stat. The perf kmem shows total allocation stat by
+ default, but this option shows live (currently allocated) pages
+ instead. (This option works with --page option only)
+
SEE ALSO
linkperf:perf-record[1]
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 0393a7f3fa35..7ead9423fd7a 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -244,6 +244,7 @@ static unsigned long nr_page_fails;
static unsigned long nr_page_nomatch;
static bool use_pfn;
+static bool live_page;
static struct perf_session *kmem_session;
#define MAX_MIGRATE_TYPES 6
@@ -264,7 +265,7 @@ struct page_stat {
int nr_free;
};
-static struct rb_root page_tree;
+static struct rb_root page_live_tree;
static struct rb_root page_alloc_tree;
static struct rb_root page_alloc_sorted;
static struct rb_root page_caller_tree;
@@ -403,10 +404,19 @@ static u64 find_callsite(struct perf_evsel *evsel, struct
perf_sample *sample)
return sample-ip;
}
+struct sort_dimension {
+ const char name[20];
+ sort_fn_t cmp;
+ struct list_headlist;
+};
+
+static LIST_HEAD(page_alloc_sort_input);
+static LIST_HEAD(page_caller_sort_input);
+
static struct page_stat *
-__page_stat__findnew_page(u64 page, bool create)
+__page_stat__findnew_page(struct page_stat *pstat, bool create)
{
- struct rb_node **node = page_tree.rb_node;
+ struct rb_node **node = page_live_tree.rb_node;
struct rb_node *parent = NULL;
struct page_stat *data;
@@ -416,7 +426,7 @@ __page_stat__findnew_page(u64 page, bool create)
parent = *node;
data = rb_entry(*node, struct page_stat, node);
- cmp = data-page - page;
+ cmp = data-page - pstat-page;
if (cmp 0)
node = parent-rb_left;
else if (cmp 0)
@@ -430,34 +440,28 @@ __page_stat__findnew_page(u64 page, bool create)
data = zalloc(sizeof(*data));
if (data != NULL) {
- data-page = page;
+ data-page = pstat-page;
+ data-order = pstat-order;
+ data-gfp_flags = pstat-gfp_flags;
+ data-migrate_type = pstat-migrate_type;
rb_link_node(data-node, parent, node);
- rb_insert_color(data-node, page_tree);
+ rb_insert_color(data-node, page_live_tree);
}
return data;
}
-static struct page_stat *page_stat__find_page(u64 page)
+static struct page_stat *page_stat__find_page(struct page_stat *pstat)
{
- return __page_stat__findnew_page(page, false);
+ return __page_stat__findnew_page(pstat, false);
}
-static struct page_stat *page_stat__findnew_page(u64 page)
+static struct page_stat *page_stat__findnew_page(struct page_stat *pstat)
{
- return __page_stat__findnew_page(page, true);
+ return __page_stat__findnew_page(pstat, true);
}
-struct sort_dimension {
- const char name[20];
- sort_fn_t cmp;
- struct list_headlist;
-};
-
-static LIST_HEAD(page_alloc_sort_input);
-static LIST_HEAD(page_caller_sort_input);
-
static struct page_stat *
__page_stat__findnew_alloc(struct page_stat *pstat, bool create)
{
@@ -615,17 +619,8 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
* This is to find the current page (with correct gfp flags and
* migrate type) at free event.
*/
- pstat = page_stat__findnew_page(page);
- if (pstat == NULL)
- return -ENOMEM;
-
- pstat-order = order;
- pstat-gfp_flags = gfp_flags;
- pstat-migrate_type = migrate_type;
- pstat-callsite = callsite;
-
this.page = page;
- pstat = page_stat__findnew_alloc(this);
+ pstat = page_stat__findnew_page(this);
if (pstat == NULL)
return -ENOMEM;
@@ -633,6 +628,16 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
pstat-alloc_bytes += bytes;
[PATCH 1/6] perf kmem: Implement stat --page --caller
It perf kmem support caller statistics for page. Unlike slab case,
the tracepoints in page allocator don't provide callsite info. So
it records with callchain and extracts callsite info.
Note that the callchain contains several memory allocation functions
which has no meaning for users. So skip those functions to get proper
callsites. I used following regex pattern to skip the allocator
functions:
^_?_?(alloc|get_free|get_zeroed)_pages?
This gave me a following list of functions:
# perf kmem record --page sleep 3
# perf kmem stat --page -v
...
alloc func: __get_free_pages
alloc func: get_zeroed_page
alloc func: alloc_pages_exact
alloc func: __alloc_pages_direct_compact
alloc func: __alloc_pages_nodemask
alloc func: alloc_page_interleave
alloc func: alloc_pages_current
alloc func: alloc_pages_vma
alloc func: alloc_page_buffers
alloc func: alloc_pages_exact_nid
...
The output looks mostly same as --alloc (I also added callsite column
to that) but groups entries by callsite. Currently, the order,
migrate type and GFP flag info is for the last allocation and not
guaranteed to be same for all allocations from the callsite.
-
Total_alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite
-
1,064 | 266 | 0 | UNMOVABL | 00d0 | __pollwait
52 |13 | 0 | UNMOVABL | 002084d0 | pte_alloc_one
44 |11 | 0 | MOVABLE | 000280da | handle_mm_fault
20 | 5 | 0 | MOVABLE | 000200da | do_cow_fault
20 | 5 | 0 | MOVABLE | 000200da | do_wp_page
16 | 4 | 0 | UNMOVABL | 84d0 | __pmd_alloc
16 | 4 | 0 | UNMOVABL | 0200 |
__tlb_remove_page
12 | 3 | 0 | UNMOVABL | 84d0 | __pud_alloc
8 | 2 | 0 | UNMOVABL | 0010 |
bio_copy_user_iov
4 | 1 | 0 | UNMOVABL | 000200d2 | pipe_write
4 | 1 | 0 | MOVABLE | 000280da | do_wp_page
4 | 1 | 0 | UNMOVABL | 002084d0 | pgd_alloc
-
Acked-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-kmem.c | 327 +++---
1 file changed, 306 insertions(+), 21 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 4f0f38462d97..3649eec6807f 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -10,6 +10,7 @@
#include util/header.h
#include util/session.h
#include util/tool.h
+#include util/callchain.h
#include util/parse-options.h
#include util/trace-event.h
@@ -21,6 +22,7 @@
#include linux/rbtree.h
#include linux/string.h
#include locale.h
+#include regex.h
static int kmem_slab;
static int kmem_page;
@@ -241,6 +243,7 @@ static unsigned long nr_page_fails;
static unsigned long nr_page_nomatch;
static bool use_pfn;
+static struct perf_session *kmem_session;
#define MAX_MIGRATE_TYPES 6
#define MAX_PAGE_ORDER 11
@@ -250,6 +253,7 @@ static int order_stats[MAX_PAGE_ORDER][MAX_MIGRATE_TYPES];
struct page_stat {
struct rb_node node;
u64 page;
+ u64 callsite;
int order;
unsignedgfp_flags;
unsignedmigrate_type;
@@ -262,8 +266,144 @@ struct page_stat {
static struct rb_root page_tree;
static struct rb_root page_alloc_tree;
static struct rb_root page_alloc_sorted;
+static struct rb_root page_caller_tree;
+static struct rb_root page_caller_sorted;
-static struct page_stat *search_page(unsigned long page, bool create)
+struct alloc_func {
+ u64 start;
+ u64 end;
+ char *name;
+};
+
+static int nr_alloc_funcs;
+static struct alloc_func *alloc_func_list;
+
+static int funcmp(const void *a, const void *b)
+{
+ const struct alloc_func *fa = a;
+ const struct alloc_func *fb = b;
+
+ if (fa-start fb-start)
+ return 1;
+ else
+ return -1;
+}
+
+static int callcmp(const void *a, const void *b)
+{
+ const struct alloc_func *fa = a;
+ const struct alloc_func *fb = b;
+
+ if (fb-start = fa-start fa-end fb-end)
+ return 0;
+
+ if (fa-start fb-start)
+ return 1;
+ else
+ return -1;
+}
+
+static int build_alloc_func_list(void)
+{
+ int ret;
+ struct map *kernel_map;
+ struct symbol *sym;
+ struct rb_node *node;
+ struct alloc_func *func;
+ struct machine *machine =
[PATCH 6/6] perf kmem: Show warning when trying to run stat without record
Sometimes one can mistakenly run perf kmem stat without perf kmem
record before or different configuration like recoding --slab and stat
--page. Show a warning message like below to inform user:
# perf kmem stat --page --caller
Not found page events. Have you run 'perf kmem record --page' before?
Acked-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-kmem.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 828b7284e547..f29a766f18f8 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -1882,6 +1882,7 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
};
struct perf_session *session;
int ret = -1;
+ const char errmsg[] = Not found %s events. Have you run 'perf kmem
record --%s' before?\n;
perf_config(kmem_config, NULL);
argc = parse_options_subcommand(argc, argv, kmem_options,
@@ -1908,11 +1909,35 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
if (session == NULL)
return -1;
+ if (kmem_slab) {
+ struct perf_evsel *evsel;
+ bool found = false;
+
+ evlist__for_each(session-evlist, evsel) {
+ if (!strcmp(perf_evsel__name(evsel), kmem:kmalloc)) {
+ found = true;
+ break;
+ }
+ }
+ if (!found) {
+ pr_err(errmsg, slab, slab);
+ return -1;
+ }
+ }
+
if (kmem_page) {
- struct perf_evsel *evsel = perf_evlist__first(session-evlist);
+ struct perf_evsel *evsel;
+ bool found = false;
- if (evsel == NULL || evsel-tp_format == NULL) {
- pr_err(invalid event found.. aborting\n);
+ evlist__for_each(session-evlist, evsel) {
+ if (!strcmp(perf_evsel__name(evsel),
+ kmem:mm_page_alloc)) {
+ found = true;
+ break;
+ }
+ }
+ if (!found) {
+ pr_err(errmsg, page, page);
return -1;
}
--
2.3.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/6] perf kmem: Print gfp flags in human readable string
Save libtraceevent output and print it in the header.
# perf kmem stat --page --caller
#
# GFP flags
# -
# 0010: NI: GFP_NOIO
# 00d0:K: GFP_KERNEL
# 0200: NWR: GFP_NOWARN
# 84d0:K|R|Z: GFP_KERNEL|GFP_REPEAT|GFP_ZERO
# 000200d2: HU: GFP_HIGHUSER
# 000200da: HUM: GFP_HIGHUSER_MOVABLE
# 000280da:HUM|Z: GFP_HIGHUSER_MOVABLE|GFP_ZERO
# 002084d0: K|R|Z|NT: GFP_KERNEL|GFP_REPEAT|GFP_ZERO|GFP_NOTRACK
# 0102005a: NF|HW|M: GFP_NOFS|GFP_HARDWALL|GFP_MOVABLE
-
Total alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite
-
60 |15 | 0 | UNMOVABL | K|R|Z|NT | pte_alloc_one
40 |10 | 0 | MOVABLE | HUM|Z | handle_mm_fault
24 | 6 | 0 | MOVABLE | HUM | do_wp_page
24 | 6 | 0 | UNMOVABL | K | __pollwait
...
Requested-by: Joonsoo Kim js1...@gmail.com
Suggested-by: Minchan Kim minc...@kernel.org
Acked-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-kmem.c | 222 +++---
1 file changed, 209 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 7ead9423fd7a..1c668953c7ec 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -581,6 +581,176 @@ static bool valid_page(u64 pfn_or_page)
return true;
}
+struct gfp_flag {
+ unsigned int flags;
+ char *compact_str;
+ char *human_readable;
+};
+
+static struct gfp_flag *gfps;
+static int nr_gfps;
+
+static int gfpcmp(const void *a, const void *b)
+{
+ const struct gfp_flag *fa = a;
+ const struct gfp_flag *fb = b;
+
+ return fa-flags - fb-flags;
+}
+
+/* see include/trace/events/gfpflags.h */
+static const struct {
+ const char *original;
+ const char *compact;
+} gfp_compact_table[] = {
+ { GFP_TRANSHUGE, THP },
+ { GFP_HIGHUSER_MOVABLE, HUM },
+ { GFP_HIGHUSER, HU },
+ { GFP_USER, U },
+ { GFP_TEMPORARY, TMP },
+ { GFP_KERNEL, K },
+ { GFP_NOFS, NF },
+ { GFP_ATOMIC, A },
+ { GFP_NOIO, NI },
+ { GFP_HIGH, H },
+ { GFP_WAIT, W },
+ { GFP_IO, I },
+ { GFP_COLD, CO },
+ { GFP_NOWARN, NWR },
+ { GFP_REPEAT, R },
+ { GFP_NOFAIL, NF },
+ { GFP_NORETRY,NR },
+ { GFP_COMP, C },
+ { GFP_ZERO, Z },
+ { GFP_NOMEMALLOC, NMA },
+ { GFP_MEMALLOC, MA },
+ { GFP_HARDWALL, HW },
+ { GFP_THISNODE, TN },
+ { GFP_RECLAIMABLE,RC },
+ { GFP_MOVABLE,M },
+ { GFP_NOTRACK,NT },
+ { GFP_NO_KSWAPD, NK },
+ { GFP_OTHER_NODE, ON },
+ { GFP_NOWAIT, NW },
+};
+
+static size_t max_gfp_len;
+
+static char *compact_gfp_flags(char *gfp_flags)
+{
+ char *orig_flags = strdup(gfp_flags);
+ char *new_flags = NULL;
+ char *str, *pos;
+ size_t len = 0;
+
+ if (orig_flags == NULL)
+ return NULL;
+
+ str = strtok_r(orig_flags, |, pos);
+ while (str) {
+ size_t i;
+ char *new;
+ const char *cpt;
+
+ for (i = 0; i ARRAY_SIZE(gfp_compact_table); i++) {
+ if (strcmp(gfp_compact_table[i].original, str))
+ continue;
+
+ cpt = gfp_compact_table[i].compact;
+ new = realloc(new_flags, len + strlen(cpt) + 2);
+ if (new == NULL) {
+ free(new_flags);
+ return NULL;
+ }
+
+ new_flags = new;
+
+ if (!len) {
+ strcpy(new_flags, cpt);
+ } else {
+ strcat(new_flags, |);
+ strcat(new_flags, cpt);
+ len++;
+ }
+
+ len += strlen(cpt);
+ }
+
+ str = strtok_r(NULL, |, pos);
+ }
+
+ if (max_gfp_len len)
+ max_gfp_len = len;
+
+ free(orig_flags);
+ return new_flags;
+}
+
[PATCH 5/6] perf kmem: Add kmem.default config option
Currently perf kmem command will select --slab if neither --slab nor
--page is given for backward compatibility. Add kmem.default config
option to select the default value ('page' or 'slab').
# cat ~/.perfconfig
[kmem]
default = page
# perf kmem stat
SUMMARY (page allocator)
Total allocation requests :1,518 [6,096 KB ]
Total free requests :1,431 [5,748 KB ]
Total alloc+freed requests:1,330 [5,344 KB ]
Total alloc-only requests : 188 [ 752 KB ]
Total free-only requests : 101 [ 404 KB ]
Total allocation failures :0 [0 KB ]
...
Acked-by: Pekka Enberg penb...@kernel.org
Cc: Taeung Song treeze.tae...@gmail.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-kmem.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 1c668953c7ec..828b7284e547 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -28,6 +28,10 @@ static int kmem_slab;
static int kmem_page;
static longkmem_page_size;
+static enum {
+ KMEM_SLAB,
+ KMEM_PAGE,
+} kmem_default = KMEM_SLAB; /* for backward compatibility */
struct alloc_stat;
typedef int (*sort_fn_t)(void *, void *);
@@ -1710,7 +1714,8 @@ static int parse_sort_opt(const struct option *opt
__maybe_unused,
if (!arg)
return -1;
- if (kmem_page kmem_slab) {
+ if (kmem_page kmem_slab ||
+ (kmem_page == 0 kmem_slab == 0 kmem_default == KMEM_PAGE)) {
if (caller_flag alloc_flag)
return setup_page_sorting(page_caller_sort, arg);
else
@@ -1826,6 +1831,22 @@ static int __cmd_record(int argc, const char **argv)
return cmd_record(i, rec_argv, NULL);
}
+static int kmem_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, kmem.default)) {
+ if (!strcmp(value, slab))
+ kmem_default = KMEM_SLAB;
+ else if (!strcmp(value, page))
+ kmem_default = KMEM_PAGE;
+ else
+ pr_err(invalid default value ('slab' or 'page'
required): %s\n,
+ value);
+ return 0;
+ }
+
+ return perf_default_config(var, value, cb);
+}
+
int cmd_kmem(int argc, const char **argv, const char *prefix __maybe_unused)
{
const char * const default_slab_sort = frag,hit,bytes;
@@ -1862,14 +1883,19 @@ int cmd_kmem(int argc, const char **argv, const char
*prefix __maybe_unused)
struct perf_session *session;
int ret = -1;
+ perf_config(kmem_config, NULL);
argc = parse_options_subcommand(argc, argv, kmem_options,
kmem_subcommands, kmem_usage, 0);
if (!argc)
usage_with_options(kmem_usage, kmem_options);
- if (kmem_slab == 0 kmem_page == 0)
- kmem_slab = 1; /* for backward compatibility */
+ if (kmem_slab == 0 kmem_page == 0) {
+ if (kmem_default == KMEM_SLAB)
+ kmem_slab = 1;
+ else
+ kmem_page = 1;
+ }
if (!strncmp(argv[0], rec, 3)) {
symbol__init(NULL);
--
2.3.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/6] perf kmem: Support sort keys on page analysis
Add new sort keys for page: page, order, migtype, gfp - existing
'bytes', 'hit' and 'callsite' sort keys also work for page. Note that
-s/--sort option should be preceded by either of --slab or --page
option to determine where the sort keys applies.
Now it properly groups and sorts allocation stats - so same
page/caller with different order/migtype/gfp will be printed on a
different line.
# perf kmem stat --page --caller -l 10 -s order,hit
Total alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite
64 | 4 | 2 | RECLAIM | 00285250 | new_slab
50,144 |12,536 | 0 | MOVABLE | 0102005a |
__page_cache_alloc
52 |13 | 0 | UNMOVABL | 002084d0 | pte_alloc_one
40 |10 | 0 | MOVABLE | 000280da | handle_mm_fault
28 | 7 | 0 | UNMOVABL | 00d0 | __pollwait
20 | 5 | 0 | MOVABLE | 000200da | do_wp_page
20 | 5 | 0 | MOVABLE | 000200da | do_cow_fault
16 | 4 | 0 | UNMOVABL | 0200 |
__tlb_remove_page
16 | 4 | 0 | UNMOVABL | 84d0 | __pmd_alloc
8 | 2 | 0 | UNMOVABL | 84d0 | __pud_alloc
... | ... | ... | ... | ... | ...
Acked-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/Documentation/perf-kmem.txt | 6 +-
tools/perf/builtin-kmem.c | 393 ++---
2 files changed, 313 insertions(+), 86 deletions(-)
diff --git a/tools/perf/Documentation/perf-kmem.txt
b/tools/perf/Documentation/perf-kmem.txt
index 23219c65c16f..69e181272c51 100644
--- a/tools/perf/Documentation/perf-kmem.txt
+++ b/tools/perf/Documentation/perf-kmem.txt
@@ -37,7 +37,11 @@ OPTIONS
-s key[,key2...]::
--sort=key[,key2...]::
- Sort the output (default: frag,hit,bytes)
+ Sort the output (default: 'frag,hit,bytes' for slab and 'bytes,hit'
+ for page). Available sort keys are 'ptr, callsite, bytes, hit,
+ pingpong, frag' for slab and 'page, callsite, bytes, hit, order,
+ migtype, gfp' for page. This option should be preceded by one of the
+ mode selection options - i.e. --slab, --page, --alloc and/or --caller.
-l num::
--line=num::
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 3649eec6807f..0393a7f3fa35 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -30,7 +30,7 @@ static intkmem_page;
static longkmem_page_size;
struct alloc_stat;
-typedef int (*sort_fn_t)(struct alloc_stat *, struct alloc_stat *);
+typedef int (*sort_fn_t)(void *, void *);
static int alloc_flag;
static int caller_flag;
@@ -181,8 +181,8 @@ static int perf_evsel__process_alloc_node_event(struct
perf_evsel *evsel,
return ret;
}
-static int ptr_cmp(struct alloc_stat *, struct alloc_stat *);
-static int callsite_cmp(struct alloc_stat *, struct alloc_stat *);
+static int ptr_cmp(void *, void *);
+static int slab_callsite_cmp(void *, void *);
static struct alloc_stat *search_alloc_stat(unsigned long ptr,
unsigned long call_site,
@@ -223,7 +223,8 @@ static int perf_evsel__process_free_event(struct perf_evsel
*evsel,
s_alloc-pingpong++;
s_caller = search_alloc_stat(0, s_alloc-call_site,
-root_caller_stat, callsite_cmp);
+root_caller_stat,
+slab_callsite_cmp);
if (!s_caller)
return -1;
s_caller-pingpong++;
@@ -448,26 +449,14 @@ static struct page_stat *page_stat__findnew_page(u64 page)
return __page_stat__findnew_page(page, true);
}
-static int page_stat_cmp(struct page_stat *a, struct page_stat *b)
-{
- if (a-page b-page)
- return -1;
- if (a-page b-page)
- return 1;
- if (a-order b-order)
- return -1;
- if (a-order b-order)
- return 1;
- if (a-migrate_type b-migrate_type)
- return -1;
- if (a-migrate_type b-migrate_type)
- return 1;
- if (a-gfp_flags b-gfp_flags)
- return -1;
- if (a-gfp_flags b-gfp_flags)
- return 1;
- return 0;
-}
+struct sort_dimension {
+ const char name[20];
+ sort_fn_t cmp;
+ struct list_head
[PATCHSET 0/6] perf kmem: Implement page allocation analysis (v8)
Hello, Currently perf kmem command only analyzes SLAB memory allocation. And I'd like to introduce page allocation analysis also. Users can use --slab and/or --page option to select it. If none of these options are used, it does slab allocation analysis for backward compatibility. * changes in v8) - rename 'stat' to 'pstat' due to build error - add Acked-by from Pekka * changes in v7) - drop already merged patches - check return value of map__load() (Arnaldo) - rename to page_stat__findnew_*() functions (Arnaldo) - show warning when try to run stat before record * changes in v6) - add -i option fix (Jiri) - libtraceevent operator priority fix * changes in v5) - print migration type and gfp flags in more compact form (Arnaldo) - add kmem.default config option * changes in v4) - use pfn instead of struct page * in tracepoints (Joonsoo, Ingo) - print gfp flags in human readable string (Joonsoo, Minchan) * changes in v3) - add live page statistics * changes in v2) - Use thousand grouping for big numbers - i.e. 12345 - 12,345 (Ingo) - Improve output stat readability (Ingo) - Remove alloc size column as it can be calculated from hits and order In this patchset, I used two kmem events: kmem:mm_page_alloc and kmem_page_free for analysis as they can track almost all of memory allocation/free path AFAIK. However, unlike slab tracepoint events, those page allocation events don't provide callsite info directly. So I recorded callchains and extracted callsites like below: Normal page allocation callchains look like this: 360a7e __alloc_pages_nodemask 3a711c alloc_pages_current 357bc7 __page_cache_alloc -- callsite 357cf6 pagecache_get_page 48b0a prepare_pages 494d3 __btrfs_buffered_write 49cdf btrfs_file_write_iter 3ceb6e new_sync_write 3cf447 vfs_write 3cff99 sys_write 7556e9 system_call f880 __write_nocancel 33eb9 cmd_record 4b38e cmd_kmem 7aa23 run_builtin 27a9a main 20800 __libc_start_main But first two are internal page allocation functions so it should be skipped. To determine such allocation functions, I used following regex: ^_?_?(alloc|get_free|get_zeroed)_pages? This gave me a following list of functions (you can see this with -v): alloc func: __get_free_pages alloc func: get_zeroed_page alloc func: alloc_pages_exact alloc func: __alloc_pages_direct_compact alloc func: __alloc_pages_nodemask alloc func: alloc_page_interleave alloc func: alloc_pages_current alloc func: alloc_pages_vma alloc func: alloc_page_buffers alloc func: alloc_pages_exact_nid After skipping those function, it got '__page_cache_alloc'. Other information such as allocation order, migration type and gfp flags are provided by tracepoint events. Basically the output will be sorted by total allocation bytes, but you can change it by using -s/--sort option. The following sort keys are added to support page analysis: page, order, migtype, gfp. Existing 'callsite', 'bytes' and 'hit' sort keys also can be used. An example follows: # perf kmem record --page sleep 5 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 1.065 MB perf.data (2949 samples) ] # perf kmem stat --page --caller -s order,hit -l 10 # # GFP flags # - # 0010: NI: GFP_NOIO # 00d0: K: GFP_KERNEL # 0200:NWR: GFP_NOWARN # 52d0: K|NWR|NR|C: GFP_KERNEL|GFP_NOWARN|GFP_NORETRY|GFP_COMP # 84d0: K|R|Z: GFP_KERNEL|GFP_REPEAT|GFP_ZERO # 000200d0: U: GFP_USER # 000200d2: HU: GFP_HIGHUSER # 000200da:HUM: GFP_HIGHUSER_MOVABLE # 000280da: HUM|Z: GFP_HIGHUSER_MOVABLE|GFP_ZERO # 002084d0: K|R|Z|NT: GFP_KERNEL|GFP_REPEAT|GFP_ZERO|GFP_NOTRACK # 0102005a:NF|HW|M: GFP_NOFS|GFP_HARDWALL|GFP_MOVABLE - Total alloc (KB) | Hits | Order | Mig.type | GFP flags | Callsite - 16 | 1 | 2 | UNMOVABL | K|NWR|NR|C | alloc_skb_with_frags 24 | 3 | 1 | UNMOVABL | K|NWR|NR|C | alloc_skb_with_frags 3,876 | 969 | 0 | MOVABLE | HUM| shmem_alloc_page 972 | 243 | 0 | UNMOVABL | K | __pollwait 624 | 156 | 0 | MOVABLE | NF|HW|M| __page_cache_alloc 304 |76 | 0 | UNMOVABL | U | dma_generic_alloc_coherent 108 |27 | 0 | MOVABLE | HUM|Z | handle_mm_fault 56 |14 | 0 | UNMOVABL | K|R|Z|NT | pte_alloc_one 24 | 6 | 0 | MOVABLE | HUM| do_wp_page 16 | 4 | 0 | UNMOVABL | NWR
Re: [PATCHv2 1/3] phy: core: Add devm_of_phy_get_by_index to phy-core
Hi,
On Tuesday 21 April 2015 01:49 AM, Arun Ramamurthy wrote:
On 15-04-15 02:59 AM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 14 April 2015 03:40 AM, Arun Ramamurthy wrote:
Some generic drivers, such as ehci, may use multiple phys and for such
drivers referencing phy(s) by name(s) does not make sense. Instead of
inventing new naming schemes and using custom code to iterate through
them,
such drivers are better of using nameless phy bindings and using this
newly
introduced API to iterate through them.
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 3791838..964a84d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -623,6 +623,38 @@ struct phy *devm_of_phy_get(struct device *dev,
struct device_node *np,
EXPORT_SYMBOL_GPL(devm_of_phy_get);
/**
+ * devm_of_phy_get_by_index() - lookup and obtain a reference to a
phy by index.
+ * @dev: device that requests this phy
+ * @np: node containing the phy
+ * @index: index of the phy
+ *
+ * Gets the phy using _of_phy_get(), and associates a device with it
using
+ * devres. On driver detach, release function is invoked on the
devres data,
+ * then, devres data is freed.
+ *
+ */
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct
device_node *np,
+ int index)
+{
+struct phy **ptr, *phy;
+
+ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+if (!ptr)
+return ERR_PTR(-ENOMEM);
+
+phy = _of_phy_get(np, index);
+if (!IS_ERR(phy)) {
+*ptr = phy;
+devres_add(dev, ptr);
+} else {
+devres_free(ptr);
+}
+
+return phy;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
+
+/**
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @node: device node of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index a0197fa..ae2ffaf 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -133,6 +133,8 @@ struct phy *devm_phy_get(struct device *dev, const
char *string);
struct phy *devm_phy_optional_get(struct device *dev, const char
*string);
struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
const char *con_id);
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct
device_node *np,
+ int index);
Add stubs for this function too. Also update the Documentation/phy.txt.
Kishon, I have added stubs for this function in my next patch set.
However I am still unclear on whether I need to make GENERIC_PHY an
invisible option or change my select to depend ? It seems like there
was no consensus on this? Do you have any final thoughts before i send
out the next patch set? Thanks
You can follow Arnd's suggestion. You can have a separate patch to change the
GENERIC_PHY to invisible option and change existing PHY drivers to select
GENERIC_PHY.
Non-PHY drivers can either use depends on or have no explicit dependency if the
PHY is optional for that controller.
Thanks
Kishon
--
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: dsa: mv88e6xxx: fix setup of port control 1
From: Andrew Lunn and...@lunn.ch Date: Tue, 21 Apr 2015 01:05:07 +0200 On Mon, Apr 20, 2015 at 05:19:23PM -0400, Vivien Didelot wrote: mv88e6xxx_setup_port_common was writing to PORT_DEFAULT_VLAN (port offset 0x07) instead of PORT_CONTROL_1 (port offset 0x05). Hi Vivien Good catch. Signed-off-by: Vivien Didelot vivien.dide...@savoirfairelinux.com Fixes: cca8b1337541 (net: dsa: Use mnemonics rather than register numbers) Acked-by: Andrew Lunn and...@lunn.ch Applied. -- 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: dsa: mv88e6xxx: use PORT_DEFAULT_VLAN
From: Vivien Didelot vivien.dide...@savoirfairelinux.com Date: Mon, 20 Apr 2015 17:43:26 -0400 Minor, use the explicit PORT_DEFAULT_VLAN define instead of 0x07. Signed-off-by: Vivien Didelot vivien.dide...@savoirfairelinux.com Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions
On Mon, 2015-04-20 at 14:21 -0400, Steven Rostedt wrote: I would argue than every case is different, and only the sysadmin would know the right value. Thus, just set it to one, and if that's not good enough, then the sysadmins can change it to their needs. Agreed. I don't have it turned on in my -rt kernels, because I don't want to force a knight in shining (priority x) armor on users. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel] [PATCH v2 1/2] extcon: arizona: Add support for select accessory detect mode when headphone detection
This patch add support for select accessory detect mode to HPDETL or HPDETR.
Arizona provides a headphone detection circuit on the HPDETL and HPDETR pins
to measure the impedance of an external load connected to the headphone.
Depending on board design, headphone detect pins can change to HPDETR or HPDETL.
Signed-off-by: Inha Song ideal.s...@samsung.com
---
drivers/extcon/extcon-arizona.c | 28
include/dt-bindings/mfd/arizona.h | 8
include/linux/mfd/arizona/pdata.h | 3 +++
3 files changed, 31 insertions(+), 8 deletions(-)
create mode 100644 include/dt-bindings/mfd/arizona.h
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..c827342 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -32,13 +32,10 @@
#include linux/mfd/arizona/core.h
#include linux/mfd/arizona/pdata.h
#include linux/mfd/arizona/registers.h
+#include dt-bindings/mfd/arizona.h
#define ARIZONA_MAX_MICD_RANGE 8
-#define ARIZONA_ACCDET_MODE_MIC 0
-#define ARIZONA_ACCDET_MODE_HPL 1
-#define ARIZONA_ACCDET_MODE_HPR 2
-
#define ARIZONA_MICD_CLAMP_MODE_JDL 0x4
#define ARIZONA_MICD_CLAMP_MODE_JDH 0x5
#define ARIZONA_MICD_CLAMP_MODE_JDL_GP5H 0x9
@@ -653,9 +650,9 @@ static void arizona_identify_headphone(struct
arizona_extcon_info *info)
ret = regmap_update_bits(arizona-regmap,
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_MODE_MASK,
-ARIZONA_ACCDET_MODE_HPL);
+arizona-pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona-dev, Failed to set HPDETL mode: %d\n, ret);
+ dev_err(arizona-dev, Failed to set HPDET mode: %d\n, ret);
goto err;
}
@@ -705,9 +702,9 @@ static void arizona_start_hpdet_acc_id(struct
arizona_extcon_info *info)
ARIZONA_ACCESSORY_DETECT_MODE_1,
ARIZONA_ACCDET_SRC | ARIZONA_ACCDET_MODE_MASK,
info-micd_modes[0].src |
-ARIZONA_ACCDET_MODE_HPL);
+arizona-pdata.hpdet_channel);
if (ret != 0) {
- dev_err(arizona-dev, Failed to set HPDETL mode: %d\n, ret);
+ dev_err(arizona-dev, Failed to set HPDET mode: %d\n, ret);
goto err;
}
@@ -1103,6 +1100,16 @@ static void arizona_micd_set_level(struct arizona
*arizona, int index,
regmap_update_bits(arizona-regmap, reg, mask, level);
}
+static int arizona_extcon_of_get_pdata(struct arizona *arizona)
+{
+ struct arizona_pdata *pdata = arizona-pdata;
+
+ of_property_read_u32(arizona-dev-of_node, wlf,hpdet-channel,
+pdata-hpdet_channel);
+
+ return 0;
+}
+
static int arizona_extcon_probe(struct platform_device *pdev)
{
struct arizona *arizona = dev_get_drvdata(pdev-dev.parent);
@@ -1120,6 +1127,11 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
if (!info)
return -ENOMEM;
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (!dev_get_platdata(arizona-dev))
+ arizona_extcon_of_get_pdata(arizona);
+ }
+
info-micvdd = devm_regulator_get(pdev-dev, MICVDD);
if (IS_ERR(info-micvdd)) {
ret = PTR_ERR(info-micvdd);
diff --git a/include/dt-bindings/mfd/arizona.h
b/include/dt-bindings/mfd/arizona.h
new file mode 100644
index 000..9ecff78
--- /dev/null
+++ b/include/dt-bindings/mfd/arizona.h
@@ -0,0 +1,8 @@
+#ifndef __DT_BINDINGS_ARIZONA_H__
+#define __DT_BINDINGS_ARIZONA_H__
+
+#define ARIZONA_ACCDET_MODE_MIC 0
+#define ARIZONA_ACCDET_MODE_HPL 1
+#define ARIZONA_ACCDET_MODE_HPR 2
+
+#endif /* __DT_BINDINGS_ARIZONA_H__ */
diff --git a/include/linux/mfd/arizona/pdata.h
b/include/linux/mfd/arizona/pdata.h
index 4578c72..2473a67 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -139,6 +139,9 @@ struct arizona_pdata {
/** GPIO used for mic isolation with HPDET */
int hpdet_id_gpio;
+ /** Channel to use for headphone detection */
+ unsigned int hpdet_channel;
+
/** Extra debounce timeout used during initial mic detection (ms) */
int micd_detect_debounce;
--
2.0.0.390.gcb682f8
--
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/
[alsa-devel] [PATCH v2 2/2] mfd: arizona: Update DT binding to support hpdet channel
This patch add device tree bindings for the pdata needed to configure the Accessory Detect Mode select when Headphone detection. Signed-off-by: Inha Song ideal.s...@samsung.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7bd1273..3529592 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -49,6 +49,12 @@ Optional properties: input singals. If values less than the number of input signals, elements that has not been specifed are set to 0 by default. + - wlf,hpdet-channel : Headphone detection channel. + 1 or ARIZONA_ACCDET_MODE_HPL - Headphone detect mode is set to HPDETL + 2 or ARIZONA_ACCDET_MODE_HPR - Headphone detect mode is set to HPDETR + If this node is not mentioned or if the value is unknown, then + headphone detection mode is set to MICDET. + - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt -- 2.0.0.390.gcb682f8 -- 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: mips build failures due to commit 8dd928915a73 (mips: fix up obsolete cpu function usage)
On 04/20/2015 02:09 PM, Aaro Koskinen wrote:
Hi,
On Mon, Apr 20, 2015 at 12:40:28PM -0700, Guenter Roeck wrote:
the upstream kernel fails to build mips:nlm_xlp_defconfig,
mips:nlm_xlp_defconfig, mips:cavium_octeon_defconfig, and possibly
other targets, with errors such as
arch/mips/kernel/smp.c:211:2: error:
passing argument 2 of 'cpumask_set_cpu' discards 'volatile' qualifier
from pointer target type
arch/mips/kernel/process.c:52:2: error:
passing argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier
from pointer target type
arch/mips/cavium-octeon/smp.c:242:2: error:
passing argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier
from pointer target type
The problem was introduced with commit 8dd928915a73 ( mips: fix up
obsolete cpu function usage). I would send a patch to fix it, but I
am not sure if removing 'volatile' from the variable declaration(s)
would be a good idea.
I think removing volatile from cpu_callin_map declaration should be OK,
since test_cpu (only reader) uses test_bit which takes care of it:
static inline int test_bit(int nr, const volatile unsigned long *addr)
I ran two tests with nlm_xlp_defconfig:
- add volatile to the second argument of cpumask_set_cpu() and
cpumask_test_cpu():
vmlinux image size 194664946
- remove volatile from cpu_callin_map:
vmlinux image size 194664066
Given that, I am not sure I understand the impact of removing volatile
from cpu_callin_map. Maybe it is just better optimization without
volatile. Maybe there is no impact. Maybe the use of volatile is wrong
to start with ('Volatile Considered Harmful' comes into mind).
Maybe the use of volatile for cpu_callin_map is wrong for other architectures
as well (powerpc, ia64). Either case, I don't know to code well enough to
make this call.
Guenter
--
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 V6 00/10] namespaces: log namespaces per task
Richard Guy Briggs r...@redhat.com writes: The purpose is to track namespace instances in use by logged processes from the perspective of init_*_ns by logging the namespace IDs (device ID and namespace inode - offset). In broad strokes the user interface appears correct. Things that I see that concern me: - After Als most recent changes these inodes no longer live in the proc superblock so the device number reported in these patches is incorrect. - I am nervous about audit logs being flooded with users creating lots of namespaces. But that is more your lookout than mine. - unshare is not logging when it creates new namespaces. As small numbers are nice and these inodes all live in their own superblock now we should be able to remove the games with PROC_DYNAMIC_FIRST and just use small numbers for these inodes everywhere. I have answered your comments below. 1/10 exposes proc's ns entries structure which lists a number of useful operations per namespace type for other subsystems to use. 2/10 proc_ns: define PROC_*_INIT_INO in terms of PROC_DYNAMIC_FIRST 3/10 provides an example of usage for audit_log_task_info() which is used by syscall audits, among others. audit_log_task() and audit_common_recv_message() would be other potential use cases. Proposed output format: This differs slightly from Aristeu's patch because of the label conflict with pid= due to including it in existing records rather than it being a seperate record. It has now returned to being a seperate record. The proc device major/minor are listed in hexadecimal and namespace IDs are the proc inode minus the base offset. type=NS_INFO msg=audit(1408577535.306:82): dev=00:03 netns=3 utsns=-3 ipcns=-4 pidns=-1 userns=-2 mntns=0 4/10 change audit startup from __initcall to subsys_initcall to get it started earlier to be able to receive initial namespace log messages. 5/10 tracks the creation and deletion of namespaces, listing the type of namespace instance, proc device ID, related namespace id if there is one and the newly minted namespace ID. Proposed output format for initial namespace creation: type=AUDIT_NS_INIT_UTS msg=audit(1408577534.868:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_utsns=(none) utsns=-3 res=1 type=AUDIT_NS_INIT_USER msg=audit(1408577534.868:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_userns=(none) userns=-2 res=1 type=AUDIT_NS_INIT_PID msg=audit(1408577534.868:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_pidns=(none) pidns=-1 res=1 type=AUDIT_NS_INIT_MNT msg=audit(1408577534.868:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_mntns=(none) mntns=0 res=1 type=AUDIT_NS_INIT_IPC msg=audit(1408577534.868:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_ipcns=(none) ipcns=-4 res=1 type=AUDIT_NS_INIT_NET msg=audit(1408577533.500:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_netns=(none) netns=2 res=1 And a CLONE action would result in: type=type=AUDIT_NS_INIT_NET msg=audit(1408577535.306:81): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 dev=00:03 old_netns=2 netns=3 res=1 While deleting a namespace would result in: type=type=AUDIT_NS_DEL_MNT msg=audit(1408577552.221:85): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 dev=00:03 mntns=4 res=1 6/10 accepts a PID from userspace and requests logging an AUDIT_NS_INFO record type (CAP_AUDIT_CONTROL required). 7/10 is a macro for CLONE_NEW_* flags. 8/10 adds auditing on creation of namespace(s) in fork. 9/10 adds auditing a change of namespace on setns. 10/10 attaches a AUDIT_NS_INFO record to AUDIT_VIRT_CONTROL records (CAP_AUDIT_WRITE required). v5 - v6: Switch to using namespace ID based on namespace proc inode minus base offset Added proc device ID to qualify proc inode reference Eliminate exposed /proc interface v4 - v5: Clean up prototypes for dependencies on CONFIG_NAMESPACES. Add AUDIT_NS_INFO record type to AUDIT_VIRT_CONTROL record. Log AUDIT_NS_INFO with PID. Move /proc/pid/ns_* patches to end of patchset to deprecate them. Log on changing ns (setns). Log on creating new namespaces when forking. Added a macro for CLONE_NEW*. v3 - v4: Seperate out the NS_INFO message from the SYSCALL message. Moved audit_log_namespace_info() out of audit_log_task_info(). Use a seperate message type per namespace type for each of INIT/DEL. Make ns= easier to search across NS_INFO and NS_INIT/DEL_XXX msg types. Add /proc/pid/ns/ documentation. Fix dynamic initial ns logging. v2 - v3: Use atomic64_t in ns_serial to simplify it. Avoid funciton duplication in proc, keying on dentry.
Re: [PATCH v6] perf: __kmod_path__parse: deal with kernel module names in '[]' correctly.
Hi Wang,
On Tue, Apr 21, 2015 at 03:33:10AM +, Wang Nan wrote:
Before patch ba92732e9808df679ddf75c5ea1c0caae6d7dce2 ('perf kmaps:
Check kmaps to make code more robust'), perf report and perf annotate
will segfault if trace data contains kernel module information like
this:
# perf report -D -i ./perf.data
...
0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffbff1018000(0xf068000) @
0]: x [test_module]
...
# perf report -i ./perf.data --objdump=/path/to/objdump
--kallsyms=/path/to/kallsyms
perf: Segmentation fault
backtrace
/path/to/perf[0x503478]
/lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
/path/to/perf[0x499b56]
/path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
/path/to/perf(dso__load+0x72e)[0x49c21e]
/path/to/perf(map__load+0x6e)[0x4ae9ee]
/path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
/path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
/path/to/perf[0x43ad02]
/path/to/perf[0x4b55bc]
/path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
/path/to/perf[0x4b1a01]
/path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
/path/to/perf(cmd_report+0xf11)[0x43bfc1]
/path/to/perf[0x474702]
/path/to/perf(main+0x5f5)[0x42de95]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
/path/to/perf[0x42dfc4]
This is because __kmod_path__parse treats '[' leading names as kernel
name instead of names of kernel module. If perf.data contains build
information and the buildid of such modules can be found, the DSO of
it will be treated as kernel, not kernel module.
Sorry if I missed some prior discussion on it, but any chance to treat
them as modules instead of kernel binaries?
Thanks,
Namhyung
It will then be passed to
dso__load_kernel_sym() - dso__load_kcore() because of --kallsyms
argument.
The refered patch adds NULL pointer checker to avoid segfault. However,
such kernel modules are still processed incorrectly.
This patch fixes __kmod_path__parse, makes it treat names like
'[test_module]' as kernel modules.
kmod-path.c is also update to reflect the above changes.
Signed-off-by: Wang Nan wangn...@huawei.com
---
Improves commit messages.
Since ba92732e9808df679ddf75c5ea1c0caae6d7dce2 is already in -tip tree,
segfault will not be triggered even without this patch.
---
tools/perf/tests/kmod-path.c | 72
tools/perf/util/dso.c| 42 +++---
tools/perf/util/dso.h| 2 +-
tools/perf/util/header.c | 8 ++---
tools/perf/util/machine.c| 16 +-
5 files changed, 130 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index e8d7cbb..08c433b 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -34,9 +34,21 @@ static int test(const char *path, bool alloc_name, bool
alloc_ext,
return 0;
}
+static int test_is_kernel_module(const char *path, int cpumode, bool expect)
+{
+ TEST_ASSERT_VAL(is_kernel_module,
+ (!!is_kernel_module(path, cpumode)) == (!!expect));
+ pr_debug(%s (cpumode: %d) - is_kernel_module: %s\n,
+ path, cpumode, expect ? true : false);
+ return 0;
+}
+
#define T(path, an, ae, k, c, n, e) \
TEST_ASSERT_VAL(failed, !test(path, an, ae, k, c, n, e))
+#define M(path, c, e) \
+ TEST_ASSERT_VAL(failed, !test_is_kernel_module(path, c, e))
+
int test__kmod_path__parse(void)
{
/* pathalloc_name alloc_ext kmod comp name
ext */
@@ -44,30 +56,90 @@ int test__kmod_path__parse(void)
T(///x-x.ko, false , true , true, false, NULL ,
NULL);
T(///x-x.ko, true , false , true, false, [x_x],
NULL);
T(///x-x.ko, false , false , true, false, NULL ,
NULL);
+ M(///x-x.ko, PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
+ M(///x-x.ko, PERF_RECORD_MISC_KERNEL, true);
+ M(///x-x.ko, PERF_RECORD_MISC_USER, false);
/* pathalloc_name alloc_ext kmod comp name ext */
T(///x.ko.gz, true , true , true, true, [x], gz);
T(///x.ko.gz, false, true , true, true, NULL , gz);
T(///x.ko.gz, true , false , true, true, [x], NULL);
T(///x.ko.gz, false, false , true, true, NULL , NULL);
+ M(///x.ko.gz, PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
+ M(///x.ko.gz, PERF_RECORD_MISC_KERNEL, true);
+ M(///x.ko.gz, PERF_RECORD_MISC_USER, false);
/* path alloc_name alloc_ext kmod comp nameext */
T(///x.gz, true , true , false, true, x.gz ,gz);
T(///x.gz, false , true , false, true, NULL ,gz);
T(///x.gz, true , false, false, true, x.gz , NULL);
RE: [PATCH v5 13/27] IB/Verbs: Reserve legacy transport type in 'dev_addr'
-Original Message-
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
ow...@vger.kernel.org] On Behalf Of Michael Wang
Sent: Monday, April 20, 2015 2:08 PM
To: Roland Dreier; Sean Hefty; linux-r...@vger.kernel.org; linux-
ker...@vger.kernel.org; h...@dev.mellanox.co.il
Cc: Michael Wang; Tom Tucker; Steve Wise; Hoang-Nam Nguyen; Christoph
Raisch; Mike Marciniszyn; Eli Cohen; Faisal Latif; Jack Morgenstein; Or
Gerlitz;
Haggai Eran; Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford
Subject: [PATCH v5 13/27] IB/Verbs: Reserve legacy transport type in
'dev_addr'
Reserve the legacy transport type for the 'transport' member of 'struct
rdma_dev_addr' until we make sure this is no longer needed.
Cc: Hal Rosenstock h...@dev.mellanox.co.il
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey t...@talpey.com
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we...@intel.com
Cc: Sean Hefty sean.he...@intel.com
Signed-off-by: Michael Wang yun.w...@profitbricks.com
---
drivers/infiniband/core/cma.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index ebac646..6195bf6 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -244,14 +244,35 @@ static inline void cma_set_ip_ver(struct cma_hdr
*hdr, u8 ip_ver)
hdr-ip_version = (ip_ver 4) | (hdr-ip_version 0xF); }
+static inline void cma_set_legacy_transport(struct rdma_cm_id *id) {
+ switch (id-device-node_type) {
+ case RDMA_NODE_IB_CA:
+ case RDMA_NODE_IB_SWITCH:
+ case RDMA_NODE_IB_ROUTER:
+ id-route.addr.dev_addr.transport = RDMA_TRANSPORT_IB;
What about IBOE transport, am I missing something here? As of today ocrdma
exports node_type as RDMA_NODE_IB_CA, here transport will be set to
RDMA_TRANSPORT_IB,
Should it be RDMA_TRANPORT_IBOE?
+ break;
+ case RDMA_NODE_RNIC:
+ id-route.addr.dev_addr.transport =
RDMA_TRANSPORT_IWARP;
+ break;
+ case RDMA_NODE_USNIC:
+ id-route.addr.dev_addr.transport =
RDMA_TRANSPORT_USNIC;
+ break;
+ case RDMA_NODE_USNIC_UDP:
+ id-route.addr.dev_addr.transport =
RDMA_TRANSPORT_USNIC_UDP;
+ break;
+ default:
+ BUG();
+ }
+}
+
static void cma_attach_to_dev(struct rdma_id_private *id_priv,
struct cma_device *cma_dev)
{
atomic_inc(cma_dev-refcount);
id_priv-cma_dev = cma_dev;
id_priv-id.device = cma_dev-device;
- id_priv-id.route.addr.dev_addr.transport =
- rdma_node_get_transport(cma_dev-device-node_type);
+ cma_set_legacy_transport(id_priv-id);
list_add_tail(id_priv-list, cma_dev-id_list); }
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in the
body
of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sched: lockless wake-queues
Is there some reason you don't use the simpler singly-linked list construction with the tail being a pointer to a pointer: Sure, that would also work. It's just a convenient simplification, already used in struct hlist_node. +/* + * Queue a task for later wake-up by wake_up_q(). If the task is already + * queued by someone else, leave it to them to deliver the wakeup. This is already commented in the cmpxchg. + * + * This property makes it impossible to guarantee the order of wakeups, + * but for efficiency we try to deliver wakeups in the order tasks + * are added. Ok. This is just me thinking out loud about the semantics. It may also be worth commenting the fact that wake_up_q() leaves the struct wake_q_head in a corrupt state, so don't try to do it again. Right, we could re-init the list once the loop is complete, yes. But it shouldn't matter due to how we use wake-queues. Oh, indeed, there's no point. Unless it's worth a debugging option, but as you say the usage patterns are such that I don't expect it's needed. It just seemed worth commenting explicitly. If I were going to comment it, here's what I'd write. Feel free to copy any or none of this: /* * Wake-queues are lists of tasks about to be woken up. * Deferring the wakeup is useful when the waker is waking up multiple * tasks while holding a lock which the woken tasks will need, so they'd * go straight into a wait queue anyway. * * So instead, the the waker can wake_q_add(q, task) under the lock, * and then wake_up_q(q) afterward. * * The list head is allocated on the waker's stack, and the queue nodes * are preallocated as part of the task struct. * * A reference to each task (get_task_struct()) is held during the wait, * so the list will remain valid through wake_up_q(). * * One per task suffices, because there's never a need for a task to be * in two wake queues simultaneously; it is forbidden to abandon a task * in a wake queue (a call to wake_up_q() _must_ follow), so if a task is * already in a wake queue, the wakeup will happen soon and the second * waker can just skip it. * * As with all Linux wakeup primitives, there is no guarantee about the * order, but this code tries to wake tasks in wake_q_add order. * * The WAKE_Q macro declares and initializes the list head. * wake_up_q() does NOT reinitialize the list; it's expected to be * called near the end of a function, where the fact that the queue is * not used again will be easy to see by inspection. */ -- 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 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel
Hi Dave, I found the old mail: http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03584.html Please check this and you will find the discussion. Regards Zhenhua On 04/15/2015 02:48 PM, Dave Young wrote: On 04/15/15 at 01:47pm, Li, ZhenHua wrote: On 04/15/2015 08:57 AM, Dave Young wrote: Again, I think it is bad to use old page table, below issues need consider: 1) make sure old page table are reliable across crash 2) do not allow writing oldmem after crash Please correct me if I'm wrong, or if above is not doable I think I will vote for resetting pci bus. Thanks Dave Hi Dave, When updating the context tables, we have to write their address to root tables, this will cause writing to old mem. Resetting the pci bus has been discussed, please check this: http://lists.infradead.org/pipermail/kexec/2014-October/012752.html https://lkml.org/lkml/2014/10/21/890 I know one reason to use old pgtable is this looks better because it fixes the real problem, but it is not a good way if it introduce more problems because of it have to use oldmem. I will be glad if this is not a problem but I have not been convinced. OTOH, there's many types of iommu, intel, amd, a lot of other types. They need their own fixes, so it looks not that elegant. For pci reset, it is not perfect, but it has another advantage, the patch is simpler. The problem I see from the old discusssion is, reset bus in 2nd kernel is acceptable but it does not fix things on sparc platform. AFAIK current reported problems are intel and amd iommu, at least pci reset stuff does not make it worse. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/7] block: reread partitions changes and fix for loop
On Mon, Apr 13, 2015 at 5:22 PM, Christoph Hellwig h...@infradead.org wrote: The series looks fine to me: Reviewed-by: Christoph Hellwig h...@lst.de Jens, could you share us if you are OK with this patchset? 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: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)
On 04/20/2015 06:54 PM, Michael Ellerman wrote: On Mon, 2015-04-20 at 12:50 -0400, David Miller wrote: From: Guenter Roeck li...@roeck-us.net Date: Mon, 20 Apr 2015 09:44:31 -0700 On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote: From: Guenter Roeck li...@roeck-us.net Date: Sun, 19 Apr 2015 22:17:21 -0700 The debug option is intended for all _other_ architectures, to ensure that changes made for those don't break alpha/s390 builds. alpha/s390 have ARCH_NEEDS_WEAK_PER_CPU and don't need the debug option. Ironically this would not create a build failure for the architectures where this matters, because only powerpc has the like named percpu symbol. So it's not really meeting the stated objective in this case. Yes, that is correct; it can only find problems in non-architecture code, and on the downside produces false positives and thus build errors like this one. Which makes the fix a bit philosophical. Rename iommu_pool_hash in iommu-common, or drop DEBUG_FORCE_WEAK_PER_CPU. I would rename iommu_pool_hash, but that is just me. Ultimately, I don't really care one way or another, as long as the problem gets fixed. If nightly builds of s390 and alpha, the two platforms where this matters, are being done as reported in this thread, then I really don't see the value in DEBUG_FORCE_WEAK_PER_CPU. Me not either, but, as you say, that is a different discussion. We do an s390 allmodconfig for every linux-next release: http://kisskb.ellerman.id.au/kisskb/target/573/ And also for Linus' tree: http://kisskb.ellerman.id.au/kisskb/target/568/ We don't have alpha allmodconfig enabled, though we could, but we do build the defconfig: http://kisskb.ellerman.id.au/kisskb/target/2499/ http://kisskb.ellerman.id.au/kisskb/target/2494/ I cover alpha:allmodconfig in my builds for -next, mainline, as well as all kernel.org stable releases and release candidates. This discussion is a good argument for enabling s390:allmodconfig as well. So I think that should be sufficient to catch any percpus that are introduced in generic code with the same name as s390/alpha variables. Yes, but unfortunately only after the fact, though I don't see a means to avoid that. But I guess that's a more involved longer-term discussion and I guess I'll apply Sowmini's patches for now. Thanks! Guenter -- 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] Staging: comedi: fix coding style errors in daqboard2000.c
The patch fixes a trailing whitespace and code indenting coding style errors as reported by checkpatch.pl tool. Details of the lines where the fixed errors were reported are as follows: drivers/staging/comedi/drivers/daqboard2000.c:43: ERROR: trailing whitespace drivers/staging/comedi/drivers/daqboard2000.c:46: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:55: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:58: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:59: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:60: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:61: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:63: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:64: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:65: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:66: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:68: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:75: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:76: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:77: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:78: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:79: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:80: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:81: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:83: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:86: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:87: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:88: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:89: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:90: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:91: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:92: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:93: ERROR: code indent should use tabs where possible drivers/staging/comedi/drivers/daqboard2000.c:100: ERROR: code indent should use tabs where possible --Gbenga Adalumo On Mon, Apr 20, 2015 at 7:43 AM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Apr 19, 2015 at 07:59:31PM -0700, Gbenga Adalumo wrote: Fix coding style errors found by checkpatch.pl tool What errors? Be specific. -- 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: gdm72xx: enclose complex define statement
This patch fixes the warning found by checkpatch.pl:
ERROR: Macros with complex values should be enclosed in parentheses
Signed-off-by: Jaime Arrocha j...@kerneldev.net
---
drivers/staging/gdm72xx/usb_ids.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/gdm72xx/usb_ids.h
b/drivers/staging/gdm72xx/usb_ids.h
index 8ce544d..2b50ac6 100644
--- a/drivers/staging/gdm72xx/usb_ids.h
+++ b/drivers/staging/gdm72xx/usb_ids.h
@@ -32,8 +32,8 @@
#define BL_PID_MASK0xffc0
#define USB_DEVICE_BOOTLOADER(vid, pid)\
- {USB_DEVICE((vid), ((pid)BL_PID_MASK)|B_DOWNLOAD)},\
- {USB_DEVICE((vid), ((pid)BL_PID_MASK)|B_DOWNLOAD|B_DIFF_DL_DRV)}
+ ({USB_DEVICE((vid), ((pid)BL_PID_MASK)|B_DOWNLOAD)}, \
+ {USB_DEVICE((vid), ((pid)BL_PID_MASK)|B_DOWNLOAD|B_DIFF_DL_DRV)})
#define USB_DEVICE_CDC_DATA(vid, pid) \
{USB_DEVICE_INTF((vid), (pid), USB_CLASS_CDC_DATA)}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: soft-offline: fix num_poisoned_pages counting on concurrent events
If multiple soft offline events hit one free page/hugepage concurrently,
soft_offline_page() can handle the free page/hugepage multiple times,
which makes num_poisoned_pages counter increased more than once.
This patch fixes this wrong counting by checking TestSetPageHWPoison for
normal papes and by checking the return value of dequeue_hwpoisoned_huge_page()
for hugepages.
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: sta...@vger.kernel.org # v3.14+
---
# This problem might happen before 3.14, but it's rare and non-critical,
# so I want this patch to be backported to stable trees only if the patch
# cleanly applies (i.e. v3.14+).
---
mm/memory-failure.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git v4.0.orig/mm/memory-failure.c v4.0/mm/memory-failure.c
index 2cc1d578144b..72a5224c8084 100644
--- v4.0.orig/mm/memory-failure.c
+++ v4.0/mm/memory-failure.c
@@ -1721,12 +1721,12 @@ int soft_offline_page(struct page *page, int flags)
} else if (ret == 0) { /* for free pages */
if (PageHuge(page)) {
set_page_hwpoison_huge_page(hpage);
- dequeue_hwpoisoned_huge_page(hpage);
- atomic_long_add(1 compound_order(hpage),
+ if (!dequeue_hwpoisoned_huge_page(hpage))
+ atomic_long_add(1 compound_order(hpage),
num_poisoned_pages);
} else {
- SetPageHWPoison(page);
- atomic_long_inc(num_poisoned_pages);
+ if (!TestSetPageHWPoison(page))
+ atomic_long_inc(num_poisoned_pages);
}
}
unset_migratetype_isolate(page, MIGRATE_MOVABLE);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index
Arnd, On Wednesday 15 April 2015 03:17 AM, Arnd Bergmann wrote: On Tuesday 14 April 2015 11:05:35 Arun Ramamurthy wrote: [1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111 Kishon,removing select GENERIC_PHY also breaks the builds for certain architectures (i386 and x84_64). Is the consensus to leave the select but make GENERIC_PHY a invisible option? Thanks I think the best solution is - make GENERIC_PHY a silent option - change PHY_RCAR_GEN2 to use 'select' instead of 'depends on', so it will still work when all other phy drivers are disabled - change the non-phy drivers that select GENERIC_PHY to either use 'depends on' or no explicit dependency in case they are still functional without the API. Note that drivers/pinctrl/pinctrl-tegra-xusb.c is a phy provider as well, not a consumer, despite being outside of drivers/phy. makes sense to me. Thanks Kishon -- 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] dmaengine: dw: add Intel Broxton LPSS Integrated DMA support
+ dma maillist
Best wishes
Qipeng
-Original Message-
From: Zha, Qipeng
Sent: Tuesday, April 21, 2015 7:34 AM
To: linux-kernel@vger.kernel.org
Cc: viresh.li...@gmail.com; andriy.shevche...@linux.intel.com; Westerberg,
Mika; Chen, Jason CJ; Zheng, Qi; Zha, Qipeng; Zhong, Huiquan
Subject: [PATCH] dmaengine: dw: add Intel Broxton LPSS Integrated DMA support
From: Huiquan Zhong huiquan.zh...@intel.com
Add Broxton Lower Power Sub System Integrated DMA support, Since the DMA
register space is very similar to DesignWare DMA register space.
Add DW_DMAC_TYPE_IDMA type to distinguish LPSS iDMA register.
Broxton LPSS iDMA's maximum block size is 0x1(128KB -1).
Signed-off-by: Huiquan Zhong huiquan.zh...@intel.com
Signed-off-by: qipeng.zha qipeng@intel.com
---
drivers/dma/dw/core.c| 64 +---
drivers/dma/dw/internal.h| 3 --
drivers/dma/dw/regs.h| 14
include/linux/dma/dw.h | 8 +
include/linux/platform_data/dma-dw.h | 2 +-
5 files changed, 75 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c index
a8ad052..1d198c9 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -144,8 +144,19 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
*/
BUG_ON(!dws-dma_dev || dws-dma_dev != dw-dma.dev);
- cfghi |= DWC_CFGH_DST_PER(dws-dst_id);
- cfghi |= DWC_CFGH_SRC_PER(dws-src_id);
+ if (dw-type == DW_DMAC_TYPE_IDMA) {
+ /* Forces channel FIFO to drain while in suspension */
+ cfglo = IDMA_CFGL_CH_DRAIN;
+ /* Burst length aligned */
+ cfglo |= IDMA_CFGL_SRC_BURST_ALIGN
+ | IDMA_CFGL_DST_BURST_ALIGN;
+
+ cfghi |= IDMA_CFGH_DST_PER(dws-dst_id);
+ cfghi |= IDMA_CFGH_SRC_PER(dws-src_id);
+ } else {
+ cfghi |= DWC_CFGH_DST_PER(dws-dst_id);
+ cfghi |= DWC_CFGH_SRC_PER(dws-src_id);
+ }
} else {
cfghi |= DWC_CFGH_DST_PER(dwc-dst_id);
cfghi |= DWC_CFGH_SRC_PER(dwc-src_id); @@ -346,9 +357,14 @@
static void dwc_complete_all(struct dw_dma *dw, struct dw_dma_chan *dwc)
/* Returns how many bytes were already received from source */ static inline
u32 dwc_get_sent(struct dw_dma_chan *dwc) {
+ struct dw_dma *dw = to_dw_dma(dwc-chan.device);
+
u32 ctlhi = channel_readl(dwc, CTL_HI);
u32 ctllo = channel_readl(dwc, CTL_LO);
+ if (dw-type == DW_DMAC_TYPE_IDMA)
+ return ctlhi IDMA_CTLH_BLOCK_TS_MASK;
+
return (ctlhi DWC_CTLH_BLOCK_TS_MASK) * (1 (ctllo 4 7)); }
@@ -775,6 +791,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist
*sgl,
unsigned intreg_width;
unsigned intmem_width;
unsigned intdata_width;
+ unsigned intwidth_trf;
unsigned inti;
struct scatterlist *sg;
size_t total_len = 0;
@@ -823,8 +840,14 @@ slave_sg_todev_fill_desc:
desc-lli.sar = mem;
desc-lli.dar = reg;
desc-lli.ctllo = ctllo | DWC_CTLL_SRC_WIDTH(mem_width);
- if ((len mem_width) dwc-block_size) {
- dlen = dwc-block_size mem_width;
+
+ if (dw-type == DW_DMAC_TYPE_IDMA)
+ width_trf = 0;
+ else
+ width_trf = mem_width;
+
+ if ((len width_trf) dwc-block_size) {
+ dlen = dwc-block_size width_trf;
mem += dlen;
len -= dlen;
} else {
@@ -832,7 +855,7 @@ slave_sg_todev_fill_desc:
len = 0;
}
- desc-lli.ctlhi = dlen mem_width;
+ desc-lli.ctlhi = dlen width_trf;
desc-len = dlen;
if (!first) {
@@ -883,15 +906,20 @@ slave_sg_fromdev_fill_desc:
desc-lli.sar = reg;
desc-lli.dar = mem;
desc-lli.ctllo = ctllo | DWC_CTLL_DST_WIDTH(mem_width);
- if ((len reg_width) dwc-block_size) {
- dlen = dwc-block_size reg_width;
+ if (dw-type == DW_DMAC_TYPE_IDMA)
+ width_trf = 0;
+ else
+ width_trf = reg_width;
+
+ if ((len width_trf) dwc-block_size) {
+ dlen = dwc-block_size
RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
Hi Michael, is there a specific git branch available to pull out all the patches? -Regards Devesh -Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- ow...@vger.kernel.org] On Behalf Of Michael Wang Sent: Monday, April 20, 2015 1:59 PM To: Roland Dreier; Sean Hefty; Hal Rosenstock; linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org; h...@dev.mellanox.co.il Cc: Tom Tucker; Steve Wise; Hoang-Nam Nguyen; Christoph Raisch; Mike Marciniszyn; Eli Cohen; Faisal Latif; Jack Morgenstein; Or Gerlitz; Haggai Eran; Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford; Michael Wang Subject: [PATCH v5 00/27] IB/Verbs: IB Management Helpers Since v4: * Thanks for the comments from Hal, Sean, Tom, Or Gerlitz, Jason, Roland, Ira and Steve :-) Please remind me if anything missed :-P * Fix logical issue inside 3#, 14# * Refine 3#, 4#, 5# with label 'free' * Rework 10# to stop using port 1 when port already assigned There are plenty of lengthy code to check the transport type of IB device, or the link layer type of it's port, but actually we are just speculating whether a particular management/feature is supported by the device/port. Thus instead of inferring, we should have our own mechanism for IB management capability/protocol/feature checking, several proposals below. This patch set will reform the method of getting transport type, we will now using query_transport() instead of inferring from transport and link layer respectively, also we defined the new transport type to make the concept more reasonable. Mapping List: node-type link-layer old-transport new-transport nes RNICETH IWARP IWARP amso1100 RNICETH IWARP IWARP cxgb3 RNICETH IWARP IWARP cxgb4 RNICETH IWARP IWARP usnic USNIC_UDP ETH USNIC_UDP USNIC_UDP ocrdmaIB_CA ETH IB IBOE mlx4 IB_CA IB/ETH IB IB/IBOE mlx5 IB_CA IB IB IB ehca IB_CA IB IB IB ipath IB_CA IB IB IB mthca IB_CA IB IB IB qib IB_CA IB IB IB For example: if (transport == IB) (link-layer == ETH) will now become: if (query_transport() == IBOE) Thus we will be able to get rid of the respective transport and link-layer checking, and it will help us to add new protocol/Technology (like OPA) more easier, also with the introduced management helpers, IB management logical will be more clear and easier for extending. Highlights: The patch set covered a wide range of IB stuff, thus for those who are familiar with the particular part, your suggestion would be invaluable ;-) Patch 1#~15# included all the logical reform, 16#~25# introduced the management helpers, 26#~27# do clean up. Patches haven't been tested yet, we appreciate if any one who have these HW willing to provide his Tested-by :-) Doug suggested the bitmask mechanism: https://www.mail-archive.com/linux- r...@vger.kernel.org/msg23765.html which could be the plan for future reforming, we prefer that to be another series which focus on semantic and performance. This patch-set is somewhat 'bloated' now and it may be a good timing for staging, I'd like to suggest we focus on improving existed helpers and push all the further reforms into next series ;-) Proposals: Sean: https://www.mail-archive.com/linux- r...@vger.kernel.org/msg23339.html Doug: https://www.mail-archive.com/linux- r...@vger.kernel.org/msg23418.html https://www.mail-archive.com/linux- r...@vger.kernel.org/msg23765.html Jason: https://www.mail-archive.com/linux- r...@vger.kernel.org/msg23425.html Michael Wang (27): IB/Verbs: Implement new callback query_transport() IB/Verbs: Implement raw management helpers IB/Verbs: Reform IB-core mad/agent/user_mad IB/Verbs: Reform IB-core cm IB/Verbs: Reform IB-core sa_query IB/Verbs: Reform IB-core multicast IB/Verbs: Reform IB-ulp ipoib IB/Verbs: Reform IB-ulp xprtrdma IB/Verbs: Reform IB-core verbs/uverbs_cmd/sysfs IB/Verbs: Reform cm related part in IB-core cma/ucm IB/Verbs: Reform route related part in IB-core cma IB/Verbs: Reform mcast related part in IB-core cma IB/Verbs: Reserve legacy transport type in 'dev_addr' IB/Verbs: Reform cma_acquire_dev() IB/Verbs: Reform rest part in IB-core cma IB/Verbs: Use management helper cap_ib_mad() IB/Verbs: Use management helper cap_ib_smi()
Re: [RFC 0/6] perf tools: Report event parsing errors
Em Sat, Apr 18, 2015 at 10:42:58PM +0200, Jiri Olsa escreveu: On Sat, Apr 18, 2015 at 07:39:27PM +0200, Ingo Molnar wrote: So since we now know exactly what's going on, we might want to drop the 'invalid or unsupported event' language as well, and make it specific: $ ./perf record -e 'cpu/even=0x1/' ls event syntax error: 'cpu/even=0x1/' \___ unknown term ? ok Also, for the above error, could we easily list the valid terms? An error like: $ ./perf record -e 'cpu/even=0x1/' ls event syntax error: 'cpu/even=0x1/' \___ unknown term valid terms: event, raw. or so? we already carry list of all terms for given pmu, so it shouldn't be a problem So, do you want me to apply this series and you work on top of it or should I wait for another that implements what Ingo suggested? Also, we have: [root@zoo ~]# perf stat --all -e cycles usleep 1 Performance counter stats for 'system wide': 3,382,595 cycles 0.001739102 seconds time elapsed [root@zoo ~]# perf stat --all-cpus -e cycles usleep 1 Performance counter stats for 'system wide': 2,435,672 cycles 0.001191689 seconds time elapsed [root@zoo ~]# perf stat --a -e cycles usleep 1 Error: Ambiguous option: a (could be --no-no-aggr or --append) usage: perf stat [options] [command] [root@zoo ~]# Which is nice, wouldn't it be good to have it for the that as well, i.e. for your example ev= would be a valid, and shorter form of even= or event=. - Arnaldo -- 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/3] tools build: No need to make libapi for perf explicitly
Em Sat, Apr 18, 2015 at 10:34:38PM +0200, Jiri Olsa escreveu: The perf build handles its dependencies by itself. Also renaming libapi libapikfs to libapi as it got changed just recently. Thanks, applied. -- 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] lib: delete lib/find_last_bit.c
File find_next_bit.c was deleted in patch
lib: move find_last_bit to lib/find_next_bit.c from Feb, 22,
but not in master (commit 8f6f19dd51). This is just a fix for
wrong merge.
Signed-off-by: Yury Norov yury.no...@gmail.com
---
lib/find_last_bit.c | 41 -
1 file changed, 41 deletions(-)
delete mode 100644 lib/find_last_bit.c
diff --git a/lib/find_last_bit.c b/lib/find_last_bit.c
deleted file mode 100644
index 3e3be40..000
--- a/lib/find_last_bit.c
+++ /dev/null
@@ -1,41 +0,0 @@
-/* find_last_bit.c: fallback find next bit implementation
- *
- * Copyright (C) 2008 IBM Corporation
- * Written by Rusty Russell ru...@rustcorp.com.au
- * (Inspired by David Howell's find_next_bit implementation)
- *
- * Rewritten by Yury Norov yury.no...@gmail.com to decrease
- * size and improve performance, 2015.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include linux/bitops.h
-#include linux/bitmap.h
-#include linux/export.h
-#include linux/kernel.h
-
-#ifndef find_last_bit
-
-unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
-{
- if (size) {
- unsigned long val = BITMAP_LAST_WORD_MASK(size);
- unsigned long idx = (size-1) / BITS_PER_LONG;
-
- do {
- val = addr[idx];
- if (val)
- return idx * BITS_PER_LONG + __fls(val);
-
- val = ~0ul;
- } while (idx--);
- }
- return size;
-}
-EXPORT_SYMBOL(find_last_bit);
-
-#endif
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers
On Mon, Apr 20, 2015 at 08:12:36AM -0700, Kevin Cernekee wrote: On Mon, Apr 20, 2015 at 5:21 AM, Mark Brown broo...@kernel.org wrote: The same check shows up in numerous other drivers, including the one for the audio controller on my board. Sounds like either that (undisclosed) driver has a problem or you're using it inappropriately. I don't think this driver has been posted on the list yet, but the checks show up in these two functions: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/sound/soc/img/concerto-audio.c#108 https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/sound/soc/img/concerto-audio.c#147 Any suggestions on what to change? That driver has not been posted previously (and looks like it could use some rework for mainline). If it doesn't care if it set the clock and is just trying for information it should be handling -ENOTSUPP, that's why the core returns that value. signature.asc Description: Digital signature
Re: [RFC 0/6] perf tools: Report event parsing errors
On Mon, Apr 20, 2015 at 05:09:36PM -0300, Arnaldo Carvalho de Melo wrote: Em Sat, Apr 18, 2015 at 10:42:58PM +0200, Jiri Olsa escreveu: On Sat, Apr 18, 2015 at 07:39:27PM +0200, Ingo Molnar wrote: So since we now know exactly what's going on, we might want to drop the 'invalid or unsupported event' language as well, and make it specific: $ ./perf record -e 'cpu/even=0x1/' ls event syntax error: 'cpu/even=0x1/' \___ unknown term ? ok Also, for the above error, could we easily list the valid terms? An error like: $ ./perf record -e 'cpu/even=0x1/' ls event syntax error: 'cpu/even=0x1/' \___ unknown term valid terms: event, raw. or so? we already carry list of all terms for given pmu, so it shouldn't be a problem So, do you want me to apply this series and you work on top of it or should I wait for another that implements what Ingo suggested? I'll resend v2 with the update Also, we have: [root@zoo ~]# perf stat --all -e cycles usleep 1 Performance counter stats for 'system wide': 3,382,595 cycles 0.001739102 seconds time elapsed [root@zoo ~]# perf stat --all-cpus -e cycles usleep 1 Performance counter stats for 'system wide': 2,435,672 cycles 0.001191689 seconds time elapsed [root@zoo ~]# perf stat --a -e cycles usleep 1 Error: Ambiguous option: a (could be --no-no-aggr or --append) usage: perf stat [options] [command] [root@zoo ~]# Which is nice, wouldn't it be good to have it for the that as well, i.e. for your example ev= would be a valid, and shorter form of even= or event=. hum, not sure I follow.. could you please explain in more details? 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 v2] Documentation usb serial: fixed how to provide vendor and product id
From: H. Nikolaus Schaller h...@goldelico.com While trying to test a Cinterion GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CDC-ACM. It turned out that I need the usbserial driver. This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are only available if compiled as a kernel module and have been superseded by a /sys interface. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file to describe the modern variant. Please note that the old one still works (if compiled as module). Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com --- - fixed 2 sentences suggested by Johan Hovold Documentation/usb/usb-serial.txt | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 947fa62..349f310 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -465,12 +465,14 @@ Generic Serial driver device, and does not support any kind of device flow control. All that is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - - To enable the generic driver to recognize your device, build the driver - as a module and load it by the following invocation: + + To enable the generic driver to recognize your device, provide + echo vid pid /sys/bus/usb-serial/drivers/generic/new_id + where the vid and pid is replaced with the hex representation of your + device's vendor id and product id. + If the driver is compiled as a module you can also provide one id when + loading the module insmod usbserial vendor=0x product=0x - where the is replaced with the hex representation of your device's - vendor id and product id. This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] __bitmap_parselist: fix bug in empty string handling
On Fri, 17 Apr 2015 14:00:04 -0400 Chris Metcalf cmetc...@ezchip.com wrote: bitmap_parselist(, mask, nmaskbits) will erroneously set bit zero in the mask. The same bug is visible in cpumask_parselist() since it is layered on top of the bitmask code, e.g. if you boot with isolcpus=, you will actually end up with cpu zero isolated. The bug was introduced in commit 4b060420a596 (bitmap, irq: add smp_affinity_list interface to /proc/irq) when bitmap_parselist() was generalized to support userspace as well as kernelspace. Signed-off-by: Chris Metcalf cmetc...@ezchip.com Cc: sta...@vger.kernel.org I don't think we need to backport a fix for a 4 year old bug which has very minor consequences. Am I wrong? -- 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 v6 0/6] arm64: Add kernel probes (kprobes) support
From: David A. Long dave.l...@linaro.org This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, first seen in October 2013. This version attempts to address concerns raised by reviewers and also fixes problems discovered during testing. This patchset adds support for kernel probes(kprobes), jump probes(jprobes) and return probes(kretprobes) support for ARM64. The kprobes mechanism makes use of software breakpoint and single stepping support available in the ARM v8 kernel. Changes since v2 include: 1) Removal of NOP padding in kprobe XOL slots. Slots are now exactly one instruction long. 2) Disabling of interrupts during execution in single-step mode. 3) Fixing of numerous problems in instruction simulation code (mostly thanks to Will Cohen). 4) Support for the HAVE_REGS_AND_STACK_ACCESS_API feature is added, to allow access to kprobes through debugfs. 5) kprobes is *not* enabled in defconfig. 6) Numerous complaints from checkpatch have been cleaned up, although a couple remain as removing the function pointer typedefs results in ugly code. Changes since v3 include: 1) Remove table-driven instruction parsing and replace with an if statement calling out to old and new instruction test functions in insn.c. 2) I removed the addition of orig_x0 to ptrace.h. 3) Reorder the patches. 4) Replace the previous interrupt disabling (from Will Cohen) with an improved solution (from Steve Capper). Changes since v4 include: 1) Added insn.c functions to detect exception instructions and DAIF read/write instructions, and use them to reject probing same. 2) Changed adr detect function to also recognize adrp. Reject both. 3) Added missing __kprobes for some new functions. 4) Added call to kprobes_fault_handler from mm do_page_fault. 5) Reject all non-simulated branch/ret instructions, not just those that use an immediate offset. 6) Moved software breakpoint definitions into debug-monitors.h. 7) Removed !XIP_KERNEL from Kconfig. 8) changed kprobes_condition_check_t and kprobes_prepare_t to probes_*, for future sharing with uprobes. 9) Removed bogus call to kprobes_restore_local_irqflag() from trampoline_probe_handler(). Changes since v5 include: 1) Replaced installation of breakpoint hook with direct call from the handlers in debug-monitors.c, as requested. 2) Reject probing of instructions that read the interrupt mask, in addition to instructions that set it. 3) Cleaned up comments describing usage of Debug Mask. 4) Added KPROBE_REENTER case in reenter_kprobe. 5) Corrected the ifdef'd definitions for notify_page_fault() to be consistent when KPROBES is not configed. 6) Changed cpsr to pstate for HAVE_REGS_AND_STACK_ACCESS_API feature. 7) Added back in missing new files in previous patch. 8) Changed two instances of pr_warning() to pr_warn(). Note that there seems to be at least a potential issue with kprobes on multiple (possibly all) platforms having to do with use of kfree inside of the kretprobes trampoline handler. This has manifested occasionally in systemtap testing on arm64. There does not appear to be an simple solution to the problem. David A. Long (2): arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature arm64: Add more test functions to insn.c Sandeepa Prabhu (4): arm64: Kprobes with single stepping support arm64: kprobes instruction simulation support arm64: Add kernel return probes support (kretprobes) kprobes: Add arm64 case in kprobe example module arch/arm64/Kconfig | 3 + arch/arm64/include/asm/debug-monitors.h | 5 + arch/arm64/include/asm/insn.h| 18 + arch/arm64/include/asm/kprobes.h | 63 +++ arch/arm64/include/asm/probes.h | 50 +++ arch/arm64/include/asm/ptrace.h | 32 +- arch/arm64/include/uapi/asm/ptrace.h | 36 ++ arch/arm64/kernel/Makefile | 3 + arch/arm64/kernel/debug-monitors.c | 35 +- arch/arm64/kernel/insn.c | 28 ++ arch/arm64/kernel/kprobes-arm64.c| 166 arch/arm64/kernel/kprobes-arm64.h| 30 ++ arch/arm64/kernel/kprobes.c | 676 +++ arch/arm64/kernel/kprobes.h | 24 ++ arch/arm64/kernel/probes-condn-check.c | 122 ++ arch/arm64/kernel/probes-simulate-insn.c | 174 arch/arm64/kernel/probes-simulate-insn.h | 33 ++ arch/arm64/kernel/ptrace.c | 116 ++ arch/arm64/kernel/vmlinux.lds.S | 1 + arch/arm64/mm/fault.c| 25 ++ samples/kprobes/kprobe_example.c | 8 + 21 files changed, 1637 insertions(+), 11 deletions(-) create mode 100644 arch/arm64/include/asm/kprobes.h create mode 100644 arch/arm64/include/asm/probes.h create mode 100644 arch/arm64/kernel/kprobes-arm64.c create mode 100644 arch/arm64/kernel/kprobes-arm64.h create mode 100644 arch/arm64/kernel/kprobes.c create mode 100644 arch/arm64/kernel/kprobes.h create mode 100644
Re: mips build failures due to commit 8dd928915a73 (mips: fix up obsolete cpu function usage)
On Mon, Apr 20, 2015 at 10:06:42PM +0200, Ralf Baechle wrote: On Mon, Apr 20, 2015 at 12:40:28PM -0700, Guenter Roeck wrote: the upstream kernel fails to build mips:nlm_xlp_defconfig, mips:nlm_xlp_defconfig, mips:cavium_octeon_defconfig, and possibly other targets, with errors such as arch/mips/kernel/smp.c:211:2: error: passing argument 2 of 'cpumask_set_cpu' discards 'volatile' qualifier from pointer target type arch/mips/kernel/process.c:52:2: error: passing argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer target type arch/mips/cavium-octeon/smp.c:242:2: error: passing argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from pointer target type The problem was introduced with commit 8dd928915a73 ( mips: fix up obsolete cpu function usage). I would send a patch to fix it, but I am not sure if removing 'volatile' from the variable declaration(s) would be a good idea. I don't recall seeing the problem in -next, but unless I am missing something, the patch never made it into -next to start with. It was posted on March 2nd as part of a larger series. Only this patch 9/16 was send to linux-mips and when I tested the patch it failed. Back then I blamed it on not having patches 1 to 8 in my test tree so I didn't diver deeper into the issue and dropped the patch ... Hi Ralf, The patch failed all by itself, no context needed ;-). Anyway, since it was part of a larger series, I would assume that it should have been added to -next as part of that series, not through the mips tree. For whatever reason that did not happen ... and as far as I can see, many if not all mips smp builds now fail in the upstream kernel. Any idea what the fix should be ? Thanks, Guenter -- 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 1/3] phy: core: Add devm_of_phy_get_by_index to phy-core
On 15-04-15 02:59 AM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 14 April 2015 03:40 AM, Arun Ramamurthy wrote:
Some generic drivers, such as ehci, may use multiple phys and for such
drivers referencing phy(s) by name(s) does not make sense. Instead of
inventing new naming schemes and using custom code to iterate through
them,
such drivers are better of using nameless phy bindings and using this
newly
introduced API to iterate through them.
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 3791838..964a84d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -623,6 +623,38 @@ struct phy *devm_of_phy_get(struct device *dev,
struct device_node *np,
EXPORT_SYMBOL_GPL(devm_of_phy_get);
/**
+ * devm_of_phy_get_by_index() - lookup and obtain a reference to a
phy by index.
+ * @dev: device that requests this phy
+ * @np: node containing the phy
+ * @index: index of the phy
+ *
+ * Gets the phy using _of_phy_get(), and associates a device with it
using
+ * devres. On driver detach, release function is invoked on the
devres data,
+ * then, devres data is freed.
+ *
+ */
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct
device_node *np,
+ int index)
+{
+struct phy **ptr, *phy;
+
+ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+if (!ptr)
+return ERR_PTR(-ENOMEM);
+
+phy = _of_phy_get(np, index);
+if (!IS_ERR(phy)) {
+*ptr = phy;
+devres_add(dev, ptr);
+} else {
+devres_free(ptr);
+}
+
+return phy;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
+
+/**
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @node: device node of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index a0197fa..ae2ffaf 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -133,6 +133,8 @@ struct phy *devm_phy_get(struct device *dev, const
char *string);
struct phy *devm_phy_optional_get(struct device *dev, const char
*string);
struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
const char *con_id);
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct
device_node *np,
+ int index);
Add stubs for this function too. Also update the Documentation/phy.txt.
Kishon, I have added stubs for this function in my next patch set.
However I am still unclear on whether I need to make GENERIC_PHY an
invisible option or change my select to depend ? It seems like there
was no consensus on this? Do you have any final thoughts before i send
out the next patch set? Thanks
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf/x86/intel/uncore: add support for Haswell ULT IMC uncore
On Mon, Apr 20, 2015 at 2:43 PM, Sonny Rao sonny...@chromium.org wrote:
On Mon, Apr 20, 2015 at 12:34 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Mon, Apr 20, 2015 at 1:58 PM, Stephane Eranian eran...@google.com wrote:
On Mon, Apr 20, 2015 at 11:56 AM, Bjorn Helgaas bhelg...@google.com wrote:
On Mon, Apr 20, 2015 at 1:42 PM, Sonny Rao sonny...@chromium.org wrote:
This uncore is the same as the Haswell desktop part but uses a
different PCI ID.
Signed-off-by: Sonny Rao sonny...@chromium.org
---
arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c | 5 +
include/linux/pci_ids.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
index 3001015..0bda6fc 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
@@ -472,6 +472,10 @@ static const struct pci_device_id
hsw_uncore_pci_ids[] = {
PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_HSW_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC,
0),
},
+ { /* IMC */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_HSW_U_IMC),
+ .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC,
0),
+ },
{ /* end: all zeroes */ },
};
@@ -502,6 +506,7 @@ static const struct imc_uncore_pci_dev
desktop_imc_pci_ids[] = {
IMC_DEV(IVB_IMC, ivb_uncore_pci_driver),/* 3rd Gen Core
processor */
IMC_DEV(IVB_E3_IMC, ivb_uncore_pci_driver), /* Xeon E3-1200
v2/3rd Gen Core processor */
IMC_DEV(HSW_IMC, hsw_uncore_pci_driver),/* 4th Gen Core
Processor */
+ IMC_DEV(HSW_U_IMC, hsw_uncore_pci_driver), /* 4th Gen Core ULT
Mobile Processor */
{ /* end marker */ }
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 38cff8f..e5ae042 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2545,6 +2545,7 @@
#define PCI_DEVICE_ID_INTEL_IVB_IMC0x0154
#define PCI_DEVICE_ID_INTEL_IVB_E3_IMC 0x0150
#define PCI_DEVICE_ID_INTEL_HSW_IMC0x0c00
+#define PCI_DEVICE_ID_INTEL_HSW_U_IMC 0x0a04
Please either use the 0x0a04 constant directly in
perf_event_intel_uncore_snb.c, or explain why the #define should be
here, e.g., maybe it will be used in multiple places. See the comment
at the top of pci_ids.h.
But then, the same reasoning would apply to the other 3 IMC defines,
wouldn't it?
Yes. But if we made a mistake in the past, that doesn't mean we
should repeat it today.
Shall I post a patch moving the others as well?
I'm not pushing for that, since they're already there and we haven't
tried to apply that policy retroactively.
#define PCI_DEVICE_ID_INTEL_PXHD_0 0x0320
#define PCI_DEVICE_ID_INTEL_PXHD_1 0x0321
#define PCI_DEVICE_ID_INTEL_PXH_0 0x0329
--
2.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] perf data: Switch to multiple cpu stream files
On Mon, Apr 20, 2015 at 04:58:54PM -0300, Arnaldo Carvalho de Melo wrote: Em Sat, Apr 18, 2015 at 05:50:15PM +0200, Jiri Olsa escreveu: From: Sebastian Andrzej Siewior bige...@linutronix.de Currently we store the data into single data strea/file. The cpu if data is stored within the event sample. The lttng puts the CPU number that belongs to the event into the packet context instead into the event. This patch makes sure that the trace produce by perf does look the same way. We now use one stream per-CPU. Having it all in one stream increased the total size of the resulting file. The test went from 416KiB (with perf_cpu event member) to 24MiB due to the required (and pointless) flush. With the per-cpu streams the total size went up to 588KiB. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Link: http://lkml.kernel.org/n/tip-fco07vxi6yx4m9et2aimm...@git.kernel.org Signed-off-by: Jiri Olsa jo...@kernel.org With latest babeltrace.git: [acme@zoo babeltrace]$ git log --oneline | head -1 48d711a204f6 Fix: Missing stdint.h in stream-class.h hum, this is rather old one (Mar 10th), current is: [jolsa@krava babeltrace]$ git show --oneline | head -1 d8f190b24d52 Add tests for bt_ctf_field_string_append_len() 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 v6 1/6] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
From: David A. Long dave.l...@linaro.org
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
Signed-off-by: David A. Long dave.l...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.h | 29 +
arch/arm64/include/uapi/asm/ptrace.h | 36 +++
arch/arm64/kernel/ptrace.c | 116 +++
4 files changed, 182 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e973..987a681 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -65,6 +65,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index d6dd9fd..655620e 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -118,6 +118,8 @@ struct pt_regs {
u64 syscallno;
};
+#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
+
#define arch_has_single_step() (1)
#ifdef CONFIG_COMPAT
@@ -146,11 +148,38 @@ struct pt_regs {
#define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)-sp : (regs)-compat_sp)
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset MAX_REG_OFFSET))
+ return 0;
+ return *(u64 *)((u64)regs + offset);
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs-ARM_sp;
+}
+
static inline unsigned long regs_return_value(struct pt_regs *regs)
{
return regs-regs[0];
}
+extern int regs_query_register_offset(const char *name);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+ unsigned int n);
+
/*
* Are the current registers suitable for user mode? (used to maintain
* security in signal handlers)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h
b/arch/arm64/include/uapi/asm/ptrace.h
index 6913643..58c0223 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -61,6 +61,42 @@
#ifndef __ASSEMBLY__
+#define ARM_pstate pstate
+#define ARM_pc pc
+#define ARM_sp sp
+#define ARM_lr regs[30]
+#define ARM_fp regs[29]
+#define ARM_x28regs[28]
+#define ARM_x27regs[27]
+#define ARM_x26regs[26]
+#define ARM_x25regs[25]
+#define ARM_x24regs[24]
+#define ARM_x23regs[23]
+#define ARM_x22regs[22]
+#define ARM_x21regs[21]
+#define ARM_x20regs[20]
+#define ARM_x19regs[19]
+#define ARM_x18regs[18]
+#define ARM_ip1regs[17]
+#define ARM_ip0regs[16]
+#define ARM_x15regs[15]
+#define ARM_x14regs[14]
+#define ARM_x13regs[13]
+#define ARM_x12regs[12]
+#define ARM_x11regs[11]
+#define ARM_x10regs[10]
+#define ARM_x9 regs[9]
+#define ARM_x8 regs[8]
+#define ARM_x7 regs[7]
+#define ARM_x6 regs[6]
+#define ARM_x5 regs[5]
+#define ARM_x4 regs[4]
+#define ARM_x3 regs[3]
+#define ARM_x2 regs[2]
+#define ARM_x1 regs[1]
+#define ARM_x0 regs[0]
+#define ARM_ORIG_x0orig_x0
+
/*
* User structures for general purpose, floating point and debug registers.
*/
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b83..a889f79 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,122 @@
#define CREATE_TRACE_POINTS
#include trace/events/syscalls.h
+struct pt_regs_offset {
+ const char *name;
+ int offset;
+};
+
+#define REG_OFFSET_NAME(r) \
+ {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+ REG_OFFSET_NAME(x0),
+ REG_OFFSET_NAME(x1),
+ REG_OFFSET_NAME(x2),
+ REG_OFFSET_NAME(x3),
+ REG_OFFSET_NAME(x4),
+ REG_OFFSET_NAME(x5),
+ REG_OFFSET_NAME(x6),
+ REG_OFFSET_NAME(x7),
+ REG_OFFSET_NAME(x8),
+
[PATCH v6 4/6] arm64: kprobes instruction simulation support
From: Sandeepa Prabhu sandeepa.pra...@linaro.org
Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.
Following instruction catagories are simulated:
- All branching instructions(conditional, register, and immediate)
- Literal access instructions(load-literal, adr/adrp)
Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes considers
this case as 'miss'.
Thanks to Will Cohen for assorted suggested changes.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
Signed-off-by: William Cohen wco...@redhat.com
Signed-off-by: David A. Long dave.l...@linaro.org
---
arch/arm64/kernel/Makefile | 4 +-
arch/arm64/kernel/kprobes-arm64.c| 98 +
arch/arm64/kernel/kprobes-arm64.h| 2 +
arch/arm64/kernel/kprobes.c | 35 ++-
arch/arm64/kernel/probes-condn-check.c | 122 ++
arch/arm64/kernel/probes-simulate-insn.c | 174 +++
arch/arm64/kernel/probes-simulate-insn.h | 33 ++
7 files changed, 464 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/kernel/probes-condn-check.c
create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
create mode 100644 arch/arm64/kernel/probes-simulate-insn.h
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 056b1a4..0444e15 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -32,7 +32,9 @@ arm64-obj-$(CONFIG_CPU_PM)+= sleep.o suspend.o
arm64-obj-$(CONFIG_CPU_IDLE) += cpuidle.o
arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
arm64-obj-$(CONFIG_KGDB) += kgdb.o
-arm64-obj-$(CONFIG_KPROBES)+= kprobes.o kprobes-arm64.o
+arm64-obj-$(CONFIG_KPROBES)+= kprobes.o kprobes-arm64.o
\
+ probes-simulate-insn.o
\
+ probes-condn-check.o
arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
arm64-obj-$(CONFIG_PCI)+= pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
diff --git a/arch/arm64/kernel/kprobes-arm64.c
b/arch/arm64/kernel/kprobes-arm64.c
index f958c52..8a7e6b0 100644
--- a/arch/arm64/kernel/kprobes-arm64.c
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -20,6 +20,76 @@
#include asm/insn.h
#include kprobes-arm64.h
+#include probes-simulate-insn.h
+
+/*
+ * condition check functions for kprobes simulation
+ */
+static unsigned long __kprobes
+__check_pstate(struct kprobe *p, struct pt_regs *regs)
+{
+ struct arch_specific_insn *asi = p-ainsn;
+ unsigned long pstate = regs-pstate 0x;
+
+ return asi-pstate_cc(pstate);
+}
+
+static unsigned long __kprobes
+__check_cbz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_cbz((u32)p-opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_cbnz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_cbnz((u32)p-opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_tbz((u32)p-opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbnz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_tbnz((u32)p-opcode, regs);
+}
+
+/*
+ * prepare functions for instruction simulation
+ */
+static void __kprobes
+prepare_none(struct kprobe *p, struct arch_specific_insn *asi)
+{
+}
+
+static void __kprobes
+prepare_bcond(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p-opcode;
+
+ asi-check_condn = __check_pstate;
+ asi-pstate_cc = kprobe_condition_checks[insn 0xf];
+}
+
+static void __kprobes
+prepare_cbz_cbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p-opcode;
+
+ asi-check_condn = (insn (1 24)) ? __check_cbnz : __check_cbz;
+}
+
+static void __kprobes
+prepare_tbz_tbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p-opcode;
+
+ asi-check_condn = (insn (1 24)) ? __check_tbnz : __check_tbz;
+}
static bool __kprobes aarch64_insn_is_steppable(u32 insn)
{
@@ -63,6 +133,34 @@ arm_kprobe_decode_insn(kprobe_opcode_t insn, struct
arch_specific_insn *asi)
*/
if (aarch64_insn_is_steppable(insn))
return INSN_GOOD;
+
+ asi-prepare = prepare_none;
+
+ if (aarch64_insn_is_bcond(insn)) {
+ asi-prepare = prepare_bcond;
+ asi-handler = simulate_b_cond;
+ } else if (aarch64_insn_is_cb(insn)) {
+ asi-prepare = prepare_cbz_cbnz;
+ asi-handler =
[PATCH v6 6/6] kprobes: Add arm64 case in kprobe example module
From: Sandeepa Prabhu sandeepa.pra...@linaro.org Add info prints in sample kprobe handlers for ARM64 Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org --- samples/kprobes/kprobe_example.c | 8 1 file changed, 8 insertions(+) diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c index 366db1a..51d459c 100644 --- a/samples/kprobes/kprobe_example.c +++ b/samples/kprobes/kprobe_example.c @@ -42,6 +42,10 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs) ex1 = 0x%lx\n, p-addr, regs-pc, regs-ex1); #endif +#ifdef CONFIG_ARM64 + pr_info(pre_handler: p-addr = 0x%p, pc = 0x%lx\n, + p-addr, (long)regs-pc); +#endif /* A dump_stack() here will give a stack backtrace */ return 0; @@ -67,6 +71,10 @@ static void handler_post(struct kprobe *p, struct pt_regs *regs, printk(KERN_INFO post_handler: p-addr = 0x%p, ex1 = 0x%lx\n, p-addr, regs-ex1); #endif +#ifdef CONFIG_ARM64 + pr_info(post_handler: p-addr = 0x%p, pc = 0x%lx\n, + p-addr, (long)regs-pc); +#endif } /* -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/6] arm64: Kprobes with single stepping support
From: Sandeepa Prabhu sandeepa.pra...@linaro.org Add support for basic kernel probes(kprobes) and jump probes (jprobes) for ARM64. Kprobes utilizes software breakpoint and single step debug exceptions supported on ARM v8. A software breakpoint is placed at the probe address to trap the kernel execution into the kprobe handler. ARM v8 supports enabling single stepping before the break exception return (ERET), with next PC in exception return address (ELR_EL1). The kprobe handler prepares an executable memory slot for out-of-line execution with a copy of the original instruction being probed, and enables single stepping. The PC is set to the out-of-line slot address before the ERET. With this scheme, the instruction is executed with the exact same register context except for the PC (and DAIF) registers. Debug mask (PSTATE.D) is enabled only when single stepping a recursive kprobe, e.g.: during kprobes reenter so that probed instruction can be single stepped within the kprobe handler -exception- context. The recursion depth of kprobe is always 2, i.e. upon probe re-entry, any further re-entry is prevented by not calling handlers and the case counted as a missed kprobe). Single stepping from the x-o-l slot has a drawback for PC-relative accesses like branching and symbolic literals access as the offset from the new PC (slot address) may not be ensured to fit in the immediate value of the opcode. Such instructions need simulation, so reject probing them. Instructions generating exceptions or cpu mode change are rejected for probing. Instructions using Exclusive Monitor are rejected too. System instructions are mostly enabled for stepping, except MSR/MRS accesses to DAIF flags in PSTATE, which are not safe for probing. Thanks to Steve Capper and Pratyush Anand for several suggested Changes. Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org Signed-off-by: Steve Capper steve.cap...@linaro.org Signed-off-by: David A. Long dave.l...@linaro.org --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/debug-monitors.h | 5 + arch/arm64/include/asm/kprobes.h| 62 arch/arm64/include/asm/probes.h | 50 +++ arch/arm64/include/asm/ptrace.h | 3 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/debug-monitors.c | 35 ++- arch/arm64/kernel/kprobes-arm64.c | 68 arch/arm64/kernel/kprobes-arm64.h | 28 ++ arch/arm64/kernel/kprobes.c | 537 arch/arm64/kernel/kprobes.h | 24 ++ arch/arm64/kernel/vmlinux.lds.S | 1 + arch/arm64/mm/fault.c | 25 ++ 13 files changed, 829 insertions(+), 11 deletions(-) create mode 100644 arch/arm64/include/asm/kprobes.h create mode 100644 arch/arm64/include/asm/probes.h create mode 100644 arch/arm64/kernel/kprobes-arm64.c create mode 100644 arch/arm64/kernel/kprobes-arm64.h create mode 100644 arch/arm64/kernel/kprobes.c create mode 100644 arch/arm64/kernel/kprobes.h diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 987a681..8e06a03 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -68,6 +68,7 @@ config ARM64 select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RCU_TABLE_FREE select HAVE_SYSCALL_TRACEPOINTS + select HAVE_KPROBES select IRQ_DOMAIN select MODULES_USE_ELF_RELA select NO_BOOTMEM diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h index 40ec68a..92d7cea 100644 --- a/arch/arm64/include/asm/debug-monitors.h +++ b/arch/arm64/include/asm/debug-monitors.h @@ -90,6 +90,11 @@ #define CACHE_FLUSH_IS_SAFE1 +/* kprobes BRK opcodes with ESR encoding */ +#define BRK64_ESR_MASK 0x +#define BRK64_ESR_KPROBES 0x0004 +#define BRK64_OPCODE_KPROBES (AARCH64_BREAK_MON | (BRK64_ESR_KPROBES 5)) + /* AArch32 */ #define DBG_ESR_EVT_BKPT 0x4 #define DBG_ESR_EVT_VECC 0x5 diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h new file mode 100644 index 000..af31c4d --- /dev/null +++ b/arch/arm64/include/asm/kprobes.h @@ -0,0 +1,62 @@ +/* + * arch/arm64/include/asm/kprobes.h + * + * Copyright (C) 2013 Linaro Limited + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#ifndef _ARM_KPROBES_H +#define _ARM_KPROBES_H + +#include linux/types.h +#include linux/ptrace.h +#include linux/percpu.h + +#define __ARCH_WANT_KPROBES_INSN_SLOT +#define MAX_INSN_SIZE 1 +#define MAX_STACK_SIZE 128 +
[PATCH v6 2/6] arm64: Add more test functions to insn.c
From: David A. Long dave.l...@linaro.org
Certain instructions are hard to execute correctly out-of-line (as in
kprobes). Test functions are added to insn.[hc] to identify these. The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.
Signed-off-by: David A. Long dave.l...@linaro.org
---
arch/arm64/include/asm/insn.h | 18 ++
arch/arm64/kernel/insn.c | 28
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index d2f4942..0626404 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -223,8 +223,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32
code) \
static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
{ return (val); }
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F00, 0x1000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800)
__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit, 0xBF00, 0x1800)
+__AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
+__AARCH64_INSN_FUNCS(exclusive,0x3F00, 0x0800)
__AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
__AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC0, 0x2980)
@@ -264,19 +269,29 @@ __AARCH64_INSN_FUNCS(ands,0x7F20, 0x6A00)
__AARCH64_INSN_FUNCS(bics, 0x7F20, 0x6A20)
__AARCH64_INSN_FUNCS(b,0xFC00, 0x1400)
__AARCH64_INSN_FUNCS(bl, 0xFC00, 0x9400)
+__AARCH64_INSN_FUNCS(b_bl, 0x7C00, 0x1400)
+__AARCH64_INSN_FUNCS(cb, 0x7E00, 0x3400)
__AARCH64_INSN_FUNCS(cbz, 0x7F00, 0x3400)
__AARCH64_INSN_FUNCS(cbnz, 0x7F00, 0x3500)
+__AARCH64_INSN_FUNCS(tb, 0x7E00, 0x3600)
__AARCH64_INSN_FUNCS(tbz, 0x7F00, 0x3600)
__AARCH64_INSN_FUNCS(tbnz, 0x7F00, 0x3700)
+__AARCH64_INSN_FUNCS(b_bl_cb_tb, 0x5C00, 0x1400)
__AARCH64_INSN_FUNCS(bcond,0xFF10, 0x5400)
__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD401)
__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD402)
__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD403)
__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(exception,0xFF00, 0xD400)
__AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
__AARCH64_INSN_FUNCS(br, 0xFC1F, 0xD61F)
__AARCH64_INSN_FUNCS(blr, 0xFC1F, 0xD63F)
+__AARCH64_INSN_FUNCS(br_blr, 0xFFDFFC1F, 0xD61F)
__AARCH64_INSN_FUNCS(ret, 0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F000, 0xD5004000)
+__AARCH64_INSN_FUNCS(msr_reg, 0xFFF0, 0xD510)
+__AARCH64_INSN_FUNCS(set_clr_daif, 0xF0DF, 0xD50340DF)
+__AARCH64_INSN_FUNCS(rd_wr_daif, 0xFFDFFFE0, 0xD51B4220)
#undef __AARCH64_INSN_FUNCS
@@ -285,6 +300,9 @@ bool aarch64_insn_is_nop(u32 insn);
int aarch64_insn_read(void *addr, u32 *insnp);
int aarch64_insn_write(void *addr, u32 insn);
enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
+bool aarch64_insn_is_daif_access(u32 insn);
u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
u32 insn, u64 imm);
u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index c8eca88..cda1b3b 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -155,6 +155,34 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32
insn)
aarch64_insn_is_nop(insn);
}
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+ /* ldr/ldrsw (literal), prfm */
+
+ return aarch64_insn_is_ldr_lit(insn) ||
+ aarch64_insn_is_ldrsw_lit(insn) ||
+ aarch64_insn_is_adr_adrp(insn) ||
+ aarch64_insn_is_prfm_lit(insn);
+}
+
+bool __kprobes aarch64_insn_is_branch(u32 insn)
+{
+ /* b, bl, cb*, tb*, b.cond, br, blr */
+
+ return aarch64_insn_is_b_bl_cb_tb(insn) ||
+ aarch64_insn_is_br_blr(insn) ||
+ aarch64_insn_is_ret(insn) ||
+ aarch64_insn_is_bcond(insn);
+}
+
+bool __kprobes aarch64_insn_is_daif_access(u32 insn)
+{
+ /* msr daif, mrs daif, msr daifset, msr daifclr */
+
+ return aarch64_insn_is_rd_wr_daif(insn) ||
+ aarch64_insn_is_set_clr_daif(insn);
+}
+
/*
* ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
* Section B2.6.5 Concurrent modification and execution of instructions:
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH] kernel/resource: Invalid memory access in __release_resource
Hi Bjorn!
Thanks for your promtly response.
On Mon, Apr 20, 2015 at 9:28 PM, Bjorn Helgaas bhelg...@google.com wrote:
[+cc Grant (author of ac80a51e2ce5)]
Hi Ricardo,
On Mon, Apr 20, 2015 at 06:22:52PM +0200, Ricardo Ribalda Delgado wrote:
If of_platform_depopulate is called later, resource-parent is
accessed (Offset 0x30 of address 0), causing a kernel error.
Interesting; how'd you find this? It looks like the
of_platform_depopulate() code has been this way for a long time, so we
must be doing something new that makes us trip over this now. More
analysis below...
I have an out of tree driver that dynamically adds devices to the device tree.
It was developed before the dynamic_of and dt_overlays existed. Now I
am porting my code to the new interfaces available. I am trying to do
it small steps.
First step was being able to depopulate a previously loaded device
tree. Old, code was calling of_platform_populate, so calling
of_platform_depopulate looked like the right choice. Unfortunately
everything crashed, and it turned out that this was the issue.
On my defense I would say, that the plan is to make this driver
public, once the hardware is stabilized and sold to the public.
@@ -237,6 +237,9 @@ static int __release_resource(struct resource *old)
{
struct resource *tmp, **p;
+ if (!old-parent)
+ return -EINVAL;
This path has been fine for a long time without testing for a NULL
pointer, so I suspect this change papers over an issue that would be
better fixed elsewhere.
This code is pretty tested, but dynamic remove is not.
From reading drivers/base/platform.c, it looks like the intent is
that platform device users would use these interfaces:
I can take a look to modify OF to use insert_resource(), but I still
think that no matter what, we should add this extra check, like the
propossed patch or maybe with a BUG_ON()
Lets see what Grant thinks about this.
Thanks again!
--
Ricardo Ribalda
--
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] locking/rwsem: reduce spinlock contention in wakeup after up_read/up_write
On Fri, 2015-04-17 at 22:03 -0400, Waiman Long wrote:
diff --git a/include/linux/osq_lock.h b/include/linux/osq_lock.h
index 3a6490e..703ea5c 100644
--- a/include/linux/osq_lock.h
+++ b/include/linux/osq_lock.h
@@ -32,4 +32,9 @@ static inline void osq_lock_init(struct
optimistic_spin_queue *lock)
extern bool osq_lock(struct optimistic_spin_queue *lock);
extern void osq_unlock(struct optimistic_spin_queue *lock);
+static inline bool osq_is_locked(struct optimistic_spin_queue *lock)
+{
+ return atomic_read(lock-tail) != OSQ_UNLOCKED_VAL;
+}
Would it be better to separate the addition of osq_is_locked() into its
own patch, since this can be useful for other situations and isn't just
specific to the rwsem optimization.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: use -mskip-rax-setup when available
On Mon, Apr 20 2015, Borislav Petkov b...@alien8.de wrote: On Mon, Apr 20, 2015 at 02:28:16PM +0200, Rasmus Villemoes wrote: Nothing seems to have happened on the kernel side since H.J. Lu implemented this in December. Since gcc 5 is officially released I see the same patch from him from Apr. 16th: https://lkml.kernel.org/r/came9rorfdo3mgaqc_s5crw3tryhs8ntqeyrcufia0yav8e9...@mail.gmail.com Why are you sending it too? Hadn't seen that, so I wrongly assumed everybody had forgotten about it. I don't care about the S-o-b on the trivial Makefile patch, but my request for a feature-suggested-by or similar still stands. Rasmus -- 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 v6 5/6] arm64: Add kernel return probes support (kretprobes)
From: Sandeepa Prabhu sandeepa.pra...@linaro.org
AArch64 ISA does not have instructions to pop the PC register
value from the stack(like ARM v7 has ldmia {...,pc}) without using
one of the general purpose registers. This means return probes
cannot return to the actual return address directly without
modifying register context, and without trapping into debug exception.
So, like many other architectures, we prepare a global routine
with NOPs which serve as a trampoline to hack away the
function return address by placing an extra kprobe on the
trampoline entry.
The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
Signed-off-by: David A. Long dave.l...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kprobes.h | 1 +
arch/arm64/kernel/kprobes.c | 112 ++-
3 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8e06a03..84f3c9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -69,6 +69,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
+ select HAVE_KRETPROBES if HAVE_KPROBES
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index af31c4d..d081f49 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -58,5 +58,6 @@ int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+void kretprobe_trampoline(void);
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 6255814..2b3ef17 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -560,7 +560,117 @@ int __kprobes longjmp_break_handler(struct kprobe *p,
struct pt_regs *regs)
return 0;
}
+/*
+ * Kretprobes: kernel return probes handling
+ *
+ * AArch64 mode does not support popping the PC value from the
+ * stack like on ARM 32-bit (ldmia {..,pc}), so atleast one
+ * register need to be used to achieve branching/return.
+ * It means return probes cannot return back to the original
+ * return address directly without modifying the register context.
+ *
+ * So like other architectures, we prepare a global routine
+ * with NOPs, which serve as trampoline address that hack away the
+ * function return, with the exact register context.
+ * Placing a kprobe on trampoline routine entry will trap again to
+ * execute return probe handlers and restore original return address
+ * in ELR_EL1, this way saved pt_regs still hold the original
+ * register values to be carried back to the caller.
+ */
+static void __used kretprobe_trampoline_holder(void)
+{
+ asm volatile (.global kretprobe_trampoline\n
+ kretprobe_trampoline:\n
+ NOP\n\t
+ NOP\n\t);
+}
+
+static int __kprobes
+trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kretprobe_instance *ri = NULL;
+ struct hlist_head *head, empty_rp;
+ struct hlist_node *tmp;
+ unsigned long flags, orig_ret_addr = 0;
+ unsigned long trampoline_address =
+ (unsigned long)kretprobe_trampoline;
+
+ INIT_HLIST_HEAD(empty_rp);
+ kretprobe_hash_lock(current, head, flags);
+
+ /*
+* It is possible to have multiple instances associated with a given
+* task either because multiple functions in the call path have
+* a return probe installed on them, and/or more than one return
+* probe was registered for a target function.
+*
+* We can handle this because:
+* - instances are always inserted at the head of the list
+* - when multiple return probes are registered for the same
+* function, the first instance's ret_addr will point to the
+* real return address, and all the rest will point to
+* kretprobe_trampoline
+*/
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri-task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ if (ri-rp ri-rp-handler) {
+ __this_cpu_write(current_kprobe, ri-rp-kp);
+ get_kprobe_ctlblk()-kprobe_status = KPROBE_HIT_ACTIVE;
+ ri-rp-handler(ri, regs);
Re: [GIT PULL] kdbus for 4.1-rc1
It's used everywhere, on servers, embedded systems, desktops, you name it. All languages have bindings for it, and it's the underpinning of a modern Linux stack. Since when? D-bus is some GUI depoendency. On my console-only servers, it's not needed, and not installed: # dpkg-query -s libdbus-1-3 dbus dpkg-query: package 'libdbus-1-3' is not installed and no information is available dpkg-query: package 'dbus' is not installed and no information is available # dpkg-query -l \*dbus\* dpkg-query: no packages found matching *dbus* It's also not needed on a basic GUI system. Firefox complains about saving preferences if it's not running, but runs just fine: $ pgrep dbus $ ps 6570 19644 25779 29487 29492 PID TTY STAT TIME COMMAND 6570 ?Sl 1:48 iceweasel 19644 ?Sl 0:29 /usr/bin/vlc -I qt4 25779 ?Sl 0:16 rhythmbox 29487 ?Sl 0:00 /usr/bin/gnumeric 29492 ?Sl 0:01 /usr/bin/gimp $ Richard Weinberger wrote: kdbus will be a major hard-dependency for every non-trivial userland. Like cgroups... and We're all forced to use cgroups, systemd, udev unless we want to have busybox as userland. That's a fact. My daily desktop also has # CONFIG_CGROUPS is not set And no systemd. Udev actually does something useful, so I have it on my desktop, but I have machines with a static /dev instead. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] First batch of KVM changes for 4.1
On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini pbonz...@redhat.com wrote: On 17/04/2015 22:18, Marcelo Tosatti wrote: The bug which this is fixing is very rare, have no memory of a report. In fact, its even difficult to create a synthetic reproducer. But then why was the task migration notifier even in Jeremy's original code for Xen? Was it supposed to work even on non-synchronized TSC? If that's the case, then it could be reverted indeed; but then why did you commit this patch to 4.1? Did you think of something that would cause the seqcount-like protocol to fail, and that turned out not to be the case later? I was only following the mailing list sparsely in March. I don't think anyone ever tried that hard to test this stuff. There was an infinte loop that Firefox was triggering as a KVM guest somewhat reliably until a couple months ago in the same vdso code. :( --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: socfpga: dts: Add multicast bins and unicast filter entries
Add multicast-filter-bins and perfect-filter-entries configuration properties to the socfpga devicetree for the Arria 10 socfpga. Signed-off-by: Vince Bridgers vbrid...@opensource.altera.com --- This patch is based on patches http://www.spinics.net/lists/devicetree/msg75270.html http://www.spinics.net/lists/devicetree/msg75273.html --- arch/arm/boot/dts/socfpga_arria10.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi index e121661..d2ef52b 100644 --- a/arch/arm/boot/dts/socfpga_arria10.dtsi +++ b/arch/arm/boot/dts/socfpga_arria10.dtsi @@ -395,6 +395,8 @@ interrupt-names = macirq; /* Filled in by bootloader */ mac-address = [00 00 00 00 00 00]; + snps,multicast-filter-bins = 256; + snps,perfect-filter-entries = 128; clocks = l4_mp_clk; clock-names = stmmaceth; status = disabled; @@ -408,6 +410,8 @@ interrupt-names = macirq; /* Filled in by bootloader */ mac-address = [00 00 00 00 00 00]; + snps,multicast-filter-bins = 256; + snps,perfect-filter-entries = 128; status = disabled; }; @@ -419,6 +423,8 @@ interrupt-names = macirq; /* Filled in by bootloader */ mac-address = [00 00 00 00 00 00]; + snps,multicast-filter-bins = 256; + snps,perfect-filter-entries = 128; status = disabled; }; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: socfpga: dts: Add tx-fifo-depth and rx-fifo-depth properties
Add tx-fifo-depth and rx-fifo-depth devicetree properties for socfpga stmmac. These devicetree properties will be used to configure certain features of the stmmac on the socfpga. Signed-off-by: Vince Bridgers vbrid...@opensource.altera.com --- This patch is based on patches http://www.spinics.net/lists/devicetree/msg75270.html http://www.spinics.net/lists/devicetree/msg75273.html --- arch/arm/boot/dts/socfpga.dtsi | 4 arch/arm/boot/dts/socfpga_arria10.dtsi | 6 ++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi index d9176e6..4721a9d 100644 --- a/arch/arm/boot/dts/socfpga.dtsi +++ b/arch/arm/boot/dts/socfpga.dtsi @@ -488,6 +488,8 @@ reset-names = stmmaceth; snps,multicast-filter-bins = 256; snps,perfect-filter-entries = 128; + tx-fifo-depth = 4096; + rx-fifo-depth = 4096; status = disabled; }; @@ -504,6 +506,8 @@ reset-names = stmmaceth; snps,multicast-filter-bins = 256; snps,perfect-filter-entries = 128; + tx-fifo-depth = 4096; + rx-fifo-depth = 4096; status = disabled; }; diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi index d2ef52b..9c6dcff 100644 --- a/arch/arm/boot/dts/socfpga_arria10.dtsi +++ b/arch/arm/boot/dts/socfpga_arria10.dtsi @@ -397,6 +397,8 @@ mac-address = [00 00 00 00 00 00]; snps,multicast-filter-bins = 256; snps,perfect-filter-entries = 128; + tx-fifo-depth = 4096; + rx-fifo-depth = 16384; clocks = l4_mp_clk; clock-names = stmmaceth; status = disabled; @@ -412,6 +414,8 @@ mac-address = [00 00 00 00 00 00]; snps,multicast-filter-bins = 256; snps,perfect-filter-entries = 128; + tx-fifo-depth = 4096; + rx-fifo-depth = 16384; status = disabled; }; @@ -425,6 +429,8 @@ mac-address = [00 00 00 00 00 00]; snps,multicast-filter-bins = 256; snps,perfect-filter-entries = 128; + tx-fifo-depth = 4096; + rx-fifo-depth = 16384; status = disabled; }; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio:st_sensors: Fix oops when probing SPI devices
In SPI mode the transfer buffer is locked with a mutex. However this mutex is only initilized after the probe, but some transfer needs to be done in the probe. To fix this bug we move the mutex initialization at the beginning of the device probe. Signed-off-by: Alban Bedel alban.be...@avionic-design.de --- drivers/iio/accel/st_accel_core.c | 1 + drivers/iio/common/st_sensors/st_sensors_core.c | 2 -- drivers/iio/gyro/st_gyro_core.c | 1 + drivers/iio/magnetometer/st_magn_core.c | 1 + drivers/iio/pressure/st_pressure_core.c | 1 + 5 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/accel/st_accel_core.c b/drivers/iio/accel/st_accel_core.c index 58d1d13..211b132 100644 --- a/drivers/iio/accel/st_accel_core.c +++ b/drivers/iio/accel/st_accel_core.c @@ -546,6 +546,7 @@ int st_accel_common_probe(struct iio_dev *indio_dev) indio_dev-modes = INDIO_DIRECT_MODE; indio_dev-info = accel_info; + mutex_init(adata-tb.buf_lock); st_sensors_power_enable(indio_dev); diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c b/drivers/iio/common/st_sensors/st_sensors_core.c index edd13d2..8dd0477 100644 --- a/drivers/iio/common/st_sensors/st_sensors_core.c +++ b/drivers/iio/common/st_sensors/st_sensors_core.c @@ -304,8 +304,6 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev, struct st_sensors_platform_data *of_pdata; int err = 0; - mutex_init(sdata-tb.buf_lock); - /* If OF/DT pdata exists, it will take precedence of anything else */ of_pdata = st_sensors_of_probe(indio_dev-dev.parent, pdata); if (of_pdata) diff --git a/drivers/iio/gyro/st_gyro_core.c b/drivers/iio/gyro/st_gyro_core.c index 21395f2..ffe9664 100644 --- a/drivers/iio/gyro/st_gyro_core.c +++ b/drivers/iio/gyro/st_gyro_core.c @@ -400,6 +400,7 @@ int st_gyro_common_probe(struct iio_dev *indio_dev) indio_dev-modes = INDIO_DIRECT_MODE; indio_dev-info = gyro_info; + mutex_init(gdata-tb.buf_lock); st_sensors_power_enable(indio_dev); diff --git a/drivers/iio/magnetometer/st_magn_core.c b/drivers/iio/magnetometer/st_magn_core.c index 8ade473..2e56f81 100644 --- a/drivers/iio/magnetometer/st_magn_core.c +++ b/drivers/iio/magnetometer/st_magn_core.c @@ -369,6 +369,7 @@ int st_magn_common_probe(struct iio_dev *indio_dev) indio_dev-modes = INDIO_DIRECT_MODE; indio_dev-info = magn_info; + mutex_init(mdata-tb.buf_lock); st_sensors_power_enable(indio_dev); diff --git a/drivers/iio/pressure/st_pressure_core.c b/drivers/iio/pressure/st_pressure_core.c index 97baf40d..e881fa6 100644 --- a/drivers/iio/pressure/st_pressure_core.c +++ b/drivers/iio/pressure/st_pressure_core.c @@ -417,6 +417,7 @@ int st_press_common_probe(struct iio_dev *indio_dev) indio_dev-modes = INDIO_DIRECT_MODE; indio_dev-info = press_info; + mutex_init(press_data-tb.buf_lock); st_sensors_power_enable(indio_dev); -- 2.3.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 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers
On Sat, Apr 18, 2015 at 01:07:07PM -0700, Kevin Cernekee wrote: On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown broo...@kernel.org wrote: Someone trying to use the atmel_wm8904 driver with something other than a wm8904 shouldn't really be expecting a good experince... The same check shows up in numerous other drivers, including the one for the audio controller on my board. Sounds like either that (undisclosed) driver has a problem or you're using it inappropriately. Is there a stub version that I can use instead? Nothing jumped out at me when looking at the other codec drivers. No, such a stub would make no sense - why would we put a stub in all the drivers rather than just making the core do the right thing? AFAICT, implementing the set_sysclk callback is mandatory, even if it is a no-op on the codec side. If I delete the stub function, audio playback fails. For the reasons I mentioned above having a set_sysclk() function is not mandatory and your driver will not be merged with a stub such as is currently present. As far as I can tell you are trying to bodge around some problem elsewhere in either the code or your usage of it. Clearing just the LSB would accomplish the same thing, but would be less obvious IMO. It would also require an extra read, and the code is less concise. I don't think anyone is going to care about an extra read on system init, and in any case if the driver followed best practice and provided register defaults that read would be satisfied from cache. signature.asc Description: Digital signature
Re: [GIT PULL] kdbus for 4.1-rc1
On Fri 17-04-15 11:54:42, Andy Lutomirski wrote: On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko mho...@suse.cz wrote: On Thu 16-04-15 10:04:17, Andy Lutomirski wrote: On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski l...@amacapital.net wrote: Whose memcg does the pool use? The pool-owner's (i.e., the receiver's). If it's the receiver's, and if the receiver can configure a memcg, then it seems that even a single receiver could probably cause the sender to block for an unlimited amount of time. How? Which of those calls can block? I don't see how that can happen. I admit I don't fully understand memcg, but vfs_iter_write is presumably going to need to get write access to the target pool page, and that, in turn, will need that page to exist in memory and to be writable, which may need to page it in and/or allocate a page. If that uses the receiver's memcg (as it should), then the receiver can make it block. Even if it doesn't use the receiver's memcg, it can trigger direct reclaim, I think. Yes, memcg direct reclaim might trigger but we are no longer waiting for the OOM victim from non page fault paths so the time is bounded. It still might a quite some time, though, depending on the amount of work done in the direct reclaim. Is that still true if OOM notifiers are involved? I've lost track of what changed there. memcg OOM is not triggered from get_user_pages. See 519e52473ebe (mm: memcg: enable memcg OOM killer only for user faults) Any any event, I'm not entirely convinced that having a broadcast send cause, say, PID 1 to block until an unbounded number of pages in a potentially unbounded number of memcgs are reclaimed is a good idea. This deserves a clarification I guess. It is the memcg of the current task which gets charged during the page fault normally. So if PID1 tries to fault the memory in it will be its (most probably root) memcg which gets charged. If the memory was already charged to a different task's memcg and then it got swapped out, though, the PID1 would indeed wait for the reclaim in the target memcg to swap the page back in. In either case this sounds like a potential problem, because tasks could hide their memory charges from the limit or PID1 context could be blocked. But maybe I just misunderstood the and an uncharged memory cannot be used for the buffer. In the kdbus model's favor, I think that allowing pages of data in the receive queue to be swapped out is potentially quite nice, but I'm less convinced about non-full pages in the receive queue. There's a resource management tradeoff here, and one nice thing about AF_UNIX is that sends are genuinely non-blocking. --Andy -- Michal Hocko 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 v2] perf tools: Document --children option in more detail
As the --children option changes the output of perf report (and perf
top) it sometimes confuses users. Add more words and examples to help
understanding of the option's behavior - and how to disable it ;-).
Cc: Taeung Song treeze.tae...@gmail.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/Documentation/overhead.txt| 96
tools/perf/Documentation/perf-report.txt | 4 ++
tools/perf/Documentation/perf-top.txt| 3 +-
3 files changed, 102 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/Documentation/overhead.txt
diff --git a/tools/perf/Documentation/overhead.txt
b/tools/perf/Documentation/overhead.txt
new file mode 100644
index ..a7d624229087
--- /dev/null
+++ b/tools/perf/Documentation/overhead.txt
@@ -0,0 +1,96 @@
+Overhead calculation
+
+The overhead can be shown in two columns as 'Children' and 'Self' when
+perf collects callchains. The self overhead is simply calculated by
+adding all period values of the entry - usually a function (symbol).
+This is the value that perf shows traditionally and sum of the all
+self overhead should be 100%.
+
+The children overhead is calculated by adding all period values of the
+child functions so that it can show the total overhead of the higher
+level functions. The children here means that functions called from
+another function.
+
+It might be confusing that the sum of the all children overhead
+exceeds 100% since each of them is already an accumulation of (self)
+overhead of its children. But with this enabled, users can find which
+function has the most overhead even if samples are spread over the
+children.
+
+Consider the following example; there’re three functions like below.
+
+---
+void foo(void) {
+/* something */
+}
+
+bar(void) {
+/* do something */
+foo();
+}
+
+int main(void) {
+bar()
+return 0;
+}
+---
+
+In this case 'foo' is a child of 'bar', and 'bar' is an immediate
+child of 'main' so 'foo' also is a child of 'main'. In other words,
+'main' is a parent of 'foo' and 'bar'. and 'bar' is a parent of 'foo'.
+
+Suppose all samples are recorded in the 'foo' and 'bar' only. When
+you record with callchain you'll see something like below in the usual
+(self-overhead-only) output of the perf report:
+
+--
+Overhead Symbol
+ .
+ 60.00% foo
+ |
+ --- foo
+ bar
+ main
+ __libc_start_main
+
+ 40.00% bar
+ |
+ --- bar
+ main
+ __libc_start_main
+--
+
+When --children option is enabled, the (self) overhead of children (in
+this case foo and bar) are added to the parent to calculate the
+children overhead. In this case the report could be displayed as:
+
+---
+Children Self Symbol
+
+ 100.00% 0.00% __libc_start_main
+ |
+ --- __libc_start_main
+
+ 100.00% 0.00% main
+ |
+ --- main
+ __libc_start_main
+
+ 100.00%40.00% bar
+ |
+ --- bar
+ main
+ __libc_start_main
+
+ 60.00%60.00% foo
+ |
+ --- foo
+ bar
+ main
+ __libc_start_main
+---
+
+Since v3.16 the children overhead is shown by default and the output
+is sorted by the values. Children overhead is disabled by specifying
+--no-children option on the command line or by adding 'report.children
+= false' or 'top.children = false' in the perfconfig file.
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 4879cf638824..bd97e5c3c9b6 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -193,6 +193,7 @@ OPTIONS
Accumulate callchain of children to parent entry so that then can
show up in the output. The output will have a new Children column
and will be sorted on the data. It requires callchains are recorded.
+ See `overhead calculation' section for more details.
--max-stack::
Set the stack depth limit when parsing the callchain, anything
@@ -323,6 +324,9 @@ OPTIONS
--header-only::
Show only perf.data header (forces --stdio).
+
+include::overhead.txt[]
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 3265b1070518..526d6bebec1f 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -168,7 +168,7 @@ Default is to monitor all CPUS.
Accumulate callchain of children to parent entry so that then can
show up in the output. The output
[PATCH 0/3] regulator: max8973: cleanups and add DT parsing for platform data
Remove redundant variables for dvs gpio validity, handle unset/default dvs gpio and add DT parsing for platform data. Laxman Dewangan (3): regulator: max8973: get rid of extra variable for gpio validity regulator: max8973: make default/unset dvs gpio as invalid gpio regulator: max8973: add DT parsing of platform specific parameter .../bindings/regulator/max8973-regulator.txt | 14 drivers/regulator/max8973-regulator.c | 93 -- 2 files changed, 81 insertions(+), 26 deletions(-) -- 1.8.1.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/3] regulator: max8973: get rid of extra variable for gpio validity
To find that dvs-gpio is valid or not, gpio API gpio_is_valid()
can be directly used instead of intermediate variable.
Removing the extra variable and using the gpio_is_valid().
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
This is same as earlier patch. Making this as part of this series.
drivers/regulator/max8973-regulator.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/max8973-regulator.c
b/drivers/regulator/max8973-regulator.c
index c3d55c2..1890808 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -100,7 +100,6 @@ struct max8973_chip {
int curr_vout_val[MAX8973_MAX_VOUT_REG];
int curr_vout_reg;
int curr_gpio_val;
- bool valid_dvs_gpio;
struct regulator_ops ops;
};
@@ -174,7 +173,7 @@ static int max8973_dcdc_set_voltage_sel(struct
regulator_dev *rdev,
* If gpios are available to select the VOUT register then least
* recently used register for new configuration.
*/
- if (max-valid_dvs_gpio)
+ if (gpio_is_valid(max-dvs_gpio))
found = find_voltage_set_register(max, vsel,
vout_reg, gpio_val);
@@ -191,7 +190,7 @@ static int max8973_dcdc_set_voltage_sel(struct
regulator_dev *rdev,
}
/* Select proper VOUT register vio gpios */
- if (max-valid_dvs_gpio) {
+ if (gpio_is_valid(max-dvs_gpio)) {
gpio_set_value_cansleep(max-dvs_gpio, gpio_val 0x1);
max-curr_gpio_val = gpio_val;
}
@@ -434,7 +433,6 @@ static int max8973_probe(struct i2c_client *client,
max-dvs_gpio, ret);
return ret;
}
- max-valid_dvs_gpio = true;
/*
* Initialize the lru index with vout_reg id
@@ -444,8 +442,6 @@ static int max8973_probe(struct i2c_client *client,
max-lru_index[i] = i;
max-lru_index[0] = max-curr_vout_reg;
max-lru_index[max-curr_vout_reg] = 0;
- } else {
- max-valid_dvs_gpio = false;
}
if (pdata) {
--
1.8.1.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 4/7] perf tools: Move init_have_children field to struct hist_entry_tui
The init_have_children is used to init callchain info only for TUI. So
it'd be better to move it to the hist_entry_tui struct.
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/browsers/hists.c | 4 ++--
tools/perf/util/sort.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8b8a647be999..8f303eb5044d 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -275,10 +275,10 @@ static void callchain__init_have_children(struct rb_root
*root)
static void hist_entry__init_have_children(struct hist_entry *he)
{
- if (!he-init_have_children) {
+ if (!he-tui.init_have_children) {
he-ms.has_children = !RB_EMPTY_ROOT(he-sorted_chain);
callchain__init_have_children(he-sorted_chain);
- he-init_have_children = true;
+ he-tui.init_have_children = true;
}
}
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index c4598984e366..6057d8aaf19e 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -73,6 +73,7 @@ struct hist_entry_diff {
struct hist_entry_tui {
u16 row_offset;
u16 nr_rows;
+ boolinit_have_children;
};
/**
@@ -101,7 +102,6 @@ struct hist_entry {
/* We are added by hists__add_dummy_entry. */
booldummy;
- boolinit_have_children;
charlevel;
u8 filtered;
union {
--
2.3.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 2/7] perf diff: Make hist_entry_diff fields union
The period_ratio_delta, period_ratio and wdiff are never by used at the
same time. Instead, Just one of them is accessed according to a
comparison method. So make it union to reduce memory footprint.
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/util/sort.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index af192f172fa2..de3303fe726d 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -58,15 +58,16 @@ struct he_stat {
struct hist_entry_diff {
boolcomputed;
+ union {
+ /* PERF_HPP__DELTA */
+ double period_ratio_delta;
- /* PERF_HPP__DELTA */
- double period_ratio_delta;
-
- /* PERF_HPP__RATIO */
- double period_ratio;
+ /* PERF_HPP__RATIO */
+ double period_ratio;
- /* HISTC_WEIGHTED_DIFF */
- s64 wdiff;
+ /* HISTC_WEIGHTED_DIFF */
+ s64 wdiff;
+ };
};
/**
--
2.3.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 07/11] powerpc/8xx: macro for handling CPU15 errata
From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ + +#ifdef CONFIG_8xx_CPU15 +#define DO_8xx_CPU15(tmp, addr) \ + additmp, addr, PAGE_SIZE; \ + tlbie tmp;\ + additmp, addr, PAGE_SIZE; \ + tlbie tmp +#else +#define DO_8xx_CPU15(tmp, addr) +#endif I'm sure I've spotted the same obvious error in the above before. I'd also suggest calling it 'invalidate_adjacent_pages' - since that it what it does. I also guess that the execution time of 'tlbie' is non-trivial. So you might as well get rid of the temporary register and put an 'addi' to reset 'addr' at the end. David
Re: [PATCH 01/16] printk: guard the amount written per line by devkmsg_read()
On Thu 2015-04-16 19:03:38, Tejun Heo wrote:
devkmsg_read() uses 8k buffer and assumes that the formatted output
message won't overrun which seems safe given LOG_LINE_MAX, the current
use of dict and the escaping method being used; however, we're
planning to use devkmsg formatting wider and accounting for the buffer
size properly isn't that complicated.
This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates
devkmsg_read() so that it limits output accordingly.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Petr Mladek pmla...@suse.cz
It is just a refactoring and does not modify the current behavior.
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla...@suse.cz
---
include/linux/printk.h | 2 ++
kernel/printk/printk.c | 35 +++
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9b30871..58b1fec 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -30,6 +30,8 @@ static inline const char *printk_skip_level(const char
*buffer)
return buffer;
}
+#define CONSOLE_EXT_LOG_MAX 8192
If you do a respin from some reason. I would suggest to remove
CONSOLE_ because it is used also for devkmsg.
Best Regards,
Petr
+
/* printk's without a loglevel use this.. */
#define MESSAGE_LOGLEVEL_DEFAULT CONFIG_MESSAGE_LOGLEVEL_DEFAULT
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 879edfc..b6e24af 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -512,7 +512,7 @@ struct devkmsg_user {
u32 idx;
enum log_flags prev;
struct mutex lock;
- char buf[8192];
+ char buf[CONSOLE_EXT_LOG_MAX];
};
static ssize_t devkmsg_write(struct kiocb *iocb, struct iov_iter *from)
@@ -565,11 +565,18 @@ static ssize_t devkmsg_write(struct kiocb *iocb, struct
iov_iter *from)
return ret;
}
+static void append_char(char **pp, char *e, char c)
+{
+ if (*pp e)
+ *(*pp)++ = c;
+}
+
static ssize_t devkmsg_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
struct devkmsg_user *user = file-private_data;
struct printk_log *msg;
+ char *p, *e;
u64 ts_usec;
size_t i;
char cont = '-';
@@ -579,6 +586,9 @@ static ssize_t devkmsg_read(struct file *file, char
__user *buf,
if (!user)
return -EBADF;
+ p = user-buf;
+ e = user-buf + sizeof(user-buf);
+
ret = mutex_lock_interruptible(user-lock);
if (ret)
return ret;
@@ -625,9 +635,9 @@ static ssize_t devkmsg_read(struct file *file, char
__user *buf,
((user-prev LOG_CONT) !(msg-flags LOG_PREFIX)))
cont = '+';
- len = sprintf(user-buf, %u,%llu,%llu,%c;,
- (msg-facility 3) | msg-level,
- user-seq, ts_usec, cont);
+ p += scnprintf(p, e - p, %u,%llu,%llu,%c;,
+(msg-facility 3) | msg-level,
+user-seq, ts_usec, cont);
user-prev = msg-flags;
/* escape non-printable characters */
@@ -635,11 +645,11 @@ static ssize_t devkmsg_read(struct file *file, char
__user *buf,
unsigned char c = log_text(msg)[i];
if (c ' ' || c = 127 || c == '\\')
- len += sprintf(user-buf + len, \\x%02x, c);
+ p += scnprintf(p, e - p, \\x%02x, c);
else
- user-buf[len++] = c;
+ append_char(p, e, c);
}
- user-buf[len++] = '\n';
+ append_char(p, e, '\n');
if (msg-dict_len) {
bool line = true;
@@ -648,30 +658,31 @@ static ssize_t devkmsg_read(struct file *file, char
__user *buf,
unsigned char c = log_dict(msg)[i];
if (line) {
- user-buf[len++] = ' ';
+ append_char(p, e, ' ');
line = false;
}
if (c == '\0') {
- user-buf[len++] = '\n';
+ append_char(p, e, '\n');
line = true;
continue;
}
if (c ' ' || c = 127 || c == '\\') {
- len += sprintf(user-buf + len, \\x%02x, c);
+ p += scnprintf(p, e - p, \\x%02x, c);
continue;
}
- user-buf[len++] = c;
+ append_char(p, e, c);
}
- user-buf[len++] = '\n';
+ append_char(p, e, '\n');
}
user-idx = log_next(user-idx);
user-seq++;
raw_spin_unlock_irq(logbuf_lock);
+ len = p -
Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)
On Mon, Apr 20, 2015 at 07:39:55AM +0200, Ingo Molnar wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sun, Apr 19, 2015 at 11:01 AM, Ingo Molnar mi...@kernel.org wrote:
That's all fine and good, but why is an IPI sent to a non-existent
CPU? It's not like we don't know which CPU is up and down.
I agree that the qemu-arm behavior smells like a bug, plain and
simple. Nobody sane should send random IPI's to CPU's that they
don't even know are up or not.
Yeah, and a warning would have caught that bug a bit earlier, at the
cost of restricting the API:
That said, I could imagine that we would have some valid case where
we just do a cross-cpu call to (for example) do lock wakeup, and the
code would use some optimistic algorithm that prods the CPU after
the lock has been released, and there could be some random race
where the lock data structure has already been released (ie imagine
the kind of optimistic unlocked racy access to sem-owner that we
discussed as part of the rwsem_spin_on_owner() thread recently).
So I _could_ imagine that somebody would want to do optimistic prod
other cpu calls that in all normal cases are for existing cpus, but
could be racy in theory.
Yes, and I don't disagree with such optimizations in principle (it
allows less references to be taken in the fast path), but is it really
safe?
If a CPU is going down and we potentially race against that, and send
off an IPI, the IPI might be 'in flight' for an indeterminate amount
of time, especially on wildly non-deterministic hardware like virtual
platforms.
So if the CPU goes down during that time, the typical way a CPU goes
down is that it ignores all IPIs that arrive after that. End result:
the sender of the IPI may hang indefinitely (for the synchronous API),
waiting for the CSD lock to be released...
For the non-wait API we could also hang, but in an even more
interesting way: we won't hang trying to send to the downed CPU, we'd
hang on the _next_ cross-call call, possibly sending to another CPU,
because the CSD_FLAG_LOCK of the sender CPU is never released by the
offlined CPU which was supposed to unlock it.
Also note the existing warning we already have in
flush_smp_call_function_queue():
/* There shouldn't be any pending callbacks on an offline CPU. */
if (unlikely(warn_cpu_offline !cpu_online(smp_processor_id())
!warned !llist_empty(head))) {
warned = true;
WARN(1, IPI on offline CPU %d\n, smp_processor_id());
Couldn't this trigger in the opportunistic, imprecise IPI case, if
IRQs are ever enabled when or after the CPU is marked offline?
My suggested warning would simply catch this kind of unsafe looking
race a bit sooner, instead of silently ignoring the cross-call
attempt.
Now your suggestion could be made to work by:
- polling for CPU status in the CSD-lock code as well. (We don't do
this currently.)
- making sure that if a late IPI arrives to an already-down CPU it
does not attempt to execute CSD functions. (I.e. silence the
above, already existing warning.)
- auditing the CPU-down path to make sure it does not get surprised
by late external IPIs. (I think this should already be so, given
the existing warning.)
- IPIs can be pending indefinitely, so make sure a pending IPI won't
confuse the machinery after a CPU has been onlined again.
- pending IPIs may consume hardware resources when not received
properly. For example I think x86 will keep trying to resend it.
Not sure there's any timeout mechanism on the hardware level - the
sending APIC might even get stuck? Audit all hardware for this
kind of possibility.
So unless I'm missing something, to me it looks like that the current
code is only safe to be used on offline CPUs if the 'offline' CPU is
never ever brought online in the first place.
It doesn't sound like the qemu-arm case is that kind of situation,
though. That one just sounds like a stupid let's send an ipi to a
cpu whether it exists or not.
But Icommitted it without any new warning, because I could in theory
see it as being a valid use.
So my point is that we already have a 'late' warning, and I think it
actively hid the qemu-arm bug, because the 'offline' CPU was so
offline (due to being non-existent) that it never had a chance to
print a warning.
With an 'early' warning we could flush out such bugs (or code
uncleanlinesses: clearly the ARM code was at least functional before)
a bit sooner.
But I don't have strong feelings about it, SMP cross-call users are a
lot less frequent than say locking facility users, so the strength of
debugging isn't nearly as important and it's fine to me either way!
In the long term, support of send an IPI to a CPU that might or might
not be leaving will
LTP] [ANNOUNCE] The Linux Test Project has been released for APRIL 2015
Good news everyone, the Linux Test Project test suite stable release for *April 2015* has been released. Since the last release 183 patches by 23 authors were merged. Notable changes are: * Continued effort to cleanup up old testcases and test library (Special thanks to Coccinelle and spatch for making this easier) * More sleep() calls were changed into proper synchronization which saves a few minutes on test run time * Cleanups, fixes and new tests in network testcases * New testcases for futex() syscall * New testcases for select() and poll() timeouts * New mmap() regression testcase * New regression test for hugepage leak * Fixes all over the codebase The latest version of the test-suite contains 3000+ tests for the Linux and can be downloaded at: http://sourceforge.net/projects/ltp/files/LTP%20Source/ltp-20150420/ The project pages as well as GIT repository are hosted on GitHub for quite some time now: https://github.com/linux-test-project/ltp http://linux-test-project.github.io/ If you ever wondered how to run LTP or write a testcase, don't miss our developer documentation and LWN.net articles at: https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines https://github.com/linux-test-project/ltp/wiki/BuildSystem https://lwn.net/Articles/625969/ https://lwn.net/Articles/630542/ Patches, new tests, bugs, comments or questions should go to to our mailing list at ltp-list@ltp-l...@lists.sourceforge.net. -- Cyril Hrubis chru...@suse.cz -- 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: panic with CPU hotplug + blk-mq + scsi-mq
On Mon, Apr 20, 2015 at 4:07 PM, Dongsu Park dongsu.p...@profitbricks.com wrote: Hi Ming, On 18.04.2015 00:23, Ming Lei wrote: Does anyone have an idea? As far as I can see, at least two problems exist: - race between timeout and CPU hotplug - in case of shared tags, during CPU online handling, about setting and checking hctx-tags So could you please test the attached two patches to see if they fix your issue? I run them in my VM, and looks opps does disappear. Thanks for the patches. But it still panics also with your patches, both v1 and v2. I tested it multiple times, and hit the bug every time. Could you share us what the exact test you are running? Such as, CPU numbers, virtio-scsi hw queue number, and multi-lun or not, and your workload if it is specific. I can not reproduce it in my VM. One interesting point is that the oops always happened on CPU3 in your tests, looks like the mapping is broken for CPU3's ctx in case of CPU 1 offline? Cheers, Dongsu [beginning of call traces] [ 22.942214] smpboot: CPU 1 is now offline [ 30.686284] random: nonblocking pool is initialized [ 39.857305] fuse init (API version 7.23) [ 40.563853] BUG: unable to handle kernel NULL pointer dereference at 0018 [ 40.564005] IP: [813b905d] __bt_get.isra.5+0x7d/0x1e0 [ 40.564005] PGD 7a363067 PUD 7cadc067 PMD 0 [ 40.564005] Oops: [#1] SMP [ 40.564005] Modules linked in: fuse cpufreq_stats binfmt_misc 9p fscache dm_round_robin dm_multipath loop r tc_cmos 9pnet_virtio 9pnet serio_raw acpi_cpufreq i2c_piix4 virtio_net [ 40.564005] CPU: 3 PID: 6349 Comm: grub-mount Not tainted 4.0.0+ #320 [ 40.564005] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014 [ 40.564005] task: 880079011560 ti: 88007a1c8000 task.ti: 88007a1c8000 [ 40.564005] RIP: 0010:[813b905d] [813b905d] __bt_get.isra.5+0x7d/0x1e0 [ 40.564005] RSP: 0018:88007a1cb838 EFLAGS: 00010246 [ 40.564005] RAX: 0075 RBX: 88007913c400 RCX: 0078 [ 40.564005] RDX: 88007fddbb80 RSI: 0010 RDI: 88007913c400 [ 40.564005] RBP: 88007a1cb888 R08: 88007fddbb80 R09: 0001 [ 40.564005] R10: R11: 0001 R12: 0010 [ 40.564005] R13: 0010 R14: 88007a1cb988 R15: 88007fddbb80 [ 40.564005] FS: 2b7c8b6807c0() GS:88007fc0() knlGS: [ 40.564005] CS: 0010 DS: ES: CR0: 80050033 [ 40.564005] CR2: 0018 CR3: 79b0b000 CR4: 001407e0 [ 40.564005] Stack: [ 40.564005] 88007a1cb918 88007fdd58c0 0078 813b5d28 [ 40.564005] 88007a1cb878 88007913c400 0010 0010 [ 40.564005] 88007a1cb988 88007fddbb80 88007a1cb908 813b9225 [ 40.564005] Call Trace: [ 40.564005] [813b5d28] ? blk_mq_queue_enter+0x98/0x2b0 [ 40.564005] [813b9225] bt_get+0x65/0x1d0 [ 40.564005] [813b5d28] ? blk_mq_queue_enter+0x98/0x2b0 [ 40.564005] [810c13e0] ? wait_woken+0x90/0x90 [ 40.564005] [813b9737] blk_mq_get_tag+0xa7/0xd0 [ 40.564005] [810acbe8] ? sched_clock_cpu+0x88/0xb0 [ 40.564005] [813b4c5b] __blk_mq_alloc_request+0x1b/0x1f0 [ 40.564005] [813b6a41] blk_mq_map_request+0xb1/0x200 [ 40.564005] [813b828e] blk_mq_make_request+0x6e/0x2c0 [ 40.564005] [813a871f] ? generic_make_request_checks+0x1ff/0x3d0 [ 40.564005] [813a1f3e] ? bio_add_page+0x5e/0x70 [ 40.564005] [813a89b0] generic_make_request+0xc0/0x110 [ 40.564005] [813a8a68] submit_bio+0x68/0x150 [ 40.564005] [8119a3cc] ? lru_cache_add+0x1c/0x50 [ 40.564005] [8123beca] mpage_bio_submit+0x2a/0x40 [ 40.564005] [8123cfbc] mpage_readpages+0x10c/0x130 [ 40.564005] [81235d90] ? I_BDEV+0x10/0x10 [ 40.564005] [81235d90] ? I_BDEV+0x10/0x10 [ 40.564005] [81189347] ? __page_cache_alloc+0x137/0x160 [ 40.564005] [812365bd] blkdev_readpages+0x1d/0x20 [ 40.564005] [81197eef] __do_page_cache_readahead+0x28f/0x310 [ 40.564005] [81197dbe] ? __do_page_cache_readahead+0x15e/0x310 [ 40.564005] [81198052] ondemand_readahead+0xe2/0x460 [ 40.564005] [8118a70d] ? pagecache_get_page+0x2d/0x1b0 [ 40.564005] [81198501] page_cache_sync_readahead+0x31/0x50 [ 40.564005] [8118b6bc] generic_file_read_iter+0x4ec/0x600 [ 40.564005] [81236967] blkdev_read_iter+0x37/0x40 [ 40.564005] [811f69ee] new_sync_read+0x7e/0xb0 [ 40.564005] [811f7c68] __vfs_read+0x18/0x50 [ 40.564005] [811f7d2d] vfs_read+0x8d/0x150 [ 40.564005] [811f7e39]
Build regressions/improvements in v4.0
Below is the list of build error/warning regressions/improvements in v4.0[1] compared to v3.19[2]. Summarized: - build errors: +11/-10 - build warnings: +148/-184 JFYI, when comparing v4.0[1] to v4.0-rc7[3], the summaries are: - build errors: +7/-2 - build warnings: +81/-34 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.0.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/8710/ (254 out of 257 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/8427/ (255 out of 257 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/8681/ (255 out of 257 configs) *** ERRORS *** 11 regressions: + /home/kisskb/slave/src/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c: error: impossible register constraint in ‘asm’: = 34:1 + /home/kisskb/slave/src/Documentation/prctl/disable-tsc-on-off-stress-test.c: error: impossible register constraint in ‘asm’: = 36:1 + /home/kisskb/slave/src/Documentation/prctl/disable-tsc-test.c: error: impossible register constraint in ‘asm’: = 36:1 + /home/kisskb/slave/src/Documentation/vDSO/vdso_standalone_test_x86.c: error: impossible register constraint in ‘asm’: = 49:2 + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: = N/A + error: book3s_64_vio_hv.c: undefined reference to `power7_wakeup_loss': = .text+0x408) + error: fm10k_pf.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: = (.text+0x1ff8418), (.text+0x1ff7d60), (.text+0x1ff7a28), (.text+0x1ff7e88), (.text+0x1ff838c), (.text+0x1ff8094) + error: fm10k_pf.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_23' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ff8074) + error: fm10k_pf.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ff8400) + error: fm10k_pf.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ff8374) + error: fm10k_pf.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: = (.text+0x1ff8408) 10 improvements: - /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error: too few arguments to function 'ioread16': 44:2 = - /home/kisskb/slave/src/arch/sh/boards/mach-se/7343/irq.c: error: too few arguments to function 'iowrite16': 123:2 = - /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error: too few arguments to function 'ioread16': 43:2 = - /home/kisskb/slave/src/arch/sh/boards/mach-se/7722/irq.c: error: too few arguments to function 'iowrite16': 116:2 = - /home/kisskb/slave/src/include/linux/irq.h: error: conflicting types for 'ioread16': 856:19 = - /home/kisskb/slave/src/include/linux/irq.h: error: conflicting types for 'iowrite16': 847:20 = - error: csum_partial_copy_nocheck [net/ipv6/ipv6.ko] undefined!: N/A = - error: No rule to make target include/config/auto.conf: N/A = - error: skge.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/kernel/built-in.o: (.text+0x1ffaccc), (.text+0x1ffb2bc), (.text+0x1ffa444), (.text+0x1ffa050), (.text+0x1ffaf38), (.text+0x1ffa5ec), (.text+0x1ffabd4), (.text+0x1ffb058), (.text+0x1ffaae0) = - error: skge.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_19' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ff93b8) = *** WARNINGS *** 148 regressions: + /home/kisskb/slave/src/Documentation/networking/timestamping/txtimestamp.c: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘int64_t’ [-Wformat=]: = 99:3 + /home/kisskb/slave/src/arch/s390/mm/mmap.c: warning: left shift count = width of type [enabled by default]: = 189:3 + /home/kisskb/slave/src/arch/x86/kernel/hw_breakpoint.c: warning: 'align' may be used uninitialized in this function [-Wuninitialized]: = 329:20 + /home/kisskb/slave/src/arch/x86/mm/ioremap.c: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]: = 344:10 + /home/kisskb/slave/src/drivers/crypto/qat/qat_common/qat_algs.c: warning: 'sz_out' may be used uninitialized in this function [-Wuninitialized]: = 791:4 + /home/kisskb/slave/src/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: warning: overflow in implicit constant conversion [-Woverflow]: = 59:3 +
Re: On register r/w macros/procedures of drivers/media/pci
Andrey Utkin andrey.ut...@corp.bluecherry.net writes: I am starting a work on driver for techwell tw5864 media grabberencoder. If this is tw6864 then I have a driver mostly completed. Actually I'm using tw6869 but I think this is very similar (4 channels instead of 8 and PCI instead of PCIe). I have 6864s but haven't yet tried using them for trivial reasons. This is BTW completely different chip (family) than the old tw68x. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel NULL pointer deref, bisected to 746650160
On Sun, 19 Apr 2015 18:58:41 +0200 Christoph Hellwig h...@lst.de wrote: This looks like a long standing bug in all three 3ware drivers to me, that the taking the host lock around the host_busy manipulation was hiding. Can you test the patch below? I'm running it right now and keeping my fingers crossed. Thanks regards, Torsten -- 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 5/7] perf hists browser: Fix possible memory leak
On Mon, Apr 20, 2015 at 10:24:15AM +0200, Jiri Olsa wrote: On Sun, Apr 19, 2015 at 01:04:13PM +0900, Namhyung Kim wrote: The options array saves strings for each popup menu item. The number of items can be vary according to the currently selected item. So it can leak some memory if it's exited from a small item. Fix it by freeing all items when loop terminates. Signed-off-by: Namhyung Kim namhy...@kernel.org --- tools/perf/ui/browsers/hists.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index 8f303eb5044d..cace2df7e561 100644 --- a/tools/perf/ui/browsers/hists.c +++ b/tools/perf/ui/browsers/hists.c @@ -1691,7 +1691,8 @@ skip_annotation: Switch to another data file in PWD) 0) switch_data = nr_options++; add_exit_option: - options[nr_options++] = (char *)Exit; + if (asprintf(options[nr_options], Exit) 0) + nr_options++; this one could cause segfault right? nice catch Yes. But the original code don't cause segfault since it just stops at 'nr_options - 1'. When I changed it to go through the whole array, I found it caused a segfault, so changed it. Thanks, Namhyung retry_popup_menu: choice = ui__popup_menu(nr_options, options); @@ -1812,7 +1813,7 @@ out_free_stack: pstack__delete(fstack); out: hist_browser__delete(browser); - free_popup_options(options, nr_options - 1); + free_popup_options(options, ARRAY_SIZE(options)); return key; } -- 2.3.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/
[PULL] cpumask complete deprecation
The following changes since commit 6587457b4b3d663b237a0f95ddf6e67d1828c8ea: Merge tag 'dma-buf-for-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf (2015-03-04 09:59:51 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/cpumask-next-for-linus for you to fetch changes up to e4afa120c98252e44390067c3a6cc775cde30659: cpumask: remove __first_cpu / __next_cpu (2015-04-19 14:35:32 +0930) This is the final removal (after several years!) of the obsolete cpus_* functions, prompted by their mis-use in staging. With these function removed, all cpu functions should only iterate to nr_cpu_ids, so we finally only allocate that many bits when cpumasks are allocated offstack. Thanks, Rusty. Oleg Drokin (3): staging/lustre/ptlrpc: Do not use deprecated cpus_* functions staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_ staging/lustre/o2iblnd: Don't use cpus_weight Rasmus Villemoes (1): linux/cpumask.h: add typechecking to cpumask_test_cpu Rusty Russell (21): cpumask: fix cpu-hotplug documentation ia64: Use for_each_cpu_and() and cpumask_any_and() instead of temp var. drivers: fix up obsolete cpu function usage. ia64: fix up obsolete cpu function usage. um: fix up obsolete cpu function usage. x86: fix up obsolete cpu function usage. mips: fix up obsolete cpu function usage. arm64: fix up obsolete cpu function usage. tile: fix up obsolete cpu function usage. parisc: fix up obsolete cpu function usage. blackfin: fix up obsolete cpu function usage. CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region. powerpc: fix deprecated CPU_MASK_CPU0 usage. ia64: remove deprecated cpus_ usage. x86: fix more deprecated cpu function usage. mips: fix obsolete cpumask_of_cpu usage. cpumask: remove deprecated functions. Fix weird uses of num_online_cpus(). cpumask: only allocate nr_cpumask_bits. cpumask: resurrect CPU_MASK_CPU0 cpumask: remove __first_cpu / __next_cpu Documentation/cpu-hotplug.txt | 2 +- arch/arm64/kernel/smp.c| 2 +- arch/blackfin/mach-bf561/smp.c | 2 +- arch/ia64/include/asm/acpi.h | 6 +- arch/ia64/kernel/acpi.c| 2 +- arch/ia64/kernel/iosapic.c | 2 +- arch/ia64/kernel/irq_ia64.c| 36 ++--- arch/ia64/kernel/mca.c | 10 +- arch/ia64/kernel/msi_ia64.c| 10 +- arch/ia64/kernel/numa.c| 10 +- arch/ia64/kernel/salinfo.c | 24 +-- arch/ia64/kernel/setup.c | 11 +- arch/ia64/kernel/smp.c | 6 +- arch/ia64/kernel/smpboot.c | 42 ++--- arch/ia64/kernel/topology.c| 6 +- arch/m32r/kernel/smpboot.c | 2 +- arch/mips/bcm63xx/irq.c| 4 +- arch/mips/cavium-octeon/smp.c | 4 +- arch/mips/include/asm/smp.h| 2 +- arch/mips/kernel/crash.c | 8 +- arch/mips/kernel/mips-mt-fpaff.c | 4 +- arch/mips/kernel/process.c | 2 +- arch/mips/kernel/smp-bmips.c | 2 +- arch/mips/kernel/smp-cmp.c | 4 +- arch/mips/kernel/smp-cps.c | 4 +- arch/mips/kernel/smp-mt.c | 4 +- arch/mips/kernel/smp.c | 26 +-- arch/mips/kernel/traps.c | 6 +- arch/mips/loongson/loongson-3/numa.c | 4 +- arch/mips/loongson/loongson-3/smp.c| 2 +- arch/mips/paravirt/paravirt-smp.c | 2 +- arch/mips/sgi-ip27/ip27-init.c | 2 +- arch/mips/sgi-ip27/ip27-klnuma.c | 10 +- arch/mips/sgi-ip27/ip27-memory.c | 2 +- arch/parisc/kernel/irq.c | 4 +- arch/powerpc/include/asm/cputhreads.h | 2 +- arch/sh/include/asm/mmu_context.h | 2 +- arch/sh/kernel/smp.c | 6 +- arch/sparc/kernel/time_32.c| 4 +- arch/tile/kernel/setup.c | 2 +- arch/um/kernel/smp.c | 14 +- arch/x86/kernel/apic/x2apic_cluster.c | 12 +- arch/x86/kernel/irq.c | 4 +- arch/x86/platform/uv/tlb_uv.c | 6 +-
Re: On register r/w macros/procedures of drivers/media/pci
Andrey Utkin andrey.ut...@corp.bluecherry.net writes: Please check first digit. I mean _5_864, in your post there's 6869. Ok, I just thought it may be a typo. I can now see 5864 is a H.264 encoder, while 686x are simpler frame-grabbers only. Sorry for the noise. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] perf tools: Get rid of position field from struct hist_entry
It's not used anywhere, let's get rid of it.
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/util/sort.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 846036a921dc..af192f172fa2 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -106,7 +106,6 @@ struct hist_entry {
u8 filtered;
char*srcline;
struct symbol *parent;
- unsigned long position;
struct rb_root sorted_chain;
struct branch_info *branch_info;
struct hists*hists;
--
2.3.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/
[PATCHSET 0/7] perf tools: Assorted cleanup for TUI (v2)
Hello, This patches are to cleanup TUI hists browser code for later work. I moved hist_entry_diff and hist_entry_tui under an union in order to reduce memory footprint of hist entry. Also split out hist browser functions to make it easier to read. * changes in v2) - add comment on the new union fields (Jiri) - add missing sym-namelen check (Jiri) - fix transient bug in zoom out on LEFT key press (Jiri) It's available on 'perf/tui-cleanup-v2' branch in my tree: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (7): perf tools: Get rid of position field from struct hist_entry perf diff: Make hist_entry_diff fields union perf tools: Move TUI-specific fields to struct hist_entry_tui perf tools: Move init_have_children field to struct hist_entry_tui perf hists browser: Fix possible memory leak perf hists browser: Split popup menu actions perf hists browser: Simplify zooming code a bit tools/perf/ui/browsers/hists.c | 612 ++--- tools/perf/util/hist.c | 4 +- tools/perf/util/pstack.c | 7 + tools/perf/util/pstack.h | 1 + tools/perf/util/sort.h | 36 ++- 5 files changed, 416 insertions(+), 244 deletions(-) -- 2.3.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 5/7] perf hists browser: Fix possible memory leak
The options array saves strings for each popup menu item. The number of items can be vary according to the currently selected item. So it can leak some memory if it's exited from a small item. Fix it by freeing all items when loop terminates. Signed-off-by: Namhyung Kim namhy...@kernel.org --- tools/perf/ui/browsers/hists.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index 8f303eb5044d..cace2df7e561 100644 --- a/tools/perf/ui/browsers/hists.c +++ b/tools/perf/ui/browsers/hists.c @@ -1691,7 +1691,8 @@ skip_annotation: Switch to another data file in PWD) 0) switch_data = nr_options++; add_exit_option: - options[nr_options++] = (char *)Exit; + if (asprintf(options[nr_options], Exit) 0) + nr_options++; retry_popup_menu: choice = ui__popup_menu(nr_options, options); @@ -1812,7 +1813,7 @@ out_free_stack: pstack__delete(fstack); out: hist_browser__delete(browser); - free_popup_options(options, nr_options - 1); + free_popup_options(options, ARRAY_SIZE(options)); return key; } -- 2.3.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 6/7] perf hists browser: Split popup menu actions
Currently perf_evsel__hists_browse() function spins on a huge loop and
handles many key actions. Since it's hard to read and modify, let's
split it out into small helper functions.
The add_XXX_opt() functions are to register popup menu item on the
selected entry. When it adds an item, it also saves related data into
struct popup_option and returns 1 so that it can increase the number of
items (nr_opts). A callback function named do_XXX is called with saved
data when the item is selected by user.
No functional change intended.
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/browsers/hists.c | 567 ++---
1 file changed, 365 insertions(+), 202 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cace2df7e561..75366f8df848 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1216,11 +1216,6 @@ static void hist_browser__delete(struct hist_browser
*browser)
free(browser);
}
-static struct hist_entry *hist_browser__selected_entry(struct hist_browser
*browser)
-{
- return browser-he_selection;
-}
-
static struct thread *hist_browser__selected_thread(struct hist_browser
*browser)
{
return browser-he_selection-thread;
@@ -1395,6 +1390,281 @@ close_file_and_continue:
return ret;
}
+struct popup_option {
+ struct thread *thread;
+ struct map *map;
+ struct dso *dso;
+ struct symbol *sym;
+
+ int (*fn)(struct popup_option *opt, struct hist_browser *browser,
+ struct hist_browser_timer *hbt, struct pstack *pstack,
+ struct perf_session_env *env);
+};
+
+static int
+do_annotate(struct popup_option *opt, struct hist_browser *browser,
+ struct hist_browser_timer *hbt, struct pstack *pstack
__maybe_unused,
+ struct perf_session_env *env)
+{
+ struct perf_evsel *evsel;
+ struct annotation *notes;
+ struct map_symbol ms;
+ int err;
+
+ if (!objdump_path perf_session_env__lookup_objdump(env))
+ return 0;
+
+ ms.map = opt-map;
+ ms.sym = opt-sym;
+
+ notes = symbol__annotation(ms.sym);
+ if (!notes-src)
+ return 0;
+
+ evsel = hists_to_evsel(browser-hists);
+ err = map_symbol__tui_annotate(ms, evsel, hbt);
+ /*
+* offer option to annotate the other branch source or target
+* (if they exists) when returning from annotate
+*/
+ if ((err == 'q' || err == CTRL('c'))
+browser-he_selection-branch_info)
+ return 1;
+
+ ui_browser__update_nr_entries(browser-b, browser-hists-nr_entries);
+ if (err)
+ ui_browser__handle_resize(browser-b);
+ return 0;
+}
+
+static int
+add_annotate_opt(struct popup_option *opt, char **optstr,
+struct hist_browser *browser __maybe_unused,
+struct map *map, struct symbol *sym)
+{
+ if (sym == NULL || map-dso-annotate_warned)
+ return 0;
+
+ if (asprintf(optstr, Annotate %s, sym-name) 0)
+ return 0;
+
+ opt-map = map;
+ opt-sym = sym;
+ opt-fn = do_annotate;
+ return 1;
+}
+
+static int do_zoom_thread(struct popup_option *opt,
+ struct hist_browser *browser,
+ struct hist_browser_timer *hbt __maybe_unused,
+ struct pstack *pstack,
+ struct perf_session_env *env __maybe_unused)
+{
+ struct thread *thread = opt-thread;
+
+ if (browser-hists-thread_filter) {
+ pstack__remove(pstack, browser-hists-thread_filter);
+ perf_hpp__set_elide(HISTC_THREAD, false);
+ thread__zput(browser-hists-thread_filter);
+ ui_helpline__pop();
+ } else {
+ ui_helpline__fpush(To zoom out press - or - + \Zoom out of
%s(%d) thread\,
+ thread-comm_set ? thread__comm_str(thread)
: ,
+ thread-tid);
+ browser-hists-thread_filter = thread__get(thread);
+ perf_hpp__set_elide(HISTC_THREAD, false);
+ pstack__push(pstack, browser-hists-thread_filter);
+ }
+
+ hists__filter_by_thread(browser-hists);
+ hist_browser__reset(browser);
+ return 0;
+}
+
+static int
+add_thread_opt(struct popup_option *opt, char **optstr,
+ struct hist_browser *browser, struct thread *thread)
+{
+ if (thread == NULL)
+ return 0;
+
+ if (asprintf(optstr, Zoom %s %s(%d) thread,
+browser-hists-thread_filter ? out of : into,
+thread-comm_set ? thread__comm_str(thread) : ,
+thread-tid) 0)
+ return 0;
+
+ opt-thread = thread;
+ opt-fn = do_zoom_thread;
+ return 1;
+}
+
+static int
[PATCH v2] ata: ahci_st: fixup layering violations / drvdata errors
Brian noticed while working on another SATA driver that uses libahci_platform,
an error in this driver; it tries to the the driver data for its
device, while libata also thinks it can set the driver data. See:
ahci_platform_init_host()
- ata_host_alloc_pinfo()
- ata_host_alloc()
- dev_set_drvdata()
So instead of sticking the IP-specific platform data into drvdata, let's
use the plat_data variable that is reserved for this use.
Addtionally plat_data isn't set until ahci_platform_init_host() has been
called further down in probe(). So re-work the st_ahci_probe_resets and
st_ahci_deassert_resets functions to take ahci_host_priv *hpriv as a
parameter.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Suggested-by: Brian Norris computersforpe...@gmail.com
Cc: Srinivas Kandagatla srinivas.kandaga...@gmail.com
Cc: Maxime Coquelin maxime.coque...@st.com
Cc: Patrice Chotard patrice.chot...@st.com
---
drivers/ata/ahci_st.c | 49 -
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
index ea0ff00..8ff428f 100644
--- a/drivers/ata/ahci_st.c
+++ b/drivers/ata/ahci_st.c
@@ -37,7 +37,6 @@ struct st_ahci_drv_data {
struct reset_control *pwr;
struct reset_control *sw_rst;
struct reset_control *pwr_rst;
- struct ahci_host_priv *hpriv;
};
static void st_ahci_configure_oob(void __iomem *mmio)
@@ -55,9 +54,10 @@ static void st_ahci_configure_oob(void __iomem *mmio)
writel(new_val, mmio + ST_AHCI_OOBR);
}
-static int st_ahci_deassert_resets(struct device *dev)
+static int st_ahci_deassert_resets(struct ahci_host_priv *hpriv,
+ struct device *dev)
{
- struct st_ahci_drv_data *drv_data = dev_get_drvdata(dev);
+ struct st_ahci_drv_data *drv_data = hpriv-plat_data;
int err;
if (drv_data-pwr) {
@@ -90,8 +90,8 @@ static int st_ahci_deassert_resets(struct device *dev)
static void st_ahci_host_stop(struct ata_host *host)
{
struct ahci_host_priv *hpriv = host-private_data;
+ struct st_ahci_drv_data *drv_data = hpriv-plat_data;
struct device *dev = host-dev;
- struct st_ahci_drv_data *drv_data = dev_get_drvdata(dev);
int err;
if (drv_data-pwr) {
@@ -103,29 +103,30 @@ static void st_ahci_host_stop(struct ata_host *host)
ahci_platform_disable_resources(hpriv);
}
-static int st_ahci_probe_resets(struct platform_device *pdev)
+static int st_ahci_probe_resets(struct ahci_host_priv *hpriv,
+ struct device *dev)
{
- struct st_ahci_drv_data *drv_data = platform_get_drvdata(pdev);
+ struct st_ahci_drv_data *drv_data = hpriv-plat_data;
- drv_data-pwr = devm_reset_control_get(pdev-dev, pwr-dwn);
+ drv_data-pwr = devm_reset_control_get(dev, pwr-dwn);
if (IS_ERR(drv_data-pwr)) {
- dev_info(pdev-dev, power reset control not defined\n);
+ dev_info(dev, power reset control not defined\n);
drv_data-pwr = NULL;
}
- drv_data-sw_rst = devm_reset_control_get(pdev-dev, sw-rst);
+ drv_data-sw_rst = devm_reset_control_get(dev, sw-rst);
if (IS_ERR(drv_data-sw_rst)) {
- dev_info(pdev-dev, soft reset control not defined\n);
+ dev_info(dev, soft reset control not defined\n);
drv_data-sw_rst = NULL;
}
- drv_data-pwr_rst = devm_reset_control_get(pdev-dev, pwr-rst);
+ drv_data-pwr_rst = devm_reset_control_get(dev, pwr-rst);
if (IS_ERR(drv_data-pwr_rst)) {
- dev_dbg(pdev-dev, power soft reset control not defined\n);
+ dev_dbg(dev, power soft reset control not defined\n);
drv_data-pwr_rst = NULL;
}
- return st_ahci_deassert_resets(pdev-dev);
+ return st_ahci_deassert_resets(hpriv, dev);
}
static struct ata_port_operations st_ahci_port_ops = {
@@ -154,15 +155,12 @@ static int st_ahci_probe(struct platform_device *pdev)
if (!drv_data)
return -ENOMEM;
- platform_set_drvdata(pdev, drv_data);
-
hpriv = ahci_platform_get_resources(pdev);
if (IS_ERR(hpriv))
return PTR_ERR(hpriv);
+ hpriv-plat_data = drv_data;
- drv_data-hpriv = hpriv;
-
- err = st_ahci_probe_resets(pdev);
+ err = st_ahci_probe_resets(hpriv, pdev-dev);
if (err)
return err;
@@ -170,7 +168,7 @@ static int st_ahci_probe(struct platform_device *pdev)
if (err)
return err;
- st_ahci_configure_oob(drv_data-hpriv-mmio);
+ st_ahci_configure_oob(hpriv-mmio);
err = ahci_platform_init_host(pdev, hpriv, st_ahci_port_info,
ahci_platform_sht);
@@ -185,8 +183,9 @@ static int st_ahci_probe(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int
[PATCH v2] ata: ahci_st: fixup layering violations / drvdata errors
Hi Tejun / Brian, I tested the initial version of this patch (see http://patchwork.ozlabs.org/patch/459422/) on stih410 hardware, however it introduced a NULL ptr dereference, as plat_data isn't set until ahci_platform_init_host() but plat_data was being used before this in the st_ahci_probe_resets and st_ahci_deassert_resets() functions. Also the original patch had a conflict with a patch which Tejun has already taken of mine (see here http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/326900.html). So this V2 fixes the conflict, and re-works st_ahci_probe_resets and st_ahci_deassert_resets functions to take struct ahci_host_priv *hpriv as a parameter. Brian - I'm not sure of the correct patch etiquette here. Currently I have taken authorship of the patch and added a Suggested-by tag on the V2. Maybe I should have also kept your Signed-off-by or done something else? Please let me know if this is OK or if you would like something changed. regards, Peter. Changes since v1: - Rework st_ahci_deassert_resets and st_ahci_probe_resets - Fix conflict with st_configure_oob must be called after IP is clocked. patch Peter Griffin (1): ata: ahci_st: fixup layering violations / drvdata errors drivers/ata/ahci_st.c | 49 - 1 file changed, 24 insertions(+), 25 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] fs: use a sequence counter instead of file_lock in fd_install
On Sat, Apr 18, 2015 at 12:41:38PM -0700, Eric Dumazet wrote: On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote: On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote: I would say this makes the use of seq counter impossible. Even if we decided to fall back to a lock on retry, we cannot know what to do if the slot is reserved - it very well could be that something called close, and something else reserved the slot, so putting the file inside could be really bad. In fact we would be putting a file for which we don't have a reference anymore. However, not all hope is lost and I still think we can speed things up. A locking primitive which only locks stuff for current cpu and has another mode where it locks stuff for all cpus would do the trick just fine. I'm not a linux guy, quick search suggests 'lglock' would do what I want. table reallocation is an extremely rare operation, so this should be fine. It would take the lock 'globally' for given table. It would also mean percpu_alloc() for each descriptor table... I would rather use an xchg() instead of rcu_assign_ponter() old = xchg(fdt-fd[fd], file); if (unlikely(old)) filp_close(old, files); If threads are using close() on random fds, final result is not guaranteed anyway. Well I don't see how could this be used to fix the problem. If you are retrying and see NULL, you don't know whether your previous update was not picked up by memcpy OR the fd got closed, which also unreferenced the file you are installing. But you can't tell what happened. If you see non-NULL and what you found is not the file you are installing, you know the file was freed so you can't close the old file. One could try to introduce an invariant that files installed in a lockless manner have to start with refcount 1, you still can't infer anything from the fact that the counter is 1 when you retry (even if you take the lock). It could have been duped, or even sent over a unix socket and closed (although that awould surely require a solid pause in execution) and who knows what else. In general I would say this approach is too hard to get right to be worthwile given expected speedup. -- Mateusz Guzik -- 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] cdc-acm: prevent infinite loop when parsing CDC headers.
On Tue, Apr 14, 2015 at 11:25:43AM +0200, Quentin Casasnovas wrote: Phil and I found out a problem with commit: 7e860a6e7aa6 (cdc-acm: add sanity checks) Any comment on v2? Thanks, Quentin -- 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] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF
Hi Chris,
On 04/20/2015 01:44 PM, Chris Wilson wrote:
Ah, maybe this on top of the previous try:
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 88f5a74..5d22ca0 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -87,7 +87,7 @@ static int drm_helper_probe_add_cmdline_mode(struct
drm_connector *connector)
return 0;
/* Only add a GTF mode if we find no matching probed modes */
- list_for_each_entry(mode, connector-modes, head) {
+ list_for_each_entry(mode, connector-probed_modes, head) {
if (mode-hdisplay != cmdline_mode-xres ||
mode-vdisplay != cmdline_mode-yres)
continue;
@@ -211,7 +211,8 @@ static int
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
mode_flags |= DRM_MODE_FLAG_3D_MASK;
list_for_each_entry(mode, connector-modes, head) {
- mode-status = drm_mode_validate_basic(mode);
+ if (mode-status == MODE_OK)
+ mode-status = drm_mode_validate_basic(mode);
if (mode-status == MODE_OK)
mode-status = drm_mode_validate_size(mode, maxX, maxY
perfect - this seems to work :)
Radek
--
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 6/7] perf hists browser: Split popup menu actions
On Mon, Apr 20, 2015 at 11:46:07AM +0200, Jiri Olsa wrote:
On Sun, Apr 19, 2015 at 01:04:14PM +0900, Namhyung Kim wrote:
SNIP
continue;
case 's':
- if (is_report_browser(hbt))
- goto do_data_switch;
+ if (is_report_browser(hbt)) {
+ key = do_switch_data(opts, browser, hbt,
+fstack, env);
+ if (key == K_SWITCH_INPUT_DATA)
+ goto out_free_stack;
+ }
continue;
case 'i':
/* env-arch is NULL for live-mode (i.e. perf top) */
@@ -1592,10 +1878,16 @@ static int perf_evsel__hists_browse(struct
perf_evsel *evsel, int nr_events,
continue;
}
top = pstack__pop(fstack);
- if (top == browser-hists-dso_filter)
- goto zoom_out_dso;
- if (top == browser-hists-thread_filter)
- goto zoom_out_thread;
+ if (top == browser-hists-dso_filter) {
+ perf_hpp__set_elide(HISTC_DSO, false);
+ browser-hists-dso_filter = NULL;
+ ui_helpline__pop();
+ }
+ if (top == browser-hists-thread_filter) {
+ perf_hpp__set_elide(HISTC_THREAD, false);
+ thread__zput(browser-hists-thread_filter);
+ ui_helpline__pop();
+ }
ui_helpline__pop could be called in heare and removed in above legs:
ui_helpline__pop()
also the original code calls following for zoom out:
- hists__filter_by_dso(hists);
- hist_browser__reset(browser);
Right. The intention was to call do_zoom_thread() or do_zoom_dso()
like in the next patch. Will fix this anyway.
Thanks for your careful review!
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] fbdev changes for 4.1
Hi Linus, Please pull fbdev changes for 4.1. Tomi The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-4.1 for you to fetch changes up to 6b75b54c841a18ef114704aa5cf2cdf43487b0ae: Merge omapdss topic branch for fbdev 4.1 (2015-04-20 12:09:31 +0300) fbdev changes for v4.1 * Small fixes and improvements to various fbdev drivers Dan Carpenter (1): fbdev: pm3fb: cleanup some confusing indenting Geert Uytterhoeven (1): fbdev: sh_mobile_lcdc: Fix destruction of uninitialized mutex Grygorii Strashko (1): omapdss: extend pm notifier to handle hibernation Javier Martinez Canillas (1): OMAPDSS: Correct video ports description file path in DT binding doc Lad, Prabhakar (1): fbdev: via/via_clock: fix sparse warning Laurent Pinchart (1): video: fbdev: sh_mobile_lcdcfb: Fix ROP3 sysfs attribute parsing Nicholas Mc Guire (2): video: fbdev: use msecs_to_jiffies for time conversions hyperv: hyperv_fb: match wait_for_completion_timeout return type Sanjeev Sharma (1): video: fbdev: make of_device_id array const Sudip Mukherjee (1): fbdev: sm501fb: use memset_io Tomi Valkeinen (15): OMAPDSS: fix AM43xx minimum pixel clock divider OMAPDSS: HDMI5: Increase DDC SDA-HOLD time OMAPDSS: fix paddr check for TILER addresses OMAPDSS: TFP410: fix input sync signals OMAPDSS: DISPC: remove OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES OMAPDSS: DISPC: explicit handling for sync and de levels OMAPDSS: change signal_level signal_edge enum values OMAPDSS: DISPC: change sync_pclk_edge default value OMAPDSS: DISPC: fix div by zero issue in overlay scaling OMAPDSS: DISPC: lock access to DISPC_CONTROL DISPC_CONFIG OMAPDSS: setup default fifo thresholds OMAPDSS: Add support for MFLAG OMAPDSS: workaround for MFLAG + NV12 issue OMAPDSS: disable VT switch Merge omapdss topic branch for fbdev 4.1 .../devicetree/bindings/video/ti,omap-dss.txt | 4 +- drivers/gpu/drm/omapdrm/omap_connector.c | 2 +- drivers/video/fbdev/hyperv_fb.c| 6 +- drivers/video/fbdev/imxfb.c| 2 +- .../video/fbdev/omap2/displays-new/connector-dvi.c | 2 +- .../fbdev/omap2/displays-new/encoder-tfp410.c | 11 ++ .../omap2/displays-new/panel-lgphilips-lb035q02.c | 2 +- .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 2 +- .../omap2/displays-new/panel-sony-acx565akm.c | 2 +- .../omap2/displays-new/panel-tpo-td028ttec1.c | 2 +- .../omap2/displays-new/panel-tpo-td043mtea1.c | 2 +- drivers/video/fbdev/omap2/dss/core.c | 4 + drivers/video/fbdev/omap2/dss/dispc.c | 147 +++-- drivers/video/fbdev/omap2/dss/display.c| 2 +- drivers/video/fbdev/omap2/dss/dsi.c| 2 +- drivers/video/fbdev/omap2/dss/dss.c| 3 + drivers/video/fbdev/omap2/dss/dss_features.c | 2 +- drivers/video/fbdev/omap2/dss/hdmi5_core.c | 2 +- drivers/video/fbdev/omap2/dss/rfbi.c | 2 +- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 +- drivers/video/fbdev/pm3fb.c| 6 +- drivers/video/fbdev/pxafb.c| 6 +- drivers/video/fbdev/sh_mobile_lcdcfb.c | 15 ++- drivers/video/fbdev/sm501fb.c | 2 +- drivers/video/fbdev/via/via_clock.c| 2 +- include/video/omapdss.h| 7 +- 26 files changed, 193 insertions(+), 50 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/3] btrfs: set FS_SUPPORTS_SEEK_HOLE flag.
On Mon, Apr 20, 2015 at 02:48:55AM -0700, Christoph Hellwig wrote: On Mon, Apr 20, 2015 at 10:46:49AM +0100, David Howells wrote: NeilBrown ne...@suse.de wrote: Missing patch 2 of the 3-patch series? Yes. :-) Do ext4 and xfs support this, do you know? Yes. As do f2fs, ocfs2, gfs2, ceph and NFSv4.2 Er... Nominally, gfs2 supports it. By treating all files as there's a hole starting at EOF. Same as ext2 or even minix... -- 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/
I want to invest
Attention Sir, I am personally contacting you based on two reasons. 1.Your knowledge in Gold Business, Am interested in buying properties houses,Building real estate and some tourist places. 2.Your ability keeping my business reationship very strictly secret as I have finalised arrangement with Bank to release $15million for you to stand as my beneficiary and thereafter use it in acquiring gold for me with percentage to be discussed with you as your benefit. I awaits your response urgently. Kind regards Calvin Handerson -- 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/11] powerpc/8xx: macro for handling CPU15 errata
Le 20/04/2015 13:40, David Laight a écrit : From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ + +#ifdef CONFIG_8xx_CPU15 +#define DO_8xx_CPU15(tmp, addr)\ + additmp, addr, PAGE_SIZE; \ + tlbie tmp;\ + additmp, addr, PAGE_SIZE; \ + tlbie tmp +#else +#define DO_8xx_CPU15(tmp, addr) +#endif I'm sure I've spotted the same obvious error in the above before. I'd also suggest calling it 'invalidate_adjacent_pages' - since that it what it does. I also guess that the execution time of 'tlbie' is non-trivial. So you might as well get rid of the temporary register and put an 'addi' to reset 'addr' at the end. David Forget it, I did a big mistake this morning, involontarily resent an old patch. Sorry for the noise. Christophe -- 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] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF
On Mon, Apr 20, 2015 at 01:20:05PM +0200, Radek Dostál wrote:
Hi Chris,
On 04/20/2015 01:00 PM, Chris Wilson wrote:
Can you do a WARN_ON(list_empty(connector-modes)) here to see at what
point we set up the invalid GTF mode?
sure please see attached patch adding WARN_ON and corresponding output
of dmesg. As mentioned in the original commit, the mode is indeed added
in drm_helper_probe_add_cmdline_mode.
Ah, maybe this on top of the previous try:
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 88f5a74..5d22ca0 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -87,7 +87,7 @@ static int drm_helper_probe_add_cmdline_mode(struct
drm_connector *connector)
return 0;
/* Only add a GTF mode if we find no matching probed modes */
- list_for_each_entry(mode, connector-modes, head) {
+ list_for_each_entry(mode, connector-probed_modes, head) {
if (mode-hdisplay != cmdline_mode-xres ||
mode-vdisplay != cmdline_mode-yres)
continue;
@@ -211,7 +211,8 @@ static int
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
mode_flags |= DRM_MODE_FLAG_3D_MASK;
list_for_each_entry(mode, connector-modes, head) {
- mode-status = drm_mode_validate_basic(mode);
+ if (mode-status == MODE_OK)
+ mode-status = drm_mode_validate_basic(mode);
if (mode-status == MODE_OK)
mode-status = drm_mode_validate_size(mode, maxX, maxY
--
Chris Wilson, Intel Open Source Technology Centre
--
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/7] perf tools: Move TUI-specific fields to struct hist_entry_tui
Hi Jiri,
On Mon, Apr 20, 2015 at 10:20:02AM +0200, Jiri Olsa wrote:
On Sun, Apr 19, 2015 at 01:04:11PM +0900, Namhyung Kim wrote:
Since perf diff only support stdio output, TUI fields are only accessed
from perf report (or perf top). So add new struct hist_entry_tui and
move those fields into them. And include it as an union member.
SNIP
- /* XXX These two should move to some tree widget lib */
- u16 row_offset;
- u16 nr_rows;
-
boolinit_have_children;
charlevel;
u8 filtered;
+ union {
+ struct hist_entry_diff diff;
+ struct hist_entry_tui tui;
+ };
could you please add the comment from changelog in here,
so it's easy to figure this out in the future
OK, will do.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [V6,1/9] elf: Add new powerpc specifc core note sections
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 13.04.2015
10:48:57:
On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
- You provide checkpointed FPR and VMX registers, but there doesn't
seem
to be any way to get at the checkpointed *VSX* registers (i.e. the
part
that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).
Will change vsr_get, vsr_set functions as we have done for fpr_get and
fpr_set
functions. Also will add one more ELF core note NT_PPC_TM_CVSX to fetch
the
check pointed state of VSX register while inside the transaction.
OK.
I would much prefer three separate regsets (e.g. NT_PPC_DSCR,
NT_PPC_PPR,
and NT_PPC_TAR), each of which is available and valid if and only if
the
current processor actually has the register in question.
Thats like adding one ELF core note for every single register
because we cannot
put them in any category. Then as Michael Ellerman had pointed out to
include
a lot more registers in this MISC category (which we are not doing right
now
in the interest of having minimum support available before we look at the
full
possible list of MISC registers), we should add one ELF core note section
for
each of those individual registers ? I am not sure.
This confuses me a bit. My understanding was that ptrace regsets, once
defined, should never change in the future. (GDB will only check whether
or not a regset is supported; if it is, it will expect the contents to be
as it expects them to be.) Including a lot more registers would
therefore
seem to require adding new regsets anyway, which is one of the reasons why
I disagree a MISC regset is particularly useful.
- Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
matches
registers with different lifetimes. The transactional memory
registers
(TFHAR, TEXASR, TFIAR) are available *always* on machines that
support
transactions. But the other registers in that regset are
checkpointed
versions that are only available/valid within a transaction. I think
a
better way to faithfully represent this would be to have the
NT_PPC_TM_SPR
regset only contain the transcational memory registers, and use
separate
regsets for the checkpointed registers -- those should parallel the
non-
checkpointed register regset.
Right now, we support NT_PPC_TM_SPR only inside the transaction, so we
dont
have the problem with different lifetimes registers accessed together.
But
yes, I get your point.
Since the transactional SPRs are accessible from user space outside of a
transaction, it would make sense for them to accessible from ptrace as
well.
If the current patch set doesn't do that, I guess it would be better to
change that.
- Particularly confusing to me is the checkpointed original MSR which
currently also resides in NT_PPC_TM_SPR. What exactly is this? How
does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?
I believed it stores the check pointed MSR value which was in the
register
before the transaction started. But then how it is different from the
ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
more on this. I can see orig_msr getting used in many places to hold
the
check pointed value of MSR.
Your other mail states that the orig_mst may be irrelevant for ptrace
anyway ... that would be OK with me as well.
In any case, it seems the ptrace set-register case currently allows
user
space to restore *any* arbitrary value into the checkpointed MSR,
which
would presumably get restored into the real MSR at some point, unless
I'm
missing something here. Do we not need a check that only safe bits
are
modified, just like with ptrace access to the real MSR?
Where and which safe bits do we check before writing any value into the
MSR
register from ptrace interface ? May be I am missing something here.
All ptrace accesses to *set* the regular msr go via this routine:
static int set_user_msr(struct task_struct *task, unsigned long msr)
{
task-thread.regs-msr = ~MSR_DEBUGCHANGE;
task-thread.regs-msr |= msr MSR_DEBUGCHANGE;
return 0;
}
I think we'd need to do the equivalent whenever changing the checkpointed
MSR.
Bye,
Ulrich
--
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/16] printk: guard the amount written per line by devkmsg_read()
On Mon 2015-04-20 14:11:36, Petr Mladek wrote: On Thu 2015-04-16 19:03:38, Tejun Heo wrote: devkmsg_read() uses 8k buffer and assumes that the formatted output message won't overrun which seems safe given LOG_LINE_MAX, the current use of dict and the escaping method being used; however, we're planning to use devkmsg formatting wider and accounting for the buffer size properly isn't that complicated. This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates devkmsg_read() so that it limits output accordingly. Signed-off-by: Tejun Heo t...@kernel.org Reviewed-by: Petr Mladek pmla...@suse.cz It is just a refactoring and does not modify the current behavior. Ah, to make it clear. It did not modify the behavior except for adding the check for potential buffer overflow. Best Regards, Petr -- 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] pinctrl: mediatek: mtk-common: initialize unmask
Hello.
On 04/20/2015 02:15 PM, Colin King wrote:
From: Colin Ian King colin.k...@canonical.com
cppcheck detected an unitialized variable:
Uninitialized.
[drivers/pinctrl/mediatek/pinctrl-mtk-common.c:897]:
(error) Uninitialized variable: unmask
unmask should be initialized to zero to ensure unmasking
only occurs if a previous mask occurred. The current situation
is that the unmask variable could contain any random garbage
causing random unexpected unmasking.
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 493294c..3173125 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -881,7 +881,8 @@ static int mtk_gpio_set_debounce(struct gpio_chip *chip,
unsigned offset,
if (!mtk_eint_get_mask(pctl, eint_num)) {
mtk_eint_mask(d);
unmask = 1;
- }
+ } else
+ unmask = 0;
The CodingStyle dictates that there should be {} around *else* branch too.
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I don't have a board that enumerates xhci using xhci-plat.c myself. -Mathias -- 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] tools/lib/api/Makefile: Add feature check for _FORTIFY_SOURCE
For example on Gentoo systems where _FORTIFY_SOURCE is set by default, `make -C tools/perf' fails, because of the macro being redefined. Fix that by a feature-check analogous to tools/perf/config/Makefile. Signed-off-by: Dirk Gouders d...@gouders.net --- tools/lib/api/Makefile | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile index d8fe29f..acf9097 100644 --- a/tools/lib/api/Makefile +++ b/tools/lib/api/Makefile @@ -16,7 +16,14 @@ MAKEFLAGS += --no-print-directory LIBFILE = $(OUTPUT)libapi.a CFLAGS := $(EXTRA_WARNINGS) $(EXTRA_CFLAGS) -CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -fPIC +CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -fPIC + +ifeq ($(DEBUG),0) + ifeq ($(feature-fortify-source), 1) +CFLAGS += -D_FORTIFY_SOURCE=2 + endif +endif + CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 RM = rm -f -- 2.3.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: On register r/w macros/procedures of drivers/media/pci
On Mon, Apr 20, 2015 at 3:45 PM, Krzysztof Hałasa khal...@piap.pl wrote: Andrey Utkin andrey.ut...@corp.bluecherry.net writes: Please check first digit. I mean _5_864, in your post there's 6869. Ok, I just thought it may be a typo. I can now see 5864 is a H.264 encoder, while 686x are simpler frame-grabbers only. Sorry for the noise. Nothing to excuse for! Thanks for the info anyway! -- Bluecherry developer. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ata: ahci_st: fixup layering violations / drvdata errors
Hi Tejun, On Fri, 17 Apr 2015, Tejun Heo wrote: On Thu, Apr 09, 2015 at 10:43:10AM +0100, Peter Griffin wrote: Yes I can test, although not until Saturday as I only have remote access to the board today tomorrow and the hard drive isn't plugged in. What's the status on this patch? Should I push it through for-4.1-fixes? The layering violation which Brian identified does need fixing. However please don't take this patch as it currently is, as it causes a NULL ptr dereference. I can send an updated version in a moment which: - 1) Fixes the conflict you will get when applying it for v4.1 (due to my st_configure_oob must be called after IP is clocked patch). 2) Fixes the crash which this patch introduces. regards, 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: [RFC PATCH] fs: use a sequence counter instead of file_lock in fd_install
On Mon, Apr 20, 2015 at 03:06:33PM +0200, Mateusz Guzik wrote: On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote: On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote: I would say this makes the use of seq counter impossible. Even if we decided to fall back to a lock on retry, we cannot know what to do if the slot is reserved - it very well could be that something called close, and something else reserved the slot, so putting the file inside could be really bad. In fact we would be putting a file for which we don't have a reference anymore. However, not all hope is lost and I still think we can speed things up. A locking primitive which only locks stuff for current cpu and has another mode where it locks stuff for all cpus would do the trick just fine. I'm not a linux guy, quick search suggests 'lglock' would do what I want. table reallocation is an extremely rare operation, so this should be fine. It would take the lock 'globally' for given table. It would also mean percpu_alloc() for each descriptor table... Well as it was noted I have not checked how it's implemented at the time of writing the message. I agree embedding something like this into files struct is a non-starter. I would say this could work with a small set of locks, selected by hashing struct files pointer. Table resizing is supposed to be extremely rare - most processes should not need it at all (if they do, the default size is too small and should be adjusted). Not only that, the lock is only needed if the process in question is multithreaded. So I would say this would not contend in real-world workloads, but still looks crappy. Unfortunately the whole thing loses original appeal of a simple hack with no potential perfomrance drawbacks. Maybe I'll hack it up later and run some tests anyway. I just came up with another stupid hack, but this time it could really work just fine. Note that the entire issue stems from the fact that the table can be resized at any moment. If only we had a guarantee the table stands still, we would not even need that sequence couner. fd_install could just plop the file in. So a stupid hack which comes to mind tells the kernel to make sure the table is big enough and then never resize it ever again (inherited on fork, cleared on exec): prctl(FDTABLE_SIZE_FIXED, BIGNUM); or dup2(0, BIGNUM); /* sizes the table appropriately */ close(BIGNUM); prctl(FDTABLE_SIZE_FIXED); Thoughts? -- Mateusz Guzik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages.
On Mon, Apr 20, 2015 at 11:53:47AM +0100, David Vrabel wrote:
On 20/04/15 11:48, Chen Baozi wrote:
Make sure that xen_swiotlb_init allocates buffers that is DMA capable.
Signed-off-by: Chen Baozi baoz...@gmail.com
---
drivers/xen/swiotlb-xen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..7345afd 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -235,7 +235,8 @@ retry:
#define SLABS_PER_PAGE (1 (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((120) IO_TLB_SHIFT)
while ((SLABS_PER_PAGE order) IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)__get_free_pages(__GFP_NOWARN, order);
+ xen_io_tlb_start = (void *)__get_free_pages(
+ __GFP_NOWARN|__GFP_DMA, order);
I think this breaks x86 where __GFP_DMA means below 16 MB. Perhaps you
mean __GFP_DMA32?
__GFP_DMA32 doesn't help on arm64...
I guess there might be conflicts about the meaning of __GFP_DMA between x86 and
arm?
Cheers,
Baozi.
--
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 6/7] perf hists browser: Split popup menu actions
On Mon, Apr 20, 2015 at 11:21:59AM +0200, Jiri Olsa wrote:
On Sun, Apr 19, 2015 at 01:04:14PM +0900, Namhyung Kim wrote:
SNIP
+
+static int
+add_script_opt(struct popup_option *opt, char **optstr,
+ struct hist_browser *browser __maybe_unused,
+ struct thread *thread, struct symbol *sym)
+{
+ if (thread) {
+ if (asprintf(optstr, Run scripts for samples of thread [%s],
+thread__comm_str(thread)) 0)
+ return 0;
+ } else if (sym) {
there's also check for sym-namelen in the original code
Ah, right. I'll change it.
But I wonder there's a case 'sym !sym-namelen' though..
Thanks,
Namhyung
+ if (asprintf(optstr, Run scripts for samples of symbol [%s],
+sym-name) 0)
+ return 0;
+ } else {
+ if (asprintf(optstr, Run scripts for all samples) 0)
+ return 0;
+ }
+
+ opt-thread = thread;
+ opt-sym = sym;
+ opt-fn = do_run_script;
+
+ return 1;
+}
SNIP
--
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/
