Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1

[Herbert Xu]

On Fri, Apr 17, 2015 at 04:31:47PM +0200, Christophe Leroy wrote:
> The purpose of this set of patchs is to add to talitos crypto driver
> the support for the SEC1 version of the security engine, which is
> found in mpc885 and mpc8272 processors.
> 
> v3 is a complete rework of the patchset. Since a kernel can be built
> with support for both MPC82xx and MPC83xx at the same time, talitos
> driver shall support both SEC1 and SEC2+ at the same time.
> 
> Based on cryptodev-2.6 tree

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ocfs2: use retval instead of status for checking error

[Daeseok Youn]

The use of 'status' in __ocfs2_add_entry() can return wrong
value. Some functions' return value in __ocfs2_add_entry(),
i.e ocfs2_journal_access_di() is saved to 'status'.
But 'status' is not used in 'bail' label for returning result
of __ocfs2_add_entry().

So use retval instead of status.

Signed-off-by: Daeseok Youn 
---
This patch was came from 'https://lkml.org/lkml/2015/2/27/655'
This patch was needed to test but I didn't have any environment
for testing ocfs2 filesystem. But I have one, now.
(I'm too busy to make this enviroment. And qemu for this fs is difficult
 for me. :-(, sorry for that)

Briefly how to set my environment for testing this fs with qemu.
1. Getting and building linux kernel with linux-next branch for x86_64 qemu.
   And also options of ocfs2 related are enabled(built-in)
2. Makes own root file system with 'buildroot' project.
3. Getting and building ocfs2-tools.
  Then binaries after building this tool are moved my rootfs.
4. Makes dummy disk image(5G) which will be formatted in qemu.
5. Booting qemu with rootfs image and dummy disk image.
6. mkfs.ocfs2 --fs-feature=local 
  this maybe possilbe to mount standalone mode.
7. tunefs.ocfs2  --fs-features=indexed-dirs,noinline-data 
8. make a cluster and one node
  use o2cb_ctl tool.
9. o2cb service load and initialize
  # /etc/init.d/o2cb load && /etc/init.d/o2cb configure
  # /etc/init.d/o2cb online
10. mount ocfs2
  # mount.ocfs2  

And use GDB for debugging my patch path.
Connect gdb with qemu and add breakpoint in __ocfs2_add_entry() of 
fs/ocfs2/dir.c

And test my patch.
# cd 
# mkdir 

This how-to is not written all my work, just briefly I said.

 fs/ocfs2/dir.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 990e8f7..a9513ff 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1607,7 +1607,7 @@ int __ocfs2_add_entry(handle_t *handle,
struct ocfs2_dir_entry *de, *de1;
struct ocfs2_dinode *di = (struct ocfs2_dinode *)parent_fe_bh->b_data;
struct super_block *sb = dir->i_sb;
-   int retval, status;
+   int retval;
unsigned int size = sb->s_blocksize;
struct buffer_head *insert_bh = lookup->dl_leaf_bh;
char *data_start = insert_bh->b_data;
@@ -1685,25 +1685,25 @@ int __ocfs2_add_entry(handle_t *handle,
}
 
if (insert_bh == parent_fe_bh)
-   status = ocfs2_journal_access_di(handle,
+   retval = ocfs2_journal_access_di(handle,
 
INODE_CACHE(dir),
 insert_bh,
 
OCFS2_JOURNAL_ACCESS_WRITE);
else {
-   status = ocfs2_journal_access_db(handle,
+   retval = ocfs2_journal_access_db(handle,
 
INODE_CACHE(dir),
 insert_bh,
  OCFS2_JOURNAL_ACCESS_WRITE);
 
-   if (ocfs2_dir_indexed(dir)) {
-   status = ocfs2_dx_dir_insert(dir,
+   if (!retval && ocfs2_dir_indexed(dir))
+   retval = ocfs2_dx_dir_insert(dir,
handle,
lookup);
-   if (status) {
-   mlog_errno(status);
-   goto bail;
-   }
-   }
+   }
+
+   if (retval) {
+   mlog_errno(retval);
+   goto bail;
}
 
/* By now the buffer is marked for journaling */
-- 
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: [Adi-buildroot-devel] [Consult] blackfin: About one building break issue for STACKTRACE

[Chen Gang]

On 4/18/15 06:20, Chen Gang wrote:
> On 4/17/15 22:02, Chen Gang wrote:
>> On 4/17/15 11:02, Zhang, Sonic wrote:
>>> Hi Gang,
>>>
>>> Please only use the GCC for Blackfin 2013R1 or 2014R1 from 
>>> https://sourceforge.net/projects/adi-buildroot/files/ . Upstream GCC5 isn't 
>>> ported to Blackfin properly.
>>>

For building linux-next with allmodconfig by upstream gcc5, at present, I
found 2 issues totally, and report them to upstream gcc bugzilla:

 - For stacktrace.c issue:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804
   "blackfin: Not support global frame pointer with -fno-omit-frame-pointer"

 - For coredump issues (for duplication reason, only report one, now):

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
   "blackfin: internal compiler error: segment fault linux kernel"

At least, I shall try to fix the coredump issues within this month (
although at present, I guess, I can not send patch v1 for it within
2015-04-20).


Thanks.
-- 
Chen Gang

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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[Guenter Roeck]

On 04/18/2015 09:13 PM, Guenter Roeck wrote:

On 04/18/2015 02:41 PM, David Miller wrote:

From: Sowmini Varadhan 
Date: Sat, 18 Apr 2015 15:55:14 -0400



Sowmini, I think I sorted this out in the 'sparc' GIT tree.

Can you take a look?


The patches look right now. These are the commit-ids I checked

   ff7d37a502022149655c18035b99a53391be0383
   bb620c3d3925aec0ed4f21010c86df08ec18a8c7
   0ae53ed15d9b87b883b593a9884957cfa4fc2480


Thanks for checking, I'll get this to Linus ASAP.


Latest upstream (v4.0-8110-g64fb1d0) passes my tests.



I spoke too early. Now I get a similar failure in the powerpc:allmodconfig build
(which previously failed for a different reason).

lib/built-in.o:(.discard+0x1): multiple definition of 
`__pcpu_unique_iommu_pool_hash'
arch/powerpc/kernel/built-in.o:(.discard+0x18): first defined here

And, yes, there are still two instances of iommu_pool_hash.

arch/powerpc/kernel/iommu.c:static DEFINE_PER_CPU(unsigned int, 
iommu_pool_hash);
lib/iommu-common.c:static   DEFINE_PER_CPU(unsigned int, iommu_pool_hash);

Guenter

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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[Guenter Roeck]

On 04/18/2015 02:41 PM, David Miller wrote:

From: Sowmini Varadhan 
Date: Sat, 18 Apr 2015 15:55:14 -0400



Sowmini, I think I sorted this out in the 'sparc' GIT tree.

Can you take a look?


The patches look right now. These are the commit-ids I checked

   ff7d37a502022149655c18035b99a53391be0383
   bb620c3d3925aec0ed4f21010c86df08ec18a8c7
   0ae53ed15d9b87b883b593a9884957cfa4fc2480


Thanks for checking, I'll get this to Linus ASAP.


Latest upstream (v4.0-8110-g64fb1d0) passes my tests.

Guenter

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

[PATCH 7/7] perf hists browser: Simplify zooming code a bit

[Namhyung Kim]

Introduce pstack_peek() and reuse do_zoom_dso/thread() function.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 16 +---
 tools/perf/util/pstack.c   |  7 +++
 tools/perf/util/pstack.h   |  1 +
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 315ebc493508..b776c2389137 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1877,17 +1877,11 @@ static int perf_evsel__hists_browse(struct perf_evsel 
*evsel, int nr_events,
goto out_free_stack;
continue;
}
-   top = pstack__pop(fstack);
-   if (top == >hists->dso_filter) {
-   perf_hpp__set_elide(HISTC_DSO, false);
-   browser->hists->dso_filter = NULL;
-   ui_helpline__pop();
-   }
-   if (top == >hists->thread_filter) {
-   perf_hpp__set_elide(HISTC_THREAD, false);
-   thread__zput(browser->hists->thread_filter);
-   ui_helpline__pop();
-   }
+   top = pstack__peek(fstack);
+   if (top == >hists->dso_filter)
+   do_zoom_dso(opts, browser, hbt, fstack, env);
+   if (top == >hists->thread_filter)
+   do_zoom_thread(opts, browser, hbt, fstack, env);
continue;
}
case K_ESC:
diff --git a/tools/perf/util/pstack.c b/tools/perf/util/pstack.c
index a126e6cc6e73..b234a6e3d0d4 100644
--- a/tools/perf/util/pstack.c
+++ b/tools/perf/util/pstack.c
@@ -74,3 +74,10 @@ void *pstack__pop(struct pstack *pstack)
pstack->entries[pstack->top] = NULL;
return ret;
 }
+
+void *pstack__peek(struct pstack *pstack)
+{
+   if (pstack->top == 0)
+   return NULL;
+   return pstack->entries[pstack->top - 1];
+}
diff --git a/tools/perf/util/pstack.h b/tools/perf/util/pstack.h
index c3cb6584d527..ded7f2e36624 100644
--- a/tools/perf/util/pstack.h
+++ b/tools/perf/util/pstack.h
@@ -10,5 +10,6 @@ bool pstack__empty(const struct pstack *pstack);
 void pstack__remove(struct pstack *pstack, void *key);
 void pstack__push(struct pstack *pstack, void *key);
 void *pstack__pop(struct pstack *pstack);
+void *pstack__peek(struct pstack *pstack);
 
 #endif /* _PERF_PSTACK_ */
-- 
2.3.5

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

[PATCH 6/7] perf hists browser: Split popup menu actions

[Namhyung Kim]

Currently perf_evsel__hists_browse() function spins on a huge loop and
handles many key actions.  Since it's hard to read and modify, let's
split it out into small helper functions.

The add_XXX_opt() functions are to register popup menu item on the
selected entry.  When it adds an item, it also saves related data into
struct popup_option and returns 1 so that it can increase the number of
items (nr_opts).  A callback function named do_XXX is called with saved
data when the item is selected by user.

No functional change intended.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 565 ++---
 1 file changed, 363 insertions(+), 202 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index cace2df7e561..315ebc493508 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1216,11 +1216,6 @@ static void hist_browser__delete(struct hist_browser 
*browser)
free(browser);
 }
 
-static struct hist_entry *hist_browser__selected_entry(struct hist_browser 
*browser)
-{
-   return browser->he_selection;
-}
-
 static struct thread *hist_browser__selected_thread(struct hist_browser 
*browser)
 {
return browser->he_selection->thread;
@@ -1395,6 +1390,281 @@ close_file_and_continue:
return ret;
 }
 
+struct popup_option {
+   struct thread   *thread;
+   struct map  *map;
+   struct dso  *dso;
+   struct symbol   *sym;
+
+   int (*fn)(struct popup_option *opt, struct hist_browser *browser,
+ struct hist_browser_timer *hbt, struct pstack *pstack,
+ struct perf_session_env *env);
+};
+
+static int
+do_annotate(struct popup_option *opt, struct hist_browser *browser,
+   struct hist_browser_timer *hbt, struct pstack *pstack 
__maybe_unused,
+   struct perf_session_env *env)
+{
+   struct perf_evsel *evsel;
+   struct annotation *notes;
+   struct map_symbol ms;
+   int err;
+
+   if (!objdump_path && perf_session_env__lookup_objdump(env))
+   return 0;
+
+   ms.map = opt->map;
+   ms.sym = opt->sym;
+
+   notes = symbol__annotation(ms.sym);
+   if (!notes->src)
+   return 0;
+
+   evsel = hists_to_evsel(browser->hists);
+   err = map_symbol__tui_annotate(, evsel, hbt);
+   /*
+* offer option to annotate the other branch source or target
+* (if they exists) when returning from annotate
+*/
+   if ((err == 'q' || err == CTRL('c'))
+   && browser->he_selection->branch_info)
+   return 1;
+
+   ui_browser__update_nr_entries(>b, browser->hists->nr_entries);
+   if (err)
+   ui_browser__handle_resize(>b);
+   return 0;
+}
+
+static int
+add_annotate_opt(struct popup_option *opt, char **optstr,
+struct hist_browser *browser __maybe_unused,
+struct map *map, struct symbol *sym)
+{
+   if (sym == NULL || map->dso->annotate_warned)
+   return 0;
+
+   if (asprintf(optstr, "Annotate %s", sym->name) < 0)
+   return 0;
+
+   opt->map = map;
+   opt->sym = sym;
+   opt->fn = do_annotate;
+   return 1;
+}
+
+static int do_zoom_thread(struct popup_option *opt,
+ struct hist_browser *browser,
+ struct hist_browser_timer *hbt __maybe_unused,
+ struct pstack *pstack,
+ struct perf_session_env *env __maybe_unused)
+{
+   struct thread *thread = opt->thread;
+
+   if (browser->hists->thread_filter) {
+   pstack__remove(pstack, >hists->thread_filter);
+   perf_hpp__set_elide(HISTC_THREAD, false);
+   thread__zput(browser->hists->thread_filter);
+   ui_helpline__pop();
+   } else {
+   ui_helpline__fpush("To zoom out press <- or -> + \"Zoom out of 
%s(%d) thread\"",
+  thread->comm_set ? thread__comm_str(thread) 
: "",
+  thread->tid);
+   browser->hists->thread_filter = thread__get(thread);
+   perf_hpp__set_elide(HISTC_THREAD, false);
+   pstack__push(pstack, >hists->thread_filter);
+   }
+
+   hists__filter_by_thread(browser->hists);
+   hist_browser__reset(browser);
+   return 0;
+}
+
+static int
+add_thread_opt(struct popup_option *opt, char **optstr,
+  struct hist_browser *browser, struct thread *thread)
+{
+   if (thread == NULL)
+   return 0;
+
+   if (asprintf(optstr, "Zoom %s %s(%d) thread",
+browser->hists->thread_filter ? "out of" : "into",
+thread->comm_set ? thread__comm_str(thread) : "",
+thread->tid) < 0)
+   return 0;
+
+   opt->thread = thread;
+   opt->fn = do_zoom_thread;
+   return 1;
+}
+

[PATCH 5/7] perf hists browser: Fix possible memory leak

[Namhyung Kim]

The options array saves strings for each popup menu item.  The number of
items can be vary according to the currently selected item.  So it can
leak some memory if it's exited from a small item.  Fix it by freeing
all items when loop terminates.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8f303eb5044d..cace2df7e561 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1691,7 +1691,8 @@ skip_annotation:
"Switch to another data file in PWD") > 0)
switch_data = nr_options++;
 add_exit_option:
-   options[nr_options++] = (char *)"Exit";
+   if (asprintf([nr_options], "Exit") > 0)
+   nr_options++;
 retry_popup_menu:
choice = ui__popup_menu(nr_options, options);
 
@@ -1812,7 +1813,7 @@ out_free_stack:
pstack__delete(fstack);
 out:
hist_browser__delete(browser);
-   free_popup_options(options, nr_options - 1);
+   free_popup_options(options, ARRAY_SIZE(options));
return key;
 }
 
-- 
2.3.5

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

[PATCH 4/7] perf tools: Move init_have_children field to struct hist_entry_tui

[Namhyung Kim]

The init_have_children is used to init callchain info only for TUI.  So
it'd be better to move it to the hist_entry_tui struct.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 4 ++--
 tools/perf/util/sort.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8b8a647be999..8f303eb5044d 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -275,10 +275,10 @@ static void callchain__init_have_children(struct rb_root 
*root)
 
 static void hist_entry__init_have_children(struct hist_entry *he)
 {
-   if (!he->init_have_children) {
+   if (!he->tui.init_have_children) {
he->ms.has_children = !RB_EMPTY_ROOT(>sorted_chain);
callchain__init_have_children(>sorted_chain);
-   he->init_have_children = true;
+   he->tui.init_have_children = true;
}
 }
 
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index fae3bc5c1ea6..afdfaeb54b73 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -73,6 +73,7 @@ struct hist_entry_diff {
 struct hist_entry_tui {
u16 row_offset;
u16 nr_rows;
+   boolinit_have_children;
 };
 
 /**
@@ -101,7 +102,6 @@ struct hist_entry {
/* We are added by hists__add_dummy_entry. */
booldummy;
 
-   boolinit_have_children;
charlevel;
u8  filtered;
union {
-- 
2.3.5

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

[PATCH 2/7] perf diff: Make hist_entry_diff fields union

[Namhyung Kim]

The period_ratio_delta, period_ratio and wdiff are never by used at the
same time.  Instead, Just one of them is accessed according to a
comparison method.  So make it union to reduce memory footprint.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.h | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index af192f172fa2..de3303fe726d 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -58,15 +58,16 @@ struct he_stat {
 
 struct hist_entry_diff {
boolcomputed;
+   union {
+   /* PERF_HPP__DELTA */
+   double  period_ratio_delta;
 
-   /* PERF_HPP__DELTA */
-   double  period_ratio_delta;
-
-   /* PERF_HPP__RATIO */
-   double  period_ratio;
+   /* PERF_HPP__RATIO */
+   double  period_ratio;
 
-   /* HISTC_WEIGHTED_DIFF */
-   s64 wdiff;
+   /* HISTC_WEIGHTED_DIFF */
+   s64 wdiff;
+   };
 };
 
 /**
-- 
2.3.5

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

[PATCH 1/7] perf tools: Get rid of position field from struct hist_entry

[Namhyung Kim]

It's not used anywhere, let's get rid of it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 846036a921dc..af192f172fa2 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -106,7 +106,6 @@ struct hist_entry {
u8  filtered;
char*srcline;
struct symbol   *parent;
-   unsigned long   position;
struct rb_root  sorted_chain;
struct branch_info  *branch_info;
struct hists*hists;
-- 
2.3.5

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

[PATCHSET 0/7] perf tools: Assorted cleanup for TUI (v1)

[Namhyung Kim]

Hello,

This patches are to cleanup TUI hists browser code for later work.  I
moved hist_entry_diff and hist_entry_tui under an union in order to
reduce memory footprint of hist entry.  Also split out hist browser
functions to make it easier to read.

It's available on 'perf/tui-cleanup-v1' branch in my tree:

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

Thanks,
Namhyung


Namhyung Kim (7):
  perf tools: Get rid of position field from struct hist_entry
  perf diff: Make hist_entry_diff fields union
  perf tools: Move TUI-specific fields to struct hist_entry_tui
  perf tools: Move init_have_children field to struct hist_entry_tui
  perf hists browser: Fix possible memory leak
  perf hists browser: Split popup menu actions
  perf hists browser: Simplify zooming code a bit

 tools/perf/ui/browsers/hists.c | 612 ++---
 tools/perf/util/hist.c |   4 +-
 tools/perf/util/pstack.c   |   7 +
 tools/perf/util/pstack.h   |   1 +
 tools/perf/util/sort.h |  31 ++-
 5 files changed, 411 insertions(+), 244 deletions(-)

-- 
2.3.5

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

[PATCH 3/7] perf tools: Move TUI-specific fields to struct hist_entry_tui

[Namhyung Kim]

Since perf diff only support stdio output, TUI fields are only accessed
from perf report (or perf top).  So add new struct hist_entry_tui and
move those fields into them.  And include it as an union member.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 52 +-
 tools/perf/util/hist.c |  4 ++--
 tools/perf/util/sort.h | 15 +++-
 3 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 995b7a8596b1..8b8a647be999 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -61,7 +61,7 @@ static int hist_browser__get_folding(struct hist_browser 
*browser)
rb_entry(nd, struct hist_entry, rb_node);
 
if (he->ms.unfolded)
-   unfolded_rows += he->nr_rows;
+   unfolded_rows += he->tui.nr_rows;
}
return unfolded_rows;
 }
@@ -288,16 +288,16 @@ static bool hist_browser__toggle_fold(struct hist_browser 
*browser)
struct hist_entry *he = browser->he_selection;
 
hist_entry__init_have_children(he);
-   browser->b.nr_entries -= he->nr_rows;
-   browser->nr_callchain_rows -= he->nr_rows;
+   browser->b.nr_entries -= he->tui.nr_rows;
+   browser->nr_callchain_rows -= he->tui.nr_rows;
 
if (he->ms.unfolded)
-   he->nr_rows = callchain__count_rows(>sorted_chain);
+   he->tui.nr_rows = 
callchain__count_rows(>sorted_chain);
else
-   he->nr_rows = 0;
+   he->tui.nr_rows = 0;
 
-   browser->b.nr_entries += he->nr_rows;
-   browser->nr_callchain_rows += he->nr_rows;
+   browser->b.nr_entries += he->tui.nr_rows;
+   browser->nr_callchain_rows += he->tui.nr_rows;
 
return true;
}
@@ -367,9 +367,9 @@ static void hist_entry__set_folding(struct hist_entry *he, 
bool unfold)
 
if (he->ms.has_children) {
int n = callchain__set_folding(>sorted_chain, unfold);
-   he->nr_rows = unfold ? n : 0;
+   he->tui.nr_rows = unfold ? n : 0;
} else
-   he->nr_rows = 0;
+   he->tui.nr_rows = 0;
 }
 
 static void
@@ -383,7 +383,7 @@ __hist_browser__set_folding(struct hist_browser *browser, 
bool unfold)
 nd = rb_next(nd)) {
struct hist_entry *he = rb_entry(nd, struct hist_entry, 
rb_node);
hist_entry__set_folding(he, unfold);
-   browser->nr_callchain_rows += he->nr_rows;
+   browser->nr_callchain_rows += he->tui.nr_rows;
}
 }
 
@@ -459,7 +459,7 @@ static int hist_browser__run(struct hist_browser *browser,
   browser->b.rows,
   browser->b.index,
   browser->b.top_idx,
-  h->row_offset, h->nr_rows);
+  h->tui.row_offset, h->tui.nr_rows);
}
break;
case 'C':
@@ -742,7 +742,7 @@ static int hist_browser__show_entry(struct hist_browser 
*browser,
int width = browser->b.width;
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(>b, row);
-   off_t row_offset = entry->row_offset;
+   off_t row_offset = entry->tui.row_offset;
bool first = true;
struct perf_hpp_fmt *fmt;
 
@@ -997,7 +997,7 @@ static void ui_browser__hists_seek(struct ui_browser 
*browser,
 * row_offset:
 */
h = rb_entry(browser->top, struct hist_entry, rb_node);
-   h->row_offset = 0;
+   h->tui.row_offset = 0;
 
/*
 * Here we have to check if nd is expanded (+), if it is we can't go
@@ -1017,12 +1017,12 @@ do_offset:
do {
h = rb_entry(nd, struct hist_entry, rb_node);
if (h->ms.unfolded) {
-   u16 remaining = h->nr_rows - h->row_offset;
+   u16 remaining = h->tui.nr_rows - 
h->tui.row_offset;
if (offset > remaining) {
offset -= remaining;
-   h->row_offset = 0;
+   h->tui.row_offset = 0;
} else {
-   h->row_offset += offset;
+   h->tui.row_offset += offset;
offset = 0;
browser->top = nd;
break;
@@ -1039,21 +1039,21 @@ do_offset:
h = 

Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Guenter Roeck]

On 04/18/2015 08:39 PM, Rabin Vincent wrote:

On Sat, Apr 18, 2015 at 06:56:02PM -0700, Guenter Roeck wrote:

Further debugging (with added WARN_ON if cpu != 0 in smp_call_function_single) 
shows:

[<800157ec>] (unwind_backtrace) from [<8001250c>] (show_stack+0x10/0x14)
[<8001250c>] (show_stack) from [<80494cb4>] (dump_stack+0x88/0x98)
[<80494cb4>] (dump_stack) from [<80024058>] (warn_slowpath_common+0x84/0xb4)
[<80024058>] (warn_slowpath_common) from [<80024124>] 
(warn_slowpath_null+0x1c/0x24)
[<80024124>] (warn_slowpath_null) from [<80078fc8>] 
(smp_call_function_single+0x170/0x178)
[<80078fc8>] (smp_call_function_single) from [<80090024>] 
(perf_event_exit_cpu+0x80/0xf0)
[<80090024>] (perf_event_exit_cpu) from [<80090110>] (perf_cpu_notify+0x30/0x48)
[<80090110>] (perf_cpu_notify) from [<8003d340>] (notifier_call_chain+0x44/0x84)
[<8003d340>] (notifier_call_chain) from [<8002451c>] (_cpu_up+0x120/0x168)
[<8002451c>] (_cpu_up) from [<800245d4>] (cpu_up+0x70/0x94)
[<800245d4>] (cpu_up) from [<80624234>] (smp_init+0xac/0xb0)
[<80624234>] (smp_init) from [<80618d84>] (kernel_init_freeable+0x118/0x268)
[<80618d84>] (kernel_init_freeable) from [<8049107c>] (kernel_init+0x8/0xe8)
[<8049107c>] (kernel_init) from [<8000f320>] (ret_from_fork+0x14/0x34)
---[ end trace 2f9f1bb8a47b3a1b ]---
smp_call_function_single, cpu=1, wait=1, csd_stack=87825ea0
generic_exec_single, cpu=1, smp_processor_id()=0
csd_lock_wait: csd=87825ea0, flags=0x3

This is repeated for each secondary CPU. But the secondary CPUs don't respond 
because
they are not enabled, which I guess explains why the lock is never released.

So, in other words, this happens because the system believes (presumably per 
configuration
/ fdt data) that there are four CPU cores, but that is not really the case. 
Previously that
did not matter, and was handled correctly. Now it is fatal.

Does this help ?


8053871d0f7f67c7efb7f226ef031f78877d6625 moved the csd locking to the
callers, but the offline check, which was earlier done before the csd
locking, was not moved.  The following moves the checks to the earlier
point fixes your boot:



Yes, your patch fixes the problem.

Tested-by: Guenter Roeck 

Thanks,
Guenter


diff --git a/kernel/smp.c b/kernel/smp.c
index 2aaac2c..ba1fb01 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -159,9 +159,6 @@ static int generic_exec_single(int cpu, struct 
call_single_data *csd,
}


-   if ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))
-   return -ENXIO;
-
csd->func = func;
csd->info = info;

@@ -289,6 +286,12 @@ int smp_call_function_single(int cpu, smp_call_func_t 
func, void *info,
WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
 && !oops_in_progress);

+   if (cpu != smp_processor_id()
+   && ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))) {
+   err = -ENXIO;
+   goto out;
+   }
+
csd = _stack;
if (!wait) {
csd = this_cpu_ptr(_data);
@@ -300,6 +303,7 @@ int smp_call_function_single(int cpu, smp_call_func_t func, 
void *info,
if (wait)
csd_lock_wait(csd);

+out:
put_cpu();

return err;
@@ -328,6 +332,12 @@ int smp_call_function_single_async(int cpu, struct 
call_single_data *csd)

preempt_disable();

+   if (cpu != smp_processor_id()
+   && ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))) {
+   err = -ENXIO;
+   goto out;
+   }
+
/* We could deadlock if we have to wait here with interrupts disabled! 
*/
if (WARN_ON_ONCE(csd->flags & CSD_FLAG_LOCK))
csd_lock_wait(csd);
@@ -336,8 +346,9 @@ int smp_call_function_single_async(int cpu, struct 
call_single_data *csd)
smp_wmb();

err = generic_exec_single(cpu, csd, csd->func, csd->info);
-   preempt_enable();

+out:
+   preempt_enable();
return err;
  }
  EXPORT_SYMBOL_GPL(smp_call_function_single_async);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] perf stat: Metrics calculation fix

[Namhyung Kim]

Hi Jiri,

On Tue, Apr 07, 2015 at 11:25:13PM +0200, Jiri Olsa wrote:
> hi,
> I'm sending Andi's patch accompanied with changes requested by Ingo.
>   http://marc.info/?l=linux-kernel=139748629929175=2
> 
> I added simple bit calculated index array, while exclude_* bits
> might have more strict logic and ban some combinations, but I
> wanted to keep it simple and did not find better solution.

For the series,

Acked-by: Namhyung Kim 

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

[PATCH] usb: core: add usb3 lpm sysfs

[Zhuang Jin Can]

Some usb3 devices may not support usb3 lpm well.
The patch adds a sysfs to enable/disable u1 or u2 of the port.The
settings apply to both before and after device enumeration.
Supported values are "0" - u1 and u2 are disabled, "u1" - only u1 is
enabled, "u2" - only u2 is enabled, "u1_u2" - u1 and u2 are enabled.

The interface is useful for testing some USB3 devices during
development, and provides a way to disable usb3 lpm if the issues can
not be fixed in final products.

Signed-off-by: Zhuang Jin Can 
---
 Documentation/ABI/testing/sysfs-bus-usb |   10 
 drivers/usb/core/hub.c  |   16 +-
 drivers/usb/core/hub.h  |4 ++
 drivers/usb/core/port.c |   89 ++-
 4 files changed, 116 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index e5cc763..32fc689 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -179,3 +179,13 @@ Description:
Supported values are 0 - 15.
More information on how besl values map to microseconds can be 
found in
USB 2.0 ECN Errata for Link Power Management, section 4.10)
+
+What:  /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm
+Date:  March 2015
+Contact:   Zhuang Jin Can 
+Description:
+   Some USB3.0 devices may not support usb3 lpm well.
+   usb3_lpm attribute allows enabling/disabling usb3 lpm of the 
port.
+   It takes effect both before and after a usb device is 
enumerated.
+   Supported values are "0" if u1 and u2 are disabled, "u1" if 
only u1 is
+   enabled, "u2" if only u2 is enabled, "u1_u2" if u1 and u2 are 
enabled.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d7c3d5a..7732a41 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3996,6 +3996,8 @@ EXPORT_SYMBOL_GPL(usb_unlocked_disable_lpm);
 void usb_enable_lpm(struct usb_device *udev)
 {
struct usb_hcd *hcd;
+   struct usb_hub *hub;
+   struct usb_port *port_dev;
 
if (!udev || !udev->parent ||
udev->speed != USB_SPEED_SUPER ||
@@ -4015,8 +4017,18 @@ void usb_enable_lpm(struct usb_device *udev)
if (udev->lpm_disable_count > 0)
return;
 
-   usb_enable_link_state(hcd, udev, USB3_LPM_U1);
-   usb_enable_link_state(hcd, udev, USB3_LPM_U2);
+   hub = usb_hub_to_struct_hub(udev->parent);
+   if (!hub) {
+   dev_err(>dev, "can't enable lpm, usb_hub is null.\n");
+   return;
+   }
+   port_dev = hub->ports[udev->portnum - 1];
+
+   if (port_dev->u1_is_enabled)
+   usb_enable_link_state(hcd, udev, USB3_LPM_U1);
+
+   if (port_dev->u2_is_enabled)
+   usb_enable_link_state(hcd, udev, USB3_LPM_U2);
 }
 EXPORT_SYMBOL_GPL(usb_enable_lpm);
 
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 688817f..1ae060e 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -92,6 +92,8 @@ struct usb_hub {
  * @status_lock: synchronize port_event() vs usb_port_{suspend|resume}
  * @portnum: port index num based one
  * @is_superspeed cache super-speed status
+ * @u1_is_enabled: whether u1 should be enabled.
+ * @u2_is_enabled: whether u2 should be enabled.
  */
 struct usb_port {
struct usb_device *child;
@@ -104,6 +106,8 @@ struct usb_port {
struct mutex status_lock;
u8 portnum;
unsigned int is_superspeed:1;
+   unsigned int u1_is_enabled:1;
+   unsigned int u2_is_enabled:1;
 };
 
 #define to_usb_port(_dev) \
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..7f4e6c7 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -50,6 +50,72 @@ static ssize_t connect_type_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(connect_type);
 
+static ssize_t usb3_lpm_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct usb_port *port_dev = to_usb_port(dev);
+   const char *p;
+
+   if (port_dev->u1_is_enabled) {
+   if (port_dev->u2_is_enabled)
+   p = "u1_u2";
+   else
+   p = "u1";
+   } else {
+   if (port_dev->u2_is_enabled)
+   p = "u2";
+   else
+   p = "0";
+   }
+
+   return sprintf(buf, "%s\n", p);
+}
+
+static ssize_t usb3_lpm_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_port *port_dev = to_usb_port(dev);
+   struct usb_device *udev = port_dev->child;
+   struct usb_hcd *hcd;
+
+   if (!strncmp(buf, "u1_u2", 5)) {
+   port_dev->u1_is_enabled = 1;
+ 

Re: [PATCH 2/2] perf tools: Add a option 'remove' to perf-config and features which get or set a config variable.

[Namhyung Kim]

On Sat, Apr 18, 2015 at 02:02:17PM +0900, Taewoong Song wrote:
> > On Apr 13, 2015, at 3:55 PM, Namhyung Kim  wrote:
> > On Sun, Apr 12, 2015 at 11:44:49PM +0900, Taeung Song wrote:
> >> +static struct config_section *find_config_section(const char 
> >> *section_name)
> >> +{
> >> +  struct config_section *section_node;
> > 
> > It'd be better to split declaration and function body with a blank line.
> > 
> 
> Does mean it like followed by ?
> 
> +static struct config_section *find_config_section(const char *section_name)
> +
> +{
> + struct config_section *section_node;
> 
> ,or is it ?  
> 
> +static struct config_section *find_config_section(const char *section_name)
> +{
> +
> + struct config_section *section_node;

Nope!  I meant

static struct config_section *find_config_section(const char *section_name)
{
struct config_section *section node
<-- here
list_for_each_entry(section_node, , list)
...
}


> 
> > 
> >> +  list_for_each_entry(section_node, , list)
> >> +  if (!strcmp(section_node->name, section_name))
> >> +  return section_node;
> >> +
> >> +  return NULL;
> >> +}
> >> +
> >> +static struct config_element *find_config_element(const char *subkey
> >> +, struct config_section 
> >> *section_node)

And this is not how we put comma, please change it to

static struct config_element *find_config_element(const char *subkey,
  struct config_section 
*section_node)

Ditto for others..

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

Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Rabin Vincent]

On Sat, Apr 18, 2015 at 06:56:02PM -0700, Guenter Roeck wrote:
> Further debugging (with added WARN_ON if cpu != 0 in 
> smp_call_function_single) shows:
> 
> [<800157ec>] (unwind_backtrace) from [<8001250c>] (show_stack+0x10/0x14)
> [<8001250c>] (show_stack) from [<80494cb4>] (dump_stack+0x88/0x98)
> [<80494cb4>] (dump_stack) from [<80024058>] (warn_slowpath_common+0x84/0xb4)
> [<80024058>] (warn_slowpath_common) from [<80024124>] 
> (warn_slowpath_null+0x1c/0x24)
> [<80024124>] (warn_slowpath_null) from [<80078fc8>] 
> (smp_call_function_single+0x170/0x178)
> [<80078fc8>] (smp_call_function_single) from [<80090024>] 
> (perf_event_exit_cpu+0x80/0xf0)
> [<80090024>] (perf_event_exit_cpu) from [<80090110>] 
> (perf_cpu_notify+0x30/0x48)
> [<80090110>] (perf_cpu_notify) from [<8003d340>] 
> (notifier_call_chain+0x44/0x84)
> [<8003d340>] (notifier_call_chain) from [<8002451c>] (_cpu_up+0x120/0x168)
> [<8002451c>] (_cpu_up) from [<800245d4>] (cpu_up+0x70/0x94)
> [<800245d4>] (cpu_up) from [<80624234>] (smp_init+0xac/0xb0)
> [<80624234>] (smp_init) from [<80618d84>] (kernel_init_freeable+0x118/0x268)
> [<80618d84>] (kernel_init_freeable) from [<8049107c>] (kernel_init+0x8/0xe8)
> [<8049107c>] (kernel_init) from [<8000f320>] (ret_from_fork+0x14/0x34)
> ---[ end trace 2f9f1bb8a47b3a1b ]---
> smp_call_function_single, cpu=1, wait=1, csd_stack=87825ea0
> generic_exec_single, cpu=1, smp_processor_id()=0
> csd_lock_wait: csd=87825ea0, flags=0x3
> 
> This is repeated for each secondary CPU. But the secondary CPUs don't respond 
> because
> they are not enabled, which I guess explains why the lock is never released.
> 
> So, in other words, this happens because the system believes (presumably per 
> configuration
> / fdt data) that there are four CPU cores, but that is not really the case. 
> Previously that
> did not matter, and was handled correctly. Now it is fatal.
> 
> Does this help ?

8053871d0f7f67c7efb7f226ef031f78877d6625 moved the csd locking to the
callers, but the offline check, which was earlier done before the csd
locking, was not moved.  The following moves the checks to the earlier
point fixes your boot:

diff --git a/kernel/smp.c b/kernel/smp.c
index 2aaac2c..ba1fb01 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -159,9 +159,6 @@ static int generic_exec_single(int cpu, struct 
call_single_data *csd,
}
 
 
-   if ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))
-   return -ENXIO;
-
csd->func = func;
csd->info = info;
 
@@ -289,6 +286,12 @@ int smp_call_function_single(int cpu, smp_call_func_t 
func, void *info,
WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
 && !oops_in_progress);
 
+   if (cpu != smp_processor_id()
+   && ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))) {
+   err = -ENXIO;
+   goto out;
+   }
+
csd = _stack;
if (!wait) {
csd = this_cpu_ptr(_data);
@@ -300,6 +303,7 @@ int smp_call_function_single(int cpu, smp_call_func_t func, 
void *info,
if (wait)
csd_lock_wait(csd);
 
+out:
put_cpu();
 
return err;
@@ -328,6 +332,12 @@ int smp_call_function_single_async(int cpu, struct 
call_single_data *csd)
 
preempt_disable();
 
+   if (cpu != smp_processor_id()
+   && ((unsigned)cpu >= nr_cpu_ids || !cpu_online(cpu))) {
+   err = -ENXIO;
+   goto out;
+   }
+
/* We could deadlock if we have to wait here with interrupts disabled! 
*/
if (WARN_ON_ONCE(csd->flags & CSD_FLAG_LOCK))
csd_lock_wait(csd);
@@ -336,8 +346,9 @@ int smp_call_function_single_async(int cpu, struct 
call_single_data *csd)
smp_wmb();
 
err = generic_exec_single(cpu, csd, csd->func, csd->info);
-   preempt_enable();
 
+out:
+   preempt_enable();
return err;
 }
 EXPORT_SYMBOL_GPL(smp_call_function_single_async);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation/CodingStyle: fix example macro parenthesis imbalance

[Baruch Siach]

Cc: Bartosz Golaszewski 
Cc: Andrew Morton 
Fixes: f2027543b9 ('documentation: update CodingStyle on local variables naming 
in macros')
Signed-off-by: Baruch Siach 
---
 Documentation/CodingStyle | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index f4b78eafd92a..b713c35f8543 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -670,7 +670,7 @@ functions:
typeof(x) ret;  \
ret = calc_ret(x);  \
(ret);  \
-)}
+})
 
 ret is a common name for a local variable - __foo_ret is less likely
 to collide with an existing variable.
-- 
2.1.4

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

Re: [PATCH 1/2] perf tools: Add 'perf-config' command

[Namhyung Kim]

On Sat, Apr 18, 2015 at 07:14:06PM +0900, Taewoong Song wrote:
> > On Apr 13, 2015, at 3:16 PM, Namhyung Kim  wrote:
> > On Sun, Apr 12, 2015 at 11:44:48PM +0900, Taeung Song wrote:
> >> +static void check_argc(int argc, int limit)
> >> +{
> >> +  if (argc >= limit && argc <= limit)
> >> +  return;
> >> +  error("wrong number of arguments");
> >> +  usage_with_options(config_usage, config_options);
> >> +}
> > 
> > I don't know why this is needed.  The -a option won't need this and we
> > can support to get/set any number of config items IMHO.
> > 
> 
> I also think we can support to get/set any number of config items.
> But I think that ‘—list’ or  ‘—all’ can need to be checked to validate 
> argument.
> If work ‘git —list’ with other argument, error message can be printed like 
> this.
> 
> :> git config --list 134 
> error: wrong number of arguments 
> usage: git config [options] 
> 
> Config file location 
>   --global use global config file
>   --system use system config file
>   --local use repository config file 
>   -f, --file  use given config file
>   --blob  read config from given blob object
> 
> …(omitted)…
> 
> If don’t checking number of argument, we allow users to work a optio
> ‘-a’ or ‘-l’ with other arguments which can be weor meaningless.
> Did I misunderstand what you say?
> Or is there other way to avoid this problem ?

Then just check 'argc != 0' for -l or -a cases.  The get/set won't
need it IMHO.

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

Re: [PATCH 1/2] perf tools: Add 'perf-config' command

[Namhyung Kim]

Hi Taeung,

On Sat, Apr 18, 2015 at 02:02:08PM +0900, Taewoong Song wrote:
> Hi, Namhyung
> 
> Thanks for your review and advices :)
> There is a question which may be weird, followed by
> 
> > On Apr 13, 2015, at 3:16 PM, Namhyung Kim  wrote:
> > 
> > Hi Taeung,
> > 
> > On Sun, Apr 12, 2015 at 11:44:48PM +0900, Taeung Song wrote:
> >> The perf configuration file contains many variables which can make
> >> the perf command's action more effective and more skilful.
> >> But looking through state of configuration is difficult and
> >> there's no knowing what kind of other variables except variables in 
> >> perfconfig.example exist.
> >> So This patch adds 'perf-config' command with '--all' option and a 
> >> document for it.
> >> 
> >> Signed-off-by: Taeung Song  >> >
> >> ---
> > 
> > Thanks for your work!
> > 
> > I think the documentation updates need to be shared with tools
> > manpages, or at least they can point to this document for details.
> > This can be further work though. ;-)
> > 
> 
> Sorry I don’t understand this share very well.
> How can I share the documentation with tools manpages ?

I mean you can add a description for some feature to link the config
document or vice versa.  Many of those description can be added to the
tool manpage or cross-reference config option at least.

For example, I sent a patch for children overhead documentation so you
can just add 'see perf-report(1) for more details' into the
description of the config option instead of repeating the whole
contents.  Or use asciidoc's 'include' macro to include the (part of)
doc directly if possible.


> 
> And are there people who can help the document to be modified with more 
> detail info ?
> Are they contributors for doc ?

Unfortunately, very few people donated their time to improve the
documentation until now.

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

[PATCH] usb: storage: scsiglue: Remove SPRINTF macro use

[Joe Perches]

Single transform macros with hidden arguments are not
particularly useful.  Just use seq_printf directly instead.

Signed-off-by: Joe Perches 
---
 drivers/usb/storage/scsiglue.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 0e400f3..a8cbbff 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -456,17 +456,13 @@ static int write_info(struct Scsi_Host *host, char 
*buffer, int length)
return length;
 }
 
-/* we use this macro to help us write into the buffer */
-#undef SPRINTF
-#define SPRINTF(args...) seq_printf(m, ## args)
-
 static int show_info (struct seq_file *m, struct Scsi_Host *host)
 {
struct us_data *us = host_to_us(host);
const char *string;
 
/* print the controller name */
-   SPRINTF("   Host scsi%d: usb-storage\n", host->host_no);
+   seq_printf(m, "   Host scsi%d: usb-storage\n", host->host_no);
 
/* print product, vendor, and serial number strings */
if (us->pusb_dev->manufacturer)
@@ -475,26 +471,26 @@ static int show_info (struct seq_file *m, struct 
Scsi_Host *host)
string = us->unusual_dev->vendorName;
else
string = "Unknown";
-   SPRINTF("   Vendor: %s\n", string);
+   seq_printf(m, "   Vendor: %s\n", string);
if (us->pusb_dev->product)
string = us->pusb_dev->product;
else if (us->unusual_dev->productName)
string = us->unusual_dev->productName;
else
string = "Unknown";
-   SPRINTF("  Product: %s\n", string);
+   seq_printf(m, "  Product: %s\n", string);
if (us->pusb_dev->serial)
string = us->pusb_dev->serial;
else
string = "None";
-   SPRINTF("Serial Number: %s\n", string);
+   seq_printf(m, "Serial Number: %s\n", string);
 
/* show the protocol and transport */
-   SPRINTF(" Protocol: %s\n", us->protocol_name);
-   SPRINTF("Transport: %s\n", us->transport_name);
+   seq_printf(m, " Protocol: %s\n", us->protocol_name);
+   seq_printf(m, "Transport: %s\n", us->transport_name);
 
/* show the device flags */
-   SPRINTF("   Quirks:");
+   seq_printf(m, "   Quirks:");
 
 #define US_FLAG(name, value) \
if (us->fflags & value) seq_printf(m, " " #name);


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

[GIT PULL] turbostat update for Linux-4.1

[Len Brown]

Hi Linus,

Please pull these updates to the turbostat utility.
Just one kernel dependency in this batch -- added a #define to msr-index.h

thanks!
Len Brown, Intel Open Source Technology Center


The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76:

  Linux 4.0 (2015-04-12 15:12:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git turbostat

for you to fetch changes up to e9257f5fa48cc296d7eed35acf9f2ad195184122:

  tools/power turbostat: correct dumped pkg-cstate-limit value
(2015-04-18 14:20:52 -0400)


Andrey Semin (1):
  tools/power turbostat: correct DRAM RAPL units on recent Xeon processors

Len Brown (10):
  tools/power turbostat: simplify default output
  tools/power turbostat: update PERF_LIMIT_REASONS decoding
  tools/power turbostat: label base frequency
  x86 msr-index: define MSR_TURBO_RATIO_LIMIT,1,2
  tools/power turbostat: use new MSR_TURBO_RATIO_LIMIT names
  tools/power turbostat: dump MSR_TURBO_RATIO_LIMIT2
  tools/power turbostat: modprobe msr, if needed
  tools/power turbostat: Initial Skylake support
  tools/power turbostat: calculate TSC frequency from CPUID(0x15) on SKL
  tools/power turbostat: correct dumped pkg-cstate-limit value

Thomas D (1):
  tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add
support for O= option in Makefile

 arch/x86/include/uapi/asm/msr-index.h |   8 +
 tools/power/x86/turbostat/Makefile|   6 +-
 tools/power/x86/turbostat/turbostat.8 | 138 ++-
 tools/power/x86/turbostat/turbostat.c | 436 ++
 4 files changed, 427 insertions(+), 161 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT RFC PULL rcu/urgent] Prevent Kconfig from asking pointless questions

[Paul E. McKenney]

On Sat, Apr 18, 2015 at 04:32:38PM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:
> 
> > On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
> > > 
> > > * Paul E. McKenney  wrote:
> > > 
> > > > Hello, Ingo,
> > > > 
> > > > This series contains a single change that fixes Kconfig asking pointless
> > > > questions (https://lkml.org/lkml/2015/4/14/616).  This is an RFC pull
> > > > because there has not yet been a -next build for April 16th.  If you
> > > > would prefer to wait until after -next has pulled this, please let me
> > > > know and I will redo this pull request after that has happened.
> > > > 
> > > > In the meantime, this change is available in the git repository at:
> > > > 
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > > for-mingo
> > > > 
> > > > for you to fetch changes up to 8d7dc9283f399e1fda4e48a1c453f689326d9396:
> > > > 
> > > >   rcu: Control grace-period delays directly from value (2015-04-14 
> > > > 19:33:59 -0700)
> > > > 
> > > > 
> > > > Paul E. McKenney (1):
> > > >   rcu: Control grace-period delays directly from value
> > > > 
> > > >  kernel/rcu/tree.c | 16 +---
> > > >  lib/Kconfig.debug |  1 +
> > > >  2 files changed, 10 insertions(+), 7 deletions(-)
> > > 
> > > Pulled, thanks a lot Paul!
> > > 
> > > Note, while this fixes Linus's immediate complaint that arose from the 
> > > new option, I still think we need to do more fixes in this area.
> > 
> > Good point!
> > 
> > > To demonstrate the current situation I tried the following experiment, 
> > > I did a 'make defconfig' on an x86 box and then took the .config and 
> > > deleted all 'RCU Subsystem' options not marked as debugging.
> > > 
> > > Then I did a 'make oldconfig' to see what kinds of questions a user is 
> > > facing when trying to configure RCU:
> > > 
> > >   *
> > >   * Restart config...
> > >   *
> > >   *
> > >   * RCU Subsystem
> > >   *
> > >   RCU Implementation
> > >   > 1. Tree-based hierarchical RCU (TREE_RCU) (NEW)
> > >   choice[1]: 1
> > 
> > Hmmm...  Given that there is no choice, I agree that it is a bit silly
> > to ask...
> 
> To clarify: this doesn't actually ask - it gets skipped by the kconfig 
> tool. All the rest is an interactive prompt.

Ah, good point!

> > >   Task_based RCU implementation using voluntary context switch 
> > > (TASKS_RCU) [N/y/?] (NEW) 
> > 
> > Agreed, this one should be driven directly off of CONFIG_RCU_TORTURE_TEST
> > and the tracing use case.
> 
> Yeah.

OK, will do.

> > >   Consider userspace as in RCU extended quiescent state (RCU_USER_QS) 
> > > [N/y/?] (NEW) 
> > 
> > This should be driven directly off of CONFIG_NO_HZ_FULL, unless 
> > Frederic knows something I don't.
> 
> Yes.

Then unless Frederic objects...  ;-)

> > >   Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64] (NEW) 
> > 
> > Hmmm...  I could drop/obscure this one in favor of a boot parameter.
> 
> Well, what I think might be even bette to make it scale based on 
> CONFIG_NR_CPUS. Distros already actively manage the 'maximum number of 
> CPUs we support', so relying on that value makes sense.
> 
> So if someone sets CONFIG_NR_CPUS to 1024, it gets scaled accordingly. 
> If CONFIG_NR_CPUS is set to 2, it gets scaled to a minimal config. 
> Note that this would excercise and test the affected codepaths better 
> as well, as we'd get different size setups.
> 
> As for the boot option to override it: what would be the usecase for 
> that?

Well, in normal circumstances, it should be 64 for 64-bit systems and
32 for 32-bit systems, regardless of number of CPUs.  But if you had
an odd-sized multisocket system with extremely high socket-to-socket
memory latencies, you might want to select a different value.  For
a silly example, suppose your system had 27 hardware threads per socket.
Then you might want to set both RCU_FANOUT_LEAF and RCU_FANOUT to 27.

Or use a boot parameter to do so, as can be done today for RCU_FANOUT_LEAF.

@@@

> > >   Tree-based hierarchical RCU leaf-level fanout value (RCU_FANOUT_LEAF) 
> > > [16] (NEW) 
> > 
> > Ditto -- though large configurations really do set this to 64 in 
> > combination with the skew_tick boot parameter.  Maybe we need to 
> > drive these off of some large-system parameter, like CONFIG_MAX_SMP.
> 
> Or rather CONFIG_NR_CPUS. CONFIG_MAX_SMP is really a debugging thing, 
> to configure the system to the silliest high settings that doesn't 
> outright crash - but it doesn't make much sense otherwise.

Except that setting RCU_FANOUT_LEAF to 64 without also booting with
skew_tick=1 is a really bad idea, as the synchronized scheduling-clock
interrupts will cause ugly levels of lock contention on the rcu_node
->lock.  :-(

But perhaps making the default value of sched_skew_tick be 1 if
RCU_FANOUT_LEAF is greater than 16 is the right solution.

> > >   Disable tree-based hierarchical RCU auto-balancing 

Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Guenter Roeck]

On 04/18/2015 05:04 PM, Linus Torvalds wrote:

On Sat, Apr 18, 2015 at 7:40 PM, Guenter Roeck  wrote:

On Sat, Apr 18, 2015 at 04:23:25PM -0700, Guenter Roeck wrote:


my qemu test for arm:vexpress fails with the latest upstream kernel. It fails
hard - I don't get any output from the console. Bisect points to commit
8053871d0f7f ("smp: Fix smp_call_function_single_async() locking").
Reverting this commit fixes the problem.


Hmm. It being qemu, can you look at where it seems to lock?



 static void csd_lock_wait(struct call_single_data *csd)
 {
+#if 0
while (smp_load_acquire(>flags) & CSD_FLAG_LOCK)
cpu_relax();
+#else
+   pr_info("csd_lock_wait: flags=0x%x\n", smp_load_acquire(>flags));
+#endif
 }

prints

csd_lock_wait: flags=0x3

repeatedly for each call to csd_lock_wait() [and bypasses the problem].
Further debugging shows that wait==1, and that csd points to the
pre-initialized csd_stack (which has CSD_FLAG_LOCK set).

It seems that CSD_FLAG_LOCK is never reset (there is no call to csd_unlock(), 
ever).

Further debugging (with added WARN_ON if cpu != 0 in smp_call_function_single) 
shows:

[<800157ec>] (unwind_backtrace) from [<8001250c>] (show_stack+0x10/0x14)
[<8001250c>] (show_stack) from [<80494cb4>] (dump_stack+0x88/0x98)
[<80494cb4>] (dump_stack) from [<80024058>] (warn_slowpath_common+0x84/0xb4)
[<80024058>] (warn_slowpath_common) from [<80024124>] 
(warn_slowpath_null+0x1c/0x24)
[<80024124>] (warn_slowpath_null) from [<80078fc8>] 
(smp_call_function_single+0x170/0x178)
[<80078fc8>] (smp_call_function_single) from [<80090024>] 
(perf_event_exit_cpu+0x80/0xf0)
[<80090024>] (perf_event_exit_cpu) from [<80090110>] (perf_cpu_notify+0x30/0x48)
[<80090110>] (perf_cpu_notify) from [<8003d340>] (notifier_call_chain+0x44/0x84)
[<8003d340>] (notifier_call_chain) from [<8002451c>] (_cpu_up+0x120/0x168)
[<8002451c>] (_cpu_up) from [<800245d4>] (cpu_up+0x70/0x94)
[<800245d4>] (cpu_up) from [<80624234>] (smp_init+0xac/0xb0)
[<80624234>] (smp_init) from [<80618d84>] (kernel_init_freeable+0x118/0x268)
[<80618d84>] (kernel_init_freeable) from [<8049107c>] (kernel_init+0x8/0xe8)
[<8049107c>] (kernel_init) from [<8000f320>] (ret_from_fork+0x14/0x34)
---[ end trace 2f9f1bb8a47b3a1b ]---
smp_call_function_single, cpu=1, wait=1, csd_stack=87825ea0
generic_exec_single, cpu=1, smp_processor_id()=0
csd_lock_wait: csd=87825ea0, flags=0x3

This is repeated for each secondary CPU. But the secondary CPUs don't respond 
because
they are not enabled, which I guess explains why the lock is never released.

So, in other words, this happens because the system believes (presumably per 
configuration
/ fdt data) that there are four CPU cores, but that is not really the case. 
Previously that
did not matter, and was handled correctly. Now it is fatal.

Does this help ?

Guenter

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

Re: [PATCH 2/2] Staging: dgnc: fixed code style issues, mainly line width issues.

[Joe Perches]

On Sun, 2015-04-19 at 02:04 +0200, Yorick Rommers wrote:
> A patch for dgnc_mgmt.c and dgnc_neo.c to fix some code style issues.

trivial notes:

Try breaking up the patches you send into more discrete
chucks that do just one thing, not mostly one thing
and some other things.

> diff --git a/drivers/staging/dgnc/dgnc_mgmt.c 
> b/drivers/staging/dgnc/dgnc_mgmt.c
[]
> @@ -148,7 +148,9 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, 
> unsigned long arg)
>   di.info_bdstate = dgnc_Board[brd]->dpastatus;
>   di.info_ioport = 0;
>   di.info_physaddr = (ulong) dgnc_Board[brd]->membase;
> - di.info_physsize = (ulong) dgnc_Board[brd]->membase - 
> dgnc_Board[brd]->membase_end;

It may be better to use a temporary for brd like:

struct dgnc_board *bd = dgnc_Board[brd];

as is done a few other places.

> + di.info_physsize =
> + (ulong) dgnc_Board[brd]->membase - dgnc_Board[brd]->membase_end;

so this becomes
di.info->physsize = bd->membase - bd->membase_end;

though I wonder if this is a defect and size
should be bd->membase_end - bd->membase + 1

It doesn't need a cast as membase and membase_end
are ulong already.

It also seems this physsize variable isn't used.

> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
[]
> @@ -79,7 +79,8 @@ struct board_ops dgnc_neo_ops = {
>   .send_immediate_char =  neo_send_immediate_char
>  };
> 
> -static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 
> 0x40, 0x80 };
> +static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
> +0x10, 0x20, 0x40, 0x80 };

That's less attractive then what's already there.
The generic kernel form for an array declaration would be:

static uint dgnc_offset_table[8] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
};

This also would be better as static const.

I stopped reading here.

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

[PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable

[Len Brown]

From: Len Brown 

Default behavior unchanged.

cpu_up() has a hard-coded mdelay(10).  Change that to a variable,
with default CONFIG_X86_INIT_MDELAY
and a boot-time override, "cpu_init_mdelay=N"

This patch adds mechanism without changing default policy.
Default policy will be changed in a subsequent patch.

Signed-off-by: Len Brown 
---
 Documentation/kernel-parameters.txt |  7 +++
 arch/x86/Kconfig| 15 +++
 arch/x86/kernel/smpboot.c   | 16 +++-
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index bfcb1a6..ec98968 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -737,6 +737,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
cpuidle.off=1   [CPU_IDLE]
disable the cpuidle sub-system
 
+   cpu_init_mdelay=N
+   [X86] Delay for N millisec between assert and de-assert
+   of APIC INIT to start processor.  In most 
configurations,
+   this occurs once for every CPU upon boot, and online,
+   such as resume from suspend and resume from hibernate.
+   Default: 10
+
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
Format:
,,,[,]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..d2a91da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -884,6 +884,21 @@ config SCHED_MC
  making when dealing with multi-core CPU chips at a cost of slightly
  increased overhead in some places. If unsure say N here.
 
+config X86_INIT_MDELAY
+   int "Milliseconds to wait to de-assert INIT upon CPU startup" if SMP
+   range 0 10
+   default "10"
+   ---help---
+ This allows you to specify how long the BSP will delay
+ between asserting INIT and de-asserting INIT when starting another 
CPU.
+ This delay is paid on each cpu-online operation, including boot-time,
+ resume from suspend, and resume from hibernate.  The the value of
+ 10 millisec was specified by Multi-Processor Spec 1.4 in 1997.
+ But modern hardware does not require any delay.
+
+ The kernel boot-time parameter "cpu_init_mdelay="
+ will over-ride this build-time default.
+
 source "kernel/Kconfig.preempt"
 
 config UP_LATE_INIT
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index febc6aa..973621f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -555,6 +555,20 @@ wakeup_secondary_cpu_via_nmi(int apicid, unsigned long 
start_eip)
return (send_status | accept_status);
 }
 
+unsigned int x86_init_mdelay = CONFIG_X86_INIT_MDELAY;
+static int __init cpu_init_mdelay(char *str)
+{
+   unsigned int tmp;
+
+   get_option(, );
+   pr_info("x86_init_mdelay set to %d, was %d", tmp, x86_init_mdelay);
+   x86_init_mdelay = tmp;
+   return 0;
+}
+
+early_param("cpu_init_mdelay", cpu_init_mdelay);
+
+
 static int
 wakeup_secondary_cpu_via_init(int phys_apicid, unsigned long start_eip)
 {
@@ -586,7 +600,7 @@ wakeup_secondary_cpu_via_init(int phys_apicid, unsigned 
long start_eip)
pr_debug("Waiting for send to finish...\n");
send_status = safe_apic_wait_icr_idle();
 
-   mdelay(10);
+   mdelay(x86_init_mdelay);
 
pr_debug("Deasserting INIT\n");
 
-- 
2.4.0.rc1

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

[PATCH 0/1] speeding up cpu_up()

[Len Brown]

The following patch...

[PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable

enables reducing cpu_up() time by 10ms on modern systems.

This means that for every processor in the system,
boot-time and resume-time can be reduced by 10ms per-processor.

Once this patch is accepted, I'll send a subsequent patch
to update the default delay, as appropriate.

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

[GIT PULL] ext4 changes for 4.1

[Theodore Ts'o]

The following changes since commit 1efff914afac8a965ad63817ecf8861a927c2ace:

  fs: add dirtytime_expire_seconds sysctl (2015-03-17 12:23:32 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus

for you to fetch changes up to 6ddb2447846a8ece111e316a2863c2355023682d:

  ext4 crypto: enable encryption feature flag (2015-04-16 01:56:00 -0400)


A few bug fixes and add support for file-system level encryption in ext4.


Christoph Hellwig (1):
  ext4: remove block_device_ejected

Eric Whitney (2):
  ext4: fix loss of delalloc extent info in ext4_zero_range()
  ext4: don't release reserved space for previously allocated cluster

Konstantin Khlebnikov (1):
  ext4: fix bh leak on error paths in ext4_rename() and ext4_cross_rename()

Lukas Czerner (2):
  ext4: allocate entire range in zero range
  ext4: make fsync to sync parent dir in no-journal for real this time

Maurizio Lombardi (1):
  ext4: remove unnecessary lock/unlock of i_block_reservation_lock

Michael Halcrow (13):
  ext4 crypto: export ext4_empty_dir()
  ext4 crypto: add encryption xattr support
  ext4 crypto: add encryption policy and password salt support
  ext4 crypto: add ext4 encryption facilities
  ext4 crypto: add encryption key management facilities
  ext4 crypto: inherit encryption policies on inode and directory create
  ext4 crypto: implement the ext4 encryption write path
  ext4 crypto: implement the ext4 decryption read path
  ext4 crypto: filename encryption facilities
  ext4 crypto: insert encrypted filenames into a leaf directory block
  ext4 crypto: partial update to namei.c for fname crypto
  ext4 crypto: filename encryption modifications
  ext4 crypto: enable filename encryption

Rasmus Villemoes (1):
  ext4: fix transposition typo in format string

Sheng Yong (1):
  ext4: remove unused header files

Theodore Ts'o (7):
  ext4 crypto: add ext4_mpage_readpages()
  ext4 crypto: reserve codepoints used by the ext4 encryption feature
  ext4 crypto: add ext4 encryption Kconfig
  ext4 crypto: enforce context consistency
  ext4 crypto: teach ext4_htree_store_dirent() to store decrypted filenames
  ext4 crypto: add symlink encryption
  ext4 crypto: enable encryption feature flag

Wei Yuan (1):
  ext4: remove useless condition in if statement.

Xiaoguang Wang (1):
  ext4: fix comments in ext4_can_extents_be_merged()

 fs/ext4/Kconfig  |  17 +++
 fs/ext4/Makefile |   4 +-
 fs/ext4/acl.c|   5 -
 fs/ext4/balloc.c |   3 -
 fs/ext4/bitmap.c |   1 -
 fs/ext4/block_validity.c |   1 -
 fs/ext4/crypto.c | 558 
+
 fs/ext4/crypto_fname.c   | 709 
++
 fs/ext4/crypto_key.c | 165 +++
 fs/ext4/crypto_policy.c  | 194 +++
 fs/ext4/dir.c|  81 
 fs/ext4/ext4.h   | 169 ++--
 fs/ext4/ext4_crypto.h| 147 +
 fs/ext4/extents.c|  81 ++--
 fs/ext4/extents_status.c |   2 -
 fs/ext4/file.c   |  19 ++-
 fs/ext4/fsync.c  |   1 -
 fs/ext4/hash.c   |   1 -
 fs/ext4/ialloc.c |  28 +++-
 fs/ext4/inline.c |  16 ++-
 fs/ext4/inode.c  | 130 +-
 fs/ext4/ioctl.c  |  86 +++-
 fs/ext4/namei.c  | 637 
+---
 fs/ext4/page-io.c|  47 ++-
 fs/ext4/readpage.c   | 328 +
 fs/ext4/super.c  |  56 +---
 fs/ext4/symlink.c|  97 +-
 fs/ext4/xattr.c  |   4 +-
 fs/ext4/xattr.h  |   3 +
 29 files changed, 3344 insertions(+), 246 deletions(-)
 create mode 100644 fs/ext4/crypto.c
 create mode 100644 fs/ext4/crypto_fname.c
 create mode 100644 fs/ext4/crypto_key.c
 create mode 100644 fs/ext4/crypto_policy.c
 create mode 100644 fs/ext4/ext4_crypto.h
 create mode 100644 fs/ext4/readpage.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Guenter Roeck]

On 04/18/2015 05:04 PM, Linus Torvalds wrote:

On Sat, Apr 18, 2015 at 7:40 PM, Guenter Roeck  wrote:

On Sat, Apr 18, 2015 at 04:23:25PM -0700, Guenter Roeck wrote:


my qemu test for arm:vexpress fails with the latest upstream kernel. It fails
hard - I don't get any output from the console. Bisect points to commit
8053871d0f7f ("smp: Fix smp_call_function_single_async() locking").
Reverting this commit fixes the problem.


Hmm. It being qemu, can you look at where it seems to lock?


I'll try. It must be very early in the boot process, prior to console
initialization - if I load qemu without -nographic I only get "Guest
has not initialized the display (yet)".


Additional observation: The system boots if I add "-smp cpus=4" to the qemu
options. It does still hang, however, with "-smp cpus=2" and "-smp cpus=3".


Funky.

That patch still looks obviously correct to me after looking at it
again, but I guess we need to revert it if somebody can't see what's
wrong.

It does make async (wait=0) smp_call_function_single() possibly be
*really* asynchronous, ie the 'csd' ends up being released and can be
re-used even before the call-single function has completed. That
should be a good thing, but I wonder if that triggers some ARM bug.

Instead of doing a full revert, what happens if you replace this part:

+   /* Do we wait until *after* callback? */
+   if (csd->flags & CSD_FLAG_SYNCHRONOUS) {
+   func(info);
+   csd_unlock(csd);
+   } else {
+   csd_unlock(csd);
+   func(info);
+   }

with just

+   func(info);
+   csd_unlock(csd);

ie keeping the csd locked until the function has actually completed? I
guess for completeness, we should do the same thing for the cpu ==
smp_processor_id() case (see the "We can unlock early" comment).

Now, if that makes a difference, I think it implies a bug in the
caller, so it's not the right fix, but it would be an interesting
thing to test.


I applied the above. No difference. Applying the same change for the cpu ==
smp_processor_id() case does not make a difference either.

Guenter

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

Re: [patch] seccomp.2: Note that memory area is read-only

[Alexei Starovoitov]

On Sat, Apr 18, 2015 at 04:37:35PM -0700, Kees Cook wrote:
> On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
>  wrote:
> > Hi Kees,
> >
> > I recently was asked about the point below, and had to go check the code
> > to be sure, since the man page said nothing. It would be good to have
> > a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
> > is read-only, right? (That is, one can't write to the buffer in order to
> > change the arguments that a system call actually receives.)
> 
> That's correct. If BPF even allows changing the data, it's not copied
> back to the syscall when it runs. Anything wanting to do things like
> that would need to use ptrace to catch the call an directly modify the
> registers before continuing with the call.

Today BPF programs can only read from seccomp_data buffer.
I think it would be an interesting feature to allow overwrite of
syscall arguments by the program on the fly... sometime in the future.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Linus Torvalds]

On Sat, Apr 18, 2015 at 7:40 PM, Guenter Roeck  wrote:
> On Sat, Apr 18, 2015 at 04:23:25PM -0700, Guenter Roeck wrote:
>>
>> my qemu test for arm:vexpress fails with the latest upstream kernel. It fails
>> hard - I don't get any output from the console. Bisect points to commit
>> 8053871d0f7f ("smp: Fix smp_call_function_single_async() locking").
>> Reverting this commit fixes the problem.

Hmm. It being qemu, can you look at where it seems to lock?

> Additional observation: The system boots if I add "-smp cpus=4" to the qemu
> options. It does still hang, however, with "-smp cpus=2" and "-smp cpus=3".

Funky.

That patch still looks obviously correct to me after looking at it
again, but I guess we need to revert it if somebody can't see what's
wrong.

It does make async (wait=0) smp_call_function_single() possibly be
*really* asynchronous, ie the 'csd' ends up being released and can be
re-used even before the call-single function has completed. That
should be a good thing, but I wonder if that triggers some ARM bug.

Instead of doing a full revert, what happens if you replace this part:

+   /* Do we wait until *after* callback? */
+   if (csd->flags & CSD_FLAG_SYNCHRONOUS) {
+   func(info);
+   csd_unlock(csd);
+   } else {
+   csd_unlock(csd);
+   func(info);
+   }

with just

+   func(info);
+   csd_unlock(csd);

ie keeping the csd locked until the function has actually completed? I
guess for completeness, we should do the same thing for the cpu ==
smp_processor_id() case (see the "We can unlock early" comment).

Now, if that makes a difference, I think it implies a bug in the
caller, so it's not the right fix, but it would be an interesting
thing to test.

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

[PATCH 2/2] Staging: dgnc: fixed code style issues, mainly line width issues.

[Yorick Rommers]

A patch for dgnc_mgmt.c and dgnc_neo.c to fix some code style issues.

Signed-off-by: Yorick Rommers 
---
 drivers/staging/dgnc/dgnc_mgmt.c |   4 +-
 drivers/staging/dgnc/dgnc_neo.c  | 210 +++
 2 files changed, 151 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index b13318a..2385da8 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -148,7 +148,9 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
di.info_bdstate = dgnc_Board[brd]->dpastatus;
di.info_ioport = 0;
di.info_physaddr = (ulong) dgnc_Board[brd]->membase;
-   di.info_physsize = (ulong) dgnc_Board[brd]->membase - 
dgnc_Board[brd]->membase_end;
+   di.info_physsize =
+   (ulong) dgnc_Board[brd]->membase - dgnc_Board[brd]->membase_end;
+
if (dgnc_Board[brd]->state != BOARD_FAILED)
di.info_nports = dgnc_Board[brd]->nasync;
else
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index f5a4d36..23afd78 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -79,7 +79,8 @@ struct board_ops dgnc_neo_ops = {
.send_immediate_char =  neo_send_immediate_char
 };

-static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 
0x80 };
+static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
+0x10, 0x20, 0x40, 0x80 };


 /*
@@ -113,14 +114,18 @@ static inline void neo_set_cts_flow_control(struct 
channel_t *ch)
/* Turn off auto Xon flow control */
efr &= ~UART_17158_EFR_IXON;

-   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   /*
+* Why?
+* Becuz Exar's spec says we have to zero it out before setting it
+*/
writeb(0, >ch_neo_uart->efr);

/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);

/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+  >ch_neo_uart->fctr);

/* Feed the UART our trigger levels */
writeb(8, >ch_neo_uart->tfifo);
@@ -149,13 +154,17 @@ static inline void neo_set_rts_flow_control(struct 
channel_t *ch)
ier &= ~UART_17158_IER_XOFF;
efr &= ~UART_17158_EFR_IXOFF;

-   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   /*
+* Why?
+* Becuz Exar's spec says we have to zero it out before setting it
+*/
writeb(0, >ch_neo_uart->efr);

/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);

-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;

writeb(32, >ch_neo_uart->rfifo);
@@ -187,13 +196,17 @@ static inline void neo_set_ixon_flow_control(struct 
channel_t *ch)
/* Turn on auto Xon flow control */
efr |= (UART_17158_EFR_ECB | UART_17158_EFR_IXON);

-   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   /*
+* Why?
+* Becuz Exar's spec says we have to zero it out before setting it
+*/
writeb(0, >ch_neo_uart->efr);

/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);

-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;

writeb(32, >ch_neo_uart->rfifo);
@@ -225,14 +238,18 @@ static inline void neo_set_ixoff_flow_control(struct 
channel_t *ch)
ier |= UART_17158_IER_XOFF;
efr |= (UART_17158_EFR_ECB | UART_17158_EFR_IXOFF);

-   /* Why? Becuz Exar's spec says we have to zero it out before setting it 
*/
+   /*
+* Why?
+* Becuz Exar's spec says we have to zero it out before setting it
+*/
writeb(0, >ch_neo_uart->efr);

/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);

/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+  >ch_neo_uart->fctr);

writeb(8, >ch_neo_uart->tfifo);
ch->ch_t_tlevel = 8;
@@ -267,14 +284,18 @@ static inline void neo_set_no_input_flow_control(struct 
channel_t *ch)
efr &= ~(UART_17158_EFR_ECB | UART_17158_EFR_IXOFF);


-   /* Why? Becuz Exar's spec says we 

Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Guenter Roeck]

On Sat, Apr 18, 2015 at 04:23:25PM -0700, Guenter Roeck wrote:
> Hi all,
> 
> my qemu test for arm:vexpress fails with the latest upstream kernel. It fails
> hard - I don't get any output from the console. Bisect points to commit
> 8053871d0f7f ("smp: Fix smp_call_function_single_async() locking").
> Reverting this commit fixes the problem.
> 

Additional observation: The system boots if I add "-smp cpus=4" to the qemu
options. It does still hang, however, with "-smp cpus=2" and "-smp cpus=3".

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

Re: [patch] seccomp.2: Note that memory area is read-only

[Kees Cook]

On Mon, Apr 6, 2015 at 8:29 AM, Michael Kerrisk (man-pages)
 wrote:
> Hi Kees,
>
> I recently was asked about the point below, and had to go check the code
> to be sure, since the man page said nothing. It would be good to have
> a confirmation: the seccomp_data buffer supplied to a seccomp BPF program
> is read-only, right? (That is, one can't write to the buffer in order to
> change the arguments that a system call actually receives.)

That's correct. If BPF even allows changing the data, it's not copied
back to the syscall when it runs. Anything wanting to do things like
that would need to use ptrace to catch the call an directly modify the
registers before continuing with the call.

>
> A small man page patch below.

Looks good, thanks!

-Kees

>
> Cheers,
>
> Michael
>
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -232,15 +232,15 @@ struct sock_filter {/* Filter block */
>  };
>  .fi
>  .in
>
>  When executing the instructions, the BPF program operates on the
>  system call information made available (i.e., use the
>  .BR BPF_ABS
> -addressing mode) as a buffer of the following form:
> +addressing mode) as a (read-only) buffer of the following form:
>
>  .in +4n
>  .nf
>  struct seccomp_data {
>  int   nr;   /* System call number */
>  __u32 arch; /* AUDIT_ARCH_* value
> (see ) */
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



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

qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Guenter Roeck]

Hi all,

my qemu test for arm:vexpress fails with the latest upstream kernel. It fails
hard - I don't get any output from the console. Bisect points to commit
8053871d0f7f ("smp: Fix smp_call_function_single_async() locking").
Reverting this commit fixes the problem.

Please let me know if there is anything I can help to track down the problem.

Thanks,
Guenter

---
bisect log:

# bad: [34a984f7b0cc6355a1e0c184251d0d4cc86f44d2] Merge branch 
'x86-pmem-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
# good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0
git bisect start 'HEAD' 'v4.0'
# good: [c1c21f4e60ed4523292f1a89ff45a208bddd3849] i2c: core: Export bus 
recovery functions
git bisect good c1c21f4e60ed4523292f1a89ff45a208bddd3849
# good: [e693d73c20ffdb06840c9378f367bad849ac0d5d] parisc: remove use of 
seq_printf return value
git bisect good e693d73c20ffdb06840c9378f367bad849ac0d5d
# good: [d19d5efd8c8840aa4f38a6dfbfe500d8cc27de46] Merge tag 'powerpc-4.1-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux
git bisect good d19d5efd8c8840aa4f38a6dfbfe500d8cc27de46
# good: [96d928ed75c4ba4253e82910a697ec7b06ace8b4] Merge tag 'xtensa-20150416' 
of git://github.com/czankel/xtensa-linux
git bisect good 96d928ed75c4ba4253e82910a697ec7b06ace8b4
# good: [e2fdae7e7c5a690b10b2d2891ec819e554dc033d] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc
git bisect good e2fdae7e7c5a690b10b2d2891ec819e554dc033d
# good: [510965dd4a0a59504ba38455f77339ea8b4c6a70] Merge tag 'gpio-v4.1-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect good 510965dd4a0a59504ba38455f77339ea8b4c6a70
# good: [10027551ccf5459cc771c31ac8bc8e5cc8db45f8] f2fs: pass checkpoint reason 
on roll-forward recovery
git bisect good 10027551ccf5459cc771c31ac8bc8e5cc8db45f8
# good: [d6a24d0640d609138a4e40a4ce9fd9fe7859e24c] Merge tag 'docs-for-linus' 
of git://git.lwn.net/linux-2.6
git bisect good d6a24d0640d609138a4e40a4ce9fd9fe7859e24c
# bad: [396c9df2231865ef55aa031e3f5df9d99e036869] Merge branch 
'locking-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 396c9df2231865ef55aa031e3f5df9d99e036869
# good: [7bdb11de8ee4f4ae195e2fa19efd304e0b36c63b] mnt: Factor out unhash_mnt 
from detach_mnt and umount_tree
git bisect good 7bdb11de8ee4f4ae195e2fa19efd304e0b36c63b
# good: [e0c9c0afd2fc958ffa34b697972721d81df8a56f] mnt: Update detach_mounts to 
leave mounts connected
git bisect good e0c9c0afd2fc958ffa34b697972721d81df8a56f
# bad: [8053871d0f7f67c7efb7f226ef031f78877d6625] smp: Fix 
smp_call_function_single_async() locking
git bisect bad 8053871d0f7f67c7efb7f226ef031f78877d6625
# good: [d7bc3197b41e0a1af6677e83f8736e93a1575ce0] lockdep: Make print_lock() 
robust against concurrent release
git bisect good d7bc3197b41e0a1af6677e83f8736e93a1575ce0
# first bad commit: [8053871d0f7f67c7efb7f226ef031f78877d6625] smp: Fix 
smp_call_function_single_async() locking

---
configuration:

# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
CONFIG_CPUSETS=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_VEXPRESS=y
CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARCH_VEXPRESS_DCSCB=y
CONFIG_ARCH_VEXPRESS_TC2_PM=y
CONFIG_SMP=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_MCPM=y
CONFIG_VMSPLIT_2G=y
CONFIG_NR_CPUS=8
CONFIG_ARM_PSCI=y
CONFIG_AEABI=y
CONFIG_CMA=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=ttyAMA0"
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
CONFIG_NEON=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_INET_LRO is not set
# CONFIG_IPV6 is not set
# CONFIG_WIRELESS is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_UBI=y
CONFIG_VIRTIO_BLK=y
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_VIRTIO=y
CONFIG_ATA=y
# CONFIG_SATA_PMP is not set
CONFIG_NETDEVICES=y
CONFIG_VIRTIO_NET=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
# CONFIG_WLAN is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_I2C=y
CONFIG_I2C_VERSATILE=y
CONFIG_SENSORS_VEXPRESS=y
CONFIG_REGULATOR=y

Re: [PATCH 4/5] MIPS: ath79: Fix the PCI memory size and offset of window 7

[Jonas Gorski]

Hi,

On Fri, Apr 17, 2015 at 2:36 PM, Alban Bedel  wrote:
> The define AR71XX_PCI_MEM_SIZE miss one window, there is 7 windows,
> not 6. To make things clearer, and allow simpler code, derive
> AR71XX_PCI_MEM_SIZE from the newly introduced AR71XX_PCI_WIN_COUNT
> and AR71XX_PCI_WIN_SIZE.
>
> The define AR71XX_PCI_WIN7_OFFS also add a typo, fix it.

I think this will break PCI on ar71xx.

>
> Signed-off-by: Alban Bedel 
> ---
>  arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h 
> b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> index aa3800c..e2669a8 100644
> --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> @@ -41,7 +41,9 @@
>  #define AR71XX_RESET_SIZE  0x100
>
>  #define AR71XX_PCI_MEM_BASE0x1000
> -#define AR71XX_PCI_MEM_SIZE0x0700
> +#define AR71XX_PCI_WIN_COUNT   8
> +#define AR71XX_PCI_WIN_SIZE0x0100
> +#define AR71XX_PCI_MEM_SIZE(AR71XX_PCI_WIN_COUNT * AR71XX_PCI_WIN_SIZE)
>
>  #define AR71XX_PCI_WIN0_OFFS   0x1000
>  #define AR71XX_PCI_WIN1_OFFS   0x1100
> @@ -50,7 +52,7 @@
>  #define AR71XX_PCI_WIN4_OFFS   0x1400
>  #define AR71XX_PCI_WIN5_OFFS   0x1500
>  #define AR71XX_PCI_WIN6_OFFS   0x1600
> -#define AR71XX_PCI_WIN7_OFFS   0x0700
> +#define AR71XX_PCI_WIN7_OFFS   0x1700

These values are used in exactly one place, for writing into the PCI
address space offset registers.
The 7th PCI window is a special one for accessing the configuration
space registers, which requires to be set to 0x0700 for that
purpose. So by changing this value you likely break access to these
values.

>
>  #define AR71XX_PCI_CFG_BASE\
> (AR71XX_PCI_MEM_BASE + AR71XX_PCI_WIN7_OFFS + 0x1)

Also this macro would now be wrong, and calculate a wrong address.


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

Re: kernel BUG at mm/swap.c:134! - page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)

[Borislav Petkov]

Forgot to CC lkml for archiving purposes, here's the whole thread in
one:

---
Hi guys,

so I'm running some intermediate state of linus/master + tip/master from
Thursday and probably I shouldn't be even taking such splat seriously
and wait until 4.1-rc1 has been done but let me report it just in case
so that it is out there, in case someone else sees it too.

I don't have a reproducer yet except the fact that it happened twice
already, the second time while watching the new Star Wars teaser on
youtube (current->comm is "AudioThread" probably from chrome, as shown
in the splat below).

And srsly, to VM_BUG_ON_PAGE() while I'm watching the new Star Wars
teaser - you must be kidding me people!

Anyway, just FYI, someone might have an idea...

So here's the state of what I was running:

---
commit 3963e69e59fa4e36ac164e8cd520811135d868d3
Merge: 34c9a0ffc75a 11664e41b11e
Author: Borislav Petkov 
Date:   Thu Apr 16 13:39:44 2015 +0200

Merge remote-tracking branch 'tip/master' into rc0+

commit 11664e41b11ed447f598424dd83ecf65400be5a1 (refs/remotes/tip/master)
Merge: 61a7fd4deb61 2df8406a439b
Author: Ingo Molnar 
Date:   Thu Apr 16 09:20:52 2015 +0200

Merge branch 'sched/urgent'

commit eea3a00264cf243a28e4331566ce67b86059339d
Merge: e7c82412433a e693d73c20ff
Author: Linus Torvalds 
Date:   Wed Apr 15 16:39:15 2015 -0700

Merge branch 'akpm' (patches from Andrew)

Merge second patchbomb from Andrew Morton:

---

and here's the splat:

---

[115258.861335] page:ea0010a15040 count:0 mapcount:1 mapping:  
(null) index:0x0
[115258.869511] flags: 0x80008014(referenced|dirty|tail)
[115258.874159] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[115258.874177] [ cut here ]
[115258.874179] kernel BUG at mm/swap.c:134!
[115258.874182] invalid opcode:  [#1] 
[115258.874183] PREEMPT 
[115258.874184] SMP 

[115258.874187] Modules linked in:
[115258.874189]  nls_iso8859_15
[115258.874190]  nls_cp437
[115258.874192]  ipt_MASQUERADE
[115258.874193]  nf_nat_masquerade_ipv4
[115258.874194]  iptable_mangle
[115258.874195]  iptable_nat
[115258.874196]  nf_conntrack_ipv4
[115258.874198]  nf_defrag_ipv4
[115258.874199]  nf_nat_ipv4
[115258.874200]  nf_nat
[115258.874201]  nf_conntrack
[115258.874202]  iptable_filter
[115258.874204]  ip_tables
[115258.874205]  x_tables
[115258.874206]  tun
[115258.874207]  sha256_ssse3
[115258.874209]  sha256_generic
[115258.874211]  binfmt_misc
[115258.874212]  ipv6
[115258.874213]  vfat
[115258.874214]  fat
[115258.874215]  fuse
[115258.874216]  dm_crypt
[115258.874217]  dm_mod
[115258.874219]  kvm_amd
[115258.874243]  kvm crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul 
glue_helper ablk_helper cryptd amd64_edac_mod edac_core fam15h_power k10temp 
amdkfd amd_iommu_v2 radeon drm_kms_helper ttm cfbfillrect cfbimgblt cfbcopyarea 
acpi_cpufreq
[115258.874248] CPU: 0 PID: 2904 Comm: AudioThread Not tainted 4.0.0+ #1
[115258.874250] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
[115258.874252] task: 8803e8278000 ti: 8803f8a04000 task.ti: 
8803f8a04000
[115258.874262] RIP: 0010:[]  [] 
put_compound_page+0x3b9/0x480
[115258.874264] RSP: 0018:8803f8a07b98  EFLAGS: 00010246
[115258.874266] RAX: 003d RBX: ea0010a15040 RCX: 

[115258.874268] RDX: 8109f016 RSI: 810bb33f RDI: 
810bae60
[115258.874270] RBP: 8803f8a07bb8 R08: 0001 R09: 
0001
[115258.874271] R10: 0001 R11: 0001 R12: 
ea0010a15000
[115258.874273] R13: 8803f8a07e28 R14: ea0010a15040 R15: 

[115258.874276] FS:  7f206f2af700() GS:88042c60() 
knlGS:
[115258.874278] CS:  0010 DS:  ES:  CR0: 80050033
[115258.874280] CR2: 7f2095443310 CR3: 00041e866000 CR4: 
000406f0
[115258.874281] Stack:
[115258.874287]  8803f8a07e60 ea0010a151c0 8803f8a07e28 
ea0010a15040
[115258.874292]  8803f8a07c28 8113ffd0 0001 

[115258.874296]  8803f8a07de8 8803f8a07e60 8803f8a07be8 
8803f8a07be8
[115258.874298] Call Trace:
[115258.874304]  [] release_pages+0x250/0x270
[115258.874311]  [] free_pages_and_swap_cache+0x95/0xb0
[115258.874317]  [] tlb_flush_mmu_free+0x40/0x60
[115258.874323]  [] unmap_single_vma+0x69c/0x730
[115258.874331]  [] unmap_vmas+0x54/0xb0
[115258.874335]  [] unmap_region+0xa8/0x110
[115258.874342]  [] do_munmap+0x1ea/0x3f0
[115258.874346]  [] ? vm_munmap+0x43/0x80
[115258.874350]  [] vm_munmap+0x51/0x80
[115258.874354]  [] SyS_munmap+0xe/0x20
[115258.874359]  [] system_call_fastpath+0x16/0x73
[115258.874424] Code: 81 48 89 df e8 29 c9 01 00 0f 0b 48 c7 c6 00 81 8a 81 4c 
89 e7 e8 18 c9 01 00 0f 0b 48 c7 c6 d8 96 8b 81 48 89 df e8 07 c9 01 00 <0f> 0b 
48 c7 c6 30 97 8b 81 48 89 df e8 f6 c8 01 00 0f 0b 48 c7 
[115258.874428] RIP  [] 

dm log: struct log_write_super and padding (was: Re: dm: add log writes target)

[Geert Uytterhoeven]

On Sat, Apr 18, 2015 at 2:34 PM, Linux Kernel Mailing List
 wrote:
> Gitweb: 
> http://git.kernel.org/linus/;a=commit;h=0e9cebe724597a76ab1b0ebc0a21e16f7db11b47
> Commit: 0e9cebe724597a76ab1b0ebc0a21e16f7db11b47

> --- /dev/null
> +++ b/drivers/md/dm-log-writes.c
> @@ -0,0 +1,825 @@

> +/*
> + * Basic info about the log for userspace.
> + */
> +struct log_write_super {
> +   __le64 magic;
> +   __le64 version;
> +   __le64 nr_entries;
> +   __le32 sectorsize;

Should there be an explicit padding of 4 bytes?
Does anything assume that sizeof(struct log_write_super) is always 4 * 8?

On architectures where the natural alignment of 64-bit quantities is less
than 8 bytes, sizeof(struct log_write_super) is smaller than 32 bytes
(e.g. on m68k it's 28).

> +};

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dm log: Use ULL suffix for 64-bit constants

[Geert Uytterhoeven]

On 32-bit:

drivers/md/dm-log-writes.c: In function ‘log_super’:
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type
drivers/md/dm-log-writes.c:323: warning: integer constant is too large for 
‘long’ type

Add a ULL suffix to WRITE_LOG_MAGIC to fix this.
Also add a ULL suffix to WRITE_LOG_VERSION as it's stored in a __le64
field.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/md/dm-log-writes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c
index 93e08446a87d06ff..ad1b049ae2ab80a9 100644
--- a/drivers/md/dm-log-writes.c
+++ b/drivers/md/dm-log-writes.c
@@ -55,8 +55,8 @@
 #define LOG_DISCARD_FLAG (1 << 2)
 #define LOG_MARK_FLAG (1 << 3)
 
-#define WRITE_LOG_VERSION 1
-#define WRITE_LOG_MAGIC 0x6a736677736872
+#define WRITE_LOG_VERSION 1ULL
+#define WRITE_LOG_MAGIC 0x6a736677736872ULL
 
 /*
  * The disk format for this is braindead simple.
-- 
1.9.1

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

[PATCH] kbuild/mkspec: Simplify vmlinux.bz2 creation

[Borislav Petkov]

From: Borislav Petkov 

No need for the intermediary vmlinux.orig - bzip2 can keep the original
files used for compression with --keep.

Signed-off-by: Borislav Petkov 
Cc: Michal Marek 
Cc: linux-kbu...@vger.kernel.org
---
 scripts/package/mkspec | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index d9ab94b17de0..89f9669d4f00 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -111,10 +111,8 @@ echo 'cp System.map 
$RPM_BUILD_ROOT'"/boot/System.map-$KERNELRELEASE"
 echo 'cp .config $RPM_BUILD_ROOT'"/boot/config-$KERNELRELEASE"
 
 echo "%ifnarch ppc64"
-echo 'cp vmlinux vmlinux.orig'
-echo 'bzip2 -9 vmlinux'
+echo 'bzip2 -9 --keep vmlinux'
 echo 'mv vmlinux.bz2 $RPM_BUILD_ROOT'"/boot/vmlinux-$KERNELRELEASE.bz2"
-echo 'mv vmlinux.orig vmlinux'
 echo "%endif"
 
 if ! $PREBUILT; then
-- 
2.3.5

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

[GIT] Sparc

[David Miller]

Unfortunately, I brown paper bagged the generic iommu pool
allocator by applying the wrong revision of the patch series.

This reverts the bad one, and puts the right one in.

Please pull, thanks a lot!

The following changes since commit 04b7fe6a4a231871ef681bc95e08fe66992f7b1f:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide (2015-04-17 
16:36:59 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

for you to fetch changes up to ccb301862aa51ea7c10c10b440f3e8bbeac5b720:

  Merge branch 'iommu-generic-allocator' (2015-04-18 12:35:09 -0700)


David S. Miller (2):
  sparc: Revert generic IOMMU allocator.
  Merge branch 'iommu-generic-allocator'

Sowmini Varadhan (4):
  Break up monolithic iommu table/lock into finer graularity pools and lock
  sparc: Make sparc64 use scalable lib/iommu-common.c functions
  sparc: Make LDC use common iommu poll management functions
  iommu-common: Fix PARISC compile-time warnings

 arch/sparc/include/asm/iommu_64.h |   2 +-
 arch/sparc/kernel/iommu.c |  78 +++---
 arch/sparc/kernel/ldc.c   |  60 ++--
 arch/sparc/kernel/pci_sun4v.c |  64 ++---
 include/linux/iommu-common.h  |  38 +++
 lib/iommu-common.c| 190 
++
 6 files changed, 202 insertions(+), 230 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tpmdd-devel] [RFC PATCH 1/2] tee: generic TEE subsystem

[Russell King - ARM Linux]

On Sat, Apr 18, 2015 at 11:29:23AM -0600, Jason Gunthorpe wrote:
> On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > +   teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
> > > [..]
> > > > +   rc = misc_register(>miscdev);
> > > [..]
> > > > +void tee_unregister(struct tee_device *teedev)
> > > > +{
> > > [..]
> > > > +   misc_deregister(>miscdev);
> > > > +}
> > > [..]
> > > >+static int optee_remove(struct platform_device *pdev)
> > > >+{
> > > >+   tee_unregister(optee->teedev);
> > > 
> > > Isn't that a potential use after free? AFAIK misc_deregister does not
> > > guarentee the miscdev will no longer be accessed after it returns, and
> > > the devm will free it after optee_remove returns.
> > > 
> > > Memory backing a stuct device needs to be freed via the release
> > > function.
> > 
> > Out of interest, which struct device are you talking about here?
> 
> Sorry, I was imprecise. In the first paragraph I ment 'miscdev' to
> refer to the entire thing, struct tee_device, struct misc_device, the
> driver allocations, etc.
> 
> So, the first issue is the use-after-free via ioctl() touching struct
> tee_device that you described.
> 
> But then we trundle down to:
> 
> + ctx->teedev->desc->ops->get_version(ctx, _version,
> +   vers.uuid);
> 
> If we kref teedev so it is valid then calling a driver call back after
> (or during) it's remove function is very likely to blow up.

Why?

Normally, the file_operations will be associated with the module which,
in this case, called misc_register() - the same module which contains
the remove function.

So, the text for the remove function will still be available.  The data
for the remove function will also be available, because we haven't
kref_put()'d the last reference yet.

So, where's the problem?

> Also, in TPM we discovered that adding a sysfs file was very ugly
> (impossible?) because without the misc_mtx protection that open has,
> getting a locked tee_device in the sysfs callback is difficult.

Right - the problem here is that a sysfs file attached to the class
device inside miscdev could be open at the point we want to free the
tee structures - and the lifetime of the miscdev class device is
unrelated to the lifetime of the tee structure.

For a device attribute attached to that class device, the lifetime
of the class device will be controlled by the sysfs file being open.

The problem comes when you want to try to get at some private data
(in this case, the tee private data) from that class device.  The class
device has no driver data set.  So, people may be tempted to use
dev->parent to grab the parent device's private data - and that's
dangerous, because after device_destroy() in misc_deregister(),
nothing guarantees that the class device's parent pointer remains
valid.

So, attaching attributes to the class device is _really_ a no-go.
The attributes should be attached to the parent device - the device
which is actually being driven.

The second option is to attach them to the struct device for the
device being driven.  That has all the standard rules which come
from drivers attaching attributes to the struct device for which
they're driving, so that should be nothing new to anyone.

If that's hard to get right, then we have an error in the design of
the driver model - such stuff should be _easy_ to get right.  For
example, the driver model should guarantee that when a driver
attribute is removed from a struct device, its method won't be
called any further (if it doesn't do this, I suspect we have a fair
number of buggy drivers...)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[David Miller]

From: Sowmini Varadhan 
Date: Sat, 18 Apr 2015 15:55:14 -0400

>> 
>> Sowmini, I think I sorted this out in the 'sparc' GIT tree.
>> 
>> Can you take a look?
> 
> The patches look right now. These are the commit-ids I checked
> 
>   ff7d37a502022149655c18035b99a53391be0383
>   bb620c3d3925aec0ed4f21010c86df08ec18a8c7
>   0ae53ed15d9b87b883b593a9884957cfa4fc2480

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

[sparc:master 2/6] lib/iommu-common.c:14:15: sparse: symbol 'iommu_large_alloc' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master
head:   ccb301862aa51ea7c10c10b440f3e8bbeac5b720
commit: ff7d37a502022149655c18035b99a53391be0383 [2/6] Break up monolithic 
iommu table/lock into finer graularity pools and lock
reproduce:
  # apt-get install sparse
  git checkout ff7d37a502022149655c18035b99a53391be0383
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   lib/iommu-common.c:52:13: sparse: function 'iommu_tbl_pool_init' with 
external linkage has definition
>> lib/iommu-common.c:14:15: sparse: symbol 'iommu_large_alloc' was not 
>> declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tee: generic TEE subsystem

[Russell King - ARM Linux]

On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> > > > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > > > +struct tee_device {
> > > > > > +   char name[TEE_MAX_DEV_NAME_LEN];
> > > > > > +   const struct tee_desc *desc;
> > > > > > +   struct device *dev;
> > > > > 
> > > > > No, please embed the device in your structure, don't have a pointer to
> > > > > it.
> > > > 
> > > > Greg, "dev" here is not a locally allocated device, but the parent 
> > > > device.
> > > > It's actually the same as struct tee_device.miscdev.parent, which could 
> > > > be
> > > > used instead and this member deleted.
> > > 
> > > A miscdev doesn't need to have a "parent", it's just there to provide a
> > > character device node to userspace, not to represent a "device that you
> > > can do things with in the heirachy".
> > > 
> > > If you really want that, then use a real 'struct device' as should be
> > > done here.  Have just a pointer to a misc device, that is meant to be
> > > dynamic.
> > 
> > Let's rewind.
> > 
> > You are saying that "struct device *dev;" should be "struct device dev;"
> 
> Yes.
> 
> > I'm saying that you are mis-interpreting in your review what _that_ is.
> 
> Probably, I really have no idea what it is anymore.  What it _should_ be
> is the thing that controls the lifecycle of the structure.  Do not use a
> miscdevice for that, it will not work, as the TPM developers found out
> the hard way.

I _really_ don't understand what you're going on about.

The "struct device *dev" is a pointer to the struct device corresponding
to the _device_ which is being probed and the tee device is being
registered for - in the case of the submitted code, that is the
struct device embedded in the platform device.

This is a /really/ standard thing to do in drivers - saving a pointer
to the struct device which the driver is responsible for.

So why should this pointer become a struct device itself?

Greg, I think you have performed a disservice by poorly reviewing the
driver, and giving _incorrect_ comments.  Please can you have another
look at both patches together and provide a better review.  Thanks.


Second point _against_ embedding a struct device here - a struct device
is exposed to userspace.  Why expose this to userspace - we have other
ways to manage the lifetime of data structures, such as krefs, which
are not exposed to userspace.  What's wrong with using a kref to
control the lifetime of this structure?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] perf data: Fix duplicate field names and avoid reserved keywords

[Jiri Olsa]

On Sat, Apr 18, 2015 at 02:56:00PM -0400, Jérémie Galarneau wrote:
> On Sat, Apr 18, 2015 at 11:50 AM, Jiri Olsa  wrote:
> > From: Wang Nan 
> >
> > Some parameters of syscall tracepoints named as 'nr', 'event', etc.
> > When dealing with them, perf convert to ctf meets some problem:
> >
> >  1. If a parameter with name 'nr', it will duplicate syscall's
> > common field 'nr'. One such syscall is io_submit().
> >
> >  2. If a parameter with name 'event', it is denied to be inserted
> > because 'event' is a babeltrace keywork. One such syscall is
> > epoll_ctl.
> 
> Minor nitpick: "event" is a reserved keyword in the CTF specification
> [1], the rule is only enforced by Babeltrace. Also, keywork ->
> keyword.

thanks,

Arnaldo, any chance you could change it? (with ack from
He Kuang of course), or do you need a respin..

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

Re: [RFC 0/6] perf tools: Report event parsing errors

[Jiri Olsa]

On Sat, Apr 18, 2015 at 07:39:27PM +0200, Ingo Molnar wrote:
> 
> * Jiri Olsa  wrote:
> 
> > hi,
> > adding support to report error from event string parsing.
> 
> Very nice!
> 
> > This patchset contains support for standard parsing errors and more 
> > logic to recognize tracepoint and 'pmu//' terms, like:
> > 
> >   $ perf record -e 'sched:krava' ls
> >   invalid or unsupported event: 'sched:krava'
> >  \___ unknown tracepoint
> > 
> >   $ ./perf record -e 'cpu/even=0x1/' ls
> >   invalid or unsupported event: 'cpu/even=0x1/'
> >  \___ unknown term
> > 
> >   $ perf record -e cycles,cache-mises ls
> >   invalid or unsupported event: '..es,cache-mises'
> >\___ parser error
> > 
> > any feedback about the error string shape would be great ;-)
> 
> So since we now know exactly what's going on, we might want to drop 
> the 'invalid or unsupported event' language as well, and make it 
> specific:
> 
>$ ./perf record -e 'cpu/even=0x1/' ls
>event syntax error: 'cpu/even=0x1/'
> \___ unknown term
>  
> 
> ?

ok

> 
> Also, for the above error, could we easily list the valid terms? An 
> error like:
> 
>$ ./perf record -e 'cpu/even=0x1/' ls
>event syntax error: 'cpu/even=0x1/'
> \___ unknown term
>valid terms: "event", "raw".
> 
> or so?

we already carry list of all terms for given pmu,
so it shouldn't be a problem

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

Re: [RFC PATCH 1/2] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> > > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > > +struct tee_device {
> > > > > + char name[TEE_MAX_DEV_NAME_LEN];
> > > > > + const struct tee_desc *desc;
> > > > > + struct device *dev;
> > > > 
> > > > No, please embed the device in your structure, don't have a pointer to
> > > > it.
> > > 
> > > Greg, "dev" here is not a locally allocated device, but the parent device.
> > > It's actually the same as struct tee_device.miscdev.parent, which could be
> > > used instead and this member deleted.
> > 
> > A miscdev doesn't need to have a "parent", it's just there to provide a
> > character device node to userspace, not to represent a "device that you
> > can do things with in the heirachy".
> > 
> > If you really want that, then use a real 'struct device' as should be
> > done here.  Have just a pointer to a misc device, that is meant to be
> > dynamic.
> 
> Let's rewind.
> 
> You are saying that "struct device *dev;" should be "struct device dev;"

Yes.

> I'm saying that you are mis-interpreting in your review what _that_ is.

Probably, I really have no idea what it is anymore.  What it _should_ be
is the thing that controls the lifecycle of the structure.  Do not use a
miscdevice for that, it will not work, as the TPM developers found out
the hard way.

thanks,

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

Re: [PATCH 3.10 00/34] 3.10.75-stable review

[Greg Kroah-Hartman]

On Sat, Apr 18, 2015 at 12:10:47PM -0700, Guenter Roeck wrote:
> On 04/18/2015 02:02 AM, Greg Kroah-Hartman wrote:
> >On Fri, Apr 17, 2015 at 01:00:10PM -0700, Guenter Roeck wrote:
> >>On Fri, Apr 17, 2015 at 03:28:32PM +0200, Greg Kroah-Hartman wrote:
> >>>This is the start of the stable review cycle for the 3.10.75 release.
> >>>There are 34 patches in this series, all will be posted as a response
> >>>to this one.  If anyone has any issues with these being applied, please
> >>>let me know.
> >>>
> >>>Responses should be made by Sun Apr 19 13:25:20 UTC 2015.
> >>>Anything received after that time might be too late.
> >>>
> >>Build results:
> >>total: 125 pass: 124 fail: 1
> >>Failed builds:
> >>arm64:allmodconfig
> >>
> >>Qemu test results:
> >>total: 27 pass: 27 fail: 0
> >>
> >>arm64:allmodconfig was added to the list of builds only recently;
> >>the build failure is not new. Results are as expected.
> >
> >Hm, any hint on how I can solve the build failure.  It's in my nature to
> >not want any failures :)
> >
> 
> Hi Greg,
> 
> turns out it wasn't that difficult.
> 
> I sent a number of patch requests to sta...@vger.kernel.org to address
> the build failures in both v3.10 and v3.14. You'll need to apply six patches
> to v3.10, and three patches to v3.14. All but one of the patches for v3.14
> apply cleanly; I sent you a backport for the one patch which doesn't.

Thanks, I'll queue them up for the next round after this release on
Sunday/Monday.

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

[PATCH 3/3] perf tests: Add build tests for building perf from kernel source root and tools

[Jiri Olsa]

Adding build tests for following make commands:
  $ make -C  tools/perf
  $ make -C /tools perf

Link: http://lkml.kernel.org/n/tip-8mz4fits682bac4shmejj...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/tests/make | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index bff85324f799..901ec9191359 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -223,7 +223,19 @@ tarpkg:
echo "- $@: $$cmd" && echo $$cmd > $@ && \
( eval $$cmd ) >> $@ 2>&1
 
-all: $(run) $(run_O) tarpkg
+make_kernelsrc:
+   @echo " - make -C  tools/perf"
+   $(call clean); \
+   (make -C ../.. tools/perf) > $@ 2>&1 && \
+   test -x perf && rm -f $@ || (cat $@ ; false)
+
+make_kernelsrc_tools:
+   @echo " - make -C /tools perf"
+   $(call clean); \
+   (make -C ../../tools perf) > $@ 2>&1 && \
+   test -x perf && rm -f $@ || (cat $@ ; false)
+
+all: $(run) $(run_O) tarpkg make_kernelsrc make_kernelsrc_tools
@echo OK
 
 out: $(run_O)
-- 
1.9.3

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

[PATCH 1/3] tools build: No need to make libapi for perf explicitly

[Jiri Olsa]

The perf build handles its dependencies by itself.

Also renaming libapi libapikfs to libapi as it got
changed just recently.

Link: http://lkml.kernel.org/n/tip-f31hq9rl838ovbyj0w1bh...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 9a617adc6675..01995cc8ac44 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -47,10 +47,10 @@ cgroup firewire hv guest usb virtio vm net: FORCE
 liblockdep: FORCE
$(call descend,lib/lockdep)
 
-libapikfs: FORCE
+libapi: FORCE
$(call descend,lib/api)
 
-perf: libapikfs FORCE
+perf: FORCE
$(call descend,$@)
 
 selftests: FORCE
@@ -97,10 +97,10 @@ cgroup_clean hv_clean firewire_clean lguest_clean usb_clean 
virtio_clean vm_clea
 liblockdep_clean:
$(call descend,lib/lockdep,clean)
 
-libapikfs_clean:
+libapi_clean:
$(call descend,lib/api,clean)
 
-perf_clean: libapikfs_clean
+perf_clean:
$(call descend,$(@:_clean=),clean)
 
 selftests_clean:
-- 
1.9.3

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

[PATCH 2/3] tools build: Fix Makefile(s) to properly invoke tools build

[Jiri Olsa]

Several fixes were needed to allow following builds:
  $ make tools/tmon
  $ make -C  tools/perf
  $ make -C /tools perf

 - some of the tools (perf) use same make variables as in
   kernel build, unsetting srctree and objtree
 - using original $(O) for O variable
 - perf build does not follow the descend function setup
   invoking it via it's own make rule

I tried the rest of the tools/Makefile targets and they
seem to work now.

Reported-by: Brian Norris 
Link: http://lkml.kernel.org/n/tip-pvncmskx7tw8vpolkfqmc...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 Makefile   |  5 ++---
 tools/Makefile | 12 +++-
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index da36a3be7969..b1ca0607ed2e 100644
--- a/Makefile
+++ b/Makefile
@@ -214,7 +214,6 @@ VPATH   := $(srctree)$(if 
$(KBUILD_EXTMOD),:$(KBUILD_EXTMOD))
 
 export srctree objtree VPATH
 
-
 # SUBARCH tells the usermode build what the underlying arch is.  That is set
 # first, and if a usermode build is happening, the "ARCH=um" on the command
 # line overrides the setting of ARCH below.  If a native build is happening,
@@ -1504,11 +1503,11 @@ image_name:
 # Clear a bunch of variables before executing the submake
 tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(objtree) subdir=tools -C $(src)/tools/
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(O) 
subdir=tools -C $(src)/tools/
 
 tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
-   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" 
O=$(objtree) subdir=tools -C $(src)/tools/ $*
+   $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(O) 
subdir=tools -C $(src)/tools/ $*
 
 # Single targets
 # ---
diff --git a/tools/Makefile b/tools/Makefile
index 01995cc8ac44..b35102721cbb 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -1,3 +1,8 @@
+# Some of the tools (perf) use same make variables
+# as in kernel build.
+export srctree=
+export objtree=
+
 include scripts/Makefile.include
 
 help:
@@ -50,8 +55,13 @@ liblockdep: FORCE
 libapi: FORCE
$(call descend,lib/api)
 
+# The perf build does not follow the descend function setup,
+# invoking it via it's own make rule.
+PERF_O   = $(if $(O),$(O)/tools/perf,)
+
 perf: FORCE
-   $(call descend,$@)
+   $(Q)mkdir -p $(PERF_O) .
+   $(Q)$(MAKE) --no-print-directory -C perf O=$(PERF_O) subdir=
 
 selftests: FORCE
$(call descend,testing/$@)
-- 
1.9.3

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

[PATCH 0/3] tools build: Fix tools Makefile

[Jiri Olsa]

hi,
sending tools/Makefile fixes discussed in here:
  http://marc.info/?t=14225069361=1=2

thanks,
jirka
---
Jiri Olsa (3):
  tools build: No need to make libapi for perf explicitly
  tools build: Fix Makefile(s) to properly invoke tools build
  perf tests: Add build tests for building perf from kernel source root and 
tools

 Makefile  |  5 ++---
 tools/Makefile| 20 +++-
 tools/perf/tests/make | 14 +-
 3 files changed, 30 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATH] MIPS: ath79: Add OF support and DTS for TL-WR1043ND

[Florian Fainelli]

Le 17/04/2015 07:24, Alban Bedel a écrit :
> This series add OF bindings and code support for the interrupt
> controllers, clocks and GPIOs. However it was only tested on a
> TL-WR1043ND with an AR9132, others SoCs are untested, and a few are
> not supported at all.
> 
> Most code changes base on the previous bug fix series:
> [PATH] MIPS: ath79: Various small fix to prepare OF support

Any reasons why Gabor Juhos is not CC'd on these patches?
--
Florian

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

Re: panic with CPU hotplug + blk-mq + scsi-mq

[Jens Axboe]

On 04/17/2015 10:23 PM, Ming Lei wrote:

Hi Dongsu,

On Fri, Apr 17, 2015 at 5:41 AM, Dongsu Park
 wrote:

Hi,

there's a critical bug regarding CPU hotplug, blk-mq, and scsi-mq.
Every time when a CPU is offlined, some arbitrary range of kernel memory
seems to get corrupted. Then after a while, kernel panics at random places
when block IOs are issued. (for example, see the call traces below)


Thanks for the report.



This bug can be easily reproducible with a Qemu VM running with virtio-scsi,
when its guest kernel is 3.19-rc1 or higher, and when scsi-mq is loaded
with blk-mq enabled. And yes, 4.0 release is still affected, as well as
Jens' for-4.1/core. How to reproduce:

  # echo 0 > /sys/devices/system/cpu/cpu1/online
  (and issue some block IOs, that's it.)

Bisecting between 3.18 and 3.19-rc1, it looks like this bug had been hidden
until commit ccbedf117f01 ("virtio_scsi: support multi hw queue of blk-mq"),
which started to allow virtio-scsi to map virtqueues to hardware queues of
blk-mq. Reverting that commit makes the bug go away. However, I suppose
reverting it could not be a correct solution.


I agree, and that patch only enables multiple hw queues.



More precisely, every time a CPU hotplug event gets triggered,
a call graph is like the following:

   blk_mq_queue_reinit_notify()
   -> blk_mq_queue_reinit()
-> blk_mq_map_swqueue()
 -> blk_mq_free_rq_map()
  -> scsi_exit_request()

 From that point, as soon as any address in the request gets modified, an
arbitrary range of memory gets corrupted. My first guess was that probably
the exit routine could try to deallocate tags->rqs[] where invalid
addresses are stored. But actually it looks like it's not the case,
and cmd->sense_buffer looks also valid.
It's not obvious to me, exactly what could go wrong.

Does anyone have an idea?


As far as I can see, at least two problems exist:
- race between timeout and CPU hotplug
- in case of shared tags, during CPU online handling, about setting
and checking hctx->tags

So could you please test the attached two patches to see if they fix your issue?

I run them in my VM, and looks opps does disappear.


Hard to comment on your patches directly when they are attached. Both 
look good to me. I'd perhaps change the ->tags check in #1 to use 
blk_mq_hw_queue_mapped() instead of checking directly. Might even be 
worth considering changing the normal iterator to skip unmapped queues, 
but that can be left for a later change.


--
Jens Axboe

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

[PATCH 3/3] Usb: core: buffer: fixed the checkpatch warning

[Nizam Haider]

Fixed two warnings sizeof name and clank line after declaration

Signed-off-by: Nizam Haider 
---
 drivers/usb/core/buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 684ef70..04125b6 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -62,7 +62,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
size = pool_max[i];
if (!size)
continue;
-   snprintf(name, sizeof name, "buffer-%d", size);
+   snprintf(name, sizeof(name), "buffer-%d", size);
hcd->pool[i] = dma_pool_create(name, hcd->self.controller,
size, size, 0);
if (!hcd->pool[i]) {
@@ -87,6 +87,7 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
 
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
struct dma_pool *pool = hcd->pool[i];
+
if (pool) {
dma_pool_destroy(pool);
hcd->pool[i] = NULL;
-- 
1.8.1.4

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

Re: [PATCH 1/5 v2] blk-mq: Add prep/unprep support

[Christoph Hellwig]

On Sat, Apr 18, 2015 at 08:45:19AM +0200, Matias Bjorling wrote:
> The low level drivers will be NVMe and vendor's own PCI-e drivers. It's very
> generic in their nature. Each driver would duplicate the same work. Both
> could have normal and open-channel drives attached.

I didn't say the work should move into the driver, bur rather that
driver should talk to the open channel ssd code directly instead of
hooking into the core block code.

> I'll like to keep blk-mq in the loop. I don't think it will be pretty to
> have two data paths in the drivers. For blk-mq, bios are splitted/merged on
> the way down. Thus, the actual physical addresses needs aren't known before
> the IO is diced to the right size.

But you _do_ have two different data path already.  Nothing says you
can't use blk-mq for your data path, ut it should be a separate entry
point.  Similar to say how a SCSI disk and MMC device both use the block
layer but still use different entry points.

> The reason it shouldn't be under the a single block device, is that a target
> should be able to provide a global address space.
> That allows the address
> space to grow/shrink dynamically with the disks. Allowing a continuously
> growing address space, where disks can be added/removed as requirements grow
> or flash ages. Not on a sector level, but on a flash block level.

I don't understand what you mean with a single block device here, but I
suspect we're talking past each other somehow.

> >>In the future, applications can have an API to get/put flash block directly.
> >>(using the blk_nvm_[get/put]_blk interface).
> >
> >s/application/filesystem/?
> >
> 
> Applications. The goal is that key value stores, e.g. RocksDB, Aerospike,
> Ceph and similar have direct access to flash storage. There won't be a
> kernel file-system between.
> 
> The get/put interface can be seen as a space reservation interface for where
> a given process is allowed to access the storage media.
> 
> It can also be seen in the way that we provide a block allocator in the
> kernel, while applications implement the rest of "file-system" in
> user-space, specially optimized for their data structures. This makes a lot
> of sense for a small subset (LSM, Fractal trees, etc.) of database
> applications.

While we'll need a proper API for that first it's just another reason of
why we shouldnt shoe horn the open channel ssd support into the block
layer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Staging: i2o: fixed various code style issues in i2o_block.c

[Yorick Rommers]

From: Yorick 

This is a patch that fixes errors regarding whitespaces and split strings.

Signed-off-by: Yorick Rommers 
---
 drivers/staging/i2o/i2o_block.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/i2o/i2o_block.c b/drivers/staging/i2o/i2o_block.c
index 406758f..206d9c4 100644
--- a/drivers/staging/i2o/i2o_block.c
+++ b/drivers/staging/i2o/i2o_block.c
@@ -36,7 +36,7 @@
  * Independent queues per IOP
  * Support for dynamic device creation/deletion
  * Code cleanup
- * Support for larger I/Os through merge* functions
+ * Support for larger I/Os through merge* functions
  * (taken from DAC960 driver)
  * Boji T Kannanthanam:
  * Set the I2O Block devices to be detected in increasing
@@ -315,7 +315,7 @@ static inline void i2o_block_request_free(struct 
i2o_block_request *ireq)
  */
 static inline int i2o_block_sglist_alloc(struct i2o_controller *c,
 struct i2o_block_request *ireq,
-u32 ** mptr)
+u32 **mptr)
 {
int nents;
enum dma_data_direction direction;
@@ -488,8 +488,8 @@ static int i2o_block_reply(struct i2o_controller *c, u32 m,
 *  Don't stick a supertrak100 into cache aggressive modes
 */
 
-   osm_err("TID %03x error status: 0x%02x, detailed status: "
-   "0x%04x\n", (le32_to_cpu(msg->u.head[1]) >> 12 & 0xfff),
+   osm_err("TID %03x error status: 0x%02x, detailed status: 
0x%04x\n",
+  (le32_to_cpu(msg->u.head[1]) >> 12 & 0xfff),
status >> 24, status & 0x);
 
req->errors++;
@@ -505,6 +505,7 @@ static int i2o_block_reply(struct i2o_controller *c, u32 m,
 static void i2o_block_event(struct work_struct *work)
 {
struct i2o_event *evt = container_of(work, struct i2o_event, work);
+
osm_debug("event received\n");
kfree(evt);
 };
-- 
2.3.5

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

[PATCH Bugfix 3/4] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitely distinguish xstate size in kernel from user space

[Fenghua Yu]

From: Fenghua Yu 

User space uses standard format xsave area. fpstate in signal frame should
have standard format size.

To explicitly distinguish between xstate size in kernel space and the one
in user space, we rename xstate_size to kernel_xstate_size. This patch is
not fixing a bug. It just makes kernel code more clear.

So we define the xsave area sizes in two global variables:

kernel_xstate_size (previous xstate_size): the xsave area size used in
xsave area allocated in kernel
user_xstate_size: the xsave area size used in xsave area used by user.

In no "xsaves" case, xsave area in both user space and kernel space are in
standard format. Therefore, kernel_xstate_size and user_xstate_size are
equal.

In "xsaves" case, xsave area in user space is in standard format while
xsave area in kernel space is in compact format. Therefore, kernel's
xstate size is less than user's xstate size.

Signed-off-by: Fenghua Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/include/asm/fpu-internal.h |  4 ++--
 arch/x86/include/asm/processor.h|  2 +-
 arch/x86/kernel/i387.c  | 18 +-
 arch/x86/kernel/process.c   |  2 +-
 arch/x86/kernel/xsave.c | 14 +++---
 5 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index c00c769..5d9ba0c 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -597,14 +597,14 @@ static inline void fpu_free(struct fpu *fpu)
 static inline void fpu_copy(struct task_struct *dst, struct task_struct *src)
 {
if (use_eager_fpu()) {
-   memset(>thread.fpu.state->xsave, 0, xstate_size);
+   memset(>thread.fpu.state->xsave, 0, kernel_xstate_size);
__save_fpu(dst);
} else {
struct fpu *dfpu = >thread.fpu;
struct fpu *sfpu = >thread.fpu;
 
unlazy_fpu(src);
-   memcpy(dfpu->state, sfpu->state, xstate_size);
+   memcpy(dfpu->state, sfpu->state, kernel_xstate_size);
}
 }
 
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 576ff8c..f26051b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -482,7 +482,7 @@ DECLARE_PER_CPU(struct irq_stack *, hardirq_stack);
 DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
 #endif /* X86_64 */
 
-extern unsigned int xstate_size;
+extern unsigned int kernel_xstate_size;
 extern unsigned int user_xstate_size;
 extern void free_thread_xstate(struct task_struct *);
 extern struct kmem_cache *task_xstate_cachep;
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 00918327..47759a5 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -133,8 +133,8 @@ void unlazy_fpu(struct task_struct *tsk)
 EXPORT_SYMBOL(unlazy_fpu);
 
 unsigned int mxcsr_feature_mask __read_mostly = 0xu;
-unsigned int xstate_size;
-EXPORT_SYMBOL_GPL(xstate_size);
+unsigned int kernel_xstate_size;
+EXPORT_SYMBOL_GPL(kernel_xstate_size);
 static struct i387_fxsave_struct fx_scratch;
 
 static void mxcsr_feature_mask_init(void)
@@ -154,7 +154,7 @@ static void mxcsr_feature_mask_init(void)
 static void init_thread_xstate(void)
 {
/*
-* Note that xstate_size might be overwriten later during
+* Note that kernel_xstate_size might be overwriten later during
 * xsave_init().
 */
 
@@ -165,14 +165,14 @@ static void init_thread_xstate(void)
 */
setup_clear_cpu_cap(X86_FEATURE_XSAVE);
setup_clear_cpu_cap(X86_FEATURE_XSAVEOPT);
-   xstate_size = sizeof(struct i387_soft_struct);
+   kernel_xstate_size = sizeof(struct i387_soft_struct);
return;
}
 
if (cpu_has_fxsr)
-   xstate_size = sizeof(struct i387_fxsave_struct);
+   kernel_xstate_size = sizeof(struct i387_fxsave_struct);
else
-   xstate_size = sizeof(struct i387_fsave_struct);
+   kernel_xstate_size = sizeof(struct i387_fsave_struct);
 }
 
 /*
@@ -208,9 +208,9 @@ void fpu_init(void)
 
/*
 * init_thread_xstate is only called once to avoid overriding
-* xstate_size during boot time or during CPU hotplug.
+* kernel_xstate_size during boot time or during CPU hotplug.
 */
-   if (xstate_size == 0)
+   if (kernel_xstate_size == 0)
init_thread_xstate();
 
mxcsr_feature_mask_init();
@@ -225,7 +225,7 @@ void fpu_finit(struct fpu *fpu)
return;
}
 
-   memset(fpu->state, 0, xstate_size);
+   memset(fpu->state, 0, kernel_xstate_size);
 
if (cpu_has_fxsr) {
fx_finit(>state->fxsave);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 8213da6..ded2c82 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c

[PATCH Bugfix 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context

[Fenghua Yu]

From: Fenghua Yu 

If "xsaves" is enabled, kernel always uses compact format of xsave area.
But user space still uses standard format of xsave area. Thus, xstate size
in kernel's xsave area is smaller than xstate size in user's xsave area.
xstate in signal frame should be in standard format for user's signal
handler to access.

In no "xsaves" case, xsave area in both user space and kernel space are in
standard format. Therefore, user's and kernel's xstate sizes are equal.

In "xsaves" case, xsave area in user space is in standard format while
xsave area in kernel space is in compact format. Therefore, kernel's
xstate size is less than user's xstate size.

So here is the problem: currently kernel uses the kernel's xstate size
for xstate size in signal frame. This is not a problem in no "xsaves" case.
But it is an issue in "xsaves" case because kernel's xstate size is smaller
than user's xstate size. When setting up signal math frame in
alloc_ mathframe(), the fpstate is in standard format; but a smaller size
of fpstate buffer is allocated in signal frame for standard format
xstate. Then kernel saves only part of xstate registers into this smaller
user's fpstate buffer and user will see part of the xstate registers in
signal context. Similar issue happens after returning from signal handler:
kernel will only restore part of xstate registers from user's fpstate
buffer in signal frame.

This patch defines and uses user_xstate_size for xstate size in signal
frame. It's read from returned value in ebx from CPUID leaf 0x0D subleaf
0x0. This is maximum size required by enabled states in XCR0 and may be
different from ecx when states at the end of the xsave area are not
enabled. This value indicates the size required for XSAVE to save all
supported user states in legacy/standard format.

And in order to copy kernel's xsave area in compact format to user xsave
area in standard format, we use copy_to_user_xstate().

Signed-off-by: Fenghua Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/include/asm/fpu-internal.h |  3 +-
 arch/x86/include/asm/processor.h|  1 +
 arch/x86/include/asm/xsave.h|  1 -
 arch/x86/kernel/xsave.c | 95 +
 4 files changed, 90 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/fpu-internal.h 
b/arch/x86/include/asm/fpu-internal.h
index da5e967..c00c769 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -496,7 +496,8 @@ extern int __restore_xstate_sig(void __user *buf, void 
__user *fx, int size);
 
 static inline int xstate_sigframe_size(void)
 {
-   return use_xsave() ? xstate_size + FP_XSTATE_MAGIC2_SIZE : xstate_size;
+   return use_xsave() ? user_xstate_size + FP_XSTATE_MAGIC2_SIZE :
+   user_xstate_size;
 }
 
 static inline int restore_xstate_sig(void __user *buf, int ia32_frame)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 23ba676..576ff8c 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -483,6 +483,7 @@ DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
 #endif /* X86_64 */
 
 extern unsigned int xstate_size;
+extern unsigned int user_xstate_size;
 extern void free_thread_xstate(struct task_struct *);
 extern struct kmem_cache *task_xstate_cachep;
 
diff --git a/arch/x86/include/asm/xsave.h b/arch/x86/include/asm/xsave.h
index c9a6d68..7799d18 100644
--- a/arch/x86/include/asm/xsave.h
+++ b/arch/x86/include/asm/xsave.h
@@ -44,7 +44,6 @@
 #define REX_PREFIX
 #endif
 
-extern unsigned int xstate_size;
 extern u64 pcntxt_mask;
 extern u64 xstate_fx_sw_bytes[USER_XSTATE_FX_SW_WORDS];
 extern struct xsave_struct *init_xstate_buf;
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 3c0a9d1..b8373a0 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -29,6 +29,7 @@ static struct _fpx_sw_bytes fx_sw_reserved, 
fx_sw_reserved_ia32;
 static unsigned int *xstate_offsets, *xstate_sizes;
 static unsigned int xstate_comp_offsets[sizeof(pcntxt_mask)*8];
 static unsigned int xstate_features;
+unsigned int user_xstate_size;
 
 /*
  * If a processor implementation discern that a processor state component is
@@ -85,7 +86,7 @@ void __sanitize_i387_state(struct task_struct *tsk)
 */
while (xstate_bv) {
if (xstate_bv & 0x1) {
-   int offset = xstate_offsets[feature_bit];
+   int offset = xstate_comp_offsets[feature_bit];
int size = xstate_sizes[feature_bit];
 
memcpy(((void *) fx) + offset,
@@ -116,7 +117,7 @@ static inline int check_for_xstate(struct 
i387_fxsave_struct __user *buf,
/* Check for the first magic field and other error scenarios. */
if (fx_sw->magic1 != FP_XSTATE_MAGIC1 ||
fx_sw->xstate_size < min_xstate_size ||
-   fx_sw->xstate_size > xstate_size ||
+   fx_sw->xstate_size > 

[PATCH Bugfix 4/4] x86/xsave: Don't add new states in xsave_struct

[Fenghua Yu]

From: Fenghua Yu 

The structure of xsave_struct is non-architectural. Some xstates could be
disabled and leave some holes in the xsave area. In compact format,
offsets of xstates in the xsave area are decided during booting time.

So the fields in xsave_struct are not static and fixed during compilation
time. The offsets and sizes of the fields in the structure should be
detected from cpuid during runtime.

Therefore, we don't add new states in xsave_struct except legacy fpu/sse
states and header fields whose offsets and sizes are defined
architecturally.

Signed-off-by: Fenghua Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/include/asm/processor.h | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f26051b..163defc 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -386,16 +386,6 @@ struct i387_soft_struct {
u32 entry_eip;
 };
 
-struct ymmh_struct {
-   /* 16 * 16 bytes for each YMMH-reg = 256 bytes */
-   u32 ymmh_space[64];
-};
-
-/* We don't support LWP yet: */
-struct lwp_struct {
-   u8 reserved[128];
-};
-
 struct bndreg {
u64 lower_bound;
u64 upper_bound;
@@ -415,11 +405,11 @@ struct xsave_hdr_struct {
 struct xsave_struct {
struct i387_fxsave_struct i387;
struct xsave_hdr_struct xsave_hdr;
-   struct ymmh_struct ymmh;
-   struct lwp_struct lwp;
-   struct bndreg bndreg[4];
-   struct bndcsr bndcsr;
-   /* new processor state extensions will go here */
+   /*
+* Please don't add more states here. They are non-architectural.
+* Offset and size of each state should be calculated during boot time.
+* So adding states here is meanless.
+*/
 } __attribute__ ((packed, aligned (64)));
 
 union thread_xstate {
-- 
1.8.1.2

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

[PATCH Bugfix 1/4] x86/xsave.c: Fix xstate offsets and sizes enumeration

[Fenghua Yu]

From: Fenghua Yu 

When enumerating xstate offsets and sizes from cpuid (eax=0x0d, ecx>=2),
it's possible that state m is not implemented while state n (n>m)
is implemented. So enumeration shouldn't stop at state m.

There is no platform configured like above yet. But this could be a problem
in the future. For example, suppose XCR0=0xe7, that means FP, SSE, AVX, and
AVX-512 states are enabled and MPX states (bit 3 and 4) are not enabled.
Then in setup_xstate_features(), after finding BNDREGS size is 0 (i.e. eax
from CPUID xstate subleaf 3, break from the for loop. That stops finding
xstate_offsets and xstate_sizes for AVX-512. Later on incorrect
xstate_offsets and xstate_sizes for AVX-512 will be used in a few places
and will causes issues.

This patch enumerates xstate offsets and sizes for all kernel supported
xstates. If a state is not implemented in hardware or not enabled in XCR0,
its size is set as zero and its offset is read from cpuid.

Signed-off-by: Fenghua Yu 
Reviewed-by: Dave Hansen 
---
 arch/x86/kernel/xsave.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 87a815b..3c0a9d1 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -465,23 +465,18 @@ static inline void xstate_enable(void)
  */
 static void __init setup_xstate_features(void)
 {
-   int eax, ebx, ecx, edx, leaf = 0x2;
+   int eax, ebx, ecx, edx, leaf;
 
xstate_features = fls64(pcntxt_mask);
xstate_offsets = alloc_bootmem(xstate_features * sizeof(int));
xstate_sizes = alloc_bootmem(xstate_features * sizeof(int));
 
-   do {
+   for (leaf = 2; leaf < xstate_features; leaf++) {
cpuid_count(XSTATE_CPUID, leaf, , , , );
 
-   if (eax == 0)
-   break;
-
xstate_offsets[leaf] = ebx;
xstate_sizes[leaf] = eax;
-
-   leaf++;
-   } while (1);
+   }
 }
 
 /*
-- 
1.8.1.2

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

Re: [PATCH 07/21] nd: dimm devices (nfit "memory-devices")

[Dan Williams]

On Sat, Apr 18, 2015 at 1:06 AM, Greg KH  wrote:
> On Fri, Apr 17, 2015 at 09:35:52PM -0400, Dan Williams wrote:
>> Register the dimms described in the nfit as devices on a nd_bus, named
>> "dimmN" where N is a global ida index.  The dimm numbering per-bus may
>> appear contiguous, since we only allow a single nd_bus to be registered
>> at at a time.  However, eventually, dimm-hotplug invalidates this
>> property and dimms should be addressed via NFIT-handle.
>>
>> Cc: Greg KH 
>> Cc: Neil Brown 
>> Signed-off-by: Dan Williams 
>> ---
>>  drivers/block/nd/Makefile |1
>>  drivers/block/nd/bus.c|   62 +-
>>  drivers/block/nd/core.c   |   55 +
>>  drivers/block/nd/dimm_devs.c  |  243 
>> +
>>  drivers/block/nd/nd-private.h |   19 +++
>>  5 files changed, 373 insertions(+), 7 deletions(-)
>>  create mode 100644 drivers/block/nd/dimm_devs.c
>>
>> diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
>> index 7772fb599809..6b34dd4d4df8 100644
>> --- a/drivers/block/nd/Makefile
>> +++ b/drivers/block/nd/Makefile
>> @@ -21,3 +21,4 @@ nd_acpi-y := acpi.o
>>
>>  nd-y := core.o
>>  nd-y += bus.o
>> +nd-y += dimm_devs.o
>> diff --git a/drivers/block/nd/bus.c b/drivers/block/nd/bus.c
>> index c27db50511f2..e24db67001d0 100644
>> --- a/drivers/block/nd/bus.c
>> +++ b/drivers/block/nd/bus.c
>> @@ -13,18 +13,59 @@
>>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include "nd-private.h"
>>  #include "nfit.h"
>>
>> -static int nd_major;
>> +static int nd_bus_major;
>
> Call it nd_bus_major in the previous patch, and avoid the unneeded churn
> in this patch.

Ok, will do when re-flowing this series for merging.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/21] nd: ndctl class device, and nd bus attributes

[Dan Williams]

On Sat, Apr 18, 2015 at 1:07 AM, Greg KH  wrote:
> On Fri, Apr 17, 2015 at 09:35:46PM -0400, Dan Williams wrote:
>> This is the position (device topology) independent method to find all
>> the NFIT-defined buses in the system.  The expectation is that there
>> will only ever be one "nd" bus discovered via /sys/class/nd/ndctl0.
>> However, we allow for the possibility of multiple buses and they will
>> listed in discovery order as ndctl0...ndctlN.  This character device
>> hosts the ioctl for passing control messages (as defined by the NFIT
>> spec).  The "format" and "revision" attributes of this device identify
>> the format of the messages.  In the event an NFIT is registered with an
>> unknown/unsupported control message format then the "format" attribute
>> will not be visible.
>>
>> Cc: Greg KH 
>> Cc: Neil Brown 
>> Signed-off-by: Dan Williams 
>> ---
>>  drivers/block/nd/Makefile |1
>>  drivers/block/nd/bus.c|   84 
>> +
>>  drivers/block/nd/core.c   |   71 ++-
>>  drivers/block/nd/nd-private.h |5 ++
>>  4 files changed, 160 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/block/nd/bus.c
>>
>> diff --git a/drivers/block/nd/Makefile b/drivers/block/nd/Makefile
>> index c6bec0c185c5..7772fb599809 100644
>> --- a/drivers/block/nd/Makefile
>> +++ b/drivers/block/nd/Makefile
>> @@ -20,3 +20,4 @@ obj-$(CONFIG_NFIT_ACPI) += nd_acpi.o
>>  nd_acpi-y := acpi.o
>>
>>  nd-y := core.o
>> +nd-y += bus.o
>> diff --git a/drivers/block/nd/bus.c b/drivers/block/nd/bus.c
>> new file mode 100644
>> index ..c27db50511f2
>> --- /dev/null
>> +++ b/drivers/block/nd/bus.c
>> @@ -0,0 +1,84 @@
>> +/*
>> + * Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of version 2 of the GNU General Public License as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + */
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "nd-private.h"
>> +#include "nfit.h"
>> +
>> +static int nd_major;
>> +static struct class *nd_class;
>> +
>> +int nd_bus_create_ndctl(struct nd_bus *nd_bus)
>> +{
>> + dev_t devt = MKDEV(nd_major, nd_bus->id);
>> + struct device *dev;
>> +
>> + dev = device_create(nd_class, _bus->dev, devt, nd_bus, "ndctl%d",
>> + nd_bus->id);
>> +
>> + if (IS_ERR(dev)) {
>> + dev_dbg(_bus->dev, "failed to register ndctl%d: %ld\n",
>> + nd_bus->id, PTR_ERR(dev));
>> + return PTR_ERR(dev);
>> + }
>> + return 0;
>> +}
>> +
>> +void nd_bus_destroy_ndctl(struct nd_bus *nd_bus)
>> +{
>> + device_destroy(nd_class, MKDEV(nd_major, nd_bus->id));
>> +}
>> +
>> +static long nd_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>> +{
>> + return -ENXIO;
>> +}
>
> There is no ioctl call here, so why even have this character device?

Our management library finds nd buses by /sys/class/nd.  The
nd_ioctl() gets filled out in "[PATCH 08/21] nd: ndctl.h, the nd ioctl
abi".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers

[Kevin Cernekee]

On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown  wrote:
> On Sat, Apr 18, 2015 at 09:16:36AM -0700, Kevin Cernekee wrote:
>> On Sat, Apr 18, 2015 at 4:36 AM, Mark Brown  wrote:
>
>> >> +static int tas571x_set_sysclk(struct snd_soc_dai *dai,
>> >> +   int clk_id, unsigned int freq, int dir)
>
>> > Remove empty functions, at best they waste space at worst they break
>> > things.
>
>> Without the empty function, we run into problems with drivers that
>> abort when they get -ENOTSUPP here:
>
>> sound/soc/atmel/atmel_wm8904.c: ret =
>> snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
>> sound/soc/atmel/atmel_wm8904.c- 0, SND_SOC_CLOCK_IN);
>> sound/soc/atmel/atmel_wm8904.c- if (ret < 0) {
>> sound/soc/atmel/atmel_wm8904.c- pr_err("%s -failed to set
>> wm8904 SYSCLK\n", __func__);
>> sound/soc/atmel/atmel_wm8904.c- return ret;
>> sound/soc/atmel/atmel_wm8904.c- }
>
> Someone trying to use the atmel_wm8904 driver with something other than
> a wm8904 shouldn't really be expecting a good experince...

The same check shows up in numerous other drivers, including the one
for the audio controller on my board.

>> Is there a stub version that I can use instead?  Nothing jumped out at
>> me when looking at the other codec drivers.
>
> No, such a stub would make no sense - why would we put a stub in all the
> drivers rather than just making the core do the right thing?

AFAICT, implementing the set_sysclk callback is mandatory, even if it
is a no-op on the codec side.  If I delete the stub function, audio
playback fails.

>> >> + /*
>> >> +  * The master volume defaults to 0x3ff (mute), but we ignore
>> >> +  * (zero) the LSB because the hardware step size is 0.125 dB
>> >> +  * and TLV_DB_SCALE_ITEM has a resolution of 0.01 dB.
>> >> +  */
>> >> + if (regmap_write(priv->regmap, TAS571X_MVOL_REG, 0x3fe))
>> >> + return -EIO;
>
>> > I don't understand this - is the LSB a mute bit or sommething?
>
>> The 10-bit master volume field on 5717/5719 works like:
>
>> 0x3ff: MUTE (power-on default)
>> 0x3fe: -103.750 dB
>> 0x3fd: -103.625 dB
>> [lots more options, in 0.125 dB increments]
>> 0x001: 23.875 dB
>> 0x000: 24.000 dB
>
>> Since we only have a resolution of 0.01 dB, the driver forces the LSB
>> to 0 and uses 0.25 dB increments instead of 0.125 dB.  Mute is handled
>> through the dedicated per-channel soft mute register bits instead of
>> the 0x3ff volume setting.
>
> It's not entirely clear to me why we need to reset the bit, or why if
> we're just trying to update that one bit we write the entire register
> value rather than use _update_bits().  If the goal is just to change
> that one bit then _update_bits() would be a lot clearer.

The default master volume setting on the TAS5717/5719 is 0x3ff (bits
9:0).  We only ever update bits 9:1 when the volume changes, because
the driver is only able to work with 0.25 dB resolution rather than
the hardware's native 0.125 dB resolution.  So this register write
sets the master volume to an even number, which we know we can handle.

Clearing just the LSB would accomplish the same thing, but would be
less obvious IMO.  It would also require an extra read, and the code
is less concise.

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

[PATCH 3/7] direct-io: add support for write stream IDs

[Jens Axboe]

Get the streamid from the file, if any, and set it on the bio.

Signed-off-by: Jens Axboe 
---
 fs/direct-io.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index c3b560b24a46..d318a143b186 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -76,6 +76,7 @@ struct dio_submit {
int reap_counter;   /* rate limit reaping */
sector_t final_block_in_request;/* doesn't change */
int boundary;   /* prev block is at a boundary */
+   int streamid;   /* Write stream ID */
get_block_t *get_block; /* block mapping function */
dio_submit_t *submit_io;/* IO submition function */
 
@@ -371,6 +372,8 @@ dio_bio_alloc(struct dio *dio, struct dio_submit *sdio,
 
sdio->bio = bio;
sdio->logical_offset_in_bio = sdio->cur_page_fs_offset;
+
+   bio_set_streamid(bio, sdio->streamid);
 }
 
 /*
@@ -1201,6 +1204,7 @@ do_blockdev_direct_IO(struct kiocb *iocb, struct inode 
*inode,
sdio.blkbits = blkbits;
sdio.blkfactor = i_blkbits - blkbits;
sdio.block_in_file = offset >> blkbits;
+   sdio.streamid = file_streamid(iocb->ki_filp);
 
sdio.get_block = get_block;
dio->end_io = end_io;
-- 
2.4.0.rc2.1.g3d6bc9a

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

[PATCH 7/7] ext4: add support for write stream IDs

[Jens Axboe]

Signed-off-by: Jens Axboe 
---
 fs/ext4/page-io.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index 464984261e69..392a82925d5f 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -389,6 +389,7 @@ submit_and_retry:
ret = io_submit_init_bio(io, bh);
if (ret)
return ret;
+   bio_set_streamid(io->io_bio, inode_streamid(inode));
}
ret = bio_add_page(io->io_bio, bh->b_page, bh->b_size, bh_offset(bh));
if (ret != bh->b_size)
-- 
2.4.0.rc2.1.g3d6bc9a

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

[PATCH 4/7] Add stream ID support for buffered mpage/__block_write_full_page()

[Jens Axboe]

Pass on the inode stream ID to the bio allocation.

Signed-off-by: Jens Axboe 
---
 fs/buffer.c | 4 ++--
 fs/mpage.c  | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index c7a5602d01ee..5191523cec56 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1774,7 +1774,7 @@ static int __block_write_full_page(struct inode *inode, 
struct page *page,
do {
struct buffer_head *next = bh->b_this_page;
if (buffer_async_write(bh)) {
-   submit_bh(write_op, bh);
+   _submit_bh(write_op, bh, 
streamid_to_flags(inode_streamid(inode)));
nr_underway++;
}
bh = next;
@@ -1828,7 +1828,7 @@ recover:
struct buffer_head *next = bh->b_this_page;
if (buffer_async_write(bh)) {
clear_buffer_dirty(bh);
-   submit_bh(write_op, bh);
+   _submit_bh(write_op, bh, 
streamid_to_flags(inode_streamid(inode)));
nr_underway++;
}
bh = next;
diff --git a/fs/mpage.c b/fs/mpage.c
index 3e79220babac..fba13f4b981d 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -605,6 +605,7 @@ alloc_new:
bio_get_nr_vecs(bdev), GFP_NOFS|__GFP_HIGH);
if (bio == NULL)
goto confused;
+   bio_set_streamid(bio, inode_streamid(inode));
}
 
/*
-- 
2.4.0.rc2.1.g3d6bc9a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Support for write stream IDs

[Jens Axboe]

Hi,

v2 of this posting. Changes since v1:

- Rebased on top of current master.

- Fix EINVAL -> -EINVAL typo.

- Cleanup up BIO_STREAM_OFFSET definition.

- Pack i_streamid and f_streamid better into struct file and struct
  inode.

- Add a separate per-file hint, FADV_FILE_STREAMID. This only sets
  the write stream on the file, not the inode. FADV_STREAMID sets
  the hint both in the file and the inode.

 block/bio.c  |2 ++
 block/blk-core.c |3 +++
 fs/btrfs/extent_io.c |1 +
 fs/btrfs/inode.c |1 +
 fs/buffer.c  |4 ++--
 fs/direct-io.c   |4 
 fs/ext4/page-io.c|1 +
 fs/inode.c   |1 +
 fs/mpage.c   |1 +
 fs/open.c|1 +
 fs/xfs/xfs_aops.c|1 +
 include/linux/blk_types.h|   28 +++-
 include/linux/fs.h   |   22 ++
 include/uapi/linux/fadvise.h |3 +++
 mm/fadvise.c |   25 +
 15 files changed, 95 insertions(+), 3 deletions(-)


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

[PATCH 6/7] xfs: add support for buffered writeback stream ID

[Jens Axboe]

Signed-off-by: Jens Axboe 
---
 fs/xfs/xfs_aops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 1d8eef9cf0f5..6d166e55de9a 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -376,6 +376,7 @@ xfs_submit_ioend_bio(
atomic_inc(>io_remaining);
bio->bi_private = ioend;
bio->bi_end_io = xfs_end_bio;
+   bio_set_streamid(bio, ioend->io_inode->i_streamid);
submit_bio(wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC : WRITE, bio);
 }
 
-- 
2.4.0.rc2.1.g3d6bc9a

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

[PATCH 1/7] block: add support for carrying a stream ID in a bio

[Jens Axboe]

The top bits of bio->bi_flags are reserved for keeping the
allocation pool, set aside the next eight bits for carrying
a stream ID. That leaves us with support for 255 streams,
0 is reserved as a "stream not set" value.

Add helpers for setting/getting stream ID of a bio.

Signed-off-by: Jens Axboe 
---
 block/bio.c   |  2 ++
 block/blk-core.c  |  3 +++
 include/linux/blk_types.h | 28 +++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/block/bio.c b/block/bio.c
index f66a4eae16ee..1cd3d745047c 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -567,6 +567,7 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio->bi_rw = bio_src->bi_rw;
bio->bi_iter = bio_src->bi_iter;
bio->bi_io_vec = bio_src->bi_io_vec;
+   bio_set_streamid(bio, bio_get_streamid(bio_src));
 }
 EXPORT_SYMBOL(__bio_clone_fast);
 
@@ -672,6 +673,7 @@ integrity_clone:
}
}
 
+   bio_set_streamid(bio, bio_get_streamid(bio_src));
return bio;
 }
 EXPORT_SYMBOL(bio_clone_bioset);
diff --git a/block/blk-core.c b/block/blk-core.c
index fd154b94447a..6276ce1ad46b 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1941,6 +1941,9 @@ void generic_make_request(struct bio *bio)
do {
struct request_queue *q = bdev_get_queue(bio->bi_bdev);
 
+   if (bio_streamid_valid(bio))
+   blk_add_trace_msg(q, "StreamID=%u", 
bio_get_streamid(bio));
+
q->make_request_fn(q, bio);
 
bio = bio_list_pop(current->bio_list);
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index a1b25e35ea5f..0678c7baa7b1 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -138,9 +138,35 @@ struct bio {
 #define BIO_POOL_BITS  (4)
 #define BIO_POOL_NONE  ((1UL << BIO_POOL_BITS) - 1)
 #define BIO_POOL_OFFSET(BITS_PER_LONG - BIO_POOL_BITS)
-#define BIO_POOL_MASK  (1UL << BIO_POOL_OFFSET)
 #define BIO_POOL_IDX(bio)  ((bio)->bi_flags >> BIO_POOL_OFFSET)
 
+/*
+ * after the pool bits, next 8 bits are for the stream id
+ */
+#define BIO_STREAM_BITS(8)
+#define BIO_STREAM_OFFSET  (BIO_POOL_OFFSET - BIO_STREAM_BITS)
+#define BIO_STREAM_MASK((1 << BIO_STREAM_BITS) - 1)
+
+static inline unsigned long streamid_to_flags(unsigned int id)
+{
+   return (unsigned long) (id & BIO_STREAM_MASK) << BIO_STREAM_OFFSET;
+}
+
+static inline void bio_set_streamid(struct bio *bio, unsigned int id)
+{
+   bio->bi_flags |= streamid_to_flags(id);
+}
+
+static inline unsigned int bio_get_streamid(struct bio *bio)
+{
+   return (bio->bi_flags >> BIO_STREAM_OFFSET) & BIO_STREAM_MASK;
+}
+
+static inline bool bio_streamid_valid(struct bio *bio)
+{
+   return bio_get_streamid(bio) != 0;
+}
+
 #endif /* CONFIG_BLOCK */
 
 /*
-- 
2.4.0.rc2.1.g3d6bc9a

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

[PATCH 2/7] Add support for per-file/inode stream ID

[Jens Axboe]

Writing on flash devices can be much more efficient, if we can
inform the device what kind of data can be grouped together. If
the device is able to group data together with similar lifetimes,
then it can be more efficient in garbage collection. This, in turn,
leads to lower write amplification, which is a win on both device
wear and performance.

Add a new fadvise hint, POSIX_FADV_STREAMID, which sets the file
and inode streamid. The file streamid is used if we have the file
available at the time of the write (O_DIRECT), we use the inode
streamid if not (buffered writeback). The fadvise hint uses the
'offset' field to specify a stream ID. A second
POSIX_FADV_FILE_STREAMID sets only the stream ID on the file,
not the inode.

Signed-off-by: Jens Axboe 
---
 fs/inode.c   |  1 +
 fs/open.c|  1 +
 include/linux/fs.h   | 22 ++
 include/uapi/linux/fadvise.h |  3 +++
 mm/fadvise.c | 25 +
 5 files changed, 52 insertions(+)

diff --git a/fs/inode.c b/fs/inode.c
index f00b16f45507..41885322ba64 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -149,6 +149,7 @@ int inode_init_always(struct super_block *sb, struct inode 
*inode)
inode->i_blocks = 0;
inode->i_bytes = 0;
inode->i_generation = 0;
+   inode->i_streamid = 0;
inode->i_pipe = NULL;
inode->i_bdev = NULL;
inode->i_cdev = NULL;
diff --git a/fs/open.c b/fs/open.c
index 6796f04d6032..979f34ff165b 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -743,6 +743,7 @@ static int do_dentry_open(struct file *f,
f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);
 
file_ra_state_init(>f_ra, f->f_mapping->host->i_mapping);
+   f->f_streamid = 0;
 
return 0;
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index c7496f263860..f43b866c3639 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -648,6 +648,7 @@ struct inode {
 #ifdef CONFIG_IMA
atomic_ti_readcount; /* struct files open RO */
 #endif
+   unsigned inti_streamid;
const struct file_operations*i_fop; /* former 
->i_op->default_file_ops */
struct file_lock_context*i_flctx;
struct address_spacei_data;
@@ -668,6 +669,14 @@ struct inode {
void*i_private; /* fs or device private pointer */
 };
 
+static inline unsigned int inode_streamid(struct inode *inode)
+{
+   if (inode)
+   return inode->i_streamid;
+
+   return 0;
+}
+
 static inline int inode_unhashed(struct inode *inode)
 {
return hlist_unhashed(>i_hash);
@@ -839,6 +848,7 @@ struct file {
 * Must not be taken from IRQ context.
 */
spinlock_t  f_lock;
+   unsigned intf_streamid;
atomic_long_t   f_count;
unsigned intf_flags;
fmode_t f_mode;
@@ -870,6 +880,18 @@ struct file_handle {
unsigned char f_handle[0];
 };
 
+/*
+ * If the file doesn't have a stream ID set, return the inode stream ID
+ * in case that has been set.
+ */
+static inline unsigned int file_streamid(struct file *f)
+{
+   if (f->f_streamid)
+   return f->f_streamid;
+
+   return inode_streamid(f->f_inode);
+}
+
 static inline struct file *get_file(struct file *f)
 {
atomic_long_inc(>f_count);
diff --git a/include/uapi/linux/fadvise.h b/include/uapi/linux/fadvise.h
index e8e747139b9a..e6e561db7f88 100644
--- a/include/uapi/linux/fadvise.h
+++ b/include/uapi/linux/fadvise.h
@@ -18,4 +18,7 @@
 #define POSIX_FADV_NOREUSE 5 /* Data will be accessed once.  */
 #endif
 
+#define POSIX_FADV_STREAMID8 /* associate stream ID with file+inode */
+#define POSIX_FADV_FILE_STREAMID 9 /* associate stream ID with file */
+
 #endif /* FADVISE_H_INCLUDED */
diff --git a/mm/fadvise.c b/mm/fadvise.c
index 4a3907cf79f8..a56e81840040 100644
--- a/mm/fadvise.c
+++ b/mm/fadvise.c
@@ -60,6 +60,8 @@ SYSCALL_DEFINE4(fadvise64_64, int, fd, loff_t, offset, 
loff_t, len, int, advice)
case POSIX_FADV_WILLNEED:
case POSIX_FADV_NOREUSE:
case POSIX_FADV_DONTNEED:
+   case POSIX_FADV_STREAMID:
+   case POSIX_FADV_FILE_STREAMID:
/* no bad return value, but ignore advice */
break;
default:
@@ -144,6 +146,29 @@ SYSCALL_DEFINE4(fadvise64_64, int, fd, loff_t, offset, 
loff_t, len, int, advice)
}
}
break;
+   case POSIX_FADV_STREAMID:
+   case POSIX_FADV_FILE_STREAMID:
+   /*
+* streamid is stored in offset... we don't limit or check
+* if the device supports streams, or if it does, if the
+* stream nr is within the limits. 1 is the lowest valid
+* stream id, 0 is "don't care/know".
+  

[PATCH 5/7] btrfs: add support for write stream IDs

[Jens Axboe]

Both buffered and O_DIRECT.

Signed-off-by: Jens Axboe 
Acked-by: Chris Mason  
---
 fs/btrfs/extent_io.c | 1 +
 fs/btrfs/inode.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index d688cfe5d496..2845fae054b6 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2838,6 +2838,7 @@ static int submit_extent_page(int rw, struct 
extent_io_tree *tree,
bio_add_page(bio, page, page_size, offset);
bio->bi_end_io = end_io_func;
bio->bi_private = tree;
+   bio_set_streamid(bio, inode_streamid(page->mapping->host));
 
if (bio_ret)
*bio_ret = bio;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 43192e10cc43..8ff7527e8d05 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8046,6 +8046,7 @@ static void btrfs_submit_direct(int rw, struct bio 
*dio_bio,
atomic_set(>pending_bios, 0);
btrfs_bio = btrfs_io_bio(io_bio);
btrfs_bio->logical = file_offset;
+   bio_set_streamid(io_bio, inode_streamid(inode));
 
if (write) {
io_bio->bi_end_io = btrfs_endio_direct_write;
-- 
2.4.0.rc2.1.g3d6bc9a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Error: DMA: Out of SW-IOMMU space [was: External USB drives become unresponsive after few hours.]

[Dorian Gray]

On 18 April 2015 at 12:10, Dorian Gray  wrote:
> On 17 April 2015 at 22:06, Konrad Rzeszutek Wilk  
> wrote:
>> On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
>>> On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk  
>>> wrote:
>>> > And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
>>> > and then load the attached module.
>>> >
>>> > That should tell you who and what else is holding on the buffers.
>>>
>>> Ok, I have compiled 3.19.4 w/ CONFIG_DMA_API_DEBUG=y + the module you sent 
>>> me.
>>> Now, I'm not sure if I've done it right - I waited until the error
>>> occured and then modprobe'd dump_dma.
>>> I have attached the kernel log, but it tells me not much, if anything...
>>
>> The network driver is quite hungry for DMA. Did it do the same thing
>> in the earlier kernels?
>>
>> Thanks.
>>>
>>> Thanks again.
>>> Jake
>>
>>
>
> Yeah, you're right:
>
> # grep rtl8192se dump_dma_k3.19.4.log | wc -l
> 6789
> #
> # grep rtl8192se dump_dma_k3.17.8.log | wc -l
> 162
> #
>
> So, wlan driver would be the real culprit then..?
> I would have never thought...
>
> I guess I'm gonna test 3.19.4 once more (just to be sure) with
> rtl8192se removed and see what happens.
>
> Thanks!
> Jake


[update]

Ok, 6 hours of uptime (3.19.4 + blacklisted rtl8192se) and everything
was fine...
However, I was checking periodically and noticed that 'radeon' also
tends to grow continuously over time, whereas ethernet driver sticks
to, more or less, the same range:

# uname -r
3.19.4
#
# grep -Eo 'radeon|r8169' L1.log | sort | uniq -c
 62 r8169
   4183 radeon
#
# grep -Eo 'radeon|r8169' L2.log | sort | uniq -c
 33 r8169
   5582 radeon
#
# grep -Eo 'radeon|r8169' L3.log | sort | uniq -c
 54 r8169
   7007 radeon
#
# grep -Eo 'radeon|r8169' L4.log | sort | uniq -c
 49 r8169
   7429 radeon
#
# grep -Eo 'radeon|r8169' L5.log | sort | uniq -c
 34 r8169
   9360 radeon
#

It doesn't grow that much in 3.17.8:

# uname -r
3.17.8
#
# grep -Eo 'radeon|r8169|rtl8192se' L1.log | sort | uniq -c
265 r8169
   1229 radeon
142 rtl8192se
#
# grep -Eo 'radeon|r8169|rtl8192se' L2.log | sort | uniq -c
187 r8169
   3159 radeon
124 rtl8192se
#
# grep -Eo 'radeon|r8169|rtl8192se' L3.log | sort | uniq -c
 41 r8169
   1894 radeon
 39 rtl8192se
#
# grep -Eo 'radeon|r8169|rtl8192se' L4.log | sort | uniq -c
 64 r8169
   3370 radeon
 77 rtl8192se
#
# grep -Eo 'radeon|r8169|rtl8192se' L5.log | sort | uniq -c
 52 r8169
   2597 radeon
 49 rtl8192se
#


Btw, at some point (3.19.4) I encounetered this:
[21631.181909] DMA-API: debugging out of memory - disabling

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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[Sowmini Varadhan]

> 
> Sowmini, I think I sorted this out in the 'sparc' GIT tree.
> 
> Can you take a look?

The patches look right now. These are the commit-ids I checked

  ff7d37a502022149655c18035b99a53391be0383
  bb620c3d3925aec0ed4f21010c86df08ec18a8c7
  0ae53ed15d9b87b883b593a9884957cfa4fc2480

--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] block: add support for carrying a stream ID in a bio

[Jens Axboe]

On 04/09/2015 04:46 PM, Andreas Dilger wrote:

On Mar 25, 2015, at 9:07 AM, Jens Axboe  wrote:


The top bits of bio->bi_flags are reserved for keeping the
allocation pool, set aside the next eight bits for carrying
a stream ID. That leaves us with support for 255 streams,
0 is reserved as a "stream not set" value.


I understand that the stream ID is not related to specific priority
of an IO request.  However, I'm wondering how this patch series
interacts with some of the other patch series that add cache priority
hints?  Is there a danger of running out of space in the IO pipeline
for the additional cache hints if this is using 8 bits?


That's always a risk, of course, but that goes for most features that 
need to carry more data in struct bio (or elsewhere). Otherwise we'll 
have to bite the bullet and add a new field.



+/*
+ * after the pool bits, next 8 bits are for the stream id
+ */
+#define BIO_STREAM_BITS(8)
+#define BIO_STREAM_OFFSET  (BITS_PER_LONG - 12)


Should this really be:

#define BIO_STREAM_OFFSET   (BIO_POOL_OFFSET - BIO_STREAM_BITS)

Otherwise there is a risk of conflict if someone changes BIO_POOL_BITS.


Good point, that would be cleaner. I'll make that change.

--
Jens Axboe

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

Re: [PATCH 2/7] Add support for per-file stream ID

[Jens Axboe]

On 04/09/2015 05:22 PM, Andreas Dilger wrote:

On Mar 25, 2015, at 9:07 AM, Jens Axboe  wrote:


Writing on flash devices can be much more efficient, if we can
inform the device what kind of data can be grouped together. If
the device is able to group data together with similar lifetimes,
then it can be more efficient in garbage collection. This, in turn,
leads to lower write amplification, which is a win on both device
wear and performance.

Add a new fadvise hint, POSIX_FADV_STREAMID, which sets the file
and inode streamid. The file streamid is used if we have the file
available at the time of the write (O_DIRECT), we use the inode
streamid if not (buffered writeback). The fadvise hint uses the
'offset' field to specify a stream ID.

Signed-off-by: Jens Axboe 
---
fs/inode.c   |  1 +
fs/open.c|  1 +
include/linux/fs.h   | 23 +++
include/uapi/linux/fadvise.h |  2 ++
mm/fadvise.c | 17 +
5 files changed, 44 insertions(+)

diff --git a/fs/inode.c b/fs/inode.c
index f00b16f45507..41885322ba64 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -149,6 +149,7 @@ int inode_init_always(struct super_block *sb, struct inode 
*inode)
inode->i_blocks = 0;
inode->i_bytes = 0;
inode->i_generation = 0;
+   inode->i_streamid = 0;
inode->i_pipe = NULL;
inode->i_bdev = NULL;
inode->i_cdev = NULL;
diff --git a/fs/open.c b/fs/open.c
index 33f9cbf2610b..4a9b2be1a674 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -743,6 +743,7 @@ static int do_dentry_open(struct file *f,
f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);

file_ra_state_init(>f_ra, f->f_mapping->host->i_mapping);
+   f->f_streamid = 0;

return 0;

diff --git a/include/linux/fs.h b/include/linux/fs.h
index b4d71b5e1ff2..43dde70c1d0d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -631,6 +631,7 @@ struct inode {
};

__u32   i_generation;
+   unsigned inti_streamid;


Since there are only 8 bits of streamid being passed from userspace,
is it possible to declare this as a char and pack it into a hole so
that it doesn't increase the inode size for a functionality that most
people won't be using?  Maybe after i_bytes?  That could be increased
to unsigned short if needed without increasing the size of the inode.


In the next version, I've retained the int, but ensured that they pack 
better in both struct file and struct inode. Basically fill some 
existing holes.


--
Jens Axboe

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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[Sowmini Varadhan]

On (04/18/15 15:40), David Miller wrote:
> 
> Sowmini, I think I sorted this out in the 'sparc' GIT tree.
> 
> Can you take a look?
> 

checking it right now.. give me a few minutes..

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

Re: [PATCH 03/21] nd_acpi: initial core implementation and nfit skeleton

[Paul Bolle]

On Fri, 2015-04-17 at 21:35 -0400, Dan Williams wrote:
> --- /dev/null
> +++ b/drivers/block/nd/Kconfig

> + depends on (X86 || IA64 || ARM || ARM64 || SH || XTENSA)

I've only skimmed this series. I still noticed this patch contains the
only Kconfig typo I know by heart. Because I think you meant to say:
depends on (X86 || IA64 || ARM || ARM64 || SUPERH || XTENSA)

Is that right?


Paul Bolle

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

Re: [RFC PATCH] fs: use a sequence counter instead of file_lock in fd_install

[Eric Dumazet]

On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote:
> On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> 
> > I would say this makes the use of seq counter impossible. Even if we
> > decided to fall back to a lock on retry, we cannot know what to do if
> > the slot is reserved - it very well could be that something called
> > close, and something else reserved the slot, so putting the file inside
> > could be really bad. In fact we would be putting a file for which we
> > don't have a reference anymore.
> > 
> > However, not all hope is lost and I still think we can speed things up.
> > 
> > A locking primitive which only locks stuff for current cpu and has
> > another mode where it locks stuff for all cpus would do the trick just
> > fine. I'm not a linux guy, quick search suggests 'lglock' would do what
> > I want.
> > 
> > table reallocation is an extremely rare operation, so this should be
> > fine. It would take the lock 'globally' for given table.
> 
> It would also mean percpu_alloc() for each descriptor table...

I would rather use an xchg() instead of rcu_assign_ponter()

old = xchg(>fd[fd], file);
if (unlikely(old))
filp_close(old, files);

If threads are using close() on random fds, final result is not
guaranteed anyway.


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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[David Miller]

From: David Miller 
Date: Sat, 18 Apr 2015 15:27:53 -0400 (EDT)

> Dammit, somehow I applied V4 :-/
> 
> Sorry about that.  I'll try to sort this out.

Sowmini, I think I sorted this out in the 'sparc' GIT tree.

Can you take a look?

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: Allowing reset controllers before SMP initialization (on ARM)?

[Arnd Bergmann]

On Thursday 16 April 2015 11:42:08 Maxime Coquelin wrote:
> Hi Florian, Arnd,
> 
> On 04/16/2015 10:04 AM, Arnd Bergmann wrote:
> > On Wednesday 15 April 2015 17:51:18 Florian Fainelli wrote:
> >> Hi,
> >>
> >> In order to support initialization of the secondary core on BCM63138
> >> SoCs, I would want to utilize a reset controller to release the
> >> secondary CPU from reset [1].
> >>
> >> Here are multiple options:
> >>
> >> - expose a custom function which registers the reset controller platform
> >> driver as early as possible, which is probably acceptable, but also
> >> requires the DT machine descriptor to populate the platform bus earlier,
> >> which we could completely avoid
> > I think populating the platform bus earlier is not realistic, that
> > would break lots of existing dependencies. In particular, we can't
> > do it much earlier because it has to be done after the platform bus
> > itself is instantiated.
> >
> >> - have a OF_DECLARE_RESET_CONTROLLER() which is running fairly early
> >> during boot, such that we can utilize reset controllers are early as
> >> possible,  before any initcall level, and before SMP initialization is
> >> kicking in
> > We've added a couple of those, and it could be done here, but putting
> > them in the right order is a bit tricky, and I think we can avoid it.
> 
> I have already proposed a OF_DECLARE_RESET_CONTROLLER() implementation:
> https://lkml.org/lkml/2015/2/20/395
> 
> I needed it for the STM32 timers, but it was not accepted.
> Now, I perform the timers reset in the bootloader, but it shouldn't work 
> in your case.

I guess if there is enough interest in this, we will eventually do it.
This is something we can change at any time without user-visible changes
or DT binding changes. The tradeoff is mainly that without 
OF_DECLARE_RESET_CONTROLLER(), we need a couple of hacks in early init
code, while adding too many of those OF_DECLARE_*() macros has the risk
that we won't be able to order them in a sane way that works on
all platforms, so I'm always reluctant about adding an extra one.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/21] nd_pmem: add NFIT support to the pmem driver

[Dan Williams]

On Fri, Apr 17, 2015 at 11:38 PM, Christoph Hellwig  wrote:
> On Fri, Apr 17, 2015 at 09:36:18PM -0400, Dan Williams wrote:
>> nd_pmem attaches to persistent memory regions and namespaces emitted by
>> the nd subsystem, and, same as the original pmem driver, presents the
>> system-physical-address range as a block device.
>
> I don't think there is any need to move the driver around.

At this point in the patch series I agree, but in later patches we
take advantage of nd bus services.  "[PATCH 15/21] nd: pmem label sets
and namespace instantiation" adds support for labeled pmem namespaces,
and in "[PATCH 19/21] nd: infrastructure for btt devices" we make pmem
capable of hosting btt instances.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] locking/rwsem: reduce spinlock contention in wakeup after up_read/up_write

[Peter Zijlstra]

On Fri, Apr 17, 2015 at 10:03:18PM -0400, Waiman Long wrote:
> @@ -478,7 +515,28 @@ struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
>  {
>   unsigned long flags;
>  
> - raw_spin_lock_irqsave(>wait_lock, flags);
> + /*
> +  * If a spinner is present, it is not necessary to do the wakeup.
> +  * Try to do wakeup only if the trylock succeeds to minimize
> +  * spinlock contention which may introduce too much delay in the
> +  * unlock operation.
> +  *
> +  * In case the spinning writer is just going to break out of the
> +  * waiting loop, it will still do a trylock in
> +  * rwsem_down_write_failed() before sleeping.
> +  * IOW, if rwsem_has_spinner() is true, it will guarantee at least
> +  * one trylock attempt on the rwsem.

successful trylock? I think we're having 'issues' on if failed trylocks
(and cmpxchg) imply full barriers.

> +  *
> +  *spinning writer
> +  *---
> +  * [S]   osq_unlock()
> +  *   MB
> +  * [RmW] rwsem_try_write_lock()
> +  */

Ordering comes in pairs, this is incomplete.

> + if (!rwsem_has_spinner(sem))
> + raw_spin_lock_irqsave(>wait_lock, flags);
> + else if (!raw_spin_trylock_irqsave(>wait_lock, flags))
> + return sem;
>  
>   /* do nothing if list empty */
>   if (!list_empty(>wait_list))
> -- 
> 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 v3 1/3] iio: configfs: Add configfs support to IIO

[Jonathan Cameron]

On 15/04/15 23:15, Octavian Purdila wrote:
> On Wed, Apr 15, 2015 at 2:34 PM, Jonathan Cameron  wrote:
>> On 15/04/15 21:58, Octavian Purdila wrote:
>>> On Sun, Apr 12, 2015 at 8:59 AM, Jonathan Cameron  wrote:
 On 10/04/15 14:43, Daniel Baluta wrote:
> On Thu, Apr 9, 2015 at 8:18 PM, Jonathan Cameron  wrote:
>> On 08/04/15 14:30, Daniel Baluta wrote:
>>> On Mon, Apr 6, 2015 at 5:18 PM, Daniel Baluta  
>>> wrote:
 This module is the core of IIO configfs. It creates the "iio" 
 subsystem under
 configfs mount point root, with one default group for "triggers".

 It offers basic interface for registering software trigger types. Next 
 patches
 will add "hrtimer" and "sysfs" trigger types. To add a new trigger 
 type we must
 create a new kernel module which implements iio_configfs_trigger.h 
 interface.

 See Documentation/iio/iio_configfs.txt for more details on how configfs
 support for IIO works.

 Signed-off-by: Daniel Baluta 
>>>
>>> Hi all,
>>>
>>> I also need your feedback on the following problem.
>>>
>>> We would like to be able to create hrtimer triggers from within
>>> a kernel module. There are cases where we don't have an interrupt
>>> pin or the interrupt pin is not connected, and we would like
>>> that applications to run unmodified with these types of sensors too.
>> A reasonable aim perhaps, as opposed to locally implemented polling
>> all over the place (which should definitely not happen).
>
> Yes, exactly! :)
 I'm actually beginning to have my doubts about whether my initial
 response here was right.  Given your use cases and the complexity
 of matching frequencies, I think you are almost always better
 off implementing it in the drivers themselves (which can decide
 if there is new data or not).
>>>
>>> I agree. Although I think having some helper functions in IIO core
>>> should help keep the driver modifications to a minimum.
>>>
>
>>
>> An alternative the zio guys used was to create timer
>> based triggers on the fly purely based on them being requested
>> (with an appropriate name IIRC)...  Doesn't quite solve your
>> problem though as still needs userspace changes.
>>>
>>> We will split the current design into 3 parts:
>>>
>>> (1) IIO trigger handling generic part, which offers an API
>>>  to register/unregister/get a reference to a trigger type
>>>
>>> (2) IIO configfs part that gets a reference to a trigger type and
>>> handles user requests to create/destroy a trigger.
>>>
>>> (3) IIO hrtimer driver that use the API at (1) for registering
>>> / deregistering a trigger type.
>>>
>>> Then, each driver in the case that it doesn't have a "real" trigger,
>>> will get a reference to a "hrtimer" trigger type and create
>>> a new "hrtimer" trigger.
>>>
>>> Does this look good to you? This could be easily done from
>>> userspace, but we will need to modify our userspace applications.
>> My initial thought is this really is a job for userspace, as should
>> be in most cases connecting up the device specific trigger as well
>> (as it's not always the right thing to use).
>>
>> In the general case it is far from obvious that an hrtimer is the
>> right option.  Many usecases would be better off with a sysfs trigger
>> or even running off a different interrupt based trigger entirely.
>>>
>>> Also, handling sampling_frequency/delay would be transparent to
>>> applications if we provide this in kernel API.
>> Not really as sampling frequency in this case should only be an
>> attribute of the trigger, not the device.  We only really allow
>> it for the device rather than always the triggers on the basis
>> that it has impacts on other device elements (events etc).
>
> Well, if the trigger is directly created from the driver then we will
> have a reference to a function that sets its delay.
>
> Each time the user sets the sampling frequency for the device
> with hit write_raw and there on IIO_CHAN_INFO_SAMP_FREQ
> case we also call set_delay(). Thus we always have have device
> sampling frequency in sync with trigger delay.
>
> I know this sounds crazy :) and I don't like it. I am not sure how
> to guarantee that device frequency is always in sync with trigger
> delay.
 You can't that I can see.  Hence you've convinced me this is a bad
 idea.
>>>
>>> I agree we can't accurately synchronize the device frequency with the
>>> trigger frequency, but I think we can get it do a good enough level. I
>>> also see no difference in accuracy in doing it from userspace or from
>>> the driver itself.
>>>
>>> Why do you think it is a bad idea to synchronize the trigger sample
>>> frequency from 

Re: [PATCH 00/21] ND: NFIT-Defined / NVDIMM Subsystem

[Dan Williams]

On Fri, Apr 17, 2015 at 6:35 PM, Dan Williams  wrote:
> Since 2010 Intel has included non-volatile memory support on a few
> storage-focused platforms with a feature named ADR (Asynchronous DRAM
> Refresh).  These platforms were mostly targeted at custom applications
> and never enjoyed standard discovery mechanisms for platform firmware
> to advertise non-volatile memory capabilities.  This now changes with
> the publication of version 6 of the ACPI specification [1] and its
> inclusion of a new table for describing platform memory capabilities.
> The NVDIMM Firmware Interface Table (NFIT), along with new EFI and E820
> memory types, enumerates persistent memory ranges, memory-mapped-I/O
> apertures, physical memory devices (DIMMs), and their associated
> properties.
>
> The ND-subsystem wraps a Linux device driver model around the objects
> and address boundaries defined in the specification and introduces 3 new
> drivers.
>
>   nd_pmem: NFIT enabled version of the existing 'pmem' driver [2]
>   nd_blk: mmio aperture method for accessing persistent storage
>   nd_btt: give persistent memory disk semantics (atomic sector update)
>
> See the documentation in patch2 for more details, and there is
> supplemental documentation on pmem.io [4].  Please review, and
> patches welcome...
>
> For kicking the tires, this release is accompanied by a userspace
> management library 'ndctl' that includes unit tests (make check) for all
> of the kernel ABIs.  The nfit_test.ko module can be used to explore a
> sample NFIT topology.
>
> [1]: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
> [2]: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/pmem
> [3]: https://github.com/pmem/ndctl
> [4]: http://pmem.io/documents/

nd.git and ndctl.git trees are now up to date.  I'll aim to keep
nd.git non-rebasing, but what eventually goes upstream is likely to be
a re-flowed patch set.  ndctl.git won't rebase.

nd.git: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git nd
ndctl.git: https://github.com/pmem/ndctl.git
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[David Miller]

From: Sowmini Varadhan 
Date: Sat, 18 Apr 2015 14:38:44 -0400

> On (04/18/15 11:28), Guenter Roeck wrote:
>> 
>> Some merge gone wrong, maybe ? I tried to revert f1600e549b94
>> and apply http://patchwork.ozlabs.org/patch/459803/ instead.
> 
> That patch is a part-2 of a 3-part patch set. In order, this should
> have been v10: applied as:
> 
>http://patchwork.ozlabs.org/patch/459804/
>http://patchwork.ozlabs.org/patch/459803/
>http://patchwork.ozlabs.org/patch/459802/
> 
> The mail thread for the 3-part patch set was here
>http://www.spinics.net/lists/sparclinux/msg13785.html
> 
> I noticed that the existing dates on the iommu commits were also odd:
> 
>   commit 671d773297969bebb1732e1cdc1ec03aa53c6be2
>   Author: Sowmini Varadhan 
>   Date:   Thu Mar 12 20:02:37 2015 -0400
> 
> 
>   commit f1600e549b948a32ad7672e069b2915314637ae3
>   Author: Sowmini Varadhan 
>   Date:   Thu Mar 12 20:02:36 2015 -0400
>   
>   commit 10b88a4b17d31a7409494b179dcb76e7ab2fcaea
>   Author: Sowmini Varadhan 
>   Date:   Thu Mar 12 20:02:35 2015 -0400
> 
> We have had many discussions of this patch set since March 12,
> and the correct version should have been v10, dated something
> after Apr 9, and acked by Benjamin Herrenschmidt.

Dammit, somehow I applied V4 :-/

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

Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)

[David Miller]

From: Sowmini Varadhan 
Date: Sat, 18 Apr 2015 08:05:10 -0400

> But when I clone 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git
> and do a git show of the commit-id above, I see deltas that
> dont make sense (they seem to be from a patchset from somewhere
> in the middle of the review chain from the thread). 
> 
> What am I missing? 

I am pretty sure I applied V10 of your IOMMU submission.

http://patchwork.ozlabs.org/patch/459804/
http://patchwork.ozlabs.org/patch/459803/
http://patchwork.ozlabs.org/patch/459802/

and follow-on parisc build fix:

http://patchwork.ozlabs.org/patch/461905/

if I somehow botched this up, wow that's impressive :-)

If you can sort out what I did wrong and send me a relative
fixup patch, I'd really appreciate it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/24] ILP32 for ARM64

[Arnd Bergmann]

On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote:
> More comments below.
> 
> > On 17 Apr 2015, at 16:46, Catalin Marinas  wrote:
> > 
> > Even in this case, we could enable AArch32 compat knowing that ioctls
> > wouldn't work. If this is important, we can add an option to enable
> > ioctl support for ILP32 and re-target the asm/compat.h definitions.
> > 
> >>  g) create a new ABI that does things in exactly the way that we
> >> would use as the native syscall interface if we had an ilp32
> >> kernel running on aarch64 with the asm-generic/unistd.h.
> >> This would mean a 32-bit __kernel_long_t and time_t, but extending
> >> time_t in the long run, together with aarch32 and i386.
> >> This one is particularly interesting for people that are interested
> >> in maximum posix compliance and in having a "nice" ABI, in particular
> >> if there is a slight chance that within the next decade we have
> >> reason to support building an arch/arm64 kernel itself in
> >> aarch64-ilp32 mode.
> 
> I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as 
> it
> has full support for 64bit arithmetic anyway.  I also believe that other 
> kernel 
> internals (e.g. filesystems and inode-numbering) would use native 64bit types.
> 
> The differences on the kernel side would mainly rest in that only a 32bit 
> address
> space could reasonably be managed. So a native ILP32 ABI would differ from
> the LP64 ABI mainly in how sizeof(long) is represented in the user-space.
> 
> In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit 
> time_t.

We normally like to all newly architectures to have an identical ABI though,
which I think would be more important here. 64-bit time_t of course is what
we want all architectures to have in principle, but we didn't do it for nios2
because of the added complexity. I think it's more likely to have no
__kernel_time_t to defined at some point and only provide __kernel_time64_t
in the future for new architectures, but we have not even introduced that.

>  However, it would be nice to get agreement on the normal 32-bit ABI
>  for time_t and timespec first, and then use the same thing everywhere.
> >>> 
> >>> Do you mean for native 32-bit architectures? I think OpenBSD uses a
> >>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well.
> >> 
> >> Yes, and I'm working on that for Linux. The first step involves fixing
> >> the kernel, one file at a time, changing all users of time_t to use
> >> some other type (ktime_t or time64_t in most cases) instead, and 
> >> introducing
> >> additional system calls to handle the boundary to user space without
> >> breaking stuff. See my presentation at 
> >> http://elinux.org/ELC_2015_Presentations
> >> for more detail.
> > 
> > The approach here is primarily to fix the problem for existing 32-bit
> > architectures by adding a new syscall and that's fine. But what if we
> > enforce 64-bit time_t for all _new_ architectures?
> 
> This boils down to whether we can define all the new syscalls _right now_ and
> get the new (extended) compat-layer set up. In this case we could have a 
> userspace 
> implementation that already conforms to this for ILP32.
> 
> Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate
> with everyone else.
> 
> Although it feels wrong to add another ABI that has a known limitation, this 
> may
> in fact be the easiest way, as any fix to ILP32 would be done together with 
> the
> fixes to all other 32bit ABIs.
> 
> So, while I would like to have a 64bit time_t for ILP32 based on principle, I 
> do see
> the 32bit time_t path as the most pragmatic way forward… especially, as this 
> unlinks
> getting “some form of” ILP32 merged from resolving the 64bit time_t issue 
> across
> all architectures.

Given Catalin's comments from yesterday, I think we can just fix the
definitions of 'struct stat64' for asm-generic to make it have the same
layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32.

Similarly for the four sysvipc headers, we can have a modified version of
the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout
for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver

[Arnd Bergmann]

On Friday 17 April 2015 02:50:07 Duc Dang wrote:
> +
> +   /*
> +* MSIINTn (n is 0..F) indicates if there is a pending MSI interrupt
> +* If bit x of this register is set (x is 0..7), one or more interupts
> +* corresponding to MSInIRx is set.
> +*/
> +   grp_select = readl(xgene_msi->msi_regs + MSI_INT0 + (msi_grp << 16));
> +   while (grp_select) {
> +   msir_index = ffs(grp_select) - 1;
> +   /*
> +* Calculate MSInIRx address to read to check for interrupts
> +* (refer to termination address and data assignment
> +* described in xgene_compose_msi_msg function)
> +*/
> +   msir_reg = (msi_grp << 19) + (msir_index << 16);
> +   msir_val = readl(xgene_msi->msi_regs + MSI_IR0 + msir_reg);
> +   while (msir_val) {
> +   intr_index = ffs(msir_val) - 1;
> +   /*
> +* Calculate MSI vector number (refer to the 
> termination
> +* address and data assignment described in
> +* xgene_compose_msi_msg function)
> +*/
> +   hw_irq = (((msir_index * IRQS_PER_IDX) + intr_index) *
> +NR_HW_IRQS) + msi_grp;
> +   virq = irq_find_mapping(xgene_msi->domain, hw_irq);
> +   if (virq != 0)
> +   generic_handle_irq(virq);
> +   msir_val &= ~(1 << intr_index);
> +   processed++;
> +   }
> +   grp_select &= ~(1 << msir_index);
> +   }
> 

As the MSI is forwarded to the GIC here, how do you maintain ordering
between DMA data getting forwarded from the PCI host bridge to RAM
with regard to the MSI handler getting entered from this code?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.10 00/34] 3.10.75-stable review

[Guenter Roeck]

On 04/18/2015 02:02 AM, Greg Kroah-Hartman wrote:

On Fri, Apr 17, 2015 at 01:00:10PM -0700, Guenter Roeck wrote:

On Fri, Apr 17, 2015 at 03:28:32PM +0200, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.75 release.
There are 34 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Apr 19 13:25:20 UTC 2015.
Anything received after that time might be too late.


Build results:
total: 125 pass: 124 fail: 1
Failed builds:
arm64:allmodconfig

Qemu test results:
total: 27 pass: 27 fail: 0

arm64:allmodconfig was added to the list of builds only recently;
the build failure is not new. Results are as expected.


Hm, any hint on how I can solve the build failure.  It's in my nature to
not want any failures :)



Hi Greg,

turns out it wasn't that difficult.

I sent a number of patch requests to sta...@vger.kernel.org to address
the build failures in both v3.10 and v3.14. You'll need to apply six patches
to v3.10, and three patches to v3.14. All but one of the patches for v3.14
apply cleanly; I sent you a backport for the one patch which doesn't.

Guenter

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

Re: [PATCH] iio: common: ssp_sensors: Fix uninitialized warning for timestamp

[Jonathan Cameron]

On 16/04/15 10:30, Karol Wrona wrote:
> calculated_time variable caused warning as uninitialized.  It was not harmful
> because it was evaluated in the path in which was used later but it is to
> satisfy the checkers.
> 
> Signed-off-by: Karol Wrona 
Dumb compiler. It's a false positive and as the function is an inline in the 
header,
it should be able to tell. 

What compiler is spitting out the warning?

> ---
>  drivers/iio/common/ssp_sensors/ssp_iio.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/common/ssp_sensors/ssp_iio.c 
> b/drivers/iio/common/ssp_sensors/ssp_iio.c
> index a3ae165..16180e6 100644
> --- a/drivers/iio/common/ssp_sensors/ssp_iio.c
> +++ b/drivers/iio/common/ssp_sensors/ssp_iio.c
> @@ -80,7 +80,7 @@ int ssp_common_process_data(struct iio_dev *indio_dev, void 
> *buf,
>   unsigned int len, int64_t timestamp)
>  {
>   __le32 time;
> - int64_t calculated_time;
> + int64_t calculated_time = 0;
>   struct ssp_sensor_data *spd = iio_priv(indio_dev);
>  
>   if (indio_dev->scan_bytes == 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: [RFC PATCH 2/2] tee: add OP-TEE driver

[Arnd Bergmann]

On Saturday 18 April 2015 20:49:03 Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 11:36:53AM +0200, Javier González wrote:
> > Hi,
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> > We have discussed and implemented an in-kernel interface for the driver.
> > However, we need to agree on that interface with the kernel submodules that
> > can be interested in using it (e.g., IMA, keyring). We though it was easier
> > to have a framework in place before taking this space. This makes sense
> > since a TEE driver will be, as for today, mostly used by user space.
> > applications.
> 
> No, please provide a "real" solution, just providing a framework that no
> one uses means that I get to delete it from the kernel tree the next
> release, and I doubt you want that 
> 
> Please do all of the work here, as odds are, what you need in the end
> will be different from what you have proposed here.

I guess an alternative would be to remove all the unused infrastructure
code and only provide a user space interface for the features that
op_tee requires, but no optional user interfaces or in-kernel interfaces.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tee: generic TEE subsystem

[Russell King - ARM Linux]

On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > +struct tee_device {
> > > > +   char name[TEE_MAX_DEV_NAME_LEN];
> > > > +   const struct tee_desc *desc;
> > > > +   struct device *dev;
> > > 
> > > No, please embed the device in your structure, don't have a pointer to
> > > it.
> > 
> > Greg, "dev" here is not a locally allocated device, but the parent device.
> > It's actually the same as struct tee_device.miscdev.parent, which could be
> > used instead and this member deleted.
> 
> A miscdev doesn't need to have a "parent", it's just there to provide a
> character device node to userspace, not to represent a "device that you
> can do things with in the heirachy".
> 
> If you really want that, then use a real 'struct device' as should be
> done here.  Have just a pointer to a misc device, that is meant to be
> dynamic.

Let's rewind.

You are saying that "struct device *dev;" should be "struct device dev;"

I'm saying that you are mis-interpreting in your review what _that_ is.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.19 000/101] 3.19.5-stable review

[Greg Kroah-Hartman]

On Fri, Apr 17, 2015 at 01:03:42PM -0700, Guenter Roeck wrote:
> On Fri, Apr 17, 2015 at 03:27:48PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.19.5 release.
> > There are 101 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 19 13:24:43 UTC 2015.
> > Anything received after that time might be too late.
> > 
> Build results:
>   total: 123 pass: 123 fail: 0
> Qemu test results:
>   total: 30 pass: 30 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

At least this one is good.  Thanks for the results and for testing.

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 6/7] perf data: Fix duplicate field names and avoid reserved keywords

[Jérémie Galarneau]

On Sat, Apr 18, 2015 at 11:50 AM, Jiri Olsa  wrote:
> From: Wang Nan 
>
> Some parameters of syscall tracepoints named as 'nr', 'event', etc.
> When dealing with them, perf convert to ctf meets some problem:
>
>  1. If a parameter with name 'nr', it will duplicate syscall's
> common field 'nr'. One such syscall is io_submit().
>
>  2. If a parameter with name 'event', it is denied to be inserted
> because 'event' is a babeltrace keywork. One such syscall is
> epoll_ctl.

Minor nitpick: "event" is a reserved keyword in the CTF specification
[1], the rule is only enforced by Babeltrace. Also, keywork ->
keyword.

Jérémie

[1] http://diamon.org/docs/ctf/v1.8.2/#specC.1.2

>
> This patch appends '_dupl_X' suffix to avoid problem 1, prepend a '_'
> prefix to avoid problem 2.
>
> Signed-off-by: Wang Nan 
> Link: http://lkml.kernel.org/n/tip-4tlh4s2u3xnxr76d1w7qm...@git.kernel.org
> [ changed to use format_file::alias ]
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/util/data-convert-bt.c | 86 
> +--
>  1 file changed, 82 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/data-convert-bt.c 
> b/tools/perf/util/data-convert-bt.c
> index b35c8d6c291d..8eda4ed628e7 100644
> --- a/tools/perf/util/data-convert-bt.c
> +++ b/tools/perf/util/data-convert-bt.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "asm/bug.h"
> @@ -184,6 +185,7 @@ static int add_tracepoint_field_value(struct ctf_writer 
> *cw,
> unsigned int len;
> int ret;
>
> +   name = fmtf->alias;
> offset = fmtf->offset;
> len = fmtf->size;
> if (flags & FIELD_IS_STRING)
> @@ -567,6 +569,82 @@ static int process_sample_event(struct perf_tool *tool,
> return cs ? 0 : -1;
>  }
>
> +/* If dup < 0, add a prefix. Else, add _dupl_X suffix. */
> +static char *change_name(char *name, char *orig_name, int dup)
> +{
> +   char *new_name = NULL;
> +   size_t len;
> +
> +   if (!name)
> +   name = orig_name;
> +
> +   if (dup >= 10)
> +   goto out;
> +   /*
> +* Add '_' prefix to potential keywork.  According to
> +* Mathieu Desnoyers (https://lkml.org/lkml/2015/1/23/652),
> +* futher CTF spec updating may require us to use '$'.
> +*/
> +   if (dup < 0)
> +   len = strlen(name) + sizeof("_");
> +   else
> +   len = strlen(orig_name) + sizeof("_dupl_X");
> +
> +   new_name = malloc(len);
> +   if (!new_name)
> +   goto out;
> +
> +   if (dup < 0)
> +   snprintf(new_name, len, "_%s", name);
> +   else
> +   snprintf(new_name, len, "%s_dupl_%d", orig_name, dup);
> +
> +out:
> +   if (name != orig_name)
> +   free(name);
> +   return new_name;
> +}
> +
> +static int event_class_add_field(struct bt_ctf_event_class *event_class,
> +   struct bt_ctf_field_type *type,
> +   struct format_field *field)
> +{
> +   struct bt_ctf_field_type *t = NULL;
> +   char *name;
> +   int dup = 1;
> +   int ret;
> +
> +   /* alias was already assigned */
> +   if (field->alias != field->name)
> +   return bt_ctf_event_class_add_field(event_class, type,
> +   (char *)field->alias);
> +
> +   name = field->name;
> +
> +   /* If 'name' is a keywork, add prefix. */
> +   if (bt_ctf_validate_identifier(name))
> +   name = change_name(name, field->name, -1);
> +
> +   if (!name) {
> +   pr_err("Failed to fix invalid identifier.");
> +   return -1;
> +   }
> +   while ((t = bt_ctf_event_class_get_field_by_name(event_class, name))) 
> {
> +   bt_ctf_field_type_put(t);
> +   name = change_name(name, field->name, dup++);
> +   if (!name) {
> +   pr_err("Failed to create dup name for '%s'\n", 
> field->name);
> +   return -1;
> +   }
> +   }
> +
> +   ret = bt_ctf_event_class_add_field(event_class, type, name);
> +   if (!ret)
> +   field->alias = name;
> +
> +   return ret;
> +}
> +
>  static int add_tracepoint_fields_types(struct ctf_writer *cw,
>struct format_field *fields,
>struct bt_ctf_event_class *event_class)
> @@ -595,14 +673,14 @@ static int add_tracepoint_fields_types(struct 
> ctf_writer *cw,
> if (flags & FIELD_IS_ARRAY)
> type = bt_ctf_field_type_array_create(type, 
> field->arraylen);
>
> -   ret = bt_ctf_event_class_add_field(event_class, type,
> -   field->name);
> +   ret = event_class_add_field(event_class, type, field);
>
> if (flags & FIELD_IS_ARRAY)
> 

Re: Read/write file from random(4) driver

[Greg KH]

On Sat, Apr 18, 2015 at 01:02:19PM -0400, Theodore Ts'o wrote:
> (Assuming you can get the embedded developers to use the latest
> version of the userspace distributions / frameworks, granted, which is
> not at all guaranteed, but they are more likely to use newer userspace
> than they are the latest kernels, due to the device driver issue.)

What "device driver issue" is keeping anyone on such old and obsolete
kernel versions?  BSPs that never submitted their code upstream?  Or
something else that is broken and no one has told us about?

thanks,

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

[GIT PULL] 9p: patches for the 4.1 merge window

[Eric Van Hensbergen]

The following changes since commit b314acaccd7e0d55314d96be4a33b5f50d0b3344:

  Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2015-03-19
16:43:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
tags/for-linus-4.1-merge-window

for you to fetch changes up to f569d3ef8254d4b3b8daa4f131f9397d48bf296c:

  net/9p: add a privport option for RDMA transport. (2015-03-21 19:32:33 -0700)


9p: patches for 4.1 merge window

Some accumulated cleanup patches for kerneldoc and unused variables
as well as some lock bug fixes and adding privateport option for RDMA.

A quick check shows some merge-conflicts versus current-tip on
   9p: use unsigned integers for nwqid/count
If you would prefer I can rebase, remerge and fix the patch but didn't
want to do that and look the for-next references.

Signed-off-by: Eric Van Hensbergen 


Andrey Ryabinin (1):
  net/9p: use memcpy() instead of snprintf() in p9_mount_tag_show()

Dominique Martinet (3):
  net/9p: Initialize opts->privport as it should be.
  fs/9p: Initialize status in v9fs_file_do_lock.
  net/9p: add a privport option for RDMA transport.

Fabian Frederick (2):
  9p: kerneldoc warning fixes
  9p: remove unused variable in p9_fd_create()

Kirill A. Shutemov (3):
  9p: fix error handling in v9fs_file_do_lock
  9p: do not crash on unknown lock status code
  9p: use unsigned integers for nwqid/count

 fs/9p/v9fs.h  |  1 -
 fs/9p/vfs_addr.c  |  2 --
 fs/9p/vfs_file.c  | 10 ++
 net/9p/protocol.c |  6 +++---
 net/9p/trans_fd.c |  3 +--
 net/9p/trans_rdma.c   | 52 +
 net/9p/trans_virtio.c |  5 -
 7 files changed, 58 insertions(+), 21 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] tee: add OP-TEE driver

[Greg Kroah-Hartman]

On Sat, Apr 18, 2015 at 11:36:53AM +0200, Javier González wrote:
> Hi,

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

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

> We have discussed and implemented an in-kernel interface for the driver.
> However, we need to agree on that interface with the kernel submodules that
> can be interested in using it (e.g., IMA, keyring). We though it was easier
> to have a framework in place before taking this space. This makes sense
> since a TEE driver will be, as for today, mostly used by user space.
> applications.

No, please provide a "real" solution, just providing a framework that no
one uses means that I get to delete it from the kernel tree the next
release, and I doubt you want that :)

Please do all of the work here, as odds are, what you need in the end
will be different from what you have proposed here.

thanks,

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