Re: [PATCH] x86, crypto: Check if gas supports CRC32
On 31 July 2014 00:11, Borislav Petkov wrote: > > On Wed, Jul 30, 2014 at 11:28:14PM +0200, Mathias Krause wrote: > > Gah, CONFIG_AS_CRC32 gets defined as a preprocessor symbol only so > > cannot be used in makefiles. So crc32c-pcl-intel-asm_64.S needs a > > "#ifdef CONFIG_AS_CRC32" guard and still be compiled for CONFIG_64BIT, > > as it is now. It'll be an empty object for older binutils versions not > > supporting the crc32 instruction. > > Yeah, that makes it all even simpler, thanks! > > We're still b0rked though: > > arch/x86/crypto/crct10dif-pcl-asm_64.S: Assembler messages: > arch/x86/crypto/crct10dif-pcl-asm_64.S:147: Error: no such instruction: > `pclmulqdq $0x0,%xmm10,%xmm0' > arch/x86/crypto/crct10dif-pcl-asm_64.S:148: Error: no such instruction: > `pclmulqdq $0x11,%xmm10,%xmm8' > arch/x86/crypto/crct10dif-pcl-asm_64.S:149: Error: no such instruction: > `pclmulqdq $0x0,%xmm10,%xmm1' > ... > > and need checking for more instructions. I'll play with this more > tomorrow. > You probably can reuse the AVX test for this -- either the CONFIG_AS_AVX preprocessor one or the $(avx_supported) make one, local to arch/x86/crypto/Makefile. Even though the CLMUL feature has not much to with AVX (it has a dedicated CPUID feature bit), support for it in binutils was added together with AVX support, see https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c0f3af977b0f28a0dc5a620110b8dcf9d8286f84 Regards, Mathias > Good night :-) > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LKP] [mm] b72fd1470c9: -41.7% perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.pagecache_get_page
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit b72fd1470c9735f53485d089aa918dc327a86077 ("mm: rearrange zone fields
into read-only, page alloc, statistics and page reclaim lines")
test case: lkp-st02/dd-write/5m-11HDD-JBOD-cfq-xfs-10dd
e28c951ff01a805 b72fd1470c9735f53485d089a
--- -
1.06 ~ 6% -41.7% 0.62 ~ 3% TOTAL
perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.pagecache_get_page
1.34 ~ 2% -19.8% 1.07 ~ 2% TOTAL
perf-profile.cpu-cycles.__block_write_begin.xfs_vm_write_begin.generic_perform_write.xfs_file_buffered_aio_write.xfs_file_write_iter
1.19 ~ 5% -12.1% 1.05 ~ 4% TOTAL
perf-profile.cpu-cycles.copy_from_user_atomic_iovec.iov_iter_copy_from_user_atomic.generic_perform_write.xfs_file_buffered_aio_write.xfs_file_write_iter
2.78 ~ 1% -16.3% 2.32 ~ 4% TOTAL
perf-profile.cpu-cycles.__clear_user.read_zero.read_zero.vfs_read.sys_read
2.96e+09 ~ 4% -5.2% 2.806e+09 ~ 0% TOTAL perf-stat.cache-misses
3.86e+12 ~ 5% -5.2% 3.658e+12 ~ 1% TOTAL perf-stat.ref-cycles
Legend:
~XX%- stddev percent
[+-]XX% - change percent
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Aaron
echo 1 > /sys/kernel/debug/tracing/events/writeback/balance_dirty_pages/enable
echo 1 > /sys/kernel/debug/tracing/events/writeback/bdi_dirty_ratelimit/enable
echo 1 > /sys/kernel/debug/tracing/events/writeback/global_dirty_state/enable
echo 1 >
/sys/kernel/debug/tracing/events/writeback/writeback_single_inode/enable
mkfs -t xfs /dev/sdb1
mkfs -t xfs /dev/sdj1
mkfs -t xfs /dev/sdh1
mkfs -t xfs /dev/sde1
mkfs -t xfs /dev/sdc1
mkfs -t xfs /dev/sdk1
mkfs -t xfs /dev/sdd1
mkfs -t xfs /dev/sdf1
mkfs -t xfs /dev/sdg1
mkfs -t xfs /dev/sdi1
mkfs -t xfs /dev/sdl1
mount -t xfs -o nobarrier,inode64 /dev/sdb1 /fs/sdb1
mount -t xfs -o nobarrier,inode64 /dev/sdc1 /fs/sdc1
mount -t xfs -o nobarrier,inode64 /dev/sdd1 /fs/sdd1
mount -t xfs -o nobarrier,inode64 /dev/sde1 /fs/sde1
mount -t xfs -o nobarrier,inode64 /dev/sdf1 /fs/sdf1
mount -t xfs -o nobarrier,inode64 /dev/sdg1 /fs/sdg1
mount -t xfs -o nobarrier,inode64 /dev/sdh1 /fs/sdh1
mount -t xfs -o nobarrier,inode64 /dev/sdi1 /fs/sdi1
mount -t xfs -o nobarrier,inode64 /dev/sdj1 /fs/sdj1
mount -t xfs -o nobarrier,inode64 /dev/sdk1 /fs/sdk1
mount -t xfs -o nobarrier,inode64 /dev/sdl1 /fs/sdl1
dd if=/dev/zero of=/fs/sdb1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdc1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdd1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sde1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdf1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdg1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdh1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdi1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdj1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdk1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdl1/zero-1 status=noxfer &
dd if=/dev/zero of=/fs/sdb1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdc1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdd1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sde1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdf1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdg1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdh1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdi1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdj1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdk1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdl1/zero-2 status=noxfer &
dd if=/dev/zero of=/fs/sdb1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdc1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdd1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sde1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdf1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdg1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdh1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdi1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdj1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdk1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdl1/zero-3 status=noxfer &
dd if=/dev/zero of=/fs/sdb1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdc1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdd1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sde1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdf1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdg1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdh1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdi1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdj1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdk1/zero-4 status=noxfer &
dd if=/dev/zero of=/fs/sdl1/zero-4 status=noxfer &
dd
[PATCH 8/8] perf symbol: Don't demangle parameters and such by default
Some C++ symbols have very long name and they make column length
longer. Most of them are about parameters including templates and we
can ignore such info most of time IMHO.
This patch passes DMGL_NO_OPTS by default when calling bfd_demangle().
One can still see full symbols with -v/--verbose option.
before:
JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int,
JS::Value*, JS::Value*)
after:
JS_CallFunctionValue
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol-elf.c | 7 +--
tools/perf/util/symbol.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index d75349979e65..ec5ec1c9d9b5 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -939,8 +939,11 @@ new_symbol:
* to it...
*/
if (symbol_conf.demangle) {
- demangled = bfd_demangle(NULL, elf_name,
-DMGL_PARAMS | DMGL_ANSI);
+ int demangle_flags = DMGL_NO_OPTS;
+ if (verbose)
+ demangle_flags = DMGL_PARAMS | DMGL_ANSI;
+
+ demangled = bfd_demangle(NULL, elf_name,
demangle_flags);
if (demangled != NULL)
elf_name = demangled;
}
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index e7295e93cff9..c16dc16f83d5 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -59,6 +59,7 @@ extern Elf_Scn *elf_section_by_name(Elf *elf, GElf_Ehdr *ep,
#endif
#ifndef DMGL_PARAMS
+#define DMGL_NO_OPTS 0 /* For readability... */
#define DMGL_PARAMS (1 << 0) /* Include function args */
#define DMGL_ANSI(1 << 1) /* Include const, volatile, etc */
#endif
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] perf tools: Add name field into perf_hpp_fmt
It makes the code a bit simpler and easier to debug IMHO.
I guess it can also remove similar code in perf diff, but let's keep
it for a future work. :)
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/hists.c | 4 +-
tools/perf/ui/hist.c | 136 +-
tools/perf/util/hist.h| 1 +
tools/perf/util/sort.c| 6 +-
4 files changed, 66 insertions(+), 81 deletions(-)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 897b2e140428..f3fa4258b256 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -207,10 +207,8 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists,
if (perf_hpp__is_sort_entry(fmt))
sym_col = col_idx;
- fmt->header(fmt, , hists_to_evsel(hists));
-
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
- -1, ltrim(s),
+ -1, fmt->name,
renderer, "markup",
col_idx++, NULL);
}
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index b2d60a95f01d..b5fa7019d2e2 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -209,29 +209,26 @@ static int __hpp__sort_acc(struct hist_entry *a, struct
hist_entry *b,
return ret;
}
-#define __HPP_WIDTH_FN(_type, _str)\
-static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
- struct perf_hpp *hpp __maybe_unused, \
- struct perf_evsel *evsel) \
-{ \
- int len = fmt->user_len ?: fmt->len;\
- \
- if (symbol_conf.event_group)\
- len = max(len, evsel->nr_members * fmt->len); \
- \
- if (len < (int)strlen(_str))\
- len = strlen(_str); \
- \
- return len; \
-}
-
-#define __HPP_HEADER_FN(_type, _str) \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt, \
- struct perf_hpp *hpp,\
- struct perf_evsel *evsel)\
-{ \
- int len = hpp__width_##_type(fmt, hpp, evsel); \
- return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+static int hpp__width_fn(struct perf_hpp_fmt *fmt,
+struct perf_hpp *hpp __maybe_unused,
+struct perf_evsel *evsel)
+{
+ int len = fmt->user_len ?: fmt->len;
+
+ if (symbol_conf.event_group)
+ len = max(len, evsel->nr_members * fmt->len);
+
+ if (len < (int)strlen(fmt->name))
+ len = strlen(fmt->name);
+
+ return len;
+}
+
+static int hpp__header_fn(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+ struct perf_evsel *evsel)
+{
+ int len = hpp__width_fn(fmt, hpp, evsel);
+ return scnprintf(hpp->buf, hpp->size, "%*s", len, fmt->name);
}
static int hpp_color_scnprintf(struct perf_hpp *hpp, const char *fmt, ...)
@@ -337,38 +334,29 @@ static int64_t hpp__sort_##_type(struct hist_entry *a,
struct hist_entry *b) \
}
-#define HPP_PERCENT_FNS(_type, _str, _field) \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str) \
+#define HPP_PERCENT_FNS(_type, _field) \
__HPP_COLOR_PERCENT_FN(_type, _field) \
__HPP_ENTRY_PERCENT_FN(_type, _field) \
__HPP_SORT_FN(_type, _field)
-#define HPP_PERCENT_ACC_FNS(_type, _str, _field) \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str) \
+#define HPP_PERCENT_ACC_FNS(_type, _field) \
__HPP_COLOR_ACC_PERCENT_FN(_type, _field) \
__HPP_ENTRY_ACC_PERCENT_FN(_type, _field) \
__HPP_SORT_ACC_FN(_type, _field)
-#define HPP_RAW_FNS(_type, _str, _field) \
[PATCH 2/8] perf tools: Make __hpp__fmt() receive an additional len argument
So that it can properly handle alignment requirements later. To do
that, add percent_color_len_snprintf() fucntion to help coloring of
overhead columns.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 14 --
tools/perf/ui/gtk/hists.c | 8 +---
tools/perf/ui/hist.c | 43 +-
tools/perf/util/color.c| 16
tools/perf/util/color.h| 1 +
tools/perf/util/hist.h | 4 ++--
6 files changed, 54 insertions(+), 32 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a94b11fc5e00..02507ba944e3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -653,17 +653,18 @@ struct hpp_arg {
static int __hpp__slsmg_color_printf(struct perf_hpp *hpp, const char *fmt,
...)
{
struct hpp_arg *arg = hpp->ptr;
- int ret;
+ int ret, len;
va_list args;
double percent;
va_start(args, fmt);
+ len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
- ret = scnprintf(hpp->buf, hpp->size, fmt, percent);
+ ret = scnprintf(hpp->buf, hpp->size, fmt, len, percent);
slsmg_printf("%s", hpp->buf);
advance_hpp(hpp, ret);
@@ -681,7 +682,7 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused,\
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
- return __hpp__fmt(hpp, he, __hpp_get_##_field, " %6.2f%%", \
+ return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6, \
__hpp__slsmg_color_printf, true); \
}
@@ -697,13 +698,14 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused,\
struct hist_entry *he) \
{ \
if (!symbol_conf.cumulate_callchain) { \
- int ret = scnprintf(hpp->buf, hpp->size, "%8s", "N/A"); \
+ int ret = scnprintf(hpp->buf, hpp->size,\
+ "%*s", 8, "N/A"); \
slsmg_printf("%s", hpp->buf); \
\
return ret; \
} \
- return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %6.2f%%", \
- __hpp__slsmg_color_printf, true); \
+ return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%", \
+ 6, __hpp__slsmg_color_printf, true); \
}
__HPP_COLOR_PERCENT_FN(overhead, period)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 6ca60e482cdc..91f6cd7d2312 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -11,6 +11,7 @@
static int __percent_color_snprintf(struct perf_hpp *hpp, const char *fmt, ...)
{
int ret = 0;
+ int len;
va_list args;
double percent;
const char *markup;
@@ -18,6 +19,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp,
const char *fmt, ...)
size_t size = hpp->size;
va_start(args, fmt);
+ len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
@@ -25,7 +27,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp,
const char *fmt, ...)
if (markup)
ret += scnprintf(buf, size, markup);
- ret += scnprintf(buf + ret, size - ret, fmt, percent);
+ ret += scnprintf(buf + ret, size - ret, fmt, len, percent);
if (markup)
ret += scnprintf(buf + ret, size - ret, "");
@@ -43,7 +45,7 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt
*fmt __maybe_unused,
struct perf_hpp *hpp,
\
struct hist_entry *he)
\
{
\
- return __hpp__fmt(hpp, he, he_get_##_field, " %6.2f%%",
\
+ return __hpp__fmt(hpp, he, he_get_##_field, " %*.2f%%", 6,
\
__percent_color_snprintf, true);
\
}
@@ -57,7 +59,7 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt
*fmt __maybe_unused,
struct perf_hpp *hpp,
\
struct hist_entry *he)
[PATCH 4/8] perf report: Honor column width setting
Set column width and do not change it if user gives -w/--column-widths
option. It'll truncate longer symbols than the width if exists.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 18 +
tools/perf/ui/gtk/hists.c | 10 ++---
tools/perf/ui/hist.c | 84 +-
tools/perf/ui/stdio/hist.c | 4 +-
tools/perf/util/hist.h | 14 ---
tools/perf/util/sort.c | 49 +++-
6 files changed, 116 insertions(+), 63 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index c1d8d3925fe1..e07d4e848d5c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -678,12 +678,12 @@ static u64 __hpp_get_##_field(struct hist_entry *he)
\
} \
\
static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt, \
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
- return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6, \
- __hpp__slsmg_color_printf, true); \
+ return hpp__fmt(fmt, hpp, he, __hpp_get_##_field, " %*.2f%%", \
+ __hpp__slsmg_color_printf, true); \
}
#define __HPP_COLOR_ACC_PERCENT_FN(_type, _field) \
@@ -693,19 +693,20 @@ static u64 __hpp_get_acc_##_field(struct hist_entry *he)
\
} \
\
static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt, \
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
if (!symbol_conf.cumulate_callchain) { \
+ int len = fmt->user_len ?: fmt->len;\
int ret = scnprintf(hpp->buf, hpp->size,\
- "%*s", 8, "N/A"); \
+ "%*s", len, "N/A"); \
slsmg_printf("%s", hpp->buf); \
\
return ret; \
} \
- return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%", \
- 6, __hpp__slsmg_color_printf, true); \
+ return hpp__fmt(fmt, hpp, he, __hpp_get_acc_##_field, \
+ " %*.2f%%", __hpp__slsmg_color_printf, true); \
}
__HPP_COLOR_PERCENT_FN(overhead, period)
@@ -1549,6 +1550,9 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
memset(options, 0, sizeof(options));
+ if (symbol_conf.col_width_list_str)
+ perf_hpp__set_user_width(symbol_conf.col_width_list_str);
+
while (1) {
const struct thread *thread = NULL;
const struct dso *dso = NULL;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 91f6cd7d2312..897b2e140428 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -41,12 +41,12 @@ static u64 he_get_##_field(struct hist_entry *he)
\
return he->stat._field;
\
}
\
\
-static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused,\
+static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt *fmt,
\
struct perf_hpp *hpp,
\
struct hist_entry *he)
\
{
\
- return __hpp__fmt(hpp, he, he_get_##_field, " %*.2f%%", 6,
\
- __percent_color_snprintf, true);
\
+ return
[PATCH 7/8] perf tools: Fix column alignment when headers aren't shown on TUI
If user sets ui.show-headers config option to false, it didn't calculate default column width so it broke the alignment. This is because it does the calculation just before showing headers. Move it to the beginning of the hist browser so that it can be called regardless of the config option. Reported-by: Jiri Olsa Signed-off-by: Namhyung Kim --- tools/perf/ui/browsers/hists.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c index e07d4e848d5c..045c1e16ac59 100644 --- a/tools/perf/ui/browsers/hists.c +++ b/tools/perf/ui/browsers/hists.c @@ -850,9 +850,6 @@ static int hists__scnprintf_headers(char *buf, size_t size, struct hists *hists) if (perf_hpp__should_skip(fmt)) continue; - /* We need to ensure length of the columns header. */ - perf_hpp__reset_width(fmt, hists); - ret = fmt->header(fmt, _hpp, hists_to_evsel(hists)); if (advance_hpp_check(_hpp, ret)) break; @@ -1501,6 +1498,7 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events, char buf[64]; char script_opt[64]; int delay_secs = hbt ? hbt->refresh : 0; + struct perf_hpp_fmt *fmt; #define HIST_BROWSER_HELP_COMMON \ "h/?/F1Show this window\n" \ @@ -1550,6 +1548,9 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events, memset(options, 0, sizeof(options)); + perf_hpp__for_each_format(fmt) + perf_hpp__reset_width(fmt, hists); + if (symbol_conf.col_width_list_str) perf_hpp__set_user_width(symbol_conf.col_width_list_str); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 0/8] perf tools: Honor column width setting (v3)
Hello, This patchset is to control perf report/top output column width by -w/--column-widths option so that it can fit into the terminal size. The -w option is there for perf report but it ignored by recent output field changed due to some reason. This patchset fixes it and supports perf top also. This is sometimes useful if your terminal is small and there's some C++ applications which have amazingly long symbol names. Without this patchset user might not see those symbols on TUI, since it maps left/right arrow keys to other functions. The -w option sets column width starting from the first column (overhead or optional overhead_children column unless -F option is given). It doesn't make sense to limit those overhead columns so it's not a hard-limit for them. But it *is* a hard-limit for other columns such as comm, dso, symbol, and so on. One can use 0 not to limit/force a width for those columns. For example: $ perf report --stdio -s comm,dso ... # Overhead Command Shared Object # ... . # 71.08% gnome-shell perf-1497.map 9.23% gnome-shell swrast_dri.so 3.99% Xorg [unknown] 3.18% Xorg [kernel.kallsyms] 2.93% gnome-shell [kernel.kallsyms] 2.41% swapper [kernel.kallsyms] 1.55% synergys libpthread-2.15.so 1.08% synergys synergys 0.68% systemd-journal [kernel.kallsyms] 0.59% synergys libstdc++.so.6.0.17 0.58% gnome-shell libc-2.15.so 0.54% kworker/0:2 [kernel.kallsyms] 0.20% systemd-journal [unknown] 0.19% gnome-shell libclutter-1.0.so.0.1000.8.#prelink#.1kh1we (deleted) 0.18% firefox libxul.so (deleted) 0.17% gnome-shell libcogl.so.9.1.1.#prelink#.ZL3fn1 (deleted) 0.14% firefox [kernel.kallsyms] 0.14% gnome-shell libgobject-2.0.so.0.3200.4 0.13% gnome-shell libpthread-2.15.so 0.11% synergys [kernel.kallsyms] 0.10% perf [kernel.kallsyms] $ perf report --stdio -s comm,dso -w 0,10,20 # 0 means no limit ... # Overhead Command Shared Object # .. # 71.08% gnome-shel perf-1497.map 9.23% gnome-shel swrast_dri.so 3.99% Xorg[unknown] 3.18% Xorg[kernel.kallsyms] 2.93% gnome-shel [kernel.kallsyms] 2.41% swapper [kernel.kallsyms] 1.55% synergyslibpthread-2.15.so 1.08% synergyssynergys 0.68% systemd-jo [kernel.kallsyms] 0.59% synergyslibstdc++.so.6.0.17 0.58% gnome-shel libc-2.15.so 0.54% kworker/0: [kernel.kallsyms] 0.20% systemd-jo [unknown] 0.19% gnome-shel libclutter-1.0.so.0. 0.18% firefox libxul.so (deleted) 0.17% gnome-shel libcogl.so.9.1.1.#pr 0.14% firefox [kernel.kallsyms] 0.14% gnome-shel libgobject-2.0.so.0. 0.13% gnome-shel libpthread-2.15.so 0.11% synergys[kernel.kallsyms] 0.10% perf[kernel.kallsyms] * changes in v3: - use single function for fmt->header() and ->width() (Jiri) - limit symbol sort print function to given width (Jiri) - do not demangle C++ function parameters by default * changes in v2: - fix TUI alignment when no header is shown (Jiri) - change printing order of pid sort key (Jiri) You can also get this from 'perf/width-v3' branch on my tree git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (8): perf tools: Left-align output contents perf tools: Make __hpp__fmt() receive an additional len argument perf tools: Save column length in perf_hpp_fmt perf report: Honor column width setting perf top: Add -w option for setting column width perf tools: Add name field into perf_hpp_fmt perf tools: Fix column alignment when headers aren't shown on TUI perf symbol:
[PATCH 3/8] perf tools: Save column length in perf_hpp_fmt
Save column length in the hpp format and pass it to print functions.
This is a preparation for users to control column width in the output.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 2 +-
tools/perf/ui/hist.c | 135 +++--
tools/perf/util/hist.h | 2 +
tools/perf/util/sort.c | 3 +-
4 files changed, 94 insertions(+), 48 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 02507ba944e3..c1d8d3925fe1 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -849,7 +849,7 @@ static int hists__scnprintf_headers(char *buf, size_t size,
struct hists *hists)
if (perf_hpp__should_skip(fmt))
continue;
- /* We need to add the length of the columns header. */
+ /* We need to ensure length of the columns header. */
perf_hpp__reset_width(fmt, hists);
ret = fmt->header(fmt, _hpp, hists_to_evsel(hists));
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index c6cffbd0b0e1..e28ca972d046 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -110,7 +110,7 @@ int __hpp__fmt_acc(struct perf_hpp *hpp, struct hist_entry
*he,
{
if (!symbol_conf.cumulate_callchain) {
return snprintf(hpp->buf, hpp->size, "%*s",
- fmt_percent ? 8 : 12, "N/A");
+ fmt_percent ? len + 2 : len + 1, "N/A");
}
return __hpp__fmt(hpp, he, get_field, fmt, len, print_fn, fmt_percent);
@@ -190,32 +190,31 @@ static int __hpp__sort_acc(struct hist_entry *a, struct
hist_entry *b,
return ret;
}
-#define __HPP_HEADER_FN(_type, _str, _min_width, _unit_width) \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
- struct perf_hpp *hpp,\
- struct perf_evsel *evsel)\
-{ \
- int len = _min_width; \
- \
- if (symbol_conf.event_group)\
- len = max(len, evsel->nr_members * _unit_width);\
- \
- return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
-}
-
-#define __HPP_WIDTH_FN(_type, _min_width, _unit_width)
\
-static int hpp__width_##_type(struct perf_hpp_fmt *fmt __maybe_unused, \
+#define __HPP_WIDTH_FN(_type, _str)\
+static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
struct perf_hpp *hpp __maybe_unused, \
struct perf_evsel *evsel) \
{ \
- int len = _min_width; \
+ int len = fmt->len; \
\
if (symbol_conf.event_group)\
- len = max(len, evsel->nr_members * _unit_width);\
+ len = max(len, evsel->nr_members * len);\
+ \
+ if (len < (int)strlen(_str))\
+ len = strlen(_str); \
\
return len; \
}
+#define __HPP_HEADER_FN(_type, _str) \
+static int hpp__header_##_type(struct perf_hpp_fmt *fmt, \
+ struct perf_hpp *hpp,\
+ struct perf_evsel *evsel)\
+{ \
+ int len = hpp__width_##_type(fmt, hpp, evsel); \
+ return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+}
+
static int hpp_color_scnprintf(struct perf_hpp *hpp, const char *fmt, ...)
{
va_list args;
@@ -251,18 +250,19 @@ static u64 he_get_##_field(struct hist_entry *he)
\
return he->stat._field;
\
}
\
\
-static int hpp__color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
[PATCH 5/8] perf top: Add -w option for setting column width
Add -w/--column-widths option like perf report does so that users are
able to see symbols even with some very long C++ library/functions.
It can be a list separated by comma for each column.
$ perf top -w 0,20,30
The value of 0 means there's no limit.
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 2 +-
tools/perf/Documentation/perf-top.txt| 6 ++
tools/perf/builtin-top.c | 3 +++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index d2b59af62bc0..d561e0214f52 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -147,7 +147,7 @@ OPTIONS
-w::
--column-widths=::
Force each column width to the provided list, for large terminal
- readability.
+ readability. 0 means no limit (default behavior).
-t::
--field-separator=::
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 180ae02137a5..28fdee394880 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -193,6 +193,12 @@ Default is to monitor all CPUS.
sum of shown entries will be always 100%. "absolute" means it retains
the original value before and after the filter is applied.
+-w::
+--column-widths=::
+ Force each column width to the provided list, for large terminal
+ readability. 0 means no limit (default behavior).
+
+
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 377971dc89a3..bde216b2071c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1131,6 +1131,9 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
"Don't show entries under that percent",
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
"How to display percentage of filtered entries",
parse_filter_percentage),
+ OPT_STRING('w', "column-widths", _conf.col_width_list_str,
+ "width[,width...]",
+ "don't try to adjust column width, use these fixed values"),
OPT_END()
};
const char * const top_usage[] = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] perf tools: Left-align output contents
Now perf left-aligns column headers but the contents does not. It
should have same alignment. This requires a change in pid sort key -
it consists of two part (pid and comm). As length of comm can be vary
it'd be better to change the order of them.
Thanks to Jiri Olsa for pointing this out.
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 14e5a039bc45..eda9ee836cee 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -70,12 +70,12 @@ static int hist_entry__thread_snprintf(struct hist_entry
*he, char *bf,
size_t size, unsigned int width)
{
const char *comm = thread__comm_str(he->thread);
- return repsep_snprintf(bf, size, "%*s:%5d", width - 6,
- comm ?: "", he->thread->tid);
+ return repsep_snprintf(bf, size, "%5d:%-*s", he->thread->tid,
+ width - 6, comm ?: "");
}
struct sort_entry sort_thread = {
- .se_header = "Command: Pid",
+ .se_header = " Pid:Command",
.se_cmp = sort__thread_cmp,
.se_snprintf= hist_entry__thread_snprintf,
.se_width_idx = HISTC_THREAD,
@@ -106,7 +106,7 @@ sort__comm_sort(struct hist_entry *left, struct hist_entry
*right)
static int hist_entry__comm_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*s", width, comm__str(he->comm));
+ return repsep_snprintf(bf, size, "%-*s", width, comm__str(he->comm));
}
struct sort_entry sort_comm = {
@@ -305,7 +305,7 @@ static int hist_entry__srcline_snprintf(struct hist_entry
*he, char *bf,
size_t size,
unsigned int width __maybe_unused)
{
- return repsep_snprintf(bf, size, "%s", he->srcline);
+ return repsep_snprintf(bf, size, "%-s", he->srcline);
}
struct sort_entry sort_srcline = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v4] input: drv260x: Add TI drv260x haptics driver
Hi Dan,
On Wed, Jul 30, 2014 at 09:14:40AM -0500, Dan Murphy wrote:
> Add the TI drv260x haptics/vibrator driver.
> This device uses the input force feedback
> to produce a wave form to driver an
> ERM or LRA actuator device.
>
> The initial driver supports the devices
> real time playback mode. But the device
> has additional wave patterns in ROM.
>
> This functionality will be added in
> future patchsets.
>
> Product data sheet is located here:
> http://www.ti.com/product/drv2605
>
> Signed-off-by: Dan Murphy
> ---
>
> v4 - Convert regulator to devm, added error checking where required,
> updated bindings doc, moved dt parsing to separate call and made platform
> data the first data point, moved vibrator enable and mode programming from
> play entry to worker thread, added user check and input mutex in
> suspend/resume
> calls, moved platform data to individual file and into include platform-data
> directory,
> removed file names from file headers -
> https://patchwork.kernel.org/patch/4642221/
> v3 - Updated binding doc, changed to memless device, updated input alloc to
> devm, removed mutex locking, add sanity checks for mode and library -
> https://patchwork.kernel.org/patch/4635421/
> v2 - Fixed binding doc and patch headline -
> https://patchwork.kernel.org/patch/4619641/
Thank you for making changes, just a few more small nits from me and if
Mark is OK with the bindings then I will merge it.
...
> +
> +
> + if (haptics->mode < DRV260X_LRA_MODE ||
> + haptics->mode > DRV260X_ERM_MODE) {
> + dev_err(>dev,
> + "Vibrator mode is invalid: %i\n",
> + haptics->mode);
> + return -EINVAL;
Indentation for the body is wrong here.
> + }
> +
> + if (haptics->library < DRV260X_LIB_SEL_DEFAULT ||
> + haptics->library > DRV260X_LIB_F) {
> + dev_err(>dev,
> + "Library value is invalid: %i\n",
> haptics->library);
> + return -EINVAL;
Here as well
> + }
> +
> + haptics->regulator = devm_regulator_get(>dev, "vbat");
> + if (IS_ERR(haptics->regulator)) {
> + ret = PTR_ERR(haptics->regulator);
> + dev_err(>dev,
> + "unable to get regulator, error: %d\n", ret);
> + goto err_regulator;
Here and below you can return directly from the probe function, there is
no need keeping "empty" labels.
> + }
> +
> + haptics->enable_gpio = devm_gpiod_get(>dev, "enable");
> + if (IS_ERR(haptics->enable_gpio)) {
> + ret = PTR_ERR(haptics->enable_gpio);
> + if (ret != -ENOENT && ret != -ENOSYS)
> + goto err_gpio;
> +
> + haptics->enable_gpio = NULL;
> + } else {
> + gpiod_direction_output(haptics->enable_gpio, 1);
> + }
> +
> + haptics->input_dev = devm_input_allocate_device(>dev);
> + if (haptics->input_dev == NULL) {
> + dev_err(>dev, "Failed to allocate input device\n");
> + ret = -ENOMEM;
> + goto err_input_alloc;
> + }
> +
> + haptics->input_dev->name = "drv260x:haptics";
> + haptics->input_dev->dev.parent = client->dev.parent;
> + haptics->input_dev->close = drv260x_close;
> + input_set_drvdata(haptics->input_dev, haptics);
> + input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
> +
> + ret = input_ff_create_memless(haptics->input_dev, NULL,
> + drv260x_haptics_play);
> + if (ret < 0) {
> + dev_err(>dev, "input_ff_create() failed: %d\n",
> + ret);
> + goto err_ff_create;
> + }
> +
> + INIT_WORK(>work, drv260x_worker);
> +
> + haptics->client = client;
> + i2c_set_clientdata(client, haptics);
> +
> + haptics->regmap = devm_regmap_init_i2c(client, _regmap_config);
> + if (IS_ERR(haptics->regmap)) {
> + ret = PTR_ERR(haptics->regmap);
> + dev_err(>dev, "Failed to allocate register map: %d\n",
> + ret);
> + goto err_regmap;
> + }
> +
> + drv260x_init(haptics);
I believe we should abort if init fails.
> +
> + ret = input_register_device(haptics->input_dev);
> + if (ret < 0) {
> + dev_err(>dev, "couldn't register input device: %d\n",
> + ret);
> + goto err_iff;
> + }
> + return 0;
> +
> +err_iff:
> +err_regmap:
> +err_ff_create:
> +err_input_alloc:
> +err_gpio:
> +err_regulator:
> + return ret;
> +}
> +
> +static int drv260x_remove(struct i2c_client *client)
> +{
> + struct drv260x_data *haptics = i2c_get_clientdata(client);
> +
> + cancel_work_sync(>work);
> +
> + regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_STANDBY);
> + gpiod_set_value(haptics->enable_gpio, 0);
Since you provide close() method and you do not activate
Re: [PATCH v2 2/2] ksm: Provide support to use deferrable timers for scanner thread
On 07/31/2014 03:17 AM, Andrew Morton wrote:
On Fri, 25 Jul 2014 20:18:18 +0530 Chintan Pandya
wrote:
KSM thread to scan pages is scheduled on definite timeout. That wakes
up CPU from idle state and hence may affect the power consumption.
Provide an optional support to use deferrable timer which suites
low-power use-cases.
Typically, on our setup we observed, 10% less power consumption with
some use-cases in which CPU goes to power collapse frequently. For
example, playing audio while typically CPU remains idle.
To enable deferrable timers,
$ echo 1> /sys/kernel/mm/ksm/deferrable_timer
This could not have been the version which you tested. What's up?
My bad :( I will be careful next time
---
a/mm/ksm.c~ksm-provide-support-to-use-deferrable-timers-for-scanner-thread-fix-fix-2
+++ a/mm/ksm.c
@@ -1720,8 +1720,6 @@ static int ksmd_should_run(void)
static int ksm_scan_thread(void *nothing)
{
- signed long to;
-
set_freezable();
set_user_nice(current, 5);
@@ -1735,7 +1733,9 @@ static int ksm_scan_thread(void *nothing
try_to_freeze();
if (ksmd_should_run()) {
- timeout = msecs_to_jiffies(ksm_thread_sleep_millisecs);
+ signed long to;
+
+ to = msecs_to_jiffies(ksm_thread_sleep_millisecs);
if (use_deferrable_timer)
schedule_timeout_deferrable_interruptible(to);
else
_
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: BUG when __kmap_atomic_idx crosses boundary
On 07/30/2014 02:36 PM, Andrew Morton wrote: On Wed, 30 Jul 2014 14:22:35 +0530 Chintan Pandya wrote: __kmap_atomic_idx>= KM_TYPE_NR or< ZERO is a bug. Report it even if CONFIG_DEBUG_HIGHMEM is not enabled. That saves much debugging efforts. Please take considerably more care when preparing patch changelogs. Okay. I will prepare new commit message. kmap_atomic() is a very commonly called function so we'll need much more detail than this to justify adding overhead to it. I don't think CONFIG_DEBUG_HIGHMEM really needs to exist. We could do s/CONFIG_DEBUG_HIGHMEM/CONFIG_DEBUG_VM/g and perhaps your secret bug whatever it was would have been found more easily. Um, we didn't get bug directly hitting here. __kmap_atomic_idx should not be equal to KM_TYPE_NR anyway. So, at least I will share that patch. For changing DEBUG_HIGHMEM to DEBUG_VM, I will work on it. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] staging:r8190: coding style: Fixed checkpatch reported Error
Hi Greg, I have resent all the patches in order. Please review. Regards Sanjeev Sharma -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, July 31, 2014 5:51 AM To: Sharma, Sanjeev Cc: de...@driverdev.osuosl.org; oor...@gmail.com; linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging:r8190: coding style: Fixed checkpatch reported Error On Tue, Jul 29, 2014 at 04:41:53PM +0530, Sanjeev Sharma wrote: > This is a patch to the r8190_rtl8256.c file that fixes checkpatch > reported space & coding style issues. > > Signed-off-by: Sanjeev Sharma Please use a ' ' character... Please resend all of your patches, they don't have signed-off-by lines, and I don't know what order to apply them in, even if I could do so. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM/ARM64: don't enter kgdb when userspace executes a kgdb break instruction.
Hi, On Wed, Jul 30, 2014 at 12:24:14PM +0100, Will Deacon wrote: > Whilst this sounds like a worrying problem, I've failed to reproduce it > on arm64. Executing a brk instruction with either KGDB_DYN_DGB_BRK_IMM or > KDBG_COMPILED_DBG_BRK_IMM immediates from userspace results in a SIGTRAP being > delivered, assumedly because kgdb_handle_exception simply returns when kgdb > isn't active. >From what I can tell, the break hooks are registered so long as kgdb is enabled at all - i.e., the kernel was compiled with CONFIG_KGDB=y and, for example, CONFIG_KGDB_SERIAL_CONSOLE=y and kgdboc was passed on the kernel command line. kgdb_handle_exception doesn't seem to check whether the debugger is active. > The following (totally untested) diff is simpler for arm64, but again, I'm > not sure we even have a problem here. This diff also fixes the problem. I don't have a strong preference for either approach, so I can revise the patch with this approach instead if you'd prefer that. > On which systems have you managed to reproduce this and how? I first reproduced this on a Raspberry Pi. The recommended distro, Raspbian, distributes a kernel compiled with CONFIG_KGDB=y, CONFIG_KGDB_KDB=y, and CONFIG_KDB_KEYBOARD=y, so it was sufficient to have a keyboard plugged in. However, I also reproduced it by booting with kgdboc on the command line, as CONFIG_KGDB_SERIAL_CONSOLE was also enabled. Additionally, I reproduced it and then verified that my patch fixed it on self-compiled kernels. I don't currenty have access to a physical ARM64 board, so I did all the testing for this with QEMU (loosely following the instructions here: http://www.bennee.com/~alex/blog/2014/05/09/running-linux-in-qemus-aarch64-system-emulation-mode/). Again, it was sufficient to build with CONFIG_KGDB=y and CONFIG_KGDB_SERIAL_CONSOLE=y and boot with kgdboc enabled, i.e., passing --append "console=ttyAMA0 kgdboc=ttyAMA0,115200" to QEMU. Here's a snippet from that session. # ./brk Entering kdb (current=0xffc07df60a80, pid 71) on processor 0 Oops: (null) due to oops @ 0x4000d8 dCPU: 0 PID: 71 Comm: brk Not tainted 3.16.0-rc7ajb #2 dtask: ffc07df60a80 ti: ffc07d0c task.ti: ffc07d0c PC is at 0x4000d8 LR is at 0x0 pc : [<004000d8>] lr : [<>] pstate: sp : 007fceefcdd0 x29: x28: x27: x26: x25: x24: x23: x22: x21: x20: x19: x18: x17: x16: x15: x14: x13: x12: x11: x10: x9 : x8 : x7 : x6 : x5 : x4 : x3 : x2 : x1 : x0 : Let me know if you still have trouble reproducing this. Thanks again! Omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] staging:r8180: coding style: Fixed commenting style
This is a patch to the r8180_93cx6.c file that fixes commenting style warning Signed-off-by: Sanjeev Sharma --- Changes in v2: - Added signed-off field. drivers/staging/rtl8192u/r8180_93cx6.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c b/drivers/staging/rtl8192u/r8180_93cx6.c index fb8a7a8..97d9b3f 100644 --- a/drivers/staging/rtl8192u/r8180_93cx6.c +++ b/drivers/staging/rtl8192u/r8180_93cx6.c @@ -103,7 +103,7 @@ u32 eprom_read(struct net_device *dev, u32 addr) u32 ret; ret = 0; - //enable EPROM programming + /* enable EPROM programming */ write_nic_byte_E(dev, EPROM_CMD, (EPROM_CMD_PROGRAM
[PATCH v2 2/3] staging:r8180: coding style: Fixed too long lines
This is a patch to the r8180_93cx6.h file that fixes long lines along with some additional warning. Signed-off-by: Sanjeev Sharma --- Changes in v2: - Added signed-off field. drivers/staging/rtl8192u/r8180_93cx6.h | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rtl8192u/r8180_93cx6.h b/drivers/staging/rtl8192u/r8180_93cx6.h index ee55dbf..b840348 100644 --- a/drivers/staging/rtl8192u/r8180_93cx6.h +++ b/drivers/staging/rtl8192u/r8180_93cx6.h @@ -3,11 +3,14 @@ Copyright (C) Andrea Merello 2004-2005 Released under the terms of GPL (General Public Licence) - Parts of this driver are based on the GPL part of the official realtek driver - Parts of this driver are based on the rtl8180 driver skeleton from Patric Schenke & Andres Salomon + Parts of this driver are based on the GPL part of the + official realtek driver + Parts of this driver are based on the rtl8180 driver skeleton + from Patric Schenke & Andres Salomon Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver - We want to thank the Authors of such projects and the Ndiswrapper project Authors. + We want to thank the Authors of such projects and the Ndiswrapper + project Authors. */ /*This files contains card eeprom (93c46 or 93c56) programming routines*/ @@ -37,4 +40,4 @@ #define EPROM_TXPW1 0x3d -u32 eprom_read(struct net_device *dev,u32 addr); //reads a 16 bits word +u32 eprom_read(struct net_device *dev, u32 addr); /* reads a 16 bits word */ -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] staging:r8190: coding style: Fixed checkpatch reported Error
This is a patch to the r8190_rtl8256.c file that fixes
checkpatch reported space & coding style issues.
Signed-off-by: Sanjeev Sharma
---
Changes in v2:
- Added space character in the signed-off-by field.
drivers/staging/rtl8192u/r8190_rtl8256.c | 169 +++
1 file changed, 79 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c
b/drivers/staging/rtl8192u/r8190_rtl8256.c
index 08e1bc9..43ed768 100644
--- a/drivers/staging/rtl8192u/r8190_rtl8256.c
+++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
@@ -23,62 +23,64 @@
* Return: NONE
* Note: 8226 support both 20M and 40 MHz
*---*/
-void PHY_SetRF8256Bandwidth(struct net_device *dev , HT_CHANNEL_WIDTH
Bandwidth) //20M or 40M
+void PHY_SetRF8256Bandwidth(struct net_device *dev , HT_CHANNEL_WIDTH
Bandwidth)
{
u8 eRFPath;
struct r8192_priv *priv = ieee80211_priv(dev);
- //for(eRFPath = RF90_PATH_A; eRFPath NumTotalRFPath;
eRFPath++)
- for(eRFPath = 0; eRFPath NumTotalRFPath;
+* eRFPath++)
+*/
+ for (eRFPath = 0; eRFPath < RF90_PATH_MAX; eRFPath++) {
if (!rtl8192_phy_CheckIsLegalRFPath(dev, eRFPath))
continue;
- switch (Bandwidth)
- {
- case HT_CHANNEL_WIDTH_20:
- if(priv->card_8192_version == VERSION_819xU_A
|| priv->card_8192_version == VERSION_819xU_B)// 8256 D-cut, E-cut, xiong:
consider it later!
- {
- rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x100); //phy para:1ba
- rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x2c, bMask12Bits, 0x3d7);
- rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x0e, bMask12Bits, 0x021);
-
- //cosa add for sd3's request 01/23/2008
- rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x14, bMask12Bits, 0x5ab);
- }
- else
- {
+ switch (Bandwidth) {
+ case HT_CHANNEL_WIDTH_20:
+ if (priv->card_8192_version == VERSION_819xU_A
+ || priv->card_8192_version
+ == VERSION_819xU_B) { /* 8256 D-cut,
E-cut, xiong: consider it later! */
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0b, bMask12Bits, 0x100); /*
phy para:1ba */
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x2c, bMask12Bits, 0x3d7);
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x0e, bMask12Bits, 0x021);
+
+ /* cosa add for sd3's request 01/23/2008
+*/
+ rtl8192_phy_SetRFReg(dev,
+ (RF90_RADIO_PATH_E)eRFPath,
+ 0x14, bMask12Bits, 0x5ab);
+ } else {
RT_TRACE(COMP_ERR,
"PHY_SetRF8256Bandwidth(): unknown hardware version\n");
- }
-
+ }
break;
- case HT_CHANNEL_WIDTH_20_40:
- if(priv->card_8192_version == VERSION_819xU_A
||priv->card_8192_version == VERSION_819xU_B)// 8256 D-cut, E-cut, xiong:
consider it later!
- {
+ case HT_CHANNEL_WIDTH_20_40:
+ if (priv->card_8192_version == VERSION_819xU_A
|| priv->card_8192_version == VERSION_819xU_B) { /* 8256 D-cut, E-cut, xiong:
consider it later! */
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x0b, bMask12Bits, 0x300); //phy para:3ba
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x2c, bMask12Bits, 0x3df);
rtl8192_phy_SetRFReg(dev,
(RF90_RADIO_PATH_E)eRFPath, 0x0e, bMask12Bits, 0x0a1);
//cosa add for sd3's request 01/23/2008
- if(priv->chan == 3 || priv->chan == 9)
//I need
RE: [f2fs-dev] [PATCH] f2fs: reduce competition among node page writes
Hi Changman,
> -Original Message-
> From: Changman Lee [mailto:cm224@samsung.com]
> Sent: Thursday, July 31, 2014 10:07 AM
> To: Chao Yu
> Cc: 'Jaegeuk Kim'; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: reduce competition among node page
> writes
>
> Hi Chao,
>
> On Wed, Jul 30, 2014 at 09:07:49PM +0800, Chao Yu wrote:
> > Hi Jaegeuk Changman,
> >
> > > -Original Message-
> > > From: Chao Yu [mailto:chao2...@samsung.com]
> > > Sent: Thursday, July 03, 2014 6:59 PM
> > > To: Jaegeuk Kim; Changman Lee
> > > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Subject: [f2fs-dev] [PATCH] f2fs: reduce competition among node page
> > > writes
> > >
> > > We do not need to block on ->node_write among different node page writers
> > > e.g.
> > > fsync/flush, unless we have a node page writer from write_checkpoint.
> > > So it's better use rw_semaphore instead of mutex type for ->node_write to
> > > promote performance.
> >
> > If you could have time to help explaining the problem of this patch, I will
> > be
> > appreciated for that.
>
> I have no clue. Except checkpoint, I don't know why need to block to
> write node page.
> Do you have any problem when you test with this patch?
I don't have.
I send this patch about one month ago, but got no respond.
So I want to ask if any problem in this patch or forget to look at this patch?
To Jaegeuk:
Any idea about this patch?
>
> >
> > Another question is what is ->writepages in sbi used for? I'm not quite
> > clear.
> >
>
> I remember it is for writing data pages per thread as much as possible.
> When multi-threads write some files simultaneously, multi-threads contended
> with
> each other to allocate a block. So block allocation was interleaved
> across threads. It makes fragmentation of file.
Thank you for the explanation! :)
I think what you say is reasonable.
Previously I tested without this lock, although I found that the blocks written
_almost_ were continuous in each '->writepages()'. Still I think we can gain
more
from readahead continuous block when using this lock, rather than remove it for
promoting concurrent of writers.
Thanks,
Yu
>
> Thanks,
>
> > Thanks,
> >
> > >
> > > Signed-off-by: Chao Yu
> > > ---
> > > fs/f2fs/checkpoint.c |6 +++---
> > > fs/f2fs/f2fs.h |2 +-
> > > fs/f2fs/node.c |4 ++--
> > > fs/f2fs/super.c |2 +-
> > > 4 files changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > > index 0b4710c..eec406b 100644
> > > --- a/fs/f2fs/checkpoint.c
> > > +++ b/fs/f2fs/checkpoint.c
> > > @@ -714,10 +714,10 @@ retry_flush_dents:
> > >* until finishing nat/sit flush.
> > >*/
> > > retry_flush_nodes:
> > > - mutex_lock(>node_write);
> > > + down_write(>node_write);
> > >
> > > if (get_pages(sbi, F2FS_DIRTY_NODES)) {
> > > - mutex_unlock(>node_write);
> > > + up_write(>node_write);
> > > sync_node_pages(sbi, 0, );
> > > goto retry_flush_nodes;
> > > }
> > > @@ -726,7 +726,7 @@ retry_flush_nodes:
> > >
> > > static void unblock_operations(struct f2fs_sb_info *sbi)
> > > {
> > > - mutex_unlock(>node_write);
> > > + up_write(>node_write);
> > > f2fs_unlock_all(sbi);
> > > }
> > >
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > index ae3b4ac..ca30b5a 100644
> > > --- a/fs/f2fs/f2fs.h
> > > +++ b/fs/f2fs/f2fs.h
> > > @@ -444,7 +444,7 @@ struct f2fs_sb_info {
> > > struct inode *meta_inode; /* cache meta blocks */
> > > struct mutex cp_mutex; /* checkpoint procedure lock */
> > > struct rw_semaphore cp_rwsem; /* blocking FS operations */
> > > - struct mutex node_write;/* locking node writes */
> > > + struct rw_semaphore node_write; /* locking node writes */
> > > struct mutex writepages;/* mutex for writepages() */
> > > bool por_doing; /* recovery is doing or not */
> > > wait_queue_head_t cp_wait;
> > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > > index a90f51d..7b5b5de 100644
> > > --- a/fs/f2fs/node.c
> > > +++ b/fs/f2fs/node.c
> > > @@ -1231,12 +1231,12 @@ static int f2fs_write_node_page(struct page *page,
> > > if (wbc->for_reclaim)
> > > goto redirty_out;
> > >
> > > - mutex_lock(>node_write);
> > > + down_read(>node_write);
> > > set_page_writeback(page);
> > > write_node_page(sbi, page, , nid, ni.blk_addr, _addr);
> > > set_node_addr(sbi, , new_addr, is_fsync_dnode(page));
> > > dec_page_count(sbi, F2FS_DIRTY_NODES);
> > > - mutex_unlock(>node_write);
> > > + up_read(>node_write);
> > > unlock_page(page);
> > > return 0;
> > >
> > > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > > index 8f96d93..bed9413 100644
> > > --- a/fs/f2fs/super.c
> > >
[PATCH v2 0/3] Fixed commenting style problem
AddedSigned-off-by: line that was missing. Sanjeev Sharma (3): staging:r8180: coding style: Fixed commenting style staging:r8180: coding style: Fixed too long lines staging:r8190: coding style: Fixed checkpatch reported Error drivers/staging/rtl8192u/r8180_93cx6.c | 15 +-- drivers/staging/rtl8192u/r8180_93cx6.h | 11 +- drivers/staging/rtl8192u/r8190_rtl8256.c | 169 +++ 3 files changed, 95 insertions(+), 100 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm64: LLVMLinux: Calculate current_thread_info from current_stack_pointer
Hi,
Am 31.07.2014 01:57, schrieb beh...@converseincode.com:
> From: Behan Webster
>
> Use the global current_stack_pointer to get the value of the stack pointer.
> This change supports being able to compile the kernel with both gcc and clang.
>
> Signed-off-by: Behan Webster
> Signed-off-by: Mark Charlebois
> Reviewed-by: Jan-Simon M??ller
Something went wrong with ö encoding here and in 2/4.
> ---
> arch/arm64/include/asm/thread_info.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/thread_info.h
> b/arch/arm64/include/asm/thread_info.h
> index e6b6094..c2432d2 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -80,8 +80,8 @@ static inline struct thread_info *current_thread_info(void)
> __attribute_const__;
>
> static inline struct thread_info *current_thread_info(void)
> {
> - register unsigned long sp asm ("sp");
> - return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
> + return (struct thread_info *) \
This is not a macro, so \ seems superfluous.
Looks okay otherwise.
Regards,
Andreas
> + (current_stack_pointer & ~(THREAD_SIZE - 1));
> }
>
> #define thread_saved_pc(tsk) \
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 3/4] drivers: dma-coherent: add initialization from device tree
Hello,
On 2014-07-31 01:49, Grant Likely wrote:
On Tue, Jul 29, 2014 at 11:33 PM, Marek Szyprowski
wrote:
Hello,
On 2014-07-29 23:54, Grant Likely wrote:
On Mon, 14 Jul 2014 10:28:06 +0200, Marek Szyprowski
wrote:
Initialization procedure of dma coherent pool has been split into two
parts, so memory pool can now be initialized without assigning to
particular struct device. Then initialized region can be assigned to
more than one struct device. To protect from concurent allocations from
different devices, a spinlock has been added to dma_coherent_mem
structure. The last part of this patch adds support for handling
'shared-dma-pool' reserved-memory device tree nodes.
Signed-off-by: Marek Szyprowski
I think this looks okay. It isn't in my area of expertise though.
Comments below.
---
drivers/base/dma-coherent.c | 137
++--
1 file changed, 118 insertions(+), 19 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 7d6e84a51424..7185a4f247e1 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -14,11 +14,14 @@ struct dma_coherent_mem {
int size;
int flags;
unsigned long *bitmap;
+ spinlock_t spinlock;
};
-int dma_declare_coherent_memory(struct device *dev, phys_addr_t
phys_addr,
- dma_addr_t device_addr, size_t size, int
flags)
+static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t
device_addr,
+size_t size, int flags,
+struct dma_coherent_mem **mem)
This is a bit odd. Why wouldn't you return the dma_mem pointer directly
instead of passing in a **mem argument?
Because this function (as a direct successor of dma_declare_coherent_memory)
doesn't
return typical error codes, but some custom values like DMA_MEMORY_MAP,
DMA_MEMORY_IO
or zero (which means failure). I wanted to avoid confusion with typical
error
handling path and IS_ERR/ERR_PTR usage used widely in other functions. This
probably
should be unified with the rest of kernel some day, but right now I wanted
to keep
the patch simple and easy to review.
{
+ struct dma_coherent_mem *dma_mem = NULL;
void __iomem *mem_base = NULL;
int pages = size >> PAGE_SHIFT;
int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
@@ -27,27 +30,26 @@ int dma_declare_coherent_memory(struct device *dev,
phys_addr_t phys_addr,
goto out;
if (!size)
goto out;
- if (dev->dma_mem)
- goto out;
-
- /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
*/
mem_base = ioremap(phys_addr, size);
if (!mem_base)
goto out;
- dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem),
GFP_KERNEL);
- if (!dev->dma_mem)
+ dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
+ if (!dma_mem)
goto out;
- dev->dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!dev->dma_mem->bitmap)
+ dma_mem->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ if (!dma_mem->bitmap)
goto free1_out;
- dev->dma_mem->virt_base = mem_base;
- dev->dma_mem->device_base = device_addr;
- dev->dma_mem->pfn_base = PFN_DOWN(phys_addr);
- dev->dma_mem->size = pages;
- dev->dma_mem->flags = flags;
+ dma_mem->virt_base = mem_base;
+ dma_mem->device_base = device_addr;
+ dma_mem->pfn_base = PFN_DOWN(phys_addr);
+ dma_mem->size = pages;
+ dma_mem->flags = flags;
+ spin_lock_init(_mem->spinlock);
+
+ *mem = dma_mem;
if (flags & DMA_MEMORY_MAP)
return DMA_MEMORY_MAP;
@@ -55,12 +57,51 @@ int dma_declare_coherent_memory(struct device *dev,
phys_addr_t phys_addr,
return DMA_MEMORY_IO;
free1_out:
- kfree(dev->dma_mem);
+ kfree(dma_mem);
out:
if (mem_base)
iounmap(mem_base);
return 0;
}
+
+static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
+{
+ if (!mem)
+ return;
+ iounmap(mem->virt_base);
+ kfree(mem->bitmap);
+ kfree(mem);
+}
+
+static int dma_assign_coherent_memory(struct device *dev,
+ struct dma_coherent_mem *mem)
+{
+ if (dev->dma_mem)
+ return -EBUSY;
+
+ dev->dma_mem = mem;
+ /* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN
*/
+
+ return 0;
+}
+
+int dma_declare_coherent_memory(struct device *dev, phys_addr_t
phys_addr,
+ dma_addr_t device_addr, size_t size, int
flags)
+{
+ struct dma_coherent_mem *mem;
+ int ret;
+
+ ret = dma_init_coherent_memory(phys_addr, device_addr, size,
flags,
+ );
+ if (ret
Re: [LKP] [drm/i915] WARNING: CPU: 3 PID: 248 at drivers/gpu/drm/i915/intel_pm.c:6427 check_power_well_state+0x60/0x90 [i915]()
On Wed, Jul 30, 2014 at 11:40:05AM +0200, Daniel Vetter wrote: > On Wed, Jul 30, 2014 at 4:20 AM, Aaron Lu wrote: > > On 07/29/2014 07:10 PM, Daniel Vetter wrote: > >> On Tue, Jul 29, 2014 at 12:14 PM, Ville Syrjälä > >> wrote: > >>> On Tue, Jul 29, 2014 at 10:43:02AM +0800, Aaron Lu wrote: > FYI, we noticed the below changes on > > git://people.freedesktop.org/~danvet/drm colder-fusion > >>> > >>> Does it happen on -nightly too? > >> > >> git://anongit.freedesktop.org/drm-intel > > > > With this git tree, do we still need to watch the old one? Or they serve > > different purpose? > > The old one is just my private repo, never contained official > branches. The one I've given is the official drm-intel git for > upstream. Thanks for the clarification, we have removed your private repo. Regards, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local
On Wed, Jul 30, 2014 at 10:25:03AM -0400, Rik van Riel wrote: > On 07/29/2014 10:14 PM, Aaron Lu wrote: > > On Tue, Jul 29, 2014 at 04:04:37PM -0400, Rik van Riel wrote: > >> On Tue, 29 Jul 2014 10:17:12 +0200 > >> Peter Zijlstra wrote: > >> > +#define NUMA_SCALE 1000 > +#define NUMA_MOVE_THRESH 50 > >>> > >>> Please make that 1024, there's no reason not to use power of two here. > >>> This base 10 factor thing annoyed me no end already, its time for it to > >>> die. > >> > >> That's easy enough. However, it would be good to know whether > >> this actually helps with the regression Aaron found :) > > > > Sorry for the delay. > > > > I applied the last patch and queued the hackbench job to the ivb42 test > > machine for it to run 5 times, and here is the result(regarding the > > proc-vmstat.numa_hint_faults_local field): > > 173565 > > 201262 > > 192317 > > 198342 > > 198595 > > avg: > > 192816 > > > > It seems it is still very big than previous kernels. > > It looks like a step in the right direction, though. > > Could you try running with a larger threshold? > > >> +++ b/kernel/sched/fair.c > >> @@ -924,10 +924,12 @@ static inline unsigned long group_faults_cpu(struct > >> numa_group *group, int nid) > >> > >> /* > >> * These return the fraction of accesses done by a particular task, or > >> - * task group, on a particular numa node. The group weight is given a > >> - * larger multiplier, in order to group tasks together that are almost > >> - * evenly spread out between numa nodes. > >> + * task group, on a particular numa node. The NUMA move threshold > >> + * prevents task moves with marginal improvement, and is set to 5%. > >> */ > >> +#define NUMA_SCALE 1024 > >> +#define NUMA_MOVE_THRESH (5 * NUMA_SCALE / 100) > > It would be good to see if changing NUMA_MOVE_THRESH to > (NUMA_SCALE / 8) does the trick. With your 2nd patch and the above change, the result is: "proc-vmstat.numa_hint_faults_local": [ 199708, 209152, 200638, 187324, 196654 ], avg: 198695 Regards, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Am 31.07.2014 05:59, schrieb Andreas Färber: > Hi Kukjin, > > Am 31.07.2014 03:10, schrieb Kukjin Kim: >> Olof Johansson wrote: >>> >>> Hi, >>> >> Hi Olof, >> >>> On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim wrote: Andreas Färber wrote: > > Am 27.07.2014 14:22, schrieb Andreas Färber: >> Hello, >> >> This mini-series unbreaks booting on 5410 based ODROID-XU. >> >> Since I do not have access to a TRM, the address is a guess based on >> 5250 and 5410. Such a node was not present in the 3.14 downstream tree. > > s/5410/5420/ > OK. >> >> Regards, >> Andreas >> >> Andreas Färber (3): >> Documentation: devicetree: Document exynos5410 PMU >> ARM: dts: exynos: Add PMU to Exynos5410 >> ARM: EXYNOS: Add support for Exynos5410 PMU >> >> Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + >> arch/arm/boot/dts/exynos5410.dtsi | 5 + >> arch/arm/mach-exynos/exynos.c | 1 + >> 3 files changed, 7 insertions(+) > Andreas, thanks. I'll apply this whole series. >>> >>> We're getting close to the merge window. I'd prefer not to have to >>> start reverting samsung code to recover from these regressions, so >>> please send this up very soon. >>> >> Thanks for your gentle reminder. >> >> BTW I'm waiting for exynos5250-spring support from Andreas and I'd like to >> get >> confirmation about that from Doug. And I'm looking at s2r related patches >> now. >> >> OK, I will send out current samsung tree tonight in my time anyway. > > That would be kind. > > Patches 2-3 in spring v3 should be non-functional snow refactorings for > you to consider, but untested by me; patch 1 you could skip if you > modify patch 2, if necessary. As for patch 4, you can see from my > spring-next branch [1] how I am successfully testing it with a TEST_ONLY > patch: For simplefb usage I comment out the /dp-controller node to avoid > drm/exynos detection (not enabling the driver in the user's .config > would be an alternative); when I run into issues with the drm during > testing, I can usually ssh in via USB ethernet/wifi. > > In the dmesg for drm/exynos bridge series testing [2] (which I guess is > not gonna hit 3.17 any more?) I noticed that the USB3503 /usb-hub node > new in v3 is not working yet (complains about lack of #gpio-cells, I > guess for my reset-gpios property), not sure how to fix, so we/you could > probably just drop that node - preparing to test that now. Misread that message, it does not seem to be fatal. I do see the device as /sys/devices/usb-hub. [0.618757] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]' [0.618763] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]' [0.618777] /usb-hub: could not get #gpio-cells for /pinctrl@1340/hsic-reset [0.620743] of_get_named_gpiod_flags: can't parse gpios property of node '/usb-hub[0]' [0.629797] usb3503 usb-hub: switched to HUB mode [0.631752] usb3503 usb-hub: usb3503_probe: probed in hub mode Andreas > As for the rest of patch 4, it's a new DT, so we could fix up any > remaining bugs during 3.17 RC cycle, if it looks sane to you guys now. I > had replied to two series - namely cpufreq [3] and dwmmc [4] - where > merge conflicts might arise. Let me know if you need a respin for anything. > > Regards, > Andreas > > [1] https://github.com/afaerber/linux/commits/spring-next > [2] > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34927.html > [3] > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34807.html > [4] > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34898.html > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] dirreadahead system call
On Mon, Jul 28, 2014 at 03:19:31PM -0600, Andreas Dilger wrote: > On Jul 28, 2014, at 6:52 AM, Abhijith Das wrote: > > OnJuly 26, 2014 12:27:19 AM "Andreas Dilger" wrote: > >> Is there a time when this doesn't get called to prefetch entries in > >> readdir() order? It isn't clear to me what benefit there is of returning > >> the entries to userspace instead of just doing the statahead implicitly > >> in the kernel? > >> > >> The Lustre client has had what we call "statahead" for a while, > >> and similar to regular file readahead it detects the sequential access > >> pattern for readdir() + stat() in readdir() order (taking into account if > >> ".*" > >> entries are being processed or not) and starts fetching the inode > >> attributes asynchronously with a worker thread. > > > > Does this heuristic work well in practice? In the use case we were trying to > > address, a Samba server is aware beforehand if it is going to stat all the > > inodes in a directory. > > Typically this works well for us, because this is done by the Lustre > client, so the statahead is hiding the network latency of the RPCs to > fetch attributes from the server. I imagine the same could be seen with > GFS2. I don't know if this approach would help very much for local > filesystems because the latency is low. > > >> This syscall might be more useful if userspace called readdir() to get > >> the dirents and then passed the kernel the list of inode numbers > >> to prefetch before starting on the stat() calls. That way, userspace > >> could generate an arbitrary list of inodes (e.g. names matching a > >> regexp) and the kernel doesn't need to guess if every inode is needed. > > > > Were you thinking arbitrary inodes across the filesystem or just a subset > > from a directory? Arbitrary inodes may potentially throw up locking issues. > > I was thinking about inodes returned from readdir(), but the syscall > would be much more useful if it could handle arbitrary inodes. I'mnot sure we can do that. The only way to safely identify a specific inode in the filesystem from userspace is via a filehandle. Plain inode numbers are susceptible to TOCTOU race conditions that the kernel cannot resolve. Also, lookup by inode number bypasses directory access permissions, so is not something we would expose to arbitrary unprivileged users. > There are always going to be race conditions even if limited to a > single directory (e.g. another client modifies the inode after calling > dirreadahead(), but before calling stat()) that need to be handled. Unlink/realloc to a different directory with different access permissions is the big issue. > I think there are a lot of benefits that could be had by the generic > syscall, possibly similar to what XFS is doing with the "bulkstat" > interfaces that Dave always mentions. This would be much more so for > cases were you don't want to stat all of the entries in a directory. Bulkstat is not really suited to this - it gets it's speed specifically by avoiding directory traversal to find inodes. Hence it is a root-only operation because it bypasses directory based access restrictions and hence is really only useful for full-filesystem traversal operations like backups, defragmentation, etc. Bulkstat output also contains enough information to construct a valid file handle in userspace and so access to inodes found via bulkstat can be gained via the XFS open-by-handle interfaces. Again, this bypasses permissions checking and hence is a root-only operation. It does, however, avoid TOCTOU races because the open-by-handle will fail if the inode is unlinked and reallocated between the bulkstat call and the open-by-handle as the generation number in the handle will no longer match that of the inode. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
Kukjin, Am 28.07.2014 14:18, schrieb Andreas Färber: > Hello, > > This series adds a dedicated ODROID-XU device tree and enhances it with > LED configuration, to match the downstream 3.14 based behavior. > > It had turned out less trivial than I initially thought as the whole > pinctrl stuff is still missing. I thus cherry-pick two downstream commits. > > Hakjoo, can you please reply with a Signed-off-by to your patches > so that we can get them into upstream? Thanks in advance! FTR, Hakjoo Kim did reply with signed off patches (thanks again!) and updated their branch accordingly: https://github.com/hardkernel/linux/commits/odroid-3.14.y-linaro https://github.com/hardkernel/linux/commit/53edc3da0d1da287517681b47daf36679637b6ba https://github.com/hardkernel/linux/commit/afdc310e47e4d1799719566bfb5a47c55141a7cb > Andreas Färber (3): > ARM: dts: exynos5410: Clean up SMDK5410 indentation > ARM: dts: exynos5410: Prepare ODROID-XU device tree The functional changes below haven't been reviewed yet, but could you consider applying trivial patches 1-2? Regards, Andreas > ARM: dts: exynos5410: Add ODROID-XU LEDs > > Hakjoo Kim (2): > pinctrl: exynos: add exynos5410 SoC specific data > ARM: dts: add pinctrl support to Exynos5410 > > .../bindings/pinctrl/samsung-pinctrl.txt | 1 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/exynos5410-odroidxu.dts | 111 ++ > arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 408 > + > arch/arm/boot/dts/exynos5410-smdk5410.dts | 6 +- > arch/arm/boot/dts/exynos5410.dtsi | 32 ++ > drivers/pinctrl/pinctrl-exynos.c | 126 +++ > drivers/pinctrl/pinctrl-samsung.c | 2 + > drivers/pinctrl/pinctrl-samsung.h | 1 + > 9 files changed, 685 insertions(+), 3 deletions(-) > create mode 100644 arch/arm/boot/dts/exynos5410-odroidxu.dts > create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
be2net crash on next-20140730 ("Driver probe function unexpectedly returned 1966082")
Hi, When running next-20140730 form linux-next, I get the following on dmesg: be2net :02:00.0: PCIe error reporting enabled be2net :02:00.0: adapter not in advanced mode be2net :02:00.0: Emulex OneConnect(be3) initialization failed be2net :02:00.0: Driver probe function unexpectedly returned 1966082 be2net :02:00.1: PCIe error reporting enabled be2net :02:00.1: adapter not in advanced mode be2net :02:00.1: Emulex OneConnect(be3) initialization failed be2net :02:00.1: Driver probe function unexpectedly returned 1966082 Some debugging revealed that be_get_config() is returning 1966082. Machine is a HP ProLiant BL460c G7. It causes the following crash, on module unload: BUG: unable to handle kernel NULL pointer dereference at 003e IP: [] be_roce_dev_remove+0x14/0xa0 [be2net] PGD 205429067 PUD 2004ea067 PMD 0 Oops: [#1] SMP Modules linked in: ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc cpuf net macvtap macvlan vhost tun kvm_intel kvm iTCO_wdt iTCO_vendor_support microcode serio_raw hpilo hpwdt lpc_ich mfd_core i7core_edac edac_core ses enclosure sg be2iscsi iscsi_boot_sysfs libiscsi scsi_tr (E) mbcache(E) sd_mod(E) hpsa(E) lpfc(E) scsi_transport_fc(E) crc_t10dif(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) CPU: 14 PID: 3010 Comm: rmmod Tainted: GE 3.16.0-rc7-next-20140730+ #2 Hardware name: HP ProLiant BL460c G7, BIOS I27 05/05/2011 task: 880206328f20 ti: 8802004f task.ti: 8802004f RIP: 0010:[] [] be_roce_dev_remove+0x14/0xa0 [be2net] RSP: 0018:8802004f3d78 EFLAGS: 00010296 RAX: RBX: 880204600880 RCX: RDX: RSI: 0206 RDI: 880204600880 RBP: 8802004f3d88 R08: R09: 81839f5c R10: 880107a9a858 R11: 0001 R12: 880206fd3000 R13: 880206fd3000 R14: a021cc80 R15: 0001 FS: 7f10627f6700() GS:88020bae() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 003e CR3: 00020642e000 CR4: 07e0 Stack: 8802004f3da8 880204600880 8802004f3dd8 a020db1c 0004 0206 8802004f3dd8 880206fd3098 a021cc80 880206fd3000 a021cc80 0001 Call Trace: [] be_remove+0x3c/0x130 [be2net] [] pci_device_remove+0x46/0xc0 [] __device_release_driver+0x7f/0xf0 [] driver_detach+0xb8/0xc0 [] bus_remove_driver+0x59/0xd0 [] driver_unregister+0x30/0x70 [] ? show_refcnt+0x40/0x40 [] pci_unregister_driver+0x23/0x80 [] be_exit_module+0x10/0x12 [be2net] [] SyS_delete_module+0x181/0x1e0 [] system_call_fastpath+0x16/0x1b Code: c9 c3 48 c7 c7 a0 cd 21 a0 e8 a9 04 37 e1 b8 ea ff ff ff eb e6 66 90 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 07 48 89 fb <0f> b7 40 3e 66 3d 28 07 75 72 f6 83 d0 5c 14 00 04 75 09 48 83 RIP [] be_roce_dev_remove+0x14/0xa0 [be2net] RSP CR2: 003e ---[ end trace 7ac7af37404c6862 ]--- And the following, on shutdown: kvm: exiting hardware virtualization BUG: unable to handle kernel paging request at 00010004 IP: [] _raw_spin_lock_irqsave+0x11/0x30 PGD 0 Oops: 0002 [#1] SMP Modules linked in: ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc pcc_cpufreq ipv6 vhost_net macvtap macvlan vhost tun kvm_intel kvm iTCO_wdt iTCO_vendor_support microcode serio_raw hpilo hpwdt lpc_ich mfd_core i7core_edac edac_core ses enclosure sg be2iscsi iscsi_boot_sysfs libiscsi scsi_transport_iscsi be2net ext4(E) jbd2(E) mbcache(E) sd_mod(E) hpsa(E) lpfc(E) scsi_transport_fc(E) crc_t10dif(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) [last unloaded: cpufreq_ondemand] CPU: 0 PID: 7147 Comm: reboot Tainted: GE 3.16.0-rc7-next-20140730+ #2 Hardware name: HP ProLiant BL460c G7, BIOS I27 05/05/2011 task: 8800e5258de0 ti: 8800ee5c task.ti: 8800ee5c RIP: 0010:[] [] _raw_spin_lock_irqsave+0x11/0x30 RSP: 0018:8800ee5c3c68 EFLAGS: 00010002 RAX: 0002 RBX: 00010004 RCX: RDX: 0001 RSI: 8800ee5c3cb0 RDI: 00010004 RBP: 8800ee5c3c68 R08: 880206fd50b0 R09: 0001 R10: 000200014420 R11: 44204411 R12: 8800ecd46400 R13: 8800ee5c3cb0 R14: 00010006 R15: 81a45ac0 FS: 7fa9e4c1a700() GS:88020ba0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00010004 CR3: ee7e3000 CR4: 07f0 Stack: 8800ee5c3c98 810b2a0c 8800ecd46400 8800ee5c3d30 7fffbcaa0910 8800ee5c3cd8 810b3776 8800ee
[PATCH v2 2/4] usb: dwc2: add compatible data for rockchip soc
This patch add compatible data for dwc2 controller found on
rk3066, rk3188 and rk3288 processors from rockchip.
Signed-off-by: Kever Yang
---
Changes in v2:
- set most parameters as driver auto-detect
drivers/usb/dwc2/platform.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5f0c4bb..5e610dd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -77,6 +77,34 @@ static const struct dwc2_core_params params_bcm2835 = {
.uframe_sched = 0,
};
+static const struct dwc2_core_params params_rk3066 = {
+ .otg_cap= 2,/* non-HNP/non-SRP */
+ .otg_ver= -1,
+ .dma_enable = -1,
+ .dma_desc_enable= 0,
+ .speed = -1,
+ .enable_dynamic_fifo= 1,
+ .en_multiple_tx_fifo= -1,
+ .host_rx_fifo_size = 520, /* 520 DWORDs */
+ .host_nperio_tx_fifo_size = 128, /* 128 DWORDs */
+ .host_perio_tx_fifo_size= 256, /* 256 DWORDs */
+ .max_transfer_size = -1,
+ .max_packet_count = -1,
+ .host_channels = -1,
+ .phy_type = -1,
+ .phy_utmi_width = -1,
+ .phy_ulpi_ddr = -1,
+ .phy_ulpi_ext_vbus = -1,
+ .i2c_enable = -1,
+ .ulpi_fs_ls = -1,
+ .host_support_fs_ls_low_power = -1,
+ .host_ls_low_power_phy_clk = -1,
+ .ts_dline = -1,
+ .reload_ctl = -1,
+ .ahbcfg = 0x7, /* INCR16 */
+ .uframe_sched = -1,
+};
+
/**
* dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
* DWC_otg driver
@@ -99,6 +127,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = _bcm2835 },
+ { .compatible = "rockchip,rk3066-usb", .data = _rk3066 },
{ .compatible = "snps,dwc2", .data = NULL },
{},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] Documentation: dt-bindings: add dt binding info for Rockchip dwc2
This add necessary dwc2 binding documentation for Rockchip socs: rk3066, rk3188 and rk3288 Signed-off-by: Kever Yang --- Changes in v2: - Split out dr_mode and rk3288 bindings. - add compatible "snps,dwc2" bingding info Documentation/devicetree/bindings/usb/dwc2.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 801a284..6a87b27 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -4,6 +4,9 @@ Platform DesignWare HS OTG USB 2.0 controller Required properties: - compatible : One of: - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. + - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc; + - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc; + - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; - snps,dwc2: A generic DWC2 USB controller with default parameters. - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] ARM: dts: Enable USB otg and host1(dwc) on rk3288-evb
USB otg port is the usb3.0 b-port on the board.
USB host1 port is the host A port nearby the otg port.
Signed-off-by: Kever Yang
---
Changes in v2:
- evb patch added in version 2
arch/arm/boot/dts/rk3288-evb.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index da665f6..aa60a3d 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -83,5 +83,11 @@
uart4: serial@ff1c {
status = "okay";
};*/
+ _otg {
+ status = "okay";
+ }
+ _host1 {
+ status = "okay";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Patches to add support for Rockchip dwc2 controller
From: Kever Yang These patches to add support for dwc2 controller found in Rockchip processors rk3066, rk3188 and rk3288, and enable dts for rk3288 evb. Changes in v2: - Split out dr_mode and rk3288 bindings. - add compatible "snps,dwc2" bingding info - set most parameters as driver auto-detect - change the node name from 'dwc2' to 'usb' - evb patch added in version 2 Kever Yang (4): Documentation: dt-bindings: add dt binding info for Rockchip dwc2 usb: dwc2: add compatible data for rockchip soc ARM: dts: add rk3288 dwc2 controller support ARM: dts: Enable USB otg and host1(dwc) on rk3288-evb Documentation/devicetree/bindings/usb/dwc2.txt |3 +++ arch/arm/boot/dts/rk3288-evb.dtsi |6 + arch/arm/boot/dts/rk3288.dtsi | 20 drivers/usb/dwc2/platform.c| 29 4 files changed, 58 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] ARM: dts: add rk3288 dwc2 controller support
rk3288 has two kind of usb controller, this add the dwc2 controller
for otg and host1.
Controller can works with usb PHY default setting and Vbus on.
Signed-off-by: Kever Yang
---
Changes in v2:
- change the node name from 'dwc2' to 'usb'
arch/arm/boot/dts/rk3288.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index abc51f5..9555857 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -646,5 +646,25 @@
clock-names = "baudclk", "apb_pclk";
status = "disabled";
};
+
+ usb_otg: usb@ff58 {
+ compatible = "rockchip,rk3288-usb",
"rockchip,rk3066-usb",
+ "snps,dwc2";
+ reg = <0xff58 0x4>;
+ interrupts = ;
+ clocks = < HCLK_OTG0>;
+ clock-names = "otg";
+ status = "disabled";
+ };
+
+ usb_host1: usb@ff54 {
+ compatible = "rockchip,rk3288-usb",
"rockchip,rk3066-usb",
+ "snps,dwc2";
+ reg = <0xff54 0x4>;
+ interrupts = ;
+ clocks = < HCLK_USBHOST1>;
+ clock-names = "otg";
+ status = "disabled";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: Ensure --symfs ends with '/'
Hi Arnaldo,
On Wed, 30 Jul 2014 17:55:21 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jul 30, 2014 at 12:19:32PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Jul 30, 2014 at 08:52:36AM +0900, Namhyung Kim escreveu:
>> > I also thought about that way first but changed my mind to the current
>> > approach because I don't want to change current behavior.
>>
>> > I worried about the common case which has empty symfs. By your patch,
>> > it makes a pathname absolute even with an empty symfs - I can see most
>> > filenames are already absolute paths but I'm not 100% sure it's always
>> > the case.
>>
>> Yeah, after doing some research on the tools/perf/ 'git log' I got your
>> point,
>> we can't add the / after symfs usages when it is "", i.e. we need something
>> like:
>>
>> ("%s%s%s, symfs, symfs[0] ? "/" : "", dso_name)
>>
>> I.e. the equivalent of this:
>>
>> [acme@zoo linux]$ python
>> >>> import os
>> >>> symfs = ""
>> >>> os.path.join(symfs, "dso_path")
>> 'dso_path'
>> >>> symfs = "/home/acme/embedded_device_dsos"
>> >>> os.path.join(symfs, "dso_path")
>> '/home/acme/embedded_device_dsos/dso_path'
>> >>>
>>
>> I'll try and get that in place.
>
> Ok, the patch below should implement it just like above, if Minchan
> could please retest, I did just minimal testing, will do more later.
Are you still against my approach - adding '/' at the end of the symfs
string itself? It seems that mine is simpler and shorter.
Thanks,
Namhyung
>
> - Arnaldo
>
> ---
>
> From d0240769e7d844ee21c1e8fc5cc57627c666f155 Mon Sep 17 00:00:00 2001
> From: Arnaldo Carvalho de Melo
> Date: Tue, 29 Jul 2014 10:21:58 -0300
> Subject: [PATCH 1/1] perf symbols: Make sure --symfs usage includes the path
> separator
>
> Minchan reported that perf failed to load vmlinux if --symfs argument
> doesn't end with '/' character.
>
> Fix it by making sure that the '/' path separator is used when composing
> pathnames with a --symfs provided directory name.
>
> Reported-by: Minchan Kim
> Tested-by: Minchan Kim
> Cc: David Ahern
> Cc: Jiri Olsa
> Cc: Minchan Kim
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Link: http://lkml.kernel.org/n/tip-8n4s6b6zvsez5ktanw006...@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> tools/perf/util/annotate.c | 9 +++--
> tools/perf/util/dso.c | 28 +---
> tools/perf/util/symbol.c | 3 +--
> tools/perf/util/symbol.h | 9 +
> tools/perf/util/util.h | 16
> 5 files changed, 42 insertions(+), 23 deletions(-)
>
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 809b4c50beae..7745fec01a6b 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -899,10 +899,8 @@ int symbol__annotate(struct symbol *sym, struct map
> *map, size_t privsize)
> struct kcore_extract kce;
> bool delete_extract = false;
>
> - if (filename) {
> - snprintf(symfs_filename, sizeof(symfs_filename), "%s%s",
> - symbol_conf.symfs, filename);
> - }
> + if (filename)
> + symbol__join_symfs(symfs_filename, filename);
>
> if (filename == NULL) {
> if (dso->has_build_id) {
> @@ -922,8 +920,7 @@ fallback:
>* DSO is the same as when 'perf record' ran.
>*/
> filename = (char *)dso->long_name;
> - snprintf(symfs_filename, sizeof(symfs_filename), "%s%s",
> - symbol_conf.symfs, filename);
> + symbol__join_symfs(symfs_filename, filename);
> free_filename = false;
> }
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 90d02c661dd4..bdafd306fb52 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -37,6 +37,7 @@ int dso__read_binary_type_filename(const struct dso *dso,
> {
> char build_id_hex[BUILD_ID_SIZE * 2 + 1];
> int ret = 0;
> + size_t len;
>
> switch (type) {
> case DSO_BINARY_TYPE__DEBUGLINK: {
> @@ -60,26 +61,25 @@ int dso__read_binary_type_filename(const struct dso *dso,
> break;
>
> case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
> - snprintf(filename, size, "%s/usr/lib/debug%s.debug",
> - symbol_conf.symfs, dso->long_name);
> + len = __symbol__join_symfs(filename, size, "/usr/lib/debug");
> + snprintf(filename + len, size - len, "%s.debug",
> dso->long_name);
> break;
>
> case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
> - snprintf(filename, size, "%s/usr/lib/debug%s",
> - symbol_conf.symfs, dso->long_name);
> + len = __symbol__join_symfs(filename, size, "/usr/lib/debug");
> + snprintf(filename + len, size - len, "%s", dso->long_name);
> break;
>
> case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
> {
> const
[PATCH v2] kbuild, LLVMLinux: Supress warnings unless W=1-3
From: Behan Webster clang has more warnings enabled by default. Turn them off unless W is set. This patch fixes a logic bug where warnings in clang were disabled when W was set. Signed-off-by: Behan Webster Signed-off-by: Jan-Simon Möller Signed-off-by: Mark Charlebois Cc: mma...@suse.cz Cc: b...@alien8.de --- Makefile | 1 + scripts/Makefile.extrawarn | 22 -- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index f6a7794..f343e17 100644 --- a/Makefile +++ b/Makefile @@ -668,6 +668,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare) # source of a reference will be _MergedGlobals and not on of the whitelisted names. # See modpost pattern 2 KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,) +KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) else # This warning generated too much noise in a regular build. diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 6564350..b5b0751 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -26,16 +26,6 @@ warning-1 += $(call cc-option, -Wmissing-include-dirs) warning-1 += $(call cc-option, -Wunused-but-set-variable) warning-1 += $(call cc-disable-warning, missing-field-initializers) -# Clang -warning-1 += $(call cc-disable-warning, initializer-overrides) -warning-1 += $(call cc-disable-warning, unused-value) -warning-1 += $(call cc-disable-warning, format) -warning-1 += $(call cc-disable-warning, unknown-warning-option) -warning-1 += $(call cc-disable-warning, sign-compare) -warning-1 += $(call cc-disable-warning, format-zero-length) -warning-1 += $(call cc-disable-warning, uninitialized) -warning-1 += $(call cc-option, -fcatch-undefined-behavior) - warning-2 := -Waggregate-return warning-2 += -Wcast-align warning-2 += -Wdisabled-optimization @@ -55,6 +45,18 @@ warning-3 += -Wswitch-default warning-3 += $(call cc-option, -Wpacked-bitfield-compat) warning-3 += $(call cc-option, -Wvla) +ifeq ($(COMPILER),clang) +ifndef $(W) +KBUILD_CFLAGS += $(call cc-disable-warning, initializer-overrides) +KBUILD_CFLAGS += $(call cc-disable-warning, unused-value) +KBUILD_CFLAGS += $(call cc-disable-warning, format) +KBUILD_CFLAGS += $(call cc-disable-warning, unknown-warning-option) +KBUILD_CFLAGS += $(call cc-disable-warning, sign-compare) +KBUILD_CFLAGS += $(call cc-disable-warning, format-zero-length) +KBUILD_CFLAGS += $(call cc-disable-warning, uninitialized) +endif +endif + warning := $(warning-$(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS))) warning += $(warning-$(findstring 2, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS))) warning += $(warning-$(findstring 3, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS))) -- 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] Remove certain calls for releasing page cache
On Wed, Jul 30, 2014 at 11:57 PM, Dave Airlie wrote: > On 31 July 2014 12:05, Nick Krause wrote: >> On Wed, Jul 30, 2014 at 7:30 PM, Dave Airlie wrote: This patch removes the lines for releasing the page cache in certain files as this may aid in perfomance with writes in the compression rountines of btrfs. Please note that this patch has not been tested on my own hardware due to no compression based btrfs volumes of my own. >>> >>> For all that is sacred, STOP. >>> >>> Go and do something else, you are wasting people's valuable time, >>> >>> Don't send any patches you haven't tested ever. If you aren't capable >>> of setting up a VM to run compressed btrfs volumes in, what makes you >>> think you can patch the code. >>> >>> This isn't how you learn to be a kernel developer by wasting other >>> kernel developers time, if you can't work out why releasing the page cache >>> is necessary then don't send the patch until you have spent the time >>> understanding what the page cache is. >>> >>> I know you'll just ignore this, and keep on trucking just like you ignored >>> the other messages from Stephen before. >>> >>> But if you want to work on the kernel, this isn't the way to do it, and >>> nobody will ever take a patch from you seriously if you continue in this >>> fashion. >>> >>> Dave. >> Dave , >> Seems I need to have tested this code first. >> Regards Nick > > > No you needed to do a lot more, these one line replies from you are > quite stupid, > > You are quite deliberately missing the point of people trying to help you, > > Dave. Honestly , I understand and thanks for the help a lot. I am wondering if some one can give me a pointer on where to download the git repos for the btrfs user spaces tools as it seems on the btrfs tools on the wiki. Regards Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] autofs: the documentation I wanted to read
On Wed, 30 Jul 2014 11:37:14 -0700 Randy Dunlap wrote: > On 07/28/14 19:00, NeilBrown wrote: > > +Directories further down the tree depend on the *max_proto* mount > > max_proto or maxproto? > or either? > check/fix other places also. The mount option is "maxproto", the internal variable name is "max_proto" :-) > > Thanks. Nice job. > Thanks so much for all those improvements - I really appreciate it. They'll all be in the next posting. Thanks, NeilBrown signature.asc Description: PGP signature
[PATCH] ASoC: fsl_asrc: Fix sparse warnings in FSL_ASRC_FORMATS due to typo
reproduce: make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> sound/soc/fsl/fsl_asrc.c:563:28: sparse: restricted snd_pcm_format_t
>> degrades to integer
>> sound/soc/fsl/fsl_asrc.c:570:28: sparse: restricted snd_pcm_format_t
>> degrades to integer
vim +563 sound/soc/fsl/fsl_asrc.c
557 .probe = fsl_asrc_dai_probe,
558 .playback = {
559 .stream_name = "ASRC-Playback",
560 .channels_min = 1,
561 .channels_max = 10,
562 .rates = FSL_ASRC_RATES,
> 563 .formats = FSL_ASRC_FORMATS,
564 },
565 .capture = {
566 .stream_name = "ASRC-Capture",
567 .channels_min = 1,
568 .channels_max = 10,
569 .rates = FSL_ASRC_RATES,
> 570 .formats = FSL_ASRC_FORMATS,
571 },
572 .ops = _asrc_dai_ops,
573 };
Reported-by: kbuild test robot
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 41699f7..cdb5779 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -551,7 +551,7 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
#define FSL_ASRC_RATES SNDRV_PCM_RATE_8000_192000
#define FSL_ASRC_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S16_LE | \
-SNDRV_PCM_FORMAT_S20_3LE)
+SNDRV_PCM_FMTBIT_S20_3LE)
static struct snd_soc_dai_driver fsl_asrc_dai = {
.probe = fsl_asrc_dai_probe,
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] staging: dgap: introduce dgap_cleanup_nodes()
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
Making a node will allocate node memory and strings for saving
configrations with kstrdup().
So these are freed when dgap is unloaded or failed to initialize.
Signed-off-by: Daeseok Youn
---
V2: Do not need to free for NULLNODE.
I have been too busy to solve this issue, sorry for late.
Mark, Can you test this patch? I try to make simple module which is
testing dgap_parsefile() and dgap_cleanup_nodes().
There was a problem in freeing NULLNODE so if node is NULLNODE,
just bypass and get next one.
drivers/staging/dgap/dgap.c | 52 +++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 06c55cb..ac12e99 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -201,6 +201,7 @@ static int dgap_test_fep(struct board_t *brd);
static int dgap_tty_register_ports(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type,
struct board_t *brd);
+static void dgap_cleanup_nodes(void);
static void dgap_cleanup_module(void);
@@ -619,6 +620,7 @@ unregister_tty:
free_flipbuf:
dgap_free_flipbuf(brd);
cleanup_brd:
+ dgap_cleanup_nodes();
dgap_release_remap(brd);
kfree(brd);
@@ -659,6 +661,8 @@ static void dgap_cleanup_module(void)
dgap_cleanup_board(dgap_board[i]);
}
+ dgap_cleanup_nodes();
+
if (dgap_numboards)
pci_unregister_driver(_driver);
}
@@ -6323,6 +6327,54 @@ static void dgap_remove_tty_sysfs(struct device *c)
sysfs_remove_group(>kobj, _tty_attribute_group);
}
+static void dgap_cleanup_nodes(void)
+{
+ struct cnode *p;
+
+ p = _head;
+
+ while (p) {
+ struct cnode *tmp = p->next;
+
+ if (p->type == NULLNODE) {
+ p = tmp;
+ continue;
+ }
+
+ switch (p->type) {
+ case BNODE:
+ kfree(p->u.board.portstr);
+ kfree(p->u.board.addrstr);
+ kfree(p->u.board.pcibusstr);
+ kfree(p->u.board.pcislotstr);
+ kfree(p->u.board.method);
+ break;
+ case CNODE:
+ kfree(p->u.conc.id);
+ kfree(p->u.conc.connect);
+ break;
+ case MNODE:
+ kfree(p->u.module.id);
+ break;
+ case TNODE:
+ kfree(p->u.ttyname);
+ break;
+ case CUNODE:
+ kfree(p->u.cuname);
+ break;
+ case LNODE:
+ kfree(p->u.line.cable);
+ break;
+ case PNODE:
+ kfree(p->u.printname);
+ break;
+ }
+
+ kfree(p->u.board.status);
+ kfree(p);
+ p = tmp;
+ }
+}
/*
* Parse a configuration file read into memory as a string.
*/
--
1.7.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 v2 1/2] Documentation: dt-bindings: add dt binding info for dwc2 dr_mode
Kever, On Wed, Jul 30, 2014 at 5:29 PM, Kever Yang wrote: > Indicate that the generic dr_mode binding should be used for dwc2. > > Signed-off-by: Kever Yang > --- > > Changes in v2: > - Split out dr_mode and rk3288 bindings. > > Documentation/devicetree/bindings/usb/dwc2.txt |2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Doug Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Hi Kukjin, Am 31.07.2014 03:10, schrieb Kukjin Kim: > Olof Johansson wrote: >> >> Hi, >> > Hi Olof, > >> On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim wrote: >>> Andreas Färber wrote: Am 27.07.2014 14:22, schrieb Andreas Färber: > Hello, > > This mini-series unbreaks booting on 5410 based ODROID-XU. > > Since I do not have access to a TRM, the address is a guess based on > 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ >>> OK. >>> > > Regards, > Andreas > > Andreas Färber (3): > Documentation: devicetree: Document exynos5410 PMU > ARM: dts: exynos: Add PMU to Exynos5410 > ARM: EXYNOS: Add support for Exynos5410 PMU > > Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + > arch/arm/boot/dts/exynos5410.dtsi | 5 + > arch/arm/mach-exynos/exynos.c | 1 + > 3 files changed, 7 insertions(+) >>> Andreas, thanks. >>> >>> I'll apply this whole series. >> >> We're getting close to the merge window. I'd prefer not to have to >> start reverting samsung code to recover from these regressions, so >> please send this up very soon. >> > Thanks for your gentle reminder. > > BTW I'm waiting for exynos5250-spring support from Andreas and I'd like to get > confirmation about that from Doug. And I'm looking at s2r related patches now. > > OK, I will send out current samsung tree tonight in my time anyway. That would be kind. Patches 2-3 in spring v3 should be non-functional snow refactorings for you to consider, but untested by me; patch 1 you could skip if you modify patch 2, if necessary. As for patch 4, you can see from my spring-next branch [1] how I am successfully testing it with a TEST_ONLY patch: For simplefb usage I comment out the /dp-controller node to avoid drm/exynos detection (not enabling the driver in the user's .config would be an alternative); when I run into issues with the drm during testing, I can usually ssh in via USB ethernet/wifi. In the dmesg for drm/exynos bridge series testing [2] (which I guess is not gonna hit 3.17 any more?) I noticed that the USB3503 /usb-hub node new in v3 is not working yet (complains about lack of #gpio-cells, I guess for my reset-gpios property), not sure how to fix, so we/you could probably just drop that node - preparing to test that now. As for the rest of patch 4, it's a new DT, so we could fix up any remaining bugs during 3.17 RC cycle, if it looks sane to you guys now. I had replied to two series - namely cpufreq [3] and dwmmc [4] - where merge conflicts might arise. Let me know if you need a respin for anything. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-next [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34927.html [3] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34807.html [4] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34898.html -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Remove certain calls for releasing page cache
On 31 July 2014 12:05, Nick Krause wrote: > On Wed, Jul 30, 2014 at 7:30 PM, Dave Airlie wrote: >>> This patch removes the lines for releasing the page cache in certain >>> files as this may aid in perfomance with writes in the compression >>> rountines of btrfs. Please note that this patch has not been tested >>> on my own hardware due to no compression based btrfs volumes of my >>> own. >>> >> >> For all that is sacred, STOP. >> >> Go and do something else, you are wasting people's valuable time, >> >> Don't send any patches you haven't tested ever. If you aren't capable >> of setting up a VM to run compressed btrfs volumes in, what makes you >> think you can patch the code. >> >> This isn't how you learn to be a kernel developer by wasting other >> kernel developers time, if you can't work out why releasing the page cache >> is necessary then don't send the patch until you have spent the time >> understanding what the page cache is. >> >> I know you'll just ignore this, and keep on trucking just like you ignored >> the other messages from Stephen before. >> >> But if you want to work on the kernel, this isn't the way to do it, and >> nobody will ever take a patch from you seriously if you continue in this >> fashion. >> >> Dave. > Dave , > Seems I need to have tested this code first. > Regards Nick No you needed to do a lot more, these one line replies from you are quite stupid, You are quite deliberately missing the point of people trying to help you, 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 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
On 2014-7-30 0:40, Sudeep Holla wrote:
[...]
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
>> +
>
> These can be boolean but can be removed IMO, see below.
>
>> /*
>>* __acpi_map_table() will be called before page_init(), so early_ioremap()
>>* or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long
>> size)
>> early_iounmap(map, size);
>> }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +/*
>> + * Revision in table header is the FADT Major version,
>> + * and there is a minor version of FADT which was introduced
>> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> + * to get arm boot flags, or we will disable ACPI.
>> + */
>> +if (table->revision < 5 || fadt->minor_version < 1) {
>> +pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or
>> higher\n",
>> +table->revision, fadt->minor_version);
>> +acpi_psci_present = 0;
>> +disable_acpi();
>> +return -EINVAL;
>> +}
>> +
>> +if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +acpi_psci_present = 1;
>> +
>> +if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +acpi_psci_use_hvc = 1;
>> +
>
> Why not make this macros instead of global variables as I suggested in
> previous version. acpi_gbl_FADT is already global and you can avoid
> creating new one especially they are just used on boot/init.
Ok, it makes sense to me, I will update it in next version.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: add flags argument to gpiod_get*() functions
On Mon, Jul 28, 2014 at 7:30 PM, Linus Walleij wrote: > On Fri, Jul 25, 2014 at 4:38 PM, Alexandre Courbot > wrote: > >> The huge majority of GPIOs have their direction and initial value set >> right after being obtained by one of the gpiod_get() functions. The >> integer GPIO API had gpio_request_one() that took a convenience flags >> parameter allowing to specify an direction and value applied to the >> returned GPIO. This feature greatly simplifies client code and ensures >> errors are always handled properly. >> >> A similar feature has been requested for the gpiod API. Since setting >> the direction of a GPIO is so often the very next action done after >> obtaining its descriptor, we prefer to extend the existing functions >> instead of introducing new functions that would raise the >> number of gpiod getters to 16 (!). >> >> The drawback of this approach is that all gpiod clients need to be >> updated. To limit the pain, temporary macros are introduced that allow >> gpiod_get*() to be called with or without the extra flags argument. They >> will be removed once all consumer code has been updated. >> >> Signed-off-by: Alexandre Courbot >> --- >> This dude can be applied harmlessly to the GPIO tree - then I will go >> after every gpiod user to update the calls to gpiod_get*() before >> removing the macros in consumer.h. > > OK I trust you. Patch applied with Broonie's review tag. Thanks! Unfortunately it is still not in -next due to a build error... > Just so we don't forget how we should move forward: Alex what do > you think about adding a drivers/gpio/TODO.TXT file outlining the > overall plan of the gpiod refactoring and clean-up work? I have such a file locally - I'm not sure if checking it into the kernel tree is relevant though. Sounds more like the task of a wiki page. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v4 net-next 1/5] net: filter: simplify socket charging
attaching bpf program to a socket involves multiple socket memory arithmetic,
since size of 'sk_filter' is changing when classic BPF is converted to eBPF.
Also common path of program creation has to deal with two ways of freeing
the memory.
Simplify the code by delaying socket charging until program is ready and
its size is known
Signed-off-by: Alexei Starovoitov
---
include/linux/filter.h |2 +-
net/core/filter.c | 87
net/core/sock.c|9 +++--
3 files changed, 45 insertions(+), 53 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 20dd50ef7271..00640edc166f 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -366,7 +366,7 @@ int sk_chk_filter(const struct sock_filter *filter,
unsigned int flen);
int sk_get_filter(struct sock *sk, struct sock_filter __user *filter,
unsigned int len);
-void sk_filter_charge(struct sock *sk, struct sk_filter *fp);
+bool sk_filter_charge(struct sock *sk, struct sk_filter *fp);
void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp);
u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
diff --git a/net/core/filter.c b/net/core/filter.c
index 42c1944b0c63..5a6aeb1d40b8 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -872,41 +872,30 @@ static void sk_filter_release(struct sk_filter *fp)
void sk_filter_uncharge(struct sock *sk, struct sk_filter *fp)
{
- atomic_sub(sk_filter_size(fp->len), >sk_omem_alloc);
- sk_filter_release(fp);
-}
+ u32 filter_size = sk_filter_size(fp->len);
-void sk_filter_charge(struct sock *sk, struct sk_filter *fp)
-{
- atomic_inc(>refcnt);
- atomic_add(sk_filter_size(fp->len), >sk_omem_alloc);
+ atomic_sub(filter_size, >sk_omem_alloc);
+ sk_filter_release(fp);
}
-static struct sk_filter *__sk_migrate_realloc(struct sk_filter *fp,
- struct sock *sk,
- unsigned int len)
+/* try to charge the socket memory if there is space available
+ * return true on success
+ */
+bool sk_filter_charge(struct sock *sk, struct sk_filter *fp)
{
- struct sk_filter *fp_new;
-
- if (sk == NULL)
- return krealloc(fp, len, GFP_KERNEL);
-
- fp_new = sock_kmalloc(sk, len, GFP_KERNEL);
- if (fp_new) {
- *fp_new = *fp;
- /* As we're keeping orig_prog in fp_new along,
-* we need to make sure we're not evicting it
-* from the old fp.
-*/
- fp->orig_prog = NULL;
- sk_filter_uncharge(sk, fp);
+ u32 filter_size = sk_filter_size(fp->len);
+
+ /* same check as in sock_kmalloc() */
+ if (filter_size <= sysctl_optmem_max &&
+ atomic_read(>sk_omem_alloc) + filter_size < sysctl_optmem_max) {
+ atomic_inc(>refcnt);
+ atomic_add(filter_size, >sk_omem_alloc);
+ return true;
}
-
- return fp_new;
+ return false;
}
-static struct sk_filter *__sk_migrate_filter(struct sk_filter *fp,
-struct sock *sk)
+static struct sk_filter *__sk_migrate_filter(struct sk_filter *fp)
{
struct sock_filter *old_prog;
struct sk_filter *old_fp;
@@ -938,7 +927,7 @@ static struct sk_filter *__sk_migrate_filter(struct
sk_filter *fp,
/* Expand fp for appending the new filter representation. */
old_fp = fp;
- fp = __sk_migrate_realloc(old_fp, sk, sk_filter_size(new_len));
+ fp = krealloc(old_fp, sk_filter_size(new_len), GFP_KERNEL);
if (!fp) {
/* The old_fp is still around in case we couldn't
* allocate new memory, so uncharge on that one.
@@ -956,7 +945,7 @@ static struct sk_filter *__sk_migrate_filter(struct
sk_filter *fp,
/* 2nd sk_convert_filter() can fail only if it fails
* to allocate memory, remapping must succeed. Note,
* that at this time old_fp has already been released
-* by __sk_migrate_realloc().
+* by krealloc().
*/
goto out_err_free;
@@ -968,16 +957,11 @@ static struct sk_filter *__sk_migrate_filter(struct
sk_filter *fp,
out_err_free:
kfree(old_prog);
out_err:
- /* Rollback filter setup. */
- if (sk != NULL)
- sk_filter_uncharge(sk, fp);
- else
- kfree(fp);
+ __sk_filter_release(fp);
return ERR_PTR(err);
}
-static struct sk_filter *__sk_prepare_filter(struct sk_filter *fp,
-struct sock *sk)
+static struct sk_filter *__sk_prepare_filter(struct sk_filter *fp)
{
int err;
@@ -986,10 +970,7 @@ static struct sk_filter *__sk_prepare_filter(struct
sk_filter *fp,
err = sk_chk_filter(fp->insns,
[PATCH v4 net-next 0/5] net: filter: split sk_filter into socket and bpf, cleanup names
The main goal of the series is to split 'struct sk_filter' into socket and
bpf parts and cleanup names in the following way:
- everything that deals with sockets keeps 'sk_*' prefix
- everything that is pure BPF is changed to 'bpf_*' prefix
split 'struct sk_filter' into
struct sk_filter {
atomic_trefcnt;
struct rcu_head rcu;
struct bpf_prog *prog;
};
and
struct bpf_prog {
u32 jited:1,
len:31;
struct sock_fprog_kern *orig_prog;
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct bpf_insn *filter);
union {
struct sock_filter insns[0];
struct bpf_insn insnsi[0];
struct work_struct work;
};
};
so that 'struct bpf_prog' can be used independent of sockets and cleans up
'unattached' bpf use cases:
isdn, ppp, team, seccomp, ptp, xt_bpf, cls_bpf, test_bpf
which don't need refcnt/rcu fields.
It's a follow up to the rcu cleanup started by Pablo in
commit 34c5bd66e5 ("net: filter: don't release unattached filter through
call_rcu()")
Patch 1 - cleans up socket memory charging and makes it possible for functions
sk(bpf)_migrate_filter(), sk(bpf)_prepare_filter() to be socket independent
Patches 2-4 - trivial renames
Patch 5 - sk_filter split and renames of related sk_*() functions
Alexei Starovoitov (5):
net: filter: simplify socket charging
net: filter: rename sk_filter_proglen -> bpf_classic_proglen
net: filter: rename sk_chk_filter() -> bpf_check_classic()
net: filter: rename sk_convert_filter() -> bpf_convert_filter()
net: filter: split 'struct sk_filter' into socket and bpf parts
Documentation/networking/filter.txt | 12 +-
arch/arm/net/bpf_jit_32.c|8 +-
arch/mips/net/bpf_jit.c |8 +-
arch/powerpc/net/bpf_jit_comp.c |8 +-
arch/s390/net/bpf_jit_comp.c |4 +-
arch/sparc/net/bpf_jit_comp.c|4 +-
arch/x86/net/bpf_jit_comp.c | 14 +--
drivers/isdn/i4l/isdn_ppp.c | 26 ++---
drivers/net/ppp/ppp_generic.c| 28 ++---
drivers/net/team/team_mode_loadbalance.c | 14 +--
include/linux/filter.h | 51 +
include/linux/isdn_ppp.h |4 +-
include/uapi/linux/netfilter/xt_bpf.h|4 +-
kernel/bpf/core.c| 34 +++---
kernel/seccomp.c | 18 +--
lib/test_bpf.c | 24 ++--
net/core/filter.c| 183 +++---
net/core/ptp_classifier.c|6 +-
net/core/sock.c |9 +-
net/core/sock_diag.c |4 +-
net/netfilter/xt_bpf.c |6 +-
net/sched/cls_bpf.c | 12 +-
22 files changed, 243 insertions(+), 238 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 net-next 2/5] net: filter: rename sk_filter_proglen -> bpf_classic_proglen
trivial rename to better match semantics of macro
Signed-off-by: Alexei Starovoitov
---
include/linux/filter.h |3 +--
net/core/filter.c |8
net/core/sock_diag.c |2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 00640edc166f..3769341a745d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -344,8 +344,7 @@ static inline unsigned int sk_filter_size(unsigned int
proglen)
offsetof(struct sk_filter, insns[proglen]));
}
-#define sk_filter_proglen(fprog) \
- (fprog->len * sizeof(fprog->filter[0]))
+#define bpf_classic_proglen(fprog) (fprog->len * sizeof(fprog->filter[0]))
int sk_filter(struct sock *sk, struct sk_buff *skb);
diff --git a/net/core/filter.c b/net/core/filter.c
index 5a6aeb1d40b8..d6cb287e4f59 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -813,7 +813,7 @@ EXPORT_SYMBOL(sk_chk_filter);
static int sk_store_orig_filter(struct sk_filter *fp,
const struct sock_fprog *fprog)
{
- unsigned int fsize = sk_filter_proglen(fprog);
+ unsigned int fsize = bpf_classic_proglen(fprog);
struct sock_fprog_kern *fkprog;
fp->orig_prog = kmalloc(sizeof(*fkprog), GFP_KERNEL);
@@ -1001,7 +1001,7 @@ static struct sk_filter *__sk_prepare_filter(struct
sk_filter *fp)
int sk_unattached_filter_create(struct sk_filter **pfp,
struct sock_fprog_kern *fprog)
{
- unsigned int fsize = sk_filter_proglen(fprog);
+ unsigned int fsize = bpf_classic_proglen(fprog);
struct sk_filter *fp;
/* Make sure new filter is there and in the right amounts. */
@@ -1053,7 +1053,7 @@ EXPORT_SYMBOL_GPL(sk_unattached_filter_destroy);
int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
{
struct sk_filter *fp, *old_fp;
- unsigned int fsize = sk_filter_proglen(fprog);
+ unsigned int fsize = bpf_classic_proglen(fprog);
unsigned int sk_fsize = sk_filter_size(fprog->len);
int err;
@@ -1154,7 +1154,7 @@ int sk_get_filter(struct sock *sk, struct sock_filter
__user *ubuf,
goto out;
ret = -EFAULT;
- if (copy_to_user(ubuf, fprog->filter, sk_filter_proglen(fprog)))
+ if (copy_to_user(ubuf, fprog->filter, bpf_classic_proglen(fprog)))
goto out;
/* Instead of bytes, the API requests to return the number
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index a4216a4c9572..57d922320c59 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -69,7 +69,7 @@ int sock_diag_put_filterinfo(bool may_report_filterinfo,
struct sock *sk,
goto out;
fprog = filter->orig_prog;
- flen = sk_filter_proglen(fprog);
+ flen = bpf_classic_proglen(fprog);
attr = nla_reserve(skb, attrtype, flen);
if (attr == NULL) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 net-next 4/5] net: filter: rename sk_convert_filter() -> bpf_convert_filter()
to indicate that this function is converting classic BPF into eBPF
and not related to sockets
Signed-off-by: Alexei Starovoitov
---
arch/x86/net/bpf_jit_comp.c |2 +-
include/linux/filter.h |4 ++--
kernel/bpf/core.c |2 +-
kernel/seccomp.c|4 ++--
net/core/filter.c | 16
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 71737a83f022..e2ecc1380b3d 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -235,7 +235,7 @@ static int do_jit(struct sk_filter *bpf_prog, int *addrs,
u8 *image,
/* mov qword ptr [rbp-X],rbx */
EMIT3_off32(0x48, 0x89, 0x9D, -stacksize);
- /* sk_convert_filter() maps classic BPF register X to R7 and uses R8
+ /* bpf_convert_filter() maps classic BPF register X to R7 and uses R8
* as temporary, so all tcpdump filters need to spill/fill R7(r13) and
* R8(r14). R9(r15) spill could be made conditional, but there is only
* one 'bpf_error' return path out of helper functions inside bpf_jit.S
diff --git a/include/linux/filter.h b/include/linux/filter.h
index c4d0be4c5e75..7cb9b40e9a2f 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -351,8 +351,8 @@ int sk_filter(struct sock *sk, struct sk_buff *skb);
void sk_filter_select_runtime(struct sk_filter *fp);
void sk_filter_free(struct sk_filter *fp);
-int sk_convert_filter(struct sock_filter *prog, int len,
- struct bpf_insn *new_prog, int *new_len);
+int bpf_convert_filter(struct sock_filter *prog, int len,
+ struct bpf_insn *new_prog, int *new_len);
int sk_unattached_filter_create(struct sk_filter **pfp,
struct sock_fprog_kern *fprog);
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index b479807ec383..188ac5ba3900 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -446,7 +446,7 @@ load_word:
/* BPF_LD + BPD_ABS and BPF_LD + BPF_IND insns are
* only appearing in the programs where ctx ==
* skb. All programs keep 'ctx' in regs[BPF_REG_CTX]
-* == BPF_R6, sk_convert_filter() saves it in BPF_R6,
+* == BPF_R6, bpf_convert_filter() saves it in BPF_R6,
* internal BPF verifier will check that BPF_R6 ==
* ctx.
*
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index f4a77d23f209..33a3a97e2b58 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -249,7 +249,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog)
goto free_prog;
/* Convert 'sock_filter' insns to 'bpf_insn' insns */
- ret = sk_convert_filter(fp, fprog->len, NULL, _len);
+ ret = bpf_convert_filter(fp, fprog->len, NULL, _len);
if (ret)
goto free_prog;
@@ -265,7 +265,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog)
if (!filter->prog)
goto free_filter;
- ret = sk_convert_filter(fp, fprog->len, filter->prog->insnsi, _len);
+ ret = bpf_convert_filter(fp, fprog->len, filter->prog->insnsi,
_len);
if (ret)
goto free_filter_prog;
kfree(fp);
diff --git a/net/core/filter.c b/net/core/filter.c
index 5740ea08a3ad..6ac901613bee 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -312,7 +312,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
}
/**
- * sk_convert_filter - convert filter program
+ * bpf_convert_filter - convert filter program
* @prog: the user passed filter program
* @len: the length of the user passed filter program
* @new_prog: buffer where converted program will be stored
@@ -322,12 +322,12 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
* Conversion workflow:
*
* 1) First pass for calculating the new program length:
- * sk_convert_filter(old_prog, old_len, NULL, _len)
+ * bpf_convert_filter(old_prog, old_len, NULL, _len)
*
* 2) 2nd pass to remap in two passes: 1st pass finds new
*jump offsets, 2nd pass remapping:
* new_prog = kmalloc(sizeof(struct bpf_insn) * new_len);
- * sk_convert_filter(old_prog, old_len, new_prog, _len);
+ * bpf_convert_filter(old_prog, old_len, new_prog, _len);
*
* User BPF's register A is mapped to our BPF register 6, user BPF
* register X is mapped to BPF register 7; frame pointer is always
@@ -335,8 +335,8 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
* for socket filters: ctx == 'struct sk_buff *', for seccomp:
* ctx == 'struct seccomp_data *'.
*/
-int sk_convert_filter(struct sock_filter *prog, int len,
- struct bpf_insn *new_prog, int *new_len)
+int bpf_convert_filter(struct sock_filter *prog, int len,
+ struct bpf_insn *new_prog, int *new_len)
{
int new_flen = 0,
[PATCH v4 net-next 3/5] net: filter: rename sk_chk_filter() -> bpf_check_classic()
trivial rename to indicate that this functions performs classic BPF checking
Signed-off-by: Alexei Starovoitov
---
Documentation/networking/filter.txt |2 +-
include/linux/filter.h |2 +-
kernel/bpf/core.c |2 +-
kernel/seccomp.c|4 ++--
net/core/filter.c | 10 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index ee78eba78a9d..712068be8171 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -591,7 +591,7 @@ sk_unattached_filter_destroy() for destroying it. The macro
SK_RUN_FILTER(filter, ctx) transparently invokes eBPF interpreter or JITed
code to run the filter. 'filter' is a pointer to struct sk_filter that we
got from sk_unattached_filter_create(), and 'ctx' the given context (e.g.
-skb pointer). All constraints and restrictions from sk_chk_filter() apply
+skb pointer). All constraints and restrictions from bpf_check_classic() apply
before a conversion to the new layout is being done behind the scenes!
Currently, the classic BPF format is being used for JITing on most of the
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 3769341a745d..c4d0be4c5e75 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -361,7 +361,7 @@ void sk_unattached_filter_destroy(struct sk_filter *fp);
int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk);
int sk_detach_filter(struct sock *sk);
-int sk_chk_filter(const struct sock_filter *filter, unsigned int flen);
+int bpf_check_classic(const struct sock_filter *filter, unsigned int flen);
int sk_get_filter(struct sock *sk, struct sock_filter __user *filter,
unsigned int len);
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 265a02cc822d..b479807ec383 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -18,7 +18,7 @@
* 2 of the License, or (at your option) any later version.
*
* Andi Kleen - Fix a few bad bugs and races.
- * Kris Katterjohn - Added many additional checks in sk_chk_filter()
+ * Kris Katterjohn - Added many additional checks in bpf_check_classic()
*/
#include
#include
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 565743db5384..f4a77d23f209 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -87,7 +87,7 @@ static void populate_seccomp_data(struct seccomp_data *sd)
* @filter: filter to verify
* @flen: length of filter
*
- * Takes a previously checked filter (by sk_chk_filter) and
+ * Takes a previously checked filter (by bpf_check_classic) and
* redirects all filter code that loads struct sk_buff data
* and related data through seccomp_bpf_load. It also
* enforces length and alignment checking of those loads.
@@ -239,7 +239,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog)
goto free_prog;
/* Check and rewrite the fprog via the skb checker */
- ret = sk_chk_filter(fp, fprog->len);
+ ret = bpf_check_classic(fp, fprog->len);
if (ret)
goto free_prog;
diff --git a/net/core/filter.c b/net/core/filter.c
index d6cb287e4f59..5740ea08a3ad 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -18,7 +18,7 @@
* 2 of the License, or (at your option) any later version.
*
* Andi Kleen - Fix a few bad bugs and races.
- * Kris Katterjohn - Added many additional checks in sk_chk_filter()
+ * Kris Katterjohn - Added many additional checks in bpf_check_classic()
*/
#include
@@ -721,7 +721,7 @@ static bool chk_code_allowed(u16 code_to_probe)
}
/**
- * sk_chk_filter - verify socket filter code
+ * bpf_check_classic - verify socket filter code
* @filter: filter to verify
* @flen: length of filter
*
@@ -734,7 +734,7 @@ static bool chk_code_allowed(u16 code_to_probe)
*
* Returns 0 if the rule set is legal or -EINVAL if not.
*/
-int sk_chk_filter(const struct sock_filter *filter, unsigned int flen)
+int bpf_check_classic(const struct sock_filter *filter, unsigned int flen)
{
bool anc_found;
int pc;
@@ -808,7 +808,7 @@ int sk_chk_filter(const struct sock_filter *filter,
unsigned int flen)
return -EINVAL;
}
-EXPORT_SYMBOL(sk_chk_filter);
+EXPORT_SYMBOL(bpf_check_classic);
static int sk_store_orig_filter(struct sk_filter *fp,
const struct sock_fprog *fprog)
@@ -968,7 +968,7 @@ static struct sk_filter *__sk_prepare_filter(struct
sk_filter *fp)
fp->bpf_func = NULL;
fp->jited = 0;
- err = sk_chk_filter(fp->insns, fp->len);
+ err = bpf_check_classic(fp->insns, fp->len);
if (err) {
__sk_filter_release(fp);
return ERR_PTR(err);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
[PATCH v4 net-next 5/5] net: filter: split 'struct sk_filter' into socket and bpf parts
clean up names related to socket filtering and bpf in the following way:
- everything that deals with sockets keeps 'sk_*' prefix
- everything that is pure BPF is changed to 'bpf_*' prefix
split 'struct sk_filter' into
struct sk_filter {
atomic_trefcnt;
struct rcu_head rcu;
struct bpf_prog *prog;
};
and
struct bpf_prog {
u32 jited:1,
len:31;
struct sock_fprog_kern *orig_prog;
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct bpf_insn *filter);
union {
struct sock_filter insns[0];
struct bpf_insn insnsi[0];
struct work_struct work;
};
};
so that 'struct bpf_prog' can be used independent of sockets and cleans up
'unattached' bpf use cases
split SK_RUN_FILTER macro into:
SK_RUN_FILTER to be used with 'struct sk_filter *' and
BPF_PROG_RUN to be used with 'struct bpf_prog *'
__sk_filter_release(struct sk_filter *) gains
__bpf_prog_release(struct bpf_prog *) helper function
also perform related renames for the functions that work
with 'struct bpf_prog *', since they're on the same lines:
sk_filter_size -> bpf_prog_size
sk_filter_select_runtime -> bpf_prog_select_runtime
sk_filter_free -> bpf_prog_free
sk_unattached_filter_create -> bpf_prog_create
sk_unattached_filter_destroy -> bpf_prog_destroy
sk_store_orig_filter -> bpf_prog_store_orig_filter
sk_release_orig_filter -> bpf_release_orig_filter
__sk_migrate_filter -> bpf_migrate_filter
__sk_prepare_filter -> bpf_prepare_filter
API for attaching classic BPF to a socket stays the same:
sk_attach_filter(prog, struct sock *)/sk_detach_filter(struct sock *)
and SK_RUN_FILTER(struct sk_filter *, ctx) to execute a program
which is used by sockets, tun, af_packet
API for 'unattached' BPF programs becomes:
bpf_prog_create(struct bpf_prog **)/bpf_prog_destroy(struct bpf_prog *)
and BPF_PROG_RUN(struct bpf_prog *, ctx) to execute a program
which is used by isdn, ppp, team, seccomp, ptp, xt_bpf, cls_bpf, test_bpf
Signed-off-by: Alexei Starovoitov
---
Documentation/networking/filter.txt | 10 ++--
arch/arm/net/bpf_jit_32.c|8 +--
arch/mips/net/bpf_jit.c |8 +--
arch/powerpc/net/bpf_jit_comp.c |8 +--
arch/s390/net/bpf_jit_comp.c |4 +-
arch/sparc/net/bpf_jit_comp.c|4 +-
arch/x86/net/bpf_jit_comp.c | 12 ++--
drivers/isdn/i4l/isdn_ppp.c | 26 -
drivers/net/ppp/ppp_generic.c| 28 -
drivers/net/team/team_mode_loadbalance.c | 14 ++---
include/linux/filter.h | 40 +++--
include/linux/isdn_ppp.h |4 +-
include/uapi/linux/netfilter/xt_bpf.h|4 +-
kernel/bpf/core.c| 30 +-
kernel/seccomp.c | 10 ++--
lib/test_bpf.c | 24
net/core/filter.c| 92 +-
net/core/ptp_classifier.c|6 +-
net/core/sock_diag.c |2 +-
net/netfilter/xt_bpf.c |6 +-
net/sched/cls_bpf.c | 12 ++--
21 files changed, 183 insertions(+), 169 deletions(-)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index 712068be8171..c48a9704bda8 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -586,11 +586,11 @@ team driver's classifier for its load-balancing mode,
netfilter's xt_bpf
extension, PTP dissector/classifier, and much more. They are all internally
converted by the kernel into the new instruction set representation and run
in the eBPF interpreter. For in-kernel handlers, this all works transparently
-by using sk_unattached_filter_create() for setting up the filter, resp.
-sk_unattached_filter_destroy() for destroying it. The macro
-SK_RUN_FILTER(filter, ctx) transparently invokes eBPF interpreter or JITed
-code to run the filter. 'filter' is a pointer to struct sk_filter that we
-got from sk_unattached_filter_create(), and 'ctx' the given context (e.g.
+by using bpf_prog_create() for setting up the filter, resp.
+bpf_prog_destroy() for destroying it. The macro
+BPF_PROG_RUN(filter, ctx) transparently invokes eBPF interpreter or JITed
+code to run the filter. 'filter' is a pointer to struct bpf_prog that we
+got from bpf_prog_create(), and 'ctx' the given context (e.g.
skb pointer). All constraints and restrictions from bpf_check_classic() apply
before a conversion to the new layout is being done behind the scenes!
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index fb5503ce016f..a37b989a2f91 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -56,7 +56,7 @@
#define
Re: Work Queue for btrfs compression writes
On Wed, Jul 30, 2014 at 11:14 PM, Austin S Hemmelgarn wrote: > On 07/30/2014 12:54 AM, Nick Krause wrote: >> On Wed, Jul 30, 2014 at 12:37 AM, Gareth Pye wrote: >>> You've been replied to politely, now listen and do or shut up. >>> >>> >>> On Wed, Jul 30, 2014 at 1:54 PM, Nick Krause wrote: Hey Guys , I am new to reading and writing kernel code.I got interested in writing code for btrfs as it seems to need more work then other file systems and this seems other then drivers, a good use of time on my part. I interested in helping improving the compression of btrfs by using a set of threads using work queues like XFS or reads and keeping the page cache after reading compressed blocks as these seem to be a great way to improve on compression performance mostly with large partitions of compressed data. I am not asking you to write the code for me but as I am new a little guidance and help would be greatly appreciated as this seems like too much work for just a newbie. Thanks A lot, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >>> >>> -- >>> Gareth Pye >>> Level 2 Judge, Melbourne, Australia >>> Australian MTG Forum: mtgau.com >>> gar...@cerberos.id.au - www.rockpaperdynamite.wordpress.com >>> "Dear God, I would like to file a bug report" >> >> Gareth >> I am asking for advice on not writing the code but can someone please >> test this for me as I don't have many hard drives lying around. In addition >> I am new to btrfs , so I would like to known if this is a good idea or should >> I just drop it? >> Nick >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@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 would look into using usermode linux (linux built with ARCH=um) for at > least the initial debugging, it is marginally more efficient than > virtualization, doesn't need root privileges, and allows you to run the > kernel under GDB without needing separate hardware with a serial console > or PS/2 keyboard. > That's what I am thinking the only issue is I am going to start my reading on work queues first. Regards Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] fs: Add dirreadahead syscall and VFS hooks
On Tue, Jul 29, 2014 at 10:21:50AM +0200, Michael Kerrisk wrote: > [CC+=linux-api] > > On Fri, Jul 25, 2014 at 7:37 PM, Abhi Das wrote: > > Also adds a void *opaque field to struct dir_context that can be > > used by filesystems to temporarily store any context as this > > struct gets passed around in the fs. So the prototype is: int dir_readahead(int fd, off64_t offset, unsigned int count); Why do we need a new syscall for this? $ man 2 readahead ssize_t readahead(int fd, off64_t offset, size_t count); EINVAL fd does not refer to a file type to which readahead() can be applied. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] smpboot: remove the unneeded declaration for smpboot_thread_data
smpboot.h doesn't need this declaration, remove it. CC: Thomas Gleixner Signed-off-by: Lai Jiangshan --- include/linux/smpboot.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h index 13e9296..d37dc78 100644 --- a/include/linux/smpboot.h +++ b/include/linux/smpboot.h @@ -4,8 +4,6 @@ #include struct task_struct; -/* Cookie handed to the thread_fn*/ -struct smpboot_thread_data; /** * struct smp_hotplug_thread - CPU hotplug related thread descriptor -- 1.7.4.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] swap: remove the struct cpumask has_work
It is suggested that cpumask_var_t and alloc_cpumask_var() should be used
instead of struct cpumask. But I don't want to add this complicity nor
leave this unwelcome "static struct cpumask has_work;", so I just remove
it and use flush_work() to perform on all online drain_work. flush_work()
performs very quickly on initialized but unused work item, thus we don't
need the struct cpumask has_work for performance.
CC: a...@linux-foundation.org
CC: Chris Metcalf
CC: Mel Gorman
CC: Tejun Heo
CC: Christoph Lameter
CC: Frederic Weisbecker
Signed-off-by: Lai Jiangshan
---
mm/swap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index 9e8e347..bb524ca 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -833,27 +833,24 @@ static DEFINE_PER_CPU(struct work_struct,
lru_add_drain_work);
void lru_add_drain_all(void)
{
static DEFINE_MUTEX(lock);
- static struct cpumask has_work;
int cpu;
mutex_lock();
get_online_cpus();
- cpumask_clear(_work);
for_each_online_cpu(cpu) {
struct work_struct *work = _cpu(lru_add_drain_work, cpu);
+ INIT_WORK(work, lru_add_drain_per_cpu);
+
if (pagevec_count(_cpu(lru_add_pvec, cpu)) ||
pagevec_count(_cpu(lru_rotate_pvecs, cpu)) ||
pagevec_count(_cpu(lru_deactivate_pvecs, cpu)) ||
- need_activate_page_drain(cpu)) {
- INIT_WORK(work, lru_add_drain_per_cpu);
+ need_activate_page_drain(cpu))
schedule_work_on(cpu, work);
- cpumask_set_cpu(cpu, _work);
- }
}
- for_each_cpu(cpu, _work)
+ for_each_online_cpu(cpu)
flush_work(_cpu(lru_add_drain_work, cpu));
put_online_cpus();
--
1.7.4.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] smpboot: add missing get_online_cpus() when register
If the smpboot_register_percpu_thread() is called after smpboot_create_threads()
but before __cpu_up(), the smpboot thread of the online-ing CPU is not created,
and it results a bug. So we use get_online_cpus() to prevent it.
smpboot_unregister_percpu_thread() travels all possible CPU, it doesn't need
get_online_cpus() which is removed in the patch.
CC: Thomas Gleixner
Cc: Rusty Russell
Cc: Peter Zijlstra
Cc: Srivatsa S. Bhat
CC: sta...@kernel.org
Signed-off-by: Lai Jiangshan
---
kernel/smpboot.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index eb89e18..8adab87 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struct
smp_hotplug_thread *plug_thread)
unsigned int cpu;
int ret = 0;
+ get_online_cpus();
mutex_lock(_threads_lock);
for_each_online_cpu(cpu) {
ret = __smpboot_create_thread(plug_thread, cpu);
@@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struct
smp_hotplug_thread *plug_thread)
list_add(_thread->list, _threads);
out:
mutex_unlock(_threads_lock);
+ put_online_cpus();
return ret;
}
EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
@@ -303,11 +305,9 @@ EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
*/
void smpboot_unregister_percpu_thread(struct smp_hotplug_thread *plug_thread)
{
- get_online_cpus();
mutex_lock(_threads_lock);
list_del(_thread->list);
smpboot_destroy_threads(plug_thread);
mutex_unlock(_threads_lock);
- put_online_cpus();
}
EXPORT_SYMBOL_GPL(smpboot_unregister_percpu_thread);
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] readdirplus implementations: xgetdents vs dirreadahead syscalls
On Mon, Jul 28, 2014 at 08:22:22AM -0400, Abhijith Das wrote: > > > - Original Message - > > From: "Dave Chinner" > > To: "Zach Brown" > > Cc: "Abhijith Das" , linux-kernel@vger.kernel.org, > > "linux-fsdevel" , > > "cluster-devel" > > Sent: Friday, July 25, 2014 7:38:59 PM > > Subject: Re: [RFC] readdirplus implementations: xgetdents vs dirreadahead > > syscalls > > > > On Fri, Jul 25, 2014 at 10:52:57AM -0700, Zach Brown wrote: > > > On Fri, Jul 25, 2014 at 01:37:19PM -0400, Abhijith Das wrote: > > > > Hi all, > > > > > > > > The topic of a readdirplus-like syscall had come up for discussion at > > > > last year's > > > > LSF/MM collab summit. I wrote a couple of syscalls with their GFS2 > > > > implementations > > > > to get at a directory's entries as well as stat() info on the individual > > > > inodes. > > > > I'm presenting these patches and some early test results on a > > > > single-node > > > > GFS2 > > > > filesystem. > > > > > > > > 1. dirreadahead() - This patchset is very simple compared to the > > > > xgetdents() system > > > > call below and scales very well for large directories in GFS2. > > > > dirreadahead() is > > > > designed to be called prior to getdents+stat operations. > > > > > > Hmm. Have you tried plumbing these read-ahead calls in under the normal > > > getdents() syscalls? > > > > The issue is not directory block readahead (which some filesystems > > like XFS already have), but issuing inode readahead during the > > getdents() syscall. > > > > It's the semi-random, interleaved inode IO that is being optimised > > here (i.e. queued, ordered, issued, cached), not the directory > > blocks themselves. As such, why does this need to be done in the > > kernel? This can all be done in userspace, and even hidden within > > the readdir() or ftw/ntfw() implementations themselves so it's OS, > > kernel and filesystem independent.. > > > > I don't see how the sorting of the inode reads in disk block order can be > accomplished in userland without knowing the fs-specific topology. I didn't say anything about doing "disk block ordering" in userspace. disk block ordering can be done by the IO scheduler and that's simple enough to do by multithreading and dispatch a few tens of stat() calls at once > From my > observations, I've seen that the performance gain is the most when we can > order the reads such that seek times are minimized on rotational media. Yup, which is done by ensuring that we drive deep IO queues rather than issuing a single IO at a time and waiting for completion before issuing the next one. This can easily be done from userspace. > I have not tested my patches against SSDs, but my guess would be that the > performance impact would be minimal, if any. Depends. if the overhead of executing readahead is higher than the time spent waiting for IO completion, then it will reduce performance. i.e. the faster the underlying storage, the less CPU time we want to spend on IO. Readahead generally increases CPU time per object that needs to be retrieved from disk, and so on high IOP devices there's a really good chance we don't want readahead like this at all. i.e. this is yet another reason directory traversal readahead should be driven from userspace so the policy can be easily controlled by the application and/or user Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARC fails to boot on linux-next of 20140711
On Sat, 26 Jul 2014 15:10:28 -0500, Rob Herring wrote:
> On Sat, Jul 26, 2014 at 11:50 AM, Grant Likely
> wrote:
> > On Sat, 26 Jul 2014 06:52:36 +, Vineet Gupta
> > wrote:
> >> Hi Rob,
> >>
> >> On Friday 25 July 2014 07:45 PM, Rob Herring wrote:
> >> > On Fri, Jul 25, 2014 at 6:02 AM, Vineet Gupta
> >> > wrote:
> >> >> > Hi Grant,
> >> >> >
> >> >> > linux-next has a series for arc_uart (via tty tree) which converts it
> >> >> > to generic
> >> >> > earlycon and specifies console via /chosen/stdout-path vs. an
> >> >> > explicit param in
> >> >> > /chose/bootargs
> >> >> >
> >> >> > 2014-06-24 9da433c0a0b5 ARC: [arcfpga] stdout-path now suffices for
> >> >> > earlycon/console
> >> >> >
> >> >> > This relied on prev commit of yours (from linux next of 20140711),
> >> >> > which seem to
> >> >> > have disappeared now.
> >> >> >
> >> >> > 2014-03-27 a9296cf2d0b6 of: Create of_console_check() for selecting a
> >> >> > console
> >> >> > specified in /chosen
> >> >> > 2014-03-27 cfa9cacc5dd3 of: Enable console on serial ports specified
> >> >> > by
> >> >> > /chosen/stdout-path
> >> >> >
> >> >> > Is there a specific reason for dropping these patches (or perhaps a
> >> >> > merge to be
> >> >> > merged). I cherry-picked both but still doesn't work.
> >> >> >
> >> >> > Can you please advise next step forward, before I go off debugging
> >> >> > with those
> >> >> > patches in.
> >> > There's an issue that if you have stdout-path and "earlycon" on the
> >> > command line, the kernel will switch to tty0 and disable the earlycon.
> >> >
> >> > This is the "fix", but I don't like adding the DT dependency into
> >> > generic code:
> >> >
> >> > @@ -2382,7 +2386,7 @@ void register_console(struct console *newcon)
> >> > if (newcon->setup == NULL ||
> >> > newcon->setup(newcon, NULL) == 0) {
> >> > newcon->flags |= CON_ENABLED;
> >> > - if (newcon->device) {
> >> > + if (newcon->device && !of_stdout) {
> >> > newcon->flags |= CON_CONSDEV;
> >> > preferred_console = 0;
> >> > }
> >>
> >> The DT settings relevant for ARC, which enable generic-earlycon and
> >> console-with-stdout-path are as follows
> >>
> >> chosen {
> >> bootargs = "earlycon";
> >> stdout-path =
> >> };
> >>
> >>
> >> arcuart0: serial@c0fc1000 {
> >> compatible = "snps,arc-uart";
> >>
> >> And it works w/o above hunk, provided the 2 patches from Grant exist in
> >> linux-next
> >> which they don't at the moment. I'm pretty confused how the hunk above
> >> comes into
> >> picture.
> >>
> >> And if not then I will have to get the ARC std-out patch reverted in
> >> tty-next as
> >> it is broken.
> >
> > You need to revert it anyway, the dependency chain is broken. Just
> > because something is in linux-next doesn't mean it will be merged.
> > Dependencies must always be in the branch to which you commit.
> >
> > If that doesn't happen (like here) then bisecting is broken and the
> > dependencies may not actually get merged.
> >
> > When this happens, what you're supposed to do is tell the maintainers
> > what commits the patch depends on so that it can be applied to the
> > correct tree. In this case I could take it through my devicetree branch
> > that contains the console patches.
> >
> > If a patch depends on commits in several branches then it is a bit more
> > complex. What we usually do is create a new branch that merges in each
> > branch that is depended on, and then apply the commit on top of that.
> >
> > As for the console patches, I'm only going to be putting them back if I
> > can devise a good fix for the earlycon duplication issue.
>
> There is also a simple work-around. You have to specify the console
> when you use earlycon. For example, you can add "earlycon
> console=ttyAMA0" instead of just earlycon. To summarize, this is the
> state of combinations of console params:
>
> Working:
> stdout-path
> console=blah
> stdout-path + console=blah
> earlycon=blah
>
> Not working:
> stdout-path + earlycon
>
> Also, it is a developer only feature which is new. You will be aware
> of an issue because the earlycon starts output and then stops on
> switching to tty0 versus complete silence which could be anything.
Fair enough. Okay, I'm going to put it back into linux-next. The proper
fix can come later.
> There are other landmines in this area already. For example, setting
> earlycon on ARM will break the boot because an ioremap is attempted
> before paging_init. This is nothing new, but has always been the case
> if the 8250 driver was enabled.
We should not allow earlycon to be selectable on ARM until this is
fixed. Can you do a patch for this?
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Re: [REVERT][v3.16-rc7][STABLE] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
On 07/30/2014 06:42 PM, Julius Werner wrote: > Hi Joseph, > >> Julius, I was hoping to get your feedback, since you are the patch >> author. Do you think gathering any additional data will help diagnose >> this issue, or would it be best to continue with this revert request? > As I understand it, this crash will disappear with Mathias' new rework > for finding the cycle state bit in > http://www.spinics.net/lists/linux-usb/msg111259.html , so a revert > should not be necessary. Hi Julius / Mathias, I was able to built a test kernel with the patch against 3.16-rc7. However, the patch would not compile against the 3.13.y stable tree(I'll debug why further). Is there plans for a version of the patch that will work with stable kernels? Thanks, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking
Hi Morten, On Wed, Jul 30, 2014 at 11:13:31AM +0100, Morten Rasmussen wrote: > > > 2. runnable_load_avg and blocked_load_avg are combined > > > > > > runnable_load_avg currently represents the sum of load_avg_contrib of > > > all tasks on the rq, while blocked_load_avg is the sum of those tasks > > > not on a runqueue. It makes perfect sense to consider the sum of both > > > when calculating the load of a cpu, but we currently don't include > > > blocked_load_avg. The reason for that is the priority scaling of the > > > task load_avg_contrib may lead to under-utilization of cpus that > > > occasionally have tiny high priority task running. You can easily have a > > > task that takes 5% of cpu time but has a load_avg_contrib several times > > > larger than a default priority task runnable 100% of the time. > > > > So this is the effect of historical averaging and weight scaling, both of > > which > > are just generally good, but may have bad cases. > > I don't agree that weight scaling is generally good. There has been > several threads discussing that topic over the last half year or so. It > is there to ensure smp niceness, but it makes load-balancing on systems > which are not fully utilized sub-optimal. You may end up with some cpus > not being fully utilized while others are over-utilized when you have > multiple tasks running at different priorities. > > It is a very real problem when user-space uses priorities extensively > like Android does. Tasks related to audio run at very high priorities > but only for a very short amount of time, but due the to priority > scaling their load ends up being several times higher than tasks running > all the time at normal priority. Hence task load is a very poor > indicator of utilization. I understand the problem you said, but the problem is not described crystal clear. You are saying tasks with big weight contribute too much, even they are running short time. But is it unfair or does it lead to imbalance? It is hard to say if not no. They have big weight, so are supposed to be "unfair" vs. small weight tasks for the sake of fairness. In addition, since they are running short time, their runnable weight/load is offset by this factor. I think I am saying from pure fairness ponit of view, which is just generally good in the sense that we can't think of a more "generally good" thing to replace it. And you are saying when big weight task is not runnable, but already contributes "too much" load, then leads to under utilization. So this is the matter of our predicting algorithm. I am afraid I will say again the pridiction is generally good. For the audio example, which is strictly periodic, it just can't be better. FWIW, I am really not sure how serious this under utilization problem is in real world. I am not saying your argument does not make sense. It makes every sense from specific case ponit from view. I do think there absolutely can be sub-optimal cases. But as I said, I just don't think the problem description is clear enough so that we know it is worth solving (by pros and cons comparison) and how to solve it, either generally or specifically. Plus, as Peter said, we have to live with user space uses big weight, and do it as what weight is supposed to be. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] dirreadahead system call
On Fri, 25 Jul 2014 12:37:29 -0500 Abhi Das wrote: > This system call takes 3 arguments: > fd - file descriptor of the directory being readahead > *offset - offset in dir from which to resume. This is updated > as we move along in the directory > count - The max number of entries to readahead > > The syscall is supposed to read upto 'count' entries starting at > '*offset' and cache the inodes corresponding to those entries. It > returns a negative error code or a positive number indicating > the number of inodes it has issued readaheads for. It also > updates the '*offset' value so that repeated calls to dirreadahead > can resume at the right location. Returns 0 when there are no more > entries left. Hi Abhi, I like the idea of enhanced read-ahead on a directory. It isn't clear to me why you have included these particular fields in the interface though. - why have an 'offset'? Why not just use the current offset of the directory 'fd'? - Why have a count? How would a program choose what count to give? Maybe you imagine using 'getdents' first to get a list of names, then selectively calling 'dirreadahead' on the offsets of the names you are interested it? That would be racy as names can be added and removed which might change offsets. So maybe you have another reason? I would like to suggest an alternate interface (I love playing the API game). 1/ Add a flag to 'fstatat' AT_EXPECT_MORE. If the pathname does not contain a '/', then the 'dirfd' is marked to indicate that stat information for all names returned by getdents will be wanted. The filesystem can choose to optimise that however it sees fit. 2/ Add a flag to 'fstatat' AT_NONBLOCK. This tells the filesystem that you want this information, so if it can return it immediately it should, and if not it should start pulling it into cache. Possibly this should be two flags: AT_NONBLOCK just avoids any IO, and AT_ASYNC instigates IO even if NONBLOCK is set. Then an "ls -l" could use AT_EXPECT_MORE and then just stat each name. An "ls -l *.c", might avoid AT_EXPECT_MORE, but would use AT_NONBLOCK against all names, then try again with all the names that returned EWOULDBLOCK the first time. I would really like to see the 'xstat' syscall too, but there is no point having both "xstat" and "fxstat". Follow the model of "fstatat" and provide just "fxstatat" which can do both. With fxstatat, AT_EXPECT_MORE would tell the dirfd exactly which attributes would be wanted so it can fetch only that which is desired. I'm not very keen on the xgetdents idea of including name information and stat information into the one syscall - I would prefer getdents and xstat be kept separate. Of course if a genuine performance cost of the separate can be demonstrated, I could well change my mind. It does, however, have the advantage that the kernel doesn't need to worry about how long read-ahead data needs to be kept, and the application doesn't need to worry about how soon to retry an fstatat which failed with EWOULDBLOCK. Thanks for raising this issue again. I hope it gets fixed one day... NeilBrown signature.asc Description: PGP signature
Re: [PATCH v3] staging: vt6655: ioctl.c - missing __user annotation
On Thursday 31 July 2014 05:38 AM, Greg KH wrote: > > This patch doesn't apply against my tree at all, what did you make it > against? > > Always work against linux-next, or the staging-next branch of my > staging.git tree on git.kernel.org. > > thanks, > > greg k-h Hi, I am working on staging.git. After rebasing with staging-next, git log shows someone has recently submitted this fix. Thanks, Anil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] readdirplus implementations: xgetdents vs dirreadahead syscalls
On Mon, Jul 28, 2014 at 03:21:20PM -0600, Andreas Dilger wrote: > On Jul 25, 2014, at 6:38 PM, Dave Chinner wrote: > > On Fri, Jul 25, 2014 at 10:52:57AM -0700, Zach Brown wrote: > >> On Fri, Jul 25, 2014 at 01:37:19PM -0400, Abhijith Das wrote: > >>> Hi all, > >>> > >>> The topic of a readdirplus-like syscall had come up for discussion at > >>> last year's > >>> LSF/MM collab summit. I wrote a couple of syscalls with their GFS2 > >>> implementations > >>> to get at a directory's entries as well as stat() info on the individual > >>> inodes. > >>> I'm presenting these patches and some early test results on a single-node > >>> GFS2 > >>> filesystem. > >>> > >>> 1. dirreadahead() - This patchset is very simple compared to the > >>> xgetdents() system > >>> call below and scales very well for large directories in GFS2. > >>> dirreadahead() is > >>> designed to be called prior to getdents+stat operations. > >> > >> Hmm. Have you tried plumbing these read-ahead calls in under the normal > >> getdents() syscalls? > > > > The issue is not directory block readahead (which some filesystems > > like XFS already have), but issuing inode readahead during the > > getdents() syscall. > > > > It's the semi-random, interleaved inode IO that is being optimised > > here (i.e. queued, ordered, issued, cached), not the directory > > blocks themselves. > > Sure. > > > As such, why does this need to be done in the > > kernel? This can all be done in userspace, and even hidden within > > the readdir() or ftw/ntfw() implementations themselves so it's OS, > > kernel and filesystem independent.. > > That assumes sorting by inode number maps to sorting by disk order. > That isn't always true. That's true, but it's a fair bet that roughly ascending inode number ordering is going to be better than random ordering for most filesystems. Besides, ordering isn't the real problem - the real problem is the latency caused by having to do the inode IO synchronously one stat() at a time. Just multithread the damn thing in userspace so the stat()s can be done asynchronously and hence be more optimally ordered by the IO scheduler and completed before the application blocks on the IO. It doesn't even need completion synchronisation - the stat() issued by the application will block until the async stat() completes the process of bringing the inode into the kernel cache... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Work Queue for btrfs compression writes
On 07/30/2014 12:54 AM, Nick Krause wrote: > On Wed, Jul 30, 2014 at 12:37 AM, Gareth Pye wrote: >> You've been replied to politely, now listen and do or shut up. >> >> >> On Wed, Jul 30, 2014 at 1:54 PM, Nick Krause wrote: >>> >>> Hey Guys , >>> I am new to reading and writing kernel code.I got interested in >>> writing code for btrfs as it seems to >>> need more work then other file systems and this seems other then >>> drivers, a good use of time on my part. >>> I interested in helping improving the compression of btrfs by using a >>> set of threads using work queues like XFS >>> or reads and keeping the page cache after reading compressed blocks as >>> these seem to be a great way to improve >>> on compression performance mostly with large partitions of compressed >>> data. I am not asking you to write the code >>> for me but as I am new a little guidance and help would be greatly >>> appreciated as this seems like too much work for just a newbie. >>> Thanks A lot, >>> Nick >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> >> -- >> Gareth Pye >> Level 2 Judge, Melbourne, Australia >> Australian MTG Forum: mtgau.com >> gar...@cerberos.id.au - www.rockpaperdynamite.wordpress.com >> "Dear God, I would like to file a bug report" > > Gareth > I am asking for advice on not writing the code but can someone please > test this for me as I don't have many hard drives lying around. In addition > I am new to btrfs , so I would like to known if this is a good idea or should > I just drop it? > Nick > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 would look into using usermode linux (linux built with ARCH=um) for at least the initial debugging, it is marginally more efficient than virtualization, doesn't need root privileges, and allows you to run the kernel under GDB without needing separate hardware with a serial console or PS/2 keyboard. smime.p7s Description: S/MIME Cryptographic Signature
Re: [x86,kaslr] [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1422 warn_pre_alternatives()
On Thu, Jul 31, 2014 at 10:42:12AM +0800, Fengguang Wu wrote: > On Wed, Jul 30, 2014 at 08:52:07AM -0700, Paul E. McKenney wrote: > > On Wed, Jul 30, 2014 at 10:17:32PM +0800, Fengguang Wu wrote: > > > On Wed, Jul 30, 2014 at 10:07:56PM +0800, Fengguang Wu wrote: > > > > Hi Andy, > > > > > > > > Here is another WARNING message for the same commit. > > > > > > > > commit d07c7f1ed61789e175fa975134855be32263be2c > > > > Author: Andy Lutomirski > > > > AuthorDate: Tue Jul 15 18:34:20 2014 -0700 > > > > Commit: Andy Lutomirski > > > > CommitDate: Wed Jul 16 10:01:27 2014 -0700 > > > > > > > > x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available > > > > > > > > It's considerably better than any of the alternatives on KVM. > > > > > > > > Rather than reinventing all of the cpu feature query code, this > > > > fixes > > > > native_cpuid to work in PIC objects. > > > > > > > > I haven't combined it with boot/cpuflags.c's cpuid implementation: > > > > including asm/processor.h from boot/cpuflags.c results in a flood of > > > > unrelated errors, and fixing it might be messy. > > > > > > > > Signed-off-by: Andy Lutomirski > > > > > > > > +-+++ > > > > | > > > > | c6f07a6360 | d07c7f1ed6 | > > > > +-+++ > > > > | boot_successes > > > > | 1000 | 636| > > > > | boot_failures > > > > | 0 | 84 | > > > > | > > > > WARNING:CPU:PID:at_arch/x86/kernel/cpu/common.c:warn_pre_alternatives() > > > > | 0 | 84 | > > > > | BUG:unable_to_handle_kernel_NULL_pointer_dereference > > > > | 0 | 84 | > > > > | Oops > > > > | 0 | 84 | > > > > | RIP:__free_pages_bootmem > > > > | 0 | 84 | > > > > | Kernel_panic-not_syncing:Fatal_exception > > > > | 0 | 84 | > > > > | backtrace:free_all_bootmem > > > > | 0 | 84 | > > > > | backtrace:mem_init > > > > | 0 | 84 | > > > > +-+++ > > > > > > > > [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes) > > > > [0.00] xsave: enabled xstate_bv 0x7, cntxt size 0x0 > > > > [0.00] [ cut here ] > > > > [0.00] WARNING: CPU: 0 PID: 0 at > > > > arch/x86/kernel/cpu/common.c:1422 warn_pre_alternatives+0x1e/0x20() > > > > [0.00] You're using static_cpu_has before alternatives have run! > > > > [0.00] Modules linked in: > > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > > 3.16.0-rc5-4-gd07c7f1 #4 > > > > [0.00] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > > > > [0.00] 81803c18 813a7bd2 > > > > 81803c60 > > > > [0.00] 81803c50 810a5485 810102f9 > > > > 81803e08 > > > > [0.00] 0002 077c > > > > 81803cb0 > > > > [0.00] Call Trace: > > > > [0.00] [] dump_stack+0x4d/0x66 > > > > [0.00] [] warn_slowpath_common+0x7f/0x98 > > > > [0.00] [] ? warn_pre_alternatives+0x1e/0x20 > > > > [0.00] [] warn_slowpath_fmt+0x4c/0x4e > > > > [0.00] [] ? restore_args+0x30/0x30 > > > > [0.00] [] warn_pre_alternatives+0x1e/0x20 > > > > [0.00] [] __do_page_fault+0x1bd/0x7ca > > > > [0.00] [] ? console_unlock+0x377/0x3c1 > > > > [0.00] [] ? trace_hardirqs_off+0xd/0xf > > > > [0.00] [] ? > > > > _raw_spin_unlock_irqrestore+0x40/0x5e > > > > [0.00] [] ? __next_mem_range_rev+0x205/0x232 > > > > [0.00] [] ? > > > > trace_hardirqs_off_caller+0xe7/0x128 > > > > [0.00] [] ? > > > > trace_hardirqs_off_thunk+0x3a/0x3c > > > > [0.00] [] do_page_fault+0x22/0x27 > > > > [0.00] [] page_fault+0x28/0x30 > > > > [0.00] [] ? __free_pages_bootmem+0x2d/0xf9 > > > > [0.00] [] __free_memory_core+0xa7/0xbe > > > > [0.00] [] free_all_bootmem+0x51/0xd2 > > > > [0.00] [] mem_init+0x5c/0x8d > > > > [0.00] [] start_kernel+0x1f7/0x53d > > > > [0.00] [] ? set_init_arg+0x55/0x55 > > > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > > > [
Re: [delayed_fput] BUG: unable to handle kernel paging request at ffff8800122a0ad0
On Wed, Jul 30, 2014 at 7:40 PM, Fengguang Wu wrote:
> On Wed, Jul 30, 2014 at 04:00:58PM -0700, Alexei Starovoitov wrote:
>> On Wed, Jul 30, 2014 at 3:51 PM, David Rientjes wrote:
>> > On Wed, 30 Jul 2014, Christoph Hellwig wrote:
>> >
>> >> On Wed, Jul 30, 2014 at 11:55:41AM +0800, Fengguang Wu wrote:
>> >> > Greetings,
>> >> >
>> >> > 0day kernel testing robot got the below dmesg and the first bad commit
>> >> > is
>> >>
>> >> How does this manage to trip over a 2 year old commit now?
>>
>> may be because all kernels are built with gcc 4.8.2 ?
>> Fengguang, did you recently switch to new compiler?
>> I think all older builds were with 4.6.3
>
> Alexei, I've been using gcc 4.8.2 for 4 months.
>
> Maybe it's because I test new randconfigs every day. And the problem
> may only show up with very specific kernel config?
It seems a lot of odd crashes suddenly showed up and I'm guessing it
may be related to compiler...
See commit 2062afb4f8 ("Fix gcc-4.9.0 miscompilation of load_balance()
in scheduler")
it's a nasty gcc bug that affects 4.9 and 4.8.
I think it makes sense to apply that workaround before debugging much with 4.8
just to eliminate the possibility of miscompiled code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [x86,kaslr] [ 0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1422 warn_pre_alternatives()
On Wed, Jul 30, 2014 at 08:52:07AM -0700, Paul E. McKenney wrote: > On Wed, Jul 30, 2014 at 10:17:32PM +0800, Fengguang Wu wrote: > > On Wed, Jul 30, 2014 at 10:07:56PM +0800, Fengguang Wu wrote: > > > Hi Andy, > > > > > > Here is another WARNING message for the same commit. > > > > > > commit d07c7f1ed61789e175fa975134855be32263be2c > > > Author: Andy Lutomirski > > > AuthorDate: Tue Jul 15 18:34:20 2014 -0700 > > > Commit: Andy Lutomirski > > > CommitDate: Wed Jul 16 10:01:27 2014 -0700 > > > > > > x86,kaslr: Use MSR_KVM_GET_RNG_SEED for KASLR if available > > > > > > It's considerably better than any of the alternatives on KVM. > > > > > > Rather than reinventing all of the cpu feature query code, this fixes > > > native_cpuid to work in PIC objects. > > > > > > I haven't combined it with boot/cpuflags.c's cpuid implementation: > > > including asm/processor.h from boot/cpuflags.c results in a flood of > > > unrelated errors, and fixing it might be messy. > > > > > > Signed-off-by: Andy Lutomirski > > > > > > +-+++ > > > | > > > | c6f07a6360 | d07c7f1ed6 | > > > +-+++ > > > | boot_successes > > > | 1000 | 636| > > > | boot_failures > > > | 0 | 84 | > > > | WARNING:CPU:PID:at_arch/x86/kernel/cpu/common.c:warn_pre_alternatives() > > > | 0 | 84 | > > > | BUG:unable_to_handle_kernel_NULL_pointer_dereference > > > | 0 | 84 | > > > | Oops > > > | 0 | 84 | > > > | RIP:__free_pages_bootmem > > > | 0 | 84 | > > > | Kernel_panic-not_syncing:Fatal_exception > > > | 0 | 84 | > > > | backtrace:free_all_bootmem > > > | 0 | 84 | > > > | backtrace:mem_init > > > | 0 | 84 | > > > +-+++ > > > > > > [0.00] PID hash table entries: 2048 (order: 2, 16384 bytes) > > > [0.00] xsave: enabled xstate_bv 0x7, cntxt size 0x0 > > > [0.00] [ cut here ] > > > [0.00] WARNING: CPU: 0 PID: 0 at > > > arch/x86/kernel/cpu/common.c:1422 warn_pre_alternatives+0x1e/0x20() > > > [0.00] You're using static_cpu_has before alternatives have run! > > > [0.00] Modules linked in: > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > 3.16.0-rc5-4-gd07c7f1 #4 > > > [0.00] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > > > [0.00] 81803c18 813a7bd2 > > > 81803c60 > > > [0.00] 81803c50 810a5485 810102f9 > > > 81803e08 > > > [0.00] 0002 077c > > > 81803cb0 > > > [0.00] Call Trace: > > > [0.00] [] dump_stack+0x4d/0x66 > > > [0.00] [] warn_slowpath_common+0x7f/0x98 > > > [0.00] [] ? warn_pre_alternatives+0x1e/0x20 > > > [0.00] [] warn_slowpath_fmt+0x4c/0x4e > > > [0.00] [] ? restore_args+0x30/0x30 > > > [0.00] [] warn_pre_alternatives+0x1e/0x20 > > > [0.00] [] __do_page_fault+0x1bd/0x7ca > > > [0.00] [] ? console_unlock+0x377/0x3c1 > > > [0.00] [] ? trace_hardirqs_off+0xd/0xf > > > [0.00] [] ? > > > _raw_spin_unlock_irqrestore+0x40/0x5e > > > [0.00] [] ? __next_mem_range_rev+0x205/0x232 > > > [0.00] [] ? > > > trace_hardirqs_off_caller+0xe7/0x128 > > > [0.00] [] ? trace_hardirqs_off_thunk+0x3a/0x3c > > > [0.00] [] do_page_fault+0x22/0x27 > > > [0.00] [] page_fault+0x28/0x30 > > > [0.00] [] ? __free_pages_bootmem+0x2d/0xf9 > > > [0.00] [] __free_memory_core+0xa7/0xbe > > > [0.00] [] free_all_bootmem+0x51/0xd2 > > > [0.00] [] mem_init+0x5c/0x8d > > > [0.00] [] start_kernel+0x1f7/0x53d > > > [0.00] [] ? set_init_arg+0x55/0x55 > > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > > [0.00] [] x86_64_start_reservations+0x2a/0x2c > > > [0.00] [] x86_64_start_kernel+0x140/0x14d > > > [0.00] ---[ end trace e4962b91bd705c64 ]--- > > > [0.00] BUG: unable to handle kernel NULL pointer dereference at > > > 077c > > > > >
Re: General flags to turn things off (getrandom, pid lookup, etc)
One Thousand Gnomes writes: > On Wed, 30 Jul 2014 11:41:41 -0700 > ebied...@xmission.com (Eric W. Biederman) wrote: > >> One Thousand Gnomes writes: >> >> >> Andy you seem to be arguing here for two system calls. >> >> get_urandom() and get_random(). >> >> >> >> Where get_urandom only blocks if there is not enough starting entropy, >> >> and get_random(GRND_RANDOM) blocks if there is currently not enough >> >> entropy. >> >> >> >> That would allow -ENOSYS to be the right return value and it would >> >> simply things for everyone. >> > >> > So you replace the "no file handle" special case with the "unsupported or >> > disabled syscall" special case, which is even harder to test. >> > >> > Interfaces have failure modes. People who can't deal with that shouldn't >> > be writing code that does anything important in languages which don't >> > handle it for them. >> >> Perhaps I misread the earlier conversation but it what I have read of >> this discussion people want to disable some of get_random() modes with >> seccomp. Today get_random does not have any failure codes define except >> -ENOSYS. >> >> get_random(0) succeeding and get_random(GRND_RANDOM) returning -ENOSYS >> has every chance of causing applications to legitimately assume the >> get_random system call is not available in any mode. > > Or more likely it'll be used like this > > get_random(foo);/* always works */ > > > Now the existing failure mode is is > > open(...) > /* forget the check */ > read() > /* forget the check */ > > and triggered by evil local attacks on file handles. The "improved" > behaviour is unchecked -ENOSYS returns which are likely to occur > systemically when users run stuff on old kernels, in vm's with it off etc. > > So you've swapped the odd evil user attack on a single target for the > likelyhood of mass generation of flawed keys with no error reporting. > > In fact you could do a better job of the whole mess in libc rather than > the kernel, because in libc you'd write it like this > > if (open(.. ) < 0) > kill(getpid(), 9); >if (read(...) < expected) > kill(getpid(), 9); >close(fd); > > and > a) on an older library you'd get a good failure (unable to execute the > binary) > b) on a newer system you'd get "do or die" behaviour and can improve its > robustness as desired I have said enough about the silliness of disabling this syscall with seccomp or related infrastructure. The aspect I like about get_random() is that it will silence the requests from people to enable binary sysctl support in the kernel. Just so they can get random numbers when /dev/random and /dev/urandom are absent in their chroots. sysctl(2) is finally legitmately going fading away. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [delayed_fput] BUG: unable to handle kernel paging request at ffff8800122a0ad0
On Wed, Jul 30, 2014 at 04:00:58PM -0700, Alexei Starovoitov wrote: > On Wed, Jul 30, 2014 at 3:51 PM, David Rientjes wrote: > > On Wed, 30 Jul 2014, Christoph Hellwig wrote: > > > >> On Wed, Jul 30, 2014 at 11:55:41AM +0800, Fengguang Wu wrote: > >> > Greetings, > >> > > >> > 0day kernel testing robot got the below dmesg and the first bad commit is > >> > >> How does this manage to trip over a 2 year old commit now? > > may be because all kernels are built with gcc 4.8.2 ? > Fengguang, did you recently switch to new compiler? > I think all older builds were with 4.6.3 Alexei, I've been using gcc 4.8.2 for 4 months. Maybe it's because I test new randconfigs every day. And the problem may only show up with very specific kernel config? Thanks, Fengguang > > I think there's something weird going on with the testing of CONFIG_SLOB, > > same as http://permalink.gmane.org/gmane.linux.kernel/1759314 that > > identified a harmless commit that only initializes a field of > > struct mm_struct and then ended up exploded in slob freeing. > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
Hi Russell,
On Wed, Jul 30, 2014 at 10:26:35AM +0100, Russell King wrote:
> On Mon, Jul 21, 2014 at 02:07:56PM -0700, Brian Norris wrote:
> > +static DEFINE_SPINLOCK(boot_lock);
> > +
> > +static void brcmstb_secondary_init(unsigned int cpu)
> > +{
> > + /*
> > +* Synchronise with the boot thread.
> > +*/
> > + spin_lock(_lock);
> > + spin_unlock(_lock);
> > +}
> > +
> > +static int brcmstb_boot_secondary(unsigned int cpu, struct task_struct
> > *idle)
> > +{
> > + /*
> > +* set synchronisation state between this boot processor
> > +* and the secondary one
> > +*/
> > + spin_lock(_lock);
> > +
> > + /* Bring up power to the core if necessary */
> > + if (brcmstb_cpu_get_power_state(cpu) == 0)
> > + brcmstb_cpu_power_on(cpu);
> > +
> > + brcmstb_cpu_boot(cpu);
> > +
> > + /*
> > +* now the secondary core is starting up let it run its
> > +* calibrations, then wait for it to finish
> > +*/
> > + spin_unlock(_lock);
>
> I've just read through this code (because it caused my allmodconfig to
> break) and spotted this.
Sorry about the allmodconfig problems. I never compile-tested with ARMv6
enabled. This look OK?
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index f3665121729b..5ce82b4ba931 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
ifeq ($(CONFIG_ARCH_BRCMSTB),y)
+CFLAGS_platsmp-brcmstb.o += -march=armv7-a
obj-y += brcmstb.o
obj-$(CONFIG_SMP) += headsmp-brcmstb.o platsmp-brcmstb.o
endif
> What function does boot_lock perform here? Please, don't quote the
> comments (I know where the comments came from) but what I want to hear
> is your comments about why you decided to retain this.
You might glean a little more from my response to Rob, but I'm not sure
there was a good reason for retaining this. We do need to be sure the
CPU is fully powered online before bringing it out of reset, but the
spinlock seems overkill AFAICT.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [perf/x86/RAPL] BUG: unable to handle kernel NULL pointer dereference at 00000028
Hi Stephane, On Wed, Jul 30, 2014 at 07:56:11PM +0200, Stephane Eranian wrote: > On Wed, Jul 30, 2014 at 7:53 AM, Fengguang Wu wrote: > > On Wed, Jul 30, 2014 at 06:45:58AM +0200, Stephane Eranian wrote: > >> On Wed, Jul 30, 2014 at 6:00 AM, Fengguang Wu > >> wrote: > >> > Greetings, > >> > > >> > 0day kernel testing robot got the below dmesg and the first bad commit is > >> > > >> Is this booting a guest kernel or native? > > > > It's a guest kernel. > > > >> What is the host CPU? > > > > The host CPU is E5-2680, Sandy Bridge-EP. > > > I thought this problem had already be mentioned a while back. > > See https://lkml.org/lkml/2014/3/6/685 > And https://lkml.org/lkml/2014/4/23/512 > > So what you are telling here is that those two fixes never made it or > that you are > running an older kernel. I just checked linux-next and find that the bug in rapl_pmu_init() has been fixed. linux-next happen to have the same "BUG: unable to handle kernel NULL pointer dereference" message but at another function validate_chain().. Attached is the dmesg in linux-next. Sorry for the noise! Thanks, Fengguang > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > >> > commit 4788e5b4b2338f85fa42a712a182d8afd65d7c58 > >> > Author: Stephane Eranian > >> > AuthorDate: Tue Nov 12 17:58:50 2013 +0100 > >> > Commit: Ingo Molnar > >> > CommitDate: Wed Nov 27 11:16:40 2013 +0100 > >> > > >> > perf/x86: Add Intel RAPL PMU support > >> > > >> > This patch adds a new uncore PMU to expose the Intel > >> > RAPL energy consumption counters. Up to 3 counters, > >> > each counting a particular RAPL event are exposed. > >> > > >> > The RAPL counters are available on Intel SandyBridge, > >> > IvyBridge, Haswell. The server skus add a 3rd counter. > >> > > >> > The following events are available and exposed in sysfs: > >> > > >> > - power/energy-cores: power consumption of all cores on socket > >> > - power/energy-pkg: power consumption of all cores + LLc cache > >> > - power/energy-dram: power consumption of DRAM (servers only) > >> > > >> > For each event both the unit (Joules) and scale (2^-32 J) > >> > is exposed in sysfs for use by perf stat and other tools. > >> > The files are: > >> > > >> > /sys/devices/power/events/energy-*.unit > >> > /sys/devices/power/events/energy-*.scale > >> > > >> > The RAPL PMU is uncore by nature and is implemented such > >> > that it only works in system-wide mode. Measuring only > >> > one CPU per socket is sufficient. The /sys/devices/power/cpumask > >> > file can be used by tools to figure out which CPUs to monitor > >> > by default. For instance, on a 2-socket system, 2 CPUs > >> > (one on each socket) will be shown. > >> > > >> > All the counters measure in the same unit (exposed via sysfs). > >> > The perf_events API exposes all RAPL counters as 64-bit integers > >> > counting in unit of 1/2^32 Joules (about 0.23 nJ). User level tools > >> > must convert the counts by multiplying them by 2^-32 to obtain > >> > Joules. The reason for this is that the kernel avoids > >> > doing floating point math whenever possible because it is > >> > expensive (user floating-point state must be saved). The method > >> > used avoids kernel floating-point usage. There is no loss of > >> > precision. Thanks to PeterZ for suggesting this approach. > >> > > >> > To convert the raw count in Watt: > >> >W = C * 2.3 / (1e10 * time) > >> > or ldexp(C, -32). > >> > > >> > RAPL PMU is a new standalone PMU which registers with the > >> > perf_event core subsystem. The PMU type (attr->type) is > >> > dynamically allocated and is available from /sys/device/power/type. > >> > > >> > Sampling is not supported by the RAPL PMU. There is no > >> > privilege level filtering either. > >> > > >> > Signed-off-by: Stephane Eranian > >> > Reviewed-by: Maria Dimakopoulou > >> > Reviewed-by: Andi Kleen > >> > Signed-off-by: Peter Zijlstra > >> > Cc: a...@redhat.com > >> > Cc: jo...@redhat.com > >> > Cc: zheng.z@intel.com > >> > Cc: b...@alien8.de > >> > Link: > >> > http://lkml.kernel.org/r/1384275531-10892-4-git-send-email-eran...@google.com > >> > Signed-off-by: Ingo Molnar > >> > > >> > +---+++---+ > >> > | | 410136f5dd > >> > | 4788e5b4b2 | next-20140724 | > >> > +---+++---+ > >> > | boot_successes| 1000 > >> > | 751| 78| > >> > | boot_failures | 0 > >> > | 149| 3 | > >> > |
Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
Hi Rob,
I appreciate your comments, but where were many of these 5 months ago on
the first 7 revisions? :)
On a practical note: v9 is already queued for 3.17. Should I send
patches for the 3.17 cycle (or later) to fixup some of these issues? Or
would you recommend pulling the patches out of Matt Porter's tree now,
and reintroducing for 3.18? (I would be much happier with the first.)
I do note that we at least need to fix allmodconfig ASAP; I'll reply to
Russell on that one.
On Wed, Jul 30, 2014 at 12:09:48PM -0500, Rob Herring wrote:
> On Mon, Jul 21, 2014 at 4:07 PM, Brian Norris
> wrote:
> > From: Marc Carino
> >
> > The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
> >
> > This patch adds machine support for the ARM-based Broadcom SoCs.
> >
> > Signed-off-by: Marc Carino
> > Signed-off-by: Brian Norris
> > ---
> > arch/arm/configs/multi_v7_defconfig | 1 +
> > arch/arm/mach-bcm/Kconfig | 14 ++
> > arch/arm/mach-bcm/Makefile | 5 +
> > arch/arm/mach-bcm/brcmstb.c | 28 +++
> > arch/arm/mach-bcm/brcmstb.h | 19 ++
> > arch/arm/mach-bcm/headsmp-brcmstb.S | 33
> > arch/arm/mach-bcm/platsmp-brcmstb.c | 363
> >
> > 7 files changed, 463 insertions(+)
> > create mode 100644 arch/arm/mach-bcm/brcmstb.c
> > create mode 100644 arch/arm/mach-bcm/brcmstb.h
> > create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
> > create mode 100644 arch/arm/mach-bcm/platsmp-brcmstb.c
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig
> > b/arch/arm/configs/multi_v7_defconfig
> > index 534836497998..bf0df396a3cf 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> > @@ -19,6 +19,7 @@ CONFIG_MACH_DOVE=y
> > CONFIG_ARCH_BCM=y
> > CONFIG_ARCH_BCM_MOBILE=y
> > CONFIG_ARCH_BCM_5301X=y
> > +CONFIG_ARCH_BRCMSTB=y
> > CONFIG_ARCH_BERLIN=y
> > CONFIG_MACH_BERLIN_BG2=y
> > CONFIG_MACH_BERLIN_BG2CD=y
> > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > index 41c839167e87..0073633e7699 100644
> > --- a/arch/arm/mach-bcm/Kconfig
> > +++ b/arch/arm/mach-bcm/Kconfig
> > @@ -87,4 +87,18 @@ config ARCH_BCM_5301X
> > different SoC or with the older BCM47XX and BCM53XX based
> > network SoC using a MIPS CPU, they are supported by
> > arch/mips/bcm47xx
> >
> > +config ARCH_BRCMSTB
> > + bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
> > + depends on MMU
>
> This was implied, but there are some patches from Arnd in this area.
> Does it really not build with !MMU?
I suppose it probably builds, it likely won't run. I can drop this line
and then reassess if ARCH_MULTIPLATFORM becomes buildable with !MMU.
> > + select ARM_GIC
>
> > + select MIGHT_HAVE_PCI
> > + select HAVE_SMP
>
> At least HAVE_SMP is for sure, but I think both of these are selected already
> .
You're correct. ARCH_MULTIPLATFORM selects MIGHT_HAVE_PCI and
ARCH_MULTI_V7 selects HAVE_SMP. I can look at dropping these.
> > + select HAVE_ARM_ARCH_TIMER
> > + help
> > + Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> > + chipset.
> > +
> > + This enables support for Broadcom ARM-based set-top box chipsets,
> > + including the 7445 family of chips.
> > +
> > endif
> > diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> > index 731292114975..f3665121729b 100644
> > --- a/arch/arm/mach-bcm/Makefile
> > +++ b/arch/arm/mach-bcm/Makefile
> > @@ -30,3 +30,8 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
> >
> > # BCM5301X
> > obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
> > +
> > +ifeq ($(CONFIG_ARCH_BRCMSTB),y)
> > +obj-y += brcmstb.o
> > +obj-$(CONFIG_SMP) += headsmp-brcmstb.o platsmp-brcmstb.o
> > +endif
> > diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
> > new file mode 100644
> > index ..60a5afa06ed7
> > --- /dev/null
> > +++ b/arch/arm/mach-bcm/brcmstb.c
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Copyright (C) 2013-2014 Broadcom Corporation
> > + *
> > + * 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 version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +static const char *brcmstb_match[] __initconst = {
> > + "brcm,bcm7445",
> > + "brcm,brcmstb",
> > + NULL
> > +};
> > +
> > +DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
> > + .dt_compat = brcmstb_match,
>
[PATCHv2] CMA/HOTPLUG: clear buffer-head lru before page migration
The previous PATCH inserts invalidate_bh_lrus() only into CMA code. HOTPLUG needs also dropping bh of lru. So v2 inserts invalidate_bh_lrus() into both of CMA and HOTPLUG. 8< The bh must be free to migrate a page at which bh is mapped. The reference count of bh is increased when it is installed into lru so that the bh of lru must be freed before migrating the page. This frees every bh of lru. We could free only bh of migrating page. But searching lru sometimes costs more than invalidating entire lru. Signed-off-by: Gioh Kim Acked-by: Michal Nazarewicz --- mm/memory_hotplug.c |1 + mm/page_alloc.c |2 ++ 2 files changed, 3 insertions(+) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index a3797d3..1c5454f 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1672,6 +1672,7 @@ repeat: lru_add_drain_all(); cond_resched(); drain_all_pages(); + invalidate_bh_lrus(); } pfn = scan_movable_pages(start_pfn, end_pfn); diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b99643d4..c00dedf 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6369,6 +6369,8 @@ int alloc_contig_range(unsigned long start, unsigned long end, if (ret) return ret; + invalidate_bh_lrus(); + ret = __alloc_contig_migrate_range(, start, end); if (ret) goto done; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] i40e: use correct structure type name in sizeof
From: Julia Lawall Date: Tue, 29 Jul 2014 17:16:45 +0200 > From: Julia Lawall > > Correct typo in the name of the type given to sizeof. Because it is the > size of a pointer that is wanted, the typo has no impact on compilation or > execution. > > This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The > semantic patch used can be found in message 0 of this patch series. > > Signed-off-by: Julia Lawall I'll let the Intel driver folks pick this one up, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] CAPI: use correct structure type name in sizeof
From: Julia Lawall Date: Tue, 29 Jul 2014 17:16:44 +0200 > From: Julia Lawall > > Correct typo in the name of the type given to sizeof. Because it is the > size of a pointer that is wanted, the typo has no impact on compilation or > execution. > > This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The > semantic patch used can be found in message 0 of this patch series. > > Signed-off-by: Julia Lawall Relatively harmless, so applied to net-next, 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: [f2fs-dev] [PATCH] f2fs: reduce competition among node page writes
Hi Chao,
On Wed, Jul 30, 2014 at 09:07:49PM +0800, Chao Yu wrote:
> Hi Jaegeuk Changman,
>
> > -Original Message-
> > From: Chao Yu [mailto:chao2...@samsung.com]
> > Sent: Thursday, July 03, 2014 6:59 PM
> > To: Jaegeuk Kim; Changman Lee
> > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Subject: [f2fs-dev] [PATCH] f2fs: reduce competition among node page writes
> >
> > We do not need to block on ->node_write among different node page writers
> > e.g.
> > fsync/flush, unless we have a node page writer from write_checkpoint.
> > So it's better use rw_semaphore instead of mutex type for ->node_write to
> > promote performance.
>
> If you could have time to help explaining the problem of this patch, I will be
> appreciated for that.
I have no clue. Except checkpoint, I don't know why need to block to
write node page.
Do you have any problem when you test with this patch?
>
> Another question is what is ->writepages in sbi used for? I'm not quite clear.
>
I remember it is for writing data pages per thread as much as possible.
When multi-threads write some files simultaneously, multi-threads contended with
each other to allocate a block. So block allocation was interleaved
across threads. It makes fragmentation of file.
Thanks,
> Thanks,
>
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/checkpoint.c |6 +++---
> > fs/f2fs/f2fs.h |2 +-
> > fs/f2fs/node.c |4 ++--
> > fs/f2fs/super.c |2 +-
> > 4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index 0b4710c..eec406b 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -714,10 +714,10 @@ retry_flush_dents:
> > * until finishing nat/sit flush.
> > */
> > retry_flush_nodes:
> > - mutex_lock(>node_write);
> > + down_write(>node_write);
> >
> > if (get_pages(sbi, F2FS_DIRTY_NODES)) {
> > - mutex_unlock(>node_write);
> > + up_write(>node_write);
> > sync_node_pages(sbi, 0, );
> > goto retry_flush_nodes;
> > }
> > @@ -726,7 +726,7 @@ retry_flush_nodes:
> >
> > static void unblock_operations(struct f2fs_sb_info *sbi)
> > {
> > - mutex_unlock(>node_write);
> > + up_write(>node_write);
> > f2fs_unlock_all(sbi);
> > }
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index ae3b4ac..ca30b5a 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -444,7 +444,7 @@ struct f2fs_sb_info {
> > struct inode *meta_inode; /* cache meta blocks */
> > struct mutex cp_mutex; /* checkpoint procedure lock */
> > struct rw_semaphore cp_rwsem; /* blocking FS operations */
> > - struct mutex node_write;/* locking node writes */
> > + struct rw_semaphore node_write; /* locking node writes */
> > struct mutex writepages;/* mutex for writepages() */
> > bool por_doing; /* recovery is doing or not */
> > wait_queue_head_t cp_wait;
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index a90f51d..7b5b5de 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -1231,12 +1231,12 @@ static int f2fs_write_node_page(struct page *page,
> > if (wbc->for_reclaim)
> > goto redirty_out;
> >
> > - mutex_lock(>node_write);
> > + down_read(>node_write);
> > set_page_writeback(page);
> > write_node_page(sbi, page, , nid, ni.blk_addr, _addr);
> > set_node_addr(sbi, , new_addr, is_fsync_dnode(page));
> > dec_page_count(sbi, F2FS_DIRTY_NODES);
> > - mutex_unlock(>node_write);
> > + up_read(>node_write);
> > unlock_page(page);
> > return 0;
> >
> > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > index 8f96d93..bed9413 100644
> > --- a/fs/f2fs/super.c
> > +++ b/fs/f2fs/super.c
> > @@ -947,7 +947,7 @@ static int f2fs_fill_super(struct super_block *sb, void
> > *data, int silent)
> > mutex_init(>gc_mutex);
> > mutex_init(>writepages);
> > mutex_init(>cp_mutex);
> > - mutex_init(>node_write);
> > + init_rwsem(>node_write);
> > sbi->por_doing = false;
> > spin_lock_init(>stat_lock);
> >
> > --
> > 1.7.9.5
> >
> >
> >
> > --
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [PATCH 0/2 net-next] Lockless netlink_lookup() with new concurrent hash table
From: Thomas Graf Date: Tue, 29 Jul 2014 13:41:31 +0200 > Netlink sockets are maintained in a hash table to allow efficient lookup > via the port ID for unicast messages. However, lookups currently require > a read lock to be taken. This series adds a new generic, resizable, > scalable, concurrent hash table based on the paper referenced in the first > patch. It then makes use of the new data type to implement lockless > netlink_lookup(). > > Against net-next since the initial user of the new hash table is in net/ > > Thomas Graf (2): > lib: Resizable, Scalable, Concurrent Hash Table > netlink: Convert netlink_lookup() to use RCU protected hash table This series looks great, please post an updated series once you have addressed the current feedback. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]
On 07/30/2014 07:16 PM, Rafael J. Wysocki wrote: On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote: On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote: On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote: On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote: On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote: [cut] This patch effectively reverts commit 955ef483. The issue reported in this patch is valid. We are seeing that internally too. I believe I reported it in another thread (within the past month). However, the original patch fixes a real deadlock issue (I'm too tired to look it up now). We can revet the original, but it's going to bring back the original issue. I just want to make sure Prarit and Raphael realize this before proceeding. I do have plans for a proper fix for the mainline (not stable branches), but plan to do that after the current set of suspend/hotplug patches go through. The fix would be easier to make after that. OK, I'm convinced by this. I suppose we should push it for -stable from 3.10 through 3.15.x, right? Rafael, I think that is a good idea. I'm not sure what the protocol is for adding sta...@kernel.org though ... I'll take care of this, thanks! But you aren't going to pull the in for the next release, right? What do you mean? Reverting the commit will bring back another dead lock issue. So, you don't want to revert it on mainline. Do I still not make sense because I'm not using the right terms? -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:irq/core] PM / sleep / irq: Do not suspend wakeup interrupts
Hi Thomas, On Tuesday, July 15, 2014 04:01:10 AM tip-bot for Rafael J. Wysocki wrote: > Commit-ID: d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1 > Gitweb: http://git.kernel.org/tip/d709f7bcbb3ab01704fa7b37a2e4b981cf3783c1 > Author: Rafael J. Wysocki > AuthorDate: Thu, 10 Jul 2014 23:37:54 +0200 > Committer: Thomas Gleixner > CommitDate: Tue, 15 Jul 2014 12:57:26 +0200 > > PM / sleep / irq: Do not suspend wakeup interrupts Please revert this one as it will introduce a problem with shared interrupts analogous to the one that the handling of IRQF_NO_SUSPEND has. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Remove certain calls for releasing page cache
On Wed, Jul 30, 2014 at 7:30 PM, Dave Airlie wrote: >> This patch removes the lines for releasing the page cache in certain >> files as this may aid in perfomance with writes in the compression >> rountines of btrfs. Please note that this patch has not been tested >> on my own hardware due to no compression based btrfs volumes of my >> own. >> > > For all that is sacred, STOP. > > Go and do something else, you are wasting people's valuable time, > > Don't send any patches you haven't tested ever. If you aren't capable > of setting up a VM to run compressed btrfs volumes in, what makes you > think you can patch the code. > > This isn't how you learn to be a kernel developer by wasting other > kernel developers time, if you can't work out why releasing the page cache > is necessary then don't send the patch until you have spent the time > understanding what the page cache is. > > I know you'll just ignore this, and keep on trucking just like you ignored > the other messages from Stephen before. > > But if you want to work on the kernel, this isn't the way to do it, and > nobody will ever take a patch from you seriously if you continue in this > fashion. > > Dave. Dave , Seems I need to have tested this code first. Regards Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:irq/core] irq: Warn when shared interrupts do not match on NO_SUSPEND
Hi Thomas, On Thursday, July 24, 2014 08:36:36 AM tip-bot for Peter Zijlstra wrote: > Commit-ID: 4fae4e7624653ef498d0e2a38f00620b9701ab04 > Gitweb: http://git.kernel.org/tip/4fae4e7624653ef498d0e2a38f00620b9701ab04 > Author: Peter Zijlstra > AuthorDate: Thu, 24 Jul 2014 15:39:21 +0200 > Committer: Thomas Gleixner > CommitDate: Thu, 24 Jul 2014 17:32:56 +0200 > > irq: Warn when shared interrupts do not match on NO_SUSPEND Please revert this one as it is likely to break existing stuff (I'm mostly worried about the ACPI interrupt, but also about a number of drivers that have been using NO_SUSPEND along with SHARED for quite some time). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: ipv4: net namespace does not inherit network configurations
On 07/30/2014 01:48 AM, Cong Wang wrote: On Tue, Jul 29, 2014 at 2:29 AM, zhuyj wrote: Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 > /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root@qemu1:~# ip netns add fib1 root@qemu1:~# ip netns exec fib1 bash root@qemu1:~# cat /proc/sys/net/ipv6/conf/all/forwarding 0 root@qemu1:~# cat /proc/sys/net/ipv4/conf/all/forwarding 1 The behavior of ipv4 and ipv6 is very inconsistent. I checked the kernel source code. I found that from this patch [ipv6: fix bad free of addrconf_init_net], the above difference appeared. Since a net namespace is independent to another. That is, there is no any relationship between the net namespaces. So the behavior of ipv4 is not correct. Well, they are already independent, not shared, just that the initial value is duplicated from init_net for IPv4. This change might break existing applications which rely on this behavior, but given IPv6 change is almost the same, I think it's ok. BTW, you need to submit a patch as normal, instead of as an attachment. OK. Thanks a lot. Zhu Yanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]
On Wednesday, July 30, 2014 06:36:00 PM Saravana Kannan wrote: > On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote: > > On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote: > >> > >> On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote: > >>> On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote: > > > > [cut] > > > This patch effectively reverts commit 955ef483. > > The issue reported in this patch is valid. We are seeing that internally > too. I believe I reported it in another thread (within the past month). > > However, the original patch fixes a real deadlock issue (I'm too tired > to look it up now). We can revet the original, but it's going to bring > back the original issue. I just want to make sure Prarit and Raphael > realize this before proceeding. > > I do have plans for a proper fix for the mainline (not stable branches), > but plan to do that after the current set of suspend/hotplug patches go > through. The fix would be easier to make after that. > > >>> > >>> OK, I'm convinced by this. > >>> > >>> I suppose we should push it for -stable from 3.10 through 3.15.x, right? > >> > >> Rafael, I think that is a good idea. I'm not sure what the protocol is for > >> adding sta...@kernel.org though ... > > > > I'll take care of this, thanks! > > > > But you aren't going to pull the in for the next release, right? What do you mean? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] irq / PM: New driver interface for wakeup interrupts
On Thursday, July 31, 2014 02:12:11 AM Thomas Gleixner wrote: > On Thu, 31 Jul 2014, Thomas Gleixner wrote: > > On Wed, 30 Jul 2014, Rafael J. Wysocki wrote: > > Before this code changes in any way I want to see: > > > > 1) a description of the existing semantics and their background On that one, the meaning of IRQF_NO_SUSPEND is quite simple to me. If it is set (for the first irqaction in a given irq_desc) suspend_device_irqs() will leave that IRQ alone (that is, will not disable it and will not mark it as IRQS_SUSPENDED). As a result, if an interrupt for that irq_desc happens after suspend_device_irqs(), the interrupt handlers from all of its irqactions will be invoked. So this basically means "ignore that IRQ" to suspend_device_irqs() and that's its *only* meaning. It's primary users are timers, per-CPU IRQs, ACPI SCI, via-pmu, Xen. There also is a bunch of drivers that use it for wakeup stuff, but they shouldn't in my opinion. The background I'm aware of was primarily timers (we wanted to be able to msleep() during PCI PM transitions in the noirq phases of system suspend and resume among other things), and we want per-CPU stuff to work all the time too. ACPI uses it for signaling various types of events (including battery and thermal) that need to be handled all the time. I'm not sure why Xen needs it exactly, but that seems to be IPI-related. The current handling of IRQF_NO_SUSPEND has a problem vs shared interrupts which I've tried to address by https://patchwork.kernel.org/patch/4643871/ and which is described in the changelog of that patch. Unfortunately, some existing users pass IRQF_SHARED along with IRQF_NO_SUSPEND which is the main motivation for that. Many of them use it for wakeup purposes, but for one example (that doesn't use it for wakeup only) the ACPI SCI is shareable by design. To be continued. > > 2) a description of the short comings of the existing semantics w/o > > considering the new fangled (hardware) use cases > > > > 3) a description how to mitigate the short comings described in #2 > > w/o breaking the world and some more and introducing hard to > > decode regressions > > > > 4) a description why the improvements introduced by #3 are not > > sufficient for the new fangled (hardware) use cases > > > > 5) a description how to mitigate the short comings described in #4 > > w/o breaking the world and some more and introducing hard to > > decode regressions > > Aside of that I want to see a coherent explanation why a shared MSI > interrupt makes any sense at all. > > 25: 1 <> 0 PCI-MSI-edge aerdrv, PCIe PME > > AFAICT, that's the primary reason why you insist to support wakeup > sources on shared irq lines. And to be honest, it's utter bullshit. No, this isn't the primary reason. Here's /proc/interrupts from my MSI Wind system and, as you can see, PCIe PME are (a) not MSI and (b) shared with some interesting things (USB, WiFi and the GPU). CPU0 CPU1 0: 26321 0 IO-APIC-edge timer 1:379 0 IO-APIC-edge i8042 7: 6 0 IO-APIC-edge 9: 59 0 IO-APIC-fasteoi acpi 12: 2824 0 IO-APIC-edge i8042 14: 9074 0 IO-APIC-edge ata_piix 15: 0 0 IO-APIC-edge ata_piix 16: 5217 0 IO-APIC-fasteoi PCIe PME, uhci_hcd:usb4, i915 17: 13964 0 IO-APIC-fasteoi PCIe PME, rtl818x_pci 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 0 0 IO-APIC-fasteoi uhci_hcd:usb2 23: 9402 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5 40: 61 0 PCI-MSI-edge eth0 41:102 0 PCI-MSI-edge snd_hda_intel NMI: 0 0 Non-maskable interrupts LOC: 18538 30831 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts IWI: 6 0 IRQ work interrupts RTR: 0 0 APIC ICR read retries RES: 5277 6121 Rescheduling interrupts CAL: 92106 Function call interrupts TLB:317302 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 5 5 Machine check polls ERR: 6 MIS: 0 > The whole purpose of MSI is to avoid interrupt sharing, but of course > if that particular interrupt source has two potential causes, i.e. the > AER and the PME one and the stupid hardware does not support different > vectors or the drivers are not able to do so, it's conveniant to make > them shared instead of thinking about them what they really are: > > Separate interrupts on a secondary interrupt controller connected to > the
Re: [REVERT][v3.16-rc7][STABLE] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
On 07/30/2014 06:42 PM, Julius Werner wrote: > Hi Joseph, > >> Julius, I was hoping to get your feedback, since you are the patch >> author. Do you think gathering any additional data will help diagnose >> this issue, or would it be best to continue with this revert request? > As I understand it, this crash will disappear with Mathias' new rework > for finding the cycle state bit in > http://www.spinics.net/lists/linux-usb/msg111259.html , so a revert > should not be necessary. Thanks, Julius. We will test that patch and report back. Thanks, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]
On 07/30/2014 02:40 PM, Rafael J. Wysocki wrote: On Wednesday, July 30, 2014 10:18:25 AM Prarit Bhargava wrote: On 07/29/2014 08:03 PM, Rafael J. Wysocki wrote: On Tuesday, July 29, 2014 07:46:02 AM Prarit Bhargava wrote: [cut] This patch effectively reverts commit 955ef483. The issue reported in this patch is valid. We are seeing that internally too. I believe I reported it in another thread (within the past month). However, the original patch fixes a real deadlock issue (I'm too tired to look it up now). We can revet the original, but it's going to bring back the original issue. I just want to make sure Prarit and Raphael realize this before proceeding. I do have plans for a proper fix for the mainline (not stable branches), but plan to do that after the current set of suspend/hotplug patches go through. The fix would be easier to make after that. OK, I'm convinced by this. I suppose we should push it for -stable from 3.10 through 3.15.x, right? Rafael, I think that is a good idea. I'm not sure what the protocol is for adding sta...@kernel.org though ... I'll take care of this, thanks! But you aren't going to pull the in for the next release, right? -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] therm_windtunnel doesn't work properly on PowerMac G4
On Wed, 2014-07-30 at 22:50 +0200, Goffredo Baroncelli wrote: > Hi All, > > I am writing to you Jean and Benjamin because it seem that both > worked on these items. > > On a PowerMac G4 I noticed that between the kernel v3.2 and v3.14 I lost > the fan management. > > I found on internet other references to this kind of problem [2] Patches look good, thanks. Jean do you want to apply them or should I ? Cheers, Ben. > > **How reproduce: > - booting with the kernel 3.2, the fan is "quite" silent. > The module therm_windtunnel is loaded and in the log there are > lines like: > > [ 1342.614956] CPU-temp: 58.7 C, Case: 33.7 C, Fan: 5 (tuned +0) > [ 1390.637793] CPU-temp: 58.6 C, Case: 33.6 C, Fan: 5 > > I had also access to the temperature via the sysfs files: > /sys/devices/temperature/case_temperature > /sys/devices/temperature/cpu_temperature > > > - booting with the kernel 3.14, the fan is very loud. The module > therm_windtunnel is not loaded. In the log there aren't any message > related to the temperature. The sysfs entries don't exist. > > > ** Analysis > In these Apple machines the module i2c-powermac requires the > i2c drivers provided by the module therm_windtunnel. > > Between the kernel v3.2 and v3.14 [1] some patches changed the > driver name requested by the i2c-powermac module, > so the therm_windtunnel modules is not instantiated anymore. > > > ** Proposed solution > In the following emails I sent you three patches to solve this > problem (tested on my PowerMac G4) > > 1) change the driver name > therm_ds1775 -> MAC,ds1775 > therm_adm1030 -> MAC,adm1030 > so the i2c driver are instantiated by i2c-powermac > > 2) remove the (unused) method do_attach from the i2c-driver > 3) add two parameters to the therm_windtunnel module > to control the kernel log message > > The patch 1) solve the problem. The patch 2) is a small cleanup. > The patch 3) allow a better control of the log in dmesg. > > Could you be so kindly to apply these patches ? > > BR > G.Baroncelli > > > > [1] I think that the guilty commit is > > commit 81e5d8646ff6bf323dddcf172aa3cef84468fa12 > Author: Benjamin Herrenschmidt > Date: Wed Apr 18 22:16:42 2012 + > > i2c/powermac: Register i2c devices from device-tree > > This causes i2c-powermac to register i2c devices exposed in the > device-tree, enabling new-style probing of devices. > > Note that we prefix the IDs with "MAC," in order to prevent the > generic drivers from matching. This is done on purpose as we only > want drivers specifically tested/designed to operate on powermacs > to match. > > This removes the special case we had for the AMS driver, and updates > the driver's match table instead. > > Signed-off-by: Benjamin Herrenschmidt > > [2] There is the debian bug #741663 which highlight the same problem. In > the bug discussion there is a patch like the my ones. > > See also > https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-July/099561.html > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] perf/x86/uncore: move SNB-EP/IvyTown specific code to seperate file
On 07/31/2014 09:08 AM, Yan, Zheng wrote: > On 07/30/2014 05:05 PM, Peter Zijlstra wrote: >> >> >> What's Ivytown? Is that IVB-EP or EX or both? I want to fix the subject >> to not mix and match these terms. > > It's IVB-EP > >> >> A quick search seems to suggest Ivytown is IVB-EX, which leaves me >> wondering what driver does IVB-EP use? >> >> Patch 2 seems to be about NHM/WSM/SNB/IVB client parts >> Patch 4 is about NHM/WSM EX parts >> >> Which leaves SNB/IBV-EP/EX unhandled, does this patch cover all 4 of >> those? > > > SNB-EP/IVB-EP's uncore subsystem are almost the same as SNB-EP/IVB-EP. sorry. I mean SNB-EX/IVB-EX's uncore subsystem are almost the same as SNB-EP/IVB-EP's. > >> >> Which I guess brings me to your total lack of Changelogs, this would've >> made prime changelog material. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Olof Johansson wrote: > > Hi, > Hi Olof, > On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim wrote: > > Andreas Färber wrote: > >> > >> Am 27.07.2014 14:22, schrieb Andreas Färber: > >> > Hello, > >> > > >> > This mini-series unbreaks booting on 5410 based ODROID-XU. > >> > > >> > Since I do not have access to a TRM, the address is a guess based on > >> > 5250 and 5410. Such a node was not present in the 3.14 downstream tree. > >> > >> s/5410/5420/ > >> > > OK. > > > >> > > >> > Regards, > >> > Andreas > >> > > >> > Andreas Färber (3): > >> > Documentation: devicetree: Document exynos5410 PMU > >> > ARM: dts: exynos: Add PMU to Exynos5410 > >> > ARM: EXYNOS: Add support for Exynos5410 PMU > >> > > >> > Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + > >> > arch/arm/boot/dts/exynos5410.dtsi | 5 + > >> > arch/arm/mach-exynos/exynos.c | 1 + > >> > 3 files changed, 7 insertions(+) > >> > > Andreas, thanks. > > > > I'll apply this whole series. > > We're getting close to the merge window. I'd prefer not to have to > start reverting samsung code to recover from these regressions, so > please send this up very soon. > Thanks for your gentle reminder. BTW I'm waiting for exynos5250-spring support from Andreas and I'd like to get confirmation about that from Doug. And I'm looking at s2r related patches now. OK, I will send out current samsung tree tonight in my time anyway. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] perf/x86/uncore: move SNB-EP/IvyTown specific code to seperate file
On 07/30/2014 05:05 PM, Peter Zijlstra wrote: > > > What's Ivytown? Is that IVB-EP or EX or both? I want to fix the subject > to not mix and match these terms. It's IVB-EP > > A quick search seems to suggest Ivytown is IVB-EX, which leaves me > wondering what driver does IVB-EP use? > > Patch 2 seems to be about NHM/WSM/SNB/IVB client parts > Patch 4 is about NHM/WSM EX parts > > Which leaves SNB/IBV-EP/EX unhandled, does this patch cover all 4 of > those? SNB-EP/IVB-EP's uncore subsystem are almost the same as SNB-EP/IVB-EP. > > Which I guess brings me to your total lack of Changelogs, this would've > made prime changelog material. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] usb: dwc2: add dr_mode support for dwc2
Some devices with A female host port and without use of usb_id pin
will need this for the otg controller works as device role
during firmware period and works as host role in rich os.
Signed-off-by: Kever Yang
---
Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h |5 +
drivers/usb/dwc2/platform.c |4
3 files changed, 27 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ u32 gusbcfg;
dev_vdbg(hsotg->dev, "%s()\n", __func__);
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset & GRSTCTL_CSFTRST);
+ if (hsotg->dr_mode == USB_DR_MODE_HOST) {
+ gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ writel(gusbcfg, hsotg->regs + GUSBCFG);
+ } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
+ gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg->regs + GUSBCFG);
+ } else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
+ gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg->regs + GUSBCFG);
+ }
+
/*
* NOTE: This long sleep is _very_ important, otherwise the core will
* not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..a34681c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
* a_peripheral and b_device=>b_host) this may not match
* the core, but allows the software to determine
* transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ * - USB_DR_MODE_PERIPHERAL
+ * - USB_DR_MODE_HOST
+ * - USB_DR_MODE_OTG
* @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
* transfer are in process of being queued
* @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+ enum usb_dr_modedr_mode;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index b14668b..669a03a 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
#include
#include
+#include
+
#include "core.h"
#include "hcd.h"
@@ -200,6 +202,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(>dev, "mapped PA %08lx to VA %p\n",
(unsigned long)res->start, hsotg->regs);
+ hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+
retval = dwc2_hcd_init(hsotg, irq, params);
if (retval)
return retval;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip v2 4/7] locking/mutex: Refactor optimistic spinning code
On Wed, 2014-07-30 at 13:41 -0700, Davidlohr Bueso wrote: > When we fail to acquire the mutex in the fastpath, we end up calling > __mutex_lock_common(). A *lot* goes on in this function. Move out the > optimistic spinning code into mutex_optimistic_spin() and simplify > the former a bit. Furthermore, this is similar to what we have in > rwsems. No logical changes. > > Signed-off-by: Davidlohr Bueso Acked-by: Jason Low -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: vmstat: On demand vmstat workers V8
On 07/30/2014 10:45 PM, Christoph Lameter wrote:
> On Wed, 30 Jul 2014, Lai Jiangshan wrote:
>
>> I think the bug is here, it re-queues the per_cpu(vmstat_work, cpu) which is
>> offline
>> (after vmstat_cpuup_callback(CPU_DOWN_PREPARE). And cpu_stat_off is
>> accessed without
>> proper lock.
>
> Ok. I guess we need to make the preemption check output more information
> so that it tells us that an operation was performed on a processor that is
> down?
If the cpu_allows of the percpu-kworker is changed, the specific processor of
the kworker
should have been down if workqueue is implemented correctly.
(the preemption check checks the cpu_allows)
>
>> I suggest to use get_cpu_online() or a new cpu_stat_off_mutex to protect it.
>
> If a processor is downed then cpu_stat_off bit should be cleared but also
> the worker thread should not run.
The kworker need to run for some reasons after the processor is down.
Peter and TJ were just discussing it.
The root cause (TO ME only) here is vmstat queues work to offline (or
offlining) CPU,
so the kworker has to run it. We may add some check for queuing on offline CPU,
but we can't check for higher level user guarantees. (Example, vmstat can't
queue
work to a CPU which is still online but after
vmstat_cpuup_callback(CPU_DOWN_PREPARE)).
>
>>> case CPU_DOWN_PREPARE:
>>> case CPU_DOWN_PREPARE_FROZEN:
>>> - cancel_delayed_work_sync(_cpu(vmstat_work, cpu));
>>> - per_cpu(vmstat_work, cpu).work.func = NULL;
>>> + if (!cpumask_test_and_set_cpu(cpu, cpu_stat_off))
>>> + cancel_delayed_work_sync(_cpu(vmstat_work, cpu));
>>
>> It is suggest that cancel_delayed_work_sync(_cpu(vmstat_work, cpu))
>> should
>> be called unconditionally. And the cpu should be cleared from cpu_stat_off.
>> (you set it, it is BUG according to vmstat_shepherd() and the semantics of
>> the
>> cpu_stat_off).
>
> True.
>
> Subject: vmstat ondemand: Fix online/offline races
>
> Do not allow onlining/offlining while the shepherd task is checking
> for vmstat threads.
>
> On offlining a processor do the right thing cancelling the vmstat
> worker thread if it exista and also exclude it from the shepherd
> process checks.
>
> Signed-off-by: Christoph Lameter
>
> Index: linux/mm/vmstat.c
> ===
> --- linux.orig/mm/vmstat.c2014-07-30 09:35:54.602662306 -0500
> +++ linux/mm/vmstat.c 2014-07-30 09:43:07.109037043 -0500
> @@ -1317,6 +1317,7 @@ static void vmstat_shepherd(struct work_
> {
> int cpu;
>
> + get_online_cpus();
> /* Check processors whose vmstat worker threads have been disabled */
> for_each_cpu(cpu, cpu_stat_off)
> if (need_update(cpu) &&
> @@ -1325,6 +1326,7 @@ static void vmstat_shepherd(struct work_
> schedule_delayed_work_on(cpu, _cpu(vmstat_work,
> cpu),
> __round_jiffies_relative(sysctl_stat_interval,
> cpu));
>
> + put_online_cpus();
>
> schedule_delayed_work(,
> round_jiffies_relative(sysctl_stat_interval));
> @@ -1380,8 +1382,8 @@ static int vmstat_cpuup_callback(struct
> break;
> case CPU_DOWN_PREPARE:
> case CPU_DOWN_PREPARE_FROZEN:
> - if (!cpumask_test_and_set_cpu(cpu, cpu_stat_off))
> - cancel_delayed_work_sync(_cpu(vmstat_work, cpu));
> + cancel_delayed_work_sync(_cpu(vmstat_work, cpu));
> + cpumask_clear_cpu(cpu, cpu_stat_off);
Sasha Levin's test result?
> break;
> case CPU_DOWN_FAILED:
> case CPU_DOWN_FAILED_FROZEN:
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2] wireless: ath9k: Convert from timespecs to ktime_t
Convert from using timespecs to ktime_t for internal timekeeping
needs. This simplifies the logic and avoids extra math required to
convert from timespec to usecs.
Cc: Stephen Rothwell
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: David Miller
Cc: "John W. Linville"
Cc: Felix Fietkau
Cc: Rajkumar Manoharan
Cc:
Cc: QCA ath9k Development
Cc: linux-n...@vger.kernel.org
Signed-off-by: John Stultz
---
Thomas made an earlier version of this patch which I queued,
but it collided badly in -next with the timestamping rework in
ath9k code. So this is my swing at fixing it up again.
v2: Fix an embarasing null pointer assignment Stephen pointed out
Compile tested only. Would apprecate feedback, testing, and review.
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/channel.c | 18 +-
drivers/net/wireless/ath/ath9k/hw.c | 19 ---
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c| 2 +-
5 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 7fc13a8..5553c0f 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -335,7 +335,7 @@ struct ath_chanctx {
struct ath_beacon_config beacon;
struct ath9k_hw_cal_data caldata;
- struct timespec tsf_ts;
+ ktime_t tsf_kt;
u64 tsf_val;
u32 last_beacon;
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index ba214eb..2b37f8d 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -228,9 +228,9 @@ static bool ath_chanctx_defer_switch(struct ath_softc *sc)
static void ath_chanctx_set_next(struct ath_softc *sc, bool force)
{
- struct timespec ts;
bool measure_time = false;
bool send_ps = false;
+ ktime_t now;
spin_lock_bh(>chan_lock);
if (!sc->next_chan) {
@@ -248,7 +248,7 @@ static void ath_chanctx_set_next(struct ath_softc *sc, bool
force)
spin_unlock_bh(>chan_lock);
if (sc->next_chan == >offchannel.chan) {
- getrawmonotonic();
+ now = ktime_get_raw();
measure_time = true;
}
__ath9k_flush(sc->hw, ~0, true);
@@ -260,7 +260,7 @@ static void ath_chanctx_set_next(struct ath_softc *sc, bool
force)
spin_lock_bh(>chan_lock);
if (sc->cur_chan != >offchannel.chan) {
- getrawmonotonic(>cur_chan->tsf_ts);
+ sc->cur_chan->tsf_kt = ktime_get_raw();
sc->cur_chan->tsf_val = ath9k_hw_gettsf64(sc->sc_ah);
}
}
@@ -279,7 +279,7 @@ static void ath_chanctx_set_next(struct ath_softc *sc, bool
force)
ath_set_channel(sc);
if (measure_time)
sc->sched.channel_switch_time =
- ath9k_hw_get_tsf_offset(, NULL);
+ ath9k_hw_get_tsf_offset(, NULL);
}
if (send_ps)
ath_chanctx_send_ps_frame(sc, false);
@@ -440,8 +440,8 @@ ath_chanctx_get_next(struct ath_softc *sc, struct
ath_chanctx *ctx)
static void ath_chanctx_adjust_tbtt_delta(struct ath_softc *sc)
{
struct ath_chanctx *prev, *cur;
- struct timespec ts;
u32 cur_tsf, prev_tsf, beacon_int;
+ ktime_t now;
s32 offset;
beacon_int = TU_TO_USEC(sc->cur_chan->beacon.beacon_interval);
@@ -449,12 +449,12 @@ static void ath_chanctx_adjust_tbtt_delta(struct
ath_softc *sc)
cur = sc->cur_chan;
prev = ath_chanctx_get_next(sc, cur);
- getrawmonotonic();
+ now = ktime_get_raw();
cur_tsf = (u32) cur->tsf_val +
- ath9k_hw_get_tsf_offset(>tsf_ts, );
+ ath9k_hw_get_tsf_offset(>tsf_kt, );
prev_tsf = prev->last_beacon - (u32) prev->tsf_val + cur_tsf;
- prev_tsf -= ath9k_hw_get_tsf_offset(>tsf_ts, );
+ prev_tsf -= ath9k_hw_get_tsf_offset(>tsf_kt, );
/* Adjust the TSF time of the AP chanctx to keep its beacons
* at half beacon interval offset relative to the STA chanctx.
@@ -614,7 +614,7 @@ void ath_chanctx_event(struct ath_softc *sc, struct
ieee80211_vif *vif,
*/
tsf_time = sc->sched.switch_start_time;
tsf_time -= (u32) sc->cur_chan->tsf_val +
- ath9k_hw_get_tsf_offset(>cur_chan->tsf_ts, NULL);
+ ath9k_hw_get_tsf_offset(>cur_chan->tsf_kt, NULL);
tsf_time += ath9k_hw_gettsf32(ah);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index fd0158f..1a0a556 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++
[PATCH v2 tip/core/rcu 06/10] rcutorture: Add RCU-tasks test cases
From: "Paul E. McKenney" This commit adds the TASKS01 and TASKS02 Kconfig fragments, along with the corresponding TASKS01.boot and TASKS02.boot boot-parameter files specifying that rcutorture test RCU-tasks instead of the default flavor. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/configs/rcu/TASKS01 | 7 +++ tools/testing/selftests/rcutorture/configs/rcu/TASKS01.boot | 1 + tools/testing/selftests/rcutorture/configs/rcu/TASKS02 | 6 ++ tools/testing/selftests/rcutorture/configs/rcu/TASKS02.boot | 1 + 4 files changed, 15 insertions(+) create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TASKS01 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TASKS01.boot create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TASKS02 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TASKS02.boot diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 new file mode 100644 index ..263a20f01fae --- /dev/null +++ b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01 @@ -0,0 +1,7 @@ +CONFIG_SMP=y +CONFIG_NR_CPUS=2 +CONFIG_HOTPLUG_CPU=y +CONFIG_PREEMPT_NONE=n +CONFIG_PREEMPT_VOLUNTARY=n +CONFIG_PREEMPT=y +CONFIG_TASKS_RCU=y diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TASKS01.boot b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01.boot new file mode 100644 index ..cd2a188eeb6d --- /dev/null +++ b/tools/testing/selftests/rcutorture/configs/rcu/TASKS01.boot @@ -0,0 +1 @@ +rcutorture.torture_type=tasks diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TASKS02 b/tools/testing/selftests/rcutorture/configs/rcu/TASKS02 new file mode 100644 index ..17b669c8833c --- /dev/null +++ b/tools/testing/selftests/rcutorture/configs/rcu/TASKS02 @@ -0,0 +1,6 @@ +CONFIG_SMP=n +CONFIG_HOTPLUG_CPU=y +CONFIG_PREEMPT_NONE=y +CONFIG_PREEMPT_VOLUNTARY=n +CONFIG_PREEMPT=n +CONFIG_TASKS_RCU=y diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TASKS02.boot b/tools/testing/selftests/rcutorture/configs/rcu/TASKS02.boot new file mode 100644 index ..cd2a188eeb6d --- /dev/null +++ b/tools/testing/selftests/rcutorture/configs/rcu/TASKS02.boot @@ -0,0 +1 @@ +rcutorture.torture_type=tasks -- 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 v2 tip/core/rcu 04/10] rcu: Export RCU-tasks APIs to GPL modules
From: Steven Rostedt This commit exports the RCU-tasks APIs, call_rcu_tasks(), synchronize_rcu_tasks(), and rcu_barrier_tasks(), to GPL-licensed kernel modules. Signed-off-by: Steven Rostedt Signed-off-by: Paul E. McKenney --- kernel/rcu/update.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index c8d304dc6d8a..1bfc07ed854e 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -429,6 +429,7 @@ void synchronize_rcu_tasks(void) /* Wait for the grace period. */ wait_rcu_gp(call_rcu_tasks); } +EXPORT_SYMBOL_GPL(synchronize_rcu_tasks); /** * rcu_barrier_tasks - Wait for in-flight call_rcu_tasks() callbacks. @@ -441,6 +442,7 @@ void rcu_barrier_tasks(void) /* There is only one callback queue, so this is easy. ;-) */ synchronize_rcu_tasks(); } +EXPORT_SYMBOL_GPL(rcu_barrier_tasks); /* RCU-tasks kthread that detects grace periods and invokes callbacks. */ static int __noreturn rcu_tasks_kthread(void *arg) -- 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 v2 tip/core/rcu 08/10] rcu: Improve RCU-tasks energy efficiency
From: "Paul E. McKenney"
The current RCU-tasks implementation uses strict polling to detect
callback arrivals. This works quite well, but is not so good for
energy efficiency. This commit therefore replaces the strict polling
with a wait queue.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/update.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index aef581854239..030494690c93 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -371,6 +371,7 @@ static LIST_HEAD(rcu_tasks_holdouts);
/* Global list of callbacks and associated lock. */
static struct rcu_head *rcu_tasks_cbs_head;
static struct rcu_head **rcu_tasks_cbs_tail = _tasks_cbs_head;
+static DECLARE_WAIT_QUEUE_HEAD(rcu_tasks_cbs_wq);
static DEFINE_RAW_SPINLOCK(rcu_tasks_cbs_lock);
/* Control stall timeouts. Disable with <= 0, otherwise jiffies till stall. */
@@ -381,13 +382,17 @@ module_param(rcu_task_stall_timeout, int, 0644);
void call_rcu_tasks(struct rcu_head *rhp, void (*func)(struct rcu_head *rhp))
{
unsigned long flags;
+ bool needwake;
rhp->next = NULL;
rhp->func = func;
raw_spin_lock_irqsave(_tasks_cbs_lock, flags);
+ needwake = !rcu_tasks_cbs_head;
*rcu_tasks_cbs_tail = rhp;
rcu_tasks_cbs_tail = >next;
raw_spin_unlock_irqrestore(_tasks_cbs_lock, flags);
+ if (needwake)
+ wake_up(_tasks_cbs_wq);
}
EXPORT_SYMBOL_GPL(call_rcu_tasks);
@@ -497,8 +502,12 @@ static int __noreturn rcu_tasks_kthread(void *arg)
/* If there were none, wait a bit and start over. */
if (!list) {
- schedule_timeout_interruptible(HZ);
- flush_signals(current);
+ wait_event_interruptible(rcu_tasks_cbs_wq,
+rcu_tasks_cbs_head);
+ if (!rcu_tasks_cbs_head) {
+ flush_signals(current);
+ schedule_timeout_interruptible(HZ/10);
+ }
continue;
}
@@ -584,6 +593,7 @@ static int __noreturn rcu_tasks_kthread(void *arg)
list = next;
cond_resched();
}
+ schedule_timeout_uninterruptible(HZ/10);
}
}
--
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 v2 tip/core/rcu 01/10] rcu: Add call_rcu_tasks()
From: "Paul E. McKenney"
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
context switch (not preemption!), userspace execution, and the idle loop.
Note that unlike other RCU flavors, these quiescent states occur in tasks,
not necessarily CPUs. Includes fixes from Steven Rostedt.
This RCU flavor is assumed to have very infrequent latency-tolerate
updaters. This assumption permits significant simplifications, including
a single global callback list protected by a single global lock, along
with a single linked list containing all tasks that have not yet passed
through a quiescent state. If experience shows this assumption to be
incorrect, the required additional complexity will be added.
Suggested-by: Steven Rostedt
Signed-off-by: Paul E. McKenney
---
include/linux/init_task.h | 9 +++
include/linux/rcupdate.h | 36 ++
include/linux/sched.h | 23 +++
init/Kconfig | 10 +++
kernel/rcu/tiny.c | 2 +
kernel/rcu/tree.c | 2 +
kernel/rcu/update.c | 164 ++
7 files changed, 235 insertions(+), 11 deletions(-)
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 6df7f9fe0d01..78715ea7c30c 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -124,6 +124,14 @@ extern struct group_info init_groups;
#else
#define INIT_TASK_RCU_PREEMPT(tsk)
#endif
+#ifdef CONFIG_TASKS_RCU
+#define INIT_TASK_RCU_TASKS(tsk) \
+ .rcu_tasks_holdout = false, \
+ .rcu_tasks_holdout_list = \
+ LIST_HEAD_INIT(tsk.rcu_tasks_holdout_list),
+#else
+#define INIT_TASK_RCU_TASKS(tsk)
+#endif
extern struct cred init_cred;
@@ -231,6 +239,7 @@ extern struct task_group root_task_group;
INIT_FTRACE_GRAPH \
INIT_TRACE_RECURSION\
INIT_TASK_RCU_PREEMPT(tsk) \
+ INIT_TASK_RCU_TASKS(tsk)\
INIT_CPUSET_SEQ(tsk)\
INIT_RT_MUTEXES(tsk)\
INIT_VTIME(tsk) \
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 6a94cc8b1ca0..05656b504295 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -197,6 +197,26 @@ void call_rcu_sched(struct rcu_head *head,
void synchronize_sched(void);
+/**
+ * call_rcu_tasks() - Queue an RCU for invocation task-based grace period
+ * @head: structure to be used for queueing the RCU updates.
+ * @func: actual callback function to be invoked after the grace period
+ *
+ * The callback function will be invoked some time after a full grace
+ * period elapses, in other words after all currently executing RCU
+ * read-side critical sections have completed. call_rcu_tasks() assumes
+ * that the read-side critical sections end at a voluntary context
+ * switch (not a preemption!), entry into idle, or transition to usermode
+ * execution. As such, there are no read-side primitives analogous to
+ * rcu_read_lock() and rcu_read_unlock() because this primitive is intended
+ * to determine that all tasks have passed through a safe state, not so
+ * much for data-strcuture synchronization.
+ *
+ * See the description of call_rcu() for more detailed information on
+ * memory ordering guarantees.
+ */
+void call_rcu_tasks(struct rcu_head *head, void (*func)(struct rcu_head
*head));
+
#ifdef CONFIG_PREEMPT_RCU
void __rcu_read_lock(void);
@@ -294,6 +314,22 @@ static inline void rcu_user_hooks_switch(struct
task_struct *prev,
rcu_irq_exit(); \
} while (0)
+/*
+ * Note a voluntary context switch for RCU-tasks benefit. This is a
+ * macro rather than an inline function to avoid #include hell.
+ */
+#ifdef CONFIG_TASKS_RCU
+#define rcu_note_voluntary_context_switch(t) \
+ do { \
+ preempt_disable(); /* Exclude synchronize_sched(); */ \
+ if ((t)->rcu_tasks_holdout) \
+ smp_store_release(&(t)->rcu_tasks_holdout, 0); \
+ preempt_enable(); \
+ } while (0)
+#else /* #ifdef CONFIG_TASKS_RCU */
+#define rcu_note_voluntary_context_switch(t) do { } while (0)
+#endif /* #else #ifdef CONFIG_TASKS_RCU */
+
#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP)
bool __rcu_is_watching(void);
#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP) */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 306f4f0c987a..3cf124389ec7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1273,6
[PATCH v2 tip/core/rcu 07/10] rcu: Add stall-warning checks for RCU-tasks
From: "Paul E. McKenney"
This commit adds a three-minute RCU-tasks stall warning. The actual
time is controlled by the boot/sysfs parameter rcu_task_stall_timeout,
with values less than or equal to zero disabling the stall warnings.
The default value is three minutes, which means that the tasks that
have not yet responded will get their stacks dumped every three minutes,
until they pass through a voluntary context switch.
Signed-off-by: Paul E. McKenney
Conflicts:
kernel/rcu/update.c
---
Documentation/kernel-parameters.txt | 5
kernel/rcu/update.c | 48 +
2 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 910c3829f81d..8cdbde7b17f5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2921,6 +2921,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
rcupdate.rcu_cpu_stall_timeout= [KNL]
Set timeout for RCU CPU stall warning messages.
+ rcupdate.rcu_task_stall_timeout= [KNL]
+ Set timeout in jiffies for RCU task stall warning
+ messages. Disable with a value less than or equal
+ to zero.
+
rdinit= [KNL]
Format:
Run specified binary instead of /init from the ramdisk,
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 1bfc07ed854e..aef581854239 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -373,6 +373,10 @@ static struct rcu_head *rcu_tasks_cbs_head;
static struct rcu_head **rcu_tasks_cbs_tail = _tasks_cbs_head;
static DEFINE_RAW_SPINLOCK(rcu_tasks_cbs_lock);
+/* Control stall timeouts. Disable with <= 0, otherwise jiffies till stall. */
+static int rcu_task_stall_timeout __read_mostly = HZ * 60 * 3;
+module_param(rcu_task_stall_timeout, int, 0644);
+
/* Post an RCU-tasks callback. */
void call_rcu_tasks(struct rcu_head *rhp, void (*func)(struct rcu_head *rhp))
{
@@ -444,11 +448,32 @@ void rcu_barrier_tasks(void)
}
EXPORT_SYMBOL_GPL(rcu_barrier_tasks);
+/* See if tasks are still holding out, complain if so. */
+static void check_holdout_task(struct task_struct *t,
+ bool needreport, bool *firstreport)
+{
+ if (!smp_load_acquire(>rcu_tasks_holdout) ||
+ t->rcu_tasks_nvcsw != ACCESS_ONCE(t->nvcsw)) {
+ ACCESS_ONCE(t->rcu_tasks_holdout) = 0;
+ /* @@@ need to check for usermode on CPU. */
+ list_del_rcu(>rcu_tasks_holdout_list);
+ return;
+ }
+ if (!needreport)
+ return;
+ if (*firstreport) {
+ pr_err("INFO: rcu_tasks detected stalls on tasks:\n");
+ *firstreport = false;
+ }
+ sched_show_task(current);
+}
+
/* RCU-tasks kthread that detects grace periods and invokes callbacks. */
static int __noreturn rcu_tasks_kthread(void *arg)
{
unsigned long flags;
struct task_struct *g, *t;
+ unsigned long lastreport;
struct rcu_head *list;
struct rcu_head *next;
@@ -517,21 +542,24 @@ static int __noreturn rcu_tasks_kthread(void *arg)
* of holdout tasks, removing any that are no longer
* holdouts. When the list is empty, we are done.
*/
+ lastreport = jiffies;
while (!list_empty(_tasks_holdouts)) {
+ bool firstreport;
+ bool needreport;
+ int rtst;
+
schedule_timeout_interruptible(HZ / 10);
+ rtst = ACCESS_ONCE(rcu_task_stall_timeout);
+ needreport = rtst > 0 &&
+time_after(jiffies, lastreport + rtst);
+ if (needreport)
+ lastreport = jiffies;
+ firstreport = true;
flush_signals(current);
rcu_read_lock();
list_for_each_entry_rcu(t, _tasks_holdouts,
- rcu_tasks_holdout_list) {
- if (smp_load_acquire(>rcu_tasks_holdout)) {
- if (t->rcu_tasks_nvcsw ==
- ACCESS_ONCE(t->nvcsw))
- continue;
- ACCESS_ONCE(t->rcu_tasks_holdout) = 0;
- }
- list_del_init(>rcu_tasks_holdout_list);
- /* @@@ need to check for usermode on CPU. */
- }
+ rcu_tasks_holdout_list)
+
[PATCH v2 tip/core/rcu 02/10] rcu: Provide cond_resched_rcu_qs() to force quiescent states in long loops
From: "Paul E. McKenney"
RCU-tasks requires the occasional voluntary context switch
from CPU-bound in-kernel tasks. In some cases, this requires
instrumenting cond_resched(). However, there is some reluctance
to countenance unconditionally instrumenting cond_resched() (see
http://lwn.net/Articles/603252/), so this commit creates a separate
cond_resched_rcu_qs() that may be used in place of cond_resched() in
locations prone to long-duration in-kernel looping.
This commit currently instruments only RCU-tasks. Future possibilities
include also instrumenting RCU, RCU-bh, and RCU-sched in order to reduce
IPI usage.
Signed-off-by: Paul E. McKenney
---
fs/file.c| 2 +-
include/linux/rcupdate.h | 13 +
kernel/rcu/rcutorture.c | 4 ++--
kernel/rcu/tree.c| 12 ++--
kernel/rcu/tree_plugin.h | 2 +-
mm/mlock.c | 2 +-
6 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 66923fe3176e..1cafc4c9275b 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -367,7 +367,7 @@ static struct fdtable *close_files(struct files_struct *
files)
struct file * file = xchg(>fd[i], NULL);
if (file) {
filp_close(file, files);
- cond_resched();
+ cond_resched_rcu_qs();
}
}
i++;
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 05656b504295..3299ff98ad03 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -330,6 +330,19 @@ static inline void rcu_user_hooks_switch(struct
task_struct *prev,
#define rcu_note_voluntary_context_switch(t) do { } while (0)
#endif /* #else #ifdef CONFIG_TASKS_RCU */
+/**
+ * cond_resched_rcu_qs - Report potential quiescent states to RCU
+ *
+ * This macro resembles cond_resched(), except that it is defined to
+ * report potential quiescent states to RCU-tasks even if the cond_resched()
+ * machinery were to be shut off, as some advocate for PREEMPT kernels.
+ */
+#define cond_resched_rcu_qs() \
+do { \
+ rcu_note_voluntary_context_switch(current); \
+ cond_resched(); \
+} while (0)
+
#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP)
bool __rcu_is_watching(void);
#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP) */
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7fa34f86e5ba..febe07062ac5 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -667,7 +667,7 @@ static int rcu_torture_boost(void *arg)
}
call_rcu_time = jiffies;
}
- cond_resched();
+ cond_resched_rcu_qs();
stutter_wait("rcu_torture_boost");
if (torture_must_stop())
goto checkwait;
@@ -1019,7 +1019,7 @@ rcu_torture_reader(void *arg)
__this_cpu_inc(rcu_torture_batch[completed]);
preempt_enable();
cur_ops->readunlock(idx);
- cond_resched();
+ cond_resched_rcu_qs();
stutter_wait("rcu_torture_reader");
} while (!torture_must_stop());
if (irqreader && cur_ops->irq_capable) {
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f958c52f644d..645a33efc0d4 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1650,7 +1650,7 @@ static int rcu_gp_init(struct rcu_state *rsp)
system_state == SYSTEM_RUNNING)
udelay(200);
#endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
- cond_resched();
+ cond_resched_rcu_qs();
}
mutex_unlock(>onoff_mutex);
@@ -1739,7 +1739,7 @@ static void rcu_gp_cleanup(struct rcu_state *rsp)
/* smp_mb() provided by prior unlock-lock pair. */
nocb += rcu_future_gp_cleanup(rsp, rnp);
raw_spin_unlock_irq(>lock);
- cond_resched();
+ cond_resched_rcu_qs();
}
rnp = rcu_get_root(rsp);
raw_spin_lock_irq(>lock);
@@ -1788,7 +1788,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
/* Locking provides needed memory barrier. */
if (rcu_gp_init(rsp))
break;
- cond_resched();
+ cond_resched_rcu_qs();
flush_signals(current);
trace_rcu_grace_period(rsp->name,
ACCESS_ONCE(rsp->gpnum),
@@ -1831,10 +1831,10 @@ static int __noreturn rcu_gp_kthread(void *arg)
