Re: [PATCH v2 3/5] ASoC: max9860: switch to SPDX license tag

[Christoph Hellwig]

On Fri, Apr 13, 2018 at 12:19:27PM +0100, Mark Brown wrote:
> On Thu, Apr 12, 2018 at 11:14:35PM +0200, Peter Rosin wrote:
> 
> > @@ -1,3 +1,4 @@
> > +// SPDX-License-Identifier: GPL-2.0
> >  /*
> >   * Driver for the MAX9860 Mono Audio Voice Codec
> >   *
> 
> Please don't mix C and C++ comments like this - it looks unintentional
> and messy.  Just convert the entire comment block to C++ so it's
> consistent with itself.

NAK - that is exactky the wrong way to go.  Normal Linux comments are
classi C-style comments and should remain so.  SPDX tags use c++
comments exactly to be different and stick out.



---end quoted text---

Re: [PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> Kconfig got text processing tools like we see in Make.  Add Kconfig
> helper macros to scripts/Kconfig.include like we collect Makefile
> macros in scripts/Kbuild.include.
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Kees Cook 
> Reviewed-by: Ulf Magnusson 
> ---
>
> Changes in v3:
>   - Move helpers to scripts/Kconfig.include
>
> Changes in v2: None
>
>  Kconfig |  2 ++
>  MAINTAINERS |  1 +
>  scripts/Kconfig.include | 17 +
>  3 files changed, 20 insertions(+)
>  create mode 100644 scripts/Kconfig.include
>
> diff --git a/Kconfig b/Kconfig
> index 5b55d87..a90d9f9 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
>
>  comment "Compiler: $(CC_VERSION_TEXT)"
>
> +source "scripts/Kconfig.include"
> +
>  source "arch/$(SRCARCH)/Kconfig"
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b9dab38..d962f4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
>  S: Maintained
>  F: Documentation/kbuild/kconfig*
>  F: scripts/kconfig/
> +F: scripts/Kconfig.include
>
>  KDUMP
>  M: Dave Young 
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> new file mode 100644
> index 000..cac7a81
> --- /dev/null
> +++ b/scripts/Kconfig.include
> @@ -0,0 +1,17 @@
> +# Kconfig helper macros
> +
> +# Convenient variables
> +comma   := ,
> +quote   := "
> +squote  := '
> +empty   :=
> +space   := $(empty) $(empty)
> +
> +# y if the command exits with 0, n otherwise
> +success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)

'{ $(1); }' might work here, to avoid the extra subshell.

Shaves 20-30% off the runtime here in a silly
system("(true) >/dev/null 2>&1 && echo y || echo n") vs.
system("{ true; } >/dev/null 2>&1 && echo y || echo n")
comparison.

> +
> +# y if the given compiler flag is supported, n otherwise
> +cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
> +
> +# y if the given linker flag is supported, n otherwise
> +ld-option = $(success $(LD) -v $(1))
> --
> 2.7.4
>

Cheers,
Ulf

[PATCH] lockdep: fix fs_reclaim annotation

[Omar Sandoval]

From: Omar Sandoval 

While revisiting my Btrfs swapfile series [1], I introduced a situation
in which reclaim would lock i_rwsem, and even though the swapon() path
clearly made GFP_KERNEL allocations while holding i_rwsem, I got no
complaints from lockdep. It turns out that the rework of the fs_reclaim
annotation was broken: if the current task has PF_MEMALLOC set, we don't
acquire the dummy fs_reclaim lock, but when reclaiming we always check
this _after_ we've just set the PF_MEMALLOC flag. In most cases, we can
fix this by moving the fs_reclaim_{acquire,release}() outside of the
memalloc_noreclaim_{save,restore}(), althought kswapd is slightly
different. After applying this, I got the expected lockdep splats.

1: https://lwn.net/Articles/625412/
Fixes: d92a8cfcb37e ("locking/lockdep: Rework FS_RECLAIM annotation")
Signed-off-by: Omar Sandoval 
---
 include/linux/sched/mm.h |  4 
 mm/page_alloc.c  | 20 +++-
 mm/vmscan.c  | 20 +---
 3 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 2c570cd934af..93294695688a 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -163,9 +163,13 @@ static inline gfp_t current_gfp_context(gfp_t flags)
 }
 
 #ifdef CONFIG_LOCKDEP
+extern void __fs_reclaim_acquire(void);
+extern void __fs_reclaim_release(void);
 extern void fs_reclaim_acquire(gfp_t gfp_mask);
 extern void fs_reclaim_release(gfp_t gfp_mask);
 #else
+static inline void __fs_reclaim_acquire(void) { }
+static inline void __fs_reclaim_release(void) { }
 static inline void fs_reclaim_acquire(gfp_t gfp_mask) { }
 static inline void fs_reclaim_release(gfp_t gfp_mask) { }
 #endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 905db9d7962f..ddcbcf8dae05 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3708,7 +3708,7 @@ should_compact_retry(struct alloc_context *ac, unsigned 
int order, int alloc_fla
 #endif /* CONFIG_COMPACTION */
 
 #ifdef CONFIG_LOCKDEP
-struct lockdep_map __fs_reclaim_map =
+static struct lockdep_map __fs_reclaim_map =
STATIC_LOCKDEP_MAP_INIT("fs_reclaim", &__fs_reclaim_map);
 
 static bool __need_fs_reclaim(gfp_t gfp_mask)
@@ -3733,17 +3733,27 @@ static bool __need_fs_reclaim(gfp_t gfp_mask)
return true;
 }
 
+void __fs_reclaim_acquire(void)
+{
+   lock_map_acquire(&__fs_reclaim_map);
+}
+
+void __fs_reclaim_release(void)
+{
+   lock_map_release(&__fs_reclaim_map);
+}
+
 void fs_reclaim_acquire(gfp_t gfp_mask)
 {
if (__need_fs_reclaim(gfp_mask))
-   lock_map_acquire(&__fs_reclaim_map);
+   __fs_reclaim_acquire();
 }
 EXPORT_SYMBOL_GPL(fs_reclaim_acquire);
 
 void fs_reclaim_release(gfp_t gfp_mask)
 {
if (__need_fs_reclaim(gfp_mask))
-   lock_map_release(&__fs_reclaim_map);
+   __fs_reclaim_release();
 }
 EXPORT_SYMBOL_GPL(fs_reclaim_release);
 #endif
@@ -3761,8 +3771,8 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
 
/* We now go into synchronous reclaim */
cpuset_memory_pressure_bump();
-   noreclaim_flag = memalloc_noreclaim_save();
fs_reclaim_acquire(gfp_mask);
+   noreclaim_flag = memalloc_noreclaim_save();
reclaim_state.reclaimed_slab = 0;
current->reclaim_state = &reclaim_state;
 
@@ -3770,8 +3780,8 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
ac->nodemask);
 
current->reclaim_state = NULL;
-   fs_reclaim_release(gfp_mask);
memalloc_noreclaim_restore(noreclaim_flag);
+   fs_reclaim_release(gfp_mask);
 
cond_resched();
 
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8b920ce3ae02..68ed72b52c59 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3299,11 +3299,15 @@ static int balance_pgdat(pg_data_t *pgdat, int order, 
int classzone_idx)
.may_unmap = 1,
.may_swap = 1,
};
+
+   __fs_reclaim_acquire();
+
count_vm_event(PAGEOUTRUN);
 
do {
unsigned long nr_reclaimed = sc.nr_reclaimed;
bool raise_priority = true;
+   bool ret;
 
sc.reclaim_idx = classzone_idx;
 
@@ -3376,7 +3380,10 @@ static int balance_pgdat(pg_data_t *pgdat, int order, 
int classzone_idx)
wake_up_all(&pgdat->pfmemalloc_wait);
 
/* Check if kswapd should be suspending */
-   if (try_to_freeze() || kthread_should_stop())
+   __fs_reclaim_release();
+   ret = try_to_freeze();
+   __fs_reclaim_acquire();
+   if (ret || kthread_should_stop())
break;
 
/*
@@ -3393,6 +3400,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int 
classzone_idx)
 
 out:
snapshot_refaults(NULL, pgdat);
+   __fs_reclaim_release();
/*
 * Return the order kswapd stopped re

Softlockup and Hardlockup sample test module

[Ivid Suvarna]

Hi All,

Could you please provide some sample test module for causing a
Softlockup and Hardlockup in latest kernel for SMP for testing
purposes. I assume there are some Kconfigs to be enabled as well for
this.

I had tried with the module where I put a busy loop inside spinlock
but was not able to cause any lockups. Maybe this is because of SMP
which schedule the job to other CPU. "How do I make a task to run on
single CPU only?"

I only get RCU stalls sometimes instead of softlockup when I use busy
loop inside a spinlock. Is there any explanation for difference
between these stalls and softlockup.

Thanks,
IVID

[GIT pull] irq updates for 4.17

[Thomas Gleixner]

Linus,

please pull the latest irq-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus

Another set of updates for the irq core:

  - Fix error path handling in the affinity spreading code

  - Make affinity spreading smarter to avoid issues on systems which claim
to have hotpluggable CPUs while in fact they can't hotplug anything. So
instead of trying to spread the vectors (and thereby the associated
device queues) to all possibe CPUs, spread them on all present CPUs
first. If there are left over vectors after that first step they are
spread among the possible, but not present CPUs which keeps the code
backwards compatible for virtual decives and NVME which allocate a
queue per possible CPU, but makes the spreading smarter for devices
which have less queues than possible or present CPUs.

Thanks,

tglx

-->
Ming Lei (4):
  genirq/affinity: Rename *node_to_possible_cpumask as *node_to_cpumask
  genirq/affinity: Move actual irq vector spreading into a helper function
  genirq/affinity: Allow irq spreading from a given starting point
  genirq/affinity: Spread irq vectors among present CPUs as far as possible

Thomas Gleixner (1):
  genirq/affinity: Don't return with empty affinity masks on error


 kernel/irq/affinity.c | 162 +-
 1 file changed, 106 insertions(+), 56 deletions(-)

diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index a37a3b4b6342..f4f29b9d90ee 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -39,7 +39,7 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
struct cpumask *nmsk,
}
 }
 
-static cpumask_var_t *alloc_node_to_possible_cpumask(void)
+static cpumask_var_t *alloc_node_to_cpumask(void)
 {
cpumask_var_t *masks;
int node;
@@ -62,7 +62,7 @@ static cpumask_var_t *alloc_node_to_possible_cpumask(void)
return NULL;
 }
 
-static void free_node_to_possible_cpumask(cpumask_var_t *masks)
+static void free_node_to_cpumask(cpumask_var_t *masks)
 {
int node;
 
@@ -71,7 +71,7 @@ static void free_node_to_possible_cpumask(cpumask_var_t 
*masks)
kfree(masks);
 }
 
-static void build_node_to_possible_cpumask(cpumask_var_t *masks)
+static void build_node_to_cpumask(cpumask_var_t *masks)
 {
int cpu;
 
@@ -79,14 +79,14 @@ static void build_node_to_possible_cpumask(cpumask_var_t 
*masks)
cpumask_set_cpu(cpu, masks[cpu_to_node(cpu)]);
 }
 
-static int get_nodes_in_cpumask(cpumask_var_t *node_to_possible_cpumask,
+static int get_nodes_in_cpumask(cpumask_var_t *node_to_cpumask,
const struct cpumask *mask, nodemask_t *nodemsk)
 {
int n, nodes = 0;
 
/* Calculate the number of nodes in the supplied affinity mask */
for_each_node(n) {
-   if (cpumask_intersects(mask, node_to_possible_cpumask[n])) {
+   if (cpumask_intersects(mask, node_to_cpumask[n])) {
node_set(n, *nodemsk);
nodes++;
}
@@ -94,73 +94,46 @@ static int get_nodes_in_cpumask(cpumask_var_t 
*node_to_possible_cpumask,
return nodes;
 }
 
-/**
- * irq_create_affinity_masks - Create affinity masks for multiqueue spreading
- * @nvecs: The total number of vectors
- * @affd:  Description of the affinity requirements
- *
- * Returns the masks pointer or NULL if allocation failed.
- */
-struct cpumask *
-irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
+static int irq_build_affinity_masks(const struct irq_affinity *affd,
+   int startvec, int numvecs,
+   cpumask_var_t *node_to_cpumask,
+   const struct cpumask *cpu_mask,
+   struct cpumask *nmsk,
+   struct cpumask *masks)
 {
-   int n, nodes, cpus_per_vec, extra_vecs, curvec;
-   int affv = nvecs - affd->pre_vectors - affd->post_vectors;
-   int last_affv = affv + affd->pre_vectors;
+   int n, nodes, cpus_per_vec, extra_vecs, done = 0;
+   int last_affv = affd->pre_vectors + numvecs;
+   int curvec = startvec;
nodemask_t nodemsk = NODE_MASK_NONE;
-   struct cpumask *masks;
-   cpumask_var_t nmsk, *node_to_possible_cpumask;
-
-   /*
-* If there aren't any vectors left after applying the pre/post
-* vectors don't bother with assigning affinity.
-*/
-   if (!affv)
-   return NULL;
-
-   if (!zalloc_cpumask_var(&nmsk, GFP_KERNEL))
-   return NULL;
-
-   masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
-   if (!masks)
-   goto out;
 
-   node_to_possible_cpumask = alloc_node_to_possible_cpumask();
-   if (!node_to_possible_cpumask)
-   goto out;
+   

Re: [PATCH 08/30] kconfig: add built-in function support

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> This commit adds a new concept 'function' to do more text processing
> in Kconfig.
>
> A function call looks like this:
>
>   $(function arg1, arg2, arg3, ...)
>
> This commit adds the basic infrastructure to expand functions.
> Change the text expansion helpers to take arguments.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3:
>   - Split base infrastructure and 'shell' function
> into separate patches.
>
> Changes in v2:
>   - Use 'shell' for getting stdout from the comment.
> It was 'shell-stdout' in the previous version.
>   - Symplify the implementation since the expansion has been moved to
> lexer.
>
>  scripts/kconfig/preprocess.c | 142 
> +++
>  1 file changed, 130 insertions(+), 12 deletions(-)
>
> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
> index fa4abc8..e77cf7c 100644
> --- a/scripts/kconfig/preprocess.c
> +++ b/scripts/kconfig/preprocess.c
> @@ -8,6 +8,10 @@
>
>  #include "list.h"
>
> +#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
> +
> +static char *expand_string_with_args(const char *in, int argc, char *argv[]);
> +
>  /*
>   * Environment variables
>   */
> @@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
> }
>  }
>
> -static char *eval_clause(const char *in)
> +/*
> + * Built-in Functions
> + */
> +struct function {
> +   char *name;
> +   char *(*func)(int argc, char *argv[]);
> +};
> +
> +static const struct function function_table[] = {
> +};
> +
> +static char *function_call(const char *name, int argc, char *argv[])
>  {
> -   char *res, *name;
> +   const struct function *f;
> +   int i;
> +
> +   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
> +   f = &function_table[i];
> +   if (!strcmp(f->name, name))
> +   return f->func(argc, argv);
> +   }
> +
> +   return NULL;
> +}
> +
> +#define FUNCTION_MAX_ARGS  16
> +
> +/*
> + * Evaluate a clause with arguments.  argc/argv are arguments from the upper
> + * function call.
> + *
> + * Returned string must be freed when done
> + */
> +static char *eval_clause(const char *in, int argc, char *argv[])
> +{
> +   char *tmp, *prev, *p, *res, *name;
> +   char delim = ' ';
> +   int new_argc = 0;
> +   char *new_argv[FUNCTION_MAX_ARGS];
> +   int nest = 0;
> +   int i;
>
> /*
>  * Returns an empty string because '$()' should be evaluated
> @@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
> if (!*in)
> return xstrdup("");
>
> -   name = expand_string(in);
> +   tmp = xstrdup(in);
> +
> +   prev = p = tmp;
>
> -   res = env_expand(name);
> +   /*
> +* Split into tokens
> +* The function name and the first argument are separated by a space.
> +* Arguments are separated by a comma.
> +* For example, if the function call is like this:
> +*   $(foo abc,$(x),$(y))
> +*
> +* The input string for this helper should be:
> +*   foo abc,$(x),$(y)
> +*
> +* and split into:
> +*   new_argv[0]: foo
> +*   new_argv[1]: abc
> +*   new_argv[2]: $(x)
> +*   new_argv[3]: $(y)
> +*/
> +   while (*p) {
> +   if (nest == 0 && *p == delim) {
> +   *p = 0;
> +   new_argv[new_argc++] = prev;

Erroring out would be nicer than overflowing the array.

Cheers,
Ulf

Re: [PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

[Ulf Magnusson]

On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
 wrote:
> Add a document for the macro language introduced to Kconfig.
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile.  A number of kernel features require the
> compiler support.  Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles.  If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it.
>
> This change was strongly prompted by Linus Torvalds.  You can find
> his suggestions [1] [2] in ML.  The original idea was to add a new
> 'option', but I found generalized text expansion would make Kconfig
> more powerful and lovely.  While polishing up the implementation, I
> noticed sort of similarity between Make and Kconfig.  This might be
> too immature to be called 'language', but anyway here it is.  All
> ideas are from Make (you can even say it is addicted), so people
> will easily understand how it works.
>
> [1]: https://lkml.org/lkml/2016/12/9/577
> [2]: https://lkml.org/lkml/2018/2/7/527
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  Documentation/kbuild/kconfig-macro-language.txt | 179 
> 
>  MAINTAINERS |   2 +-
>  2 files changed, 180 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
>
> diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
> b/Documentation/kbuild/kconfig-macro-language.txt
> new file mode 100644
> index 000..1f6281b
> --- /dev/null
> +++ b/Documentation/kbuild/kconfig-macro-language.txt
> @@ -0,0 +1,179 @@
> +Concept
> +---
> +
> +The basic idea was inspired by Make. When we look at Make, we notice sort of
> +two languages in one. One language describes dependency graphs consisting of
> +targets and prerequisites. The other is a macro language for performing 
> textual
> +substitution.
> +
> +There is clear distinction between the two language stages. For example, you
> +can write a makefile like follows:
> +
> +APP := foo
> +SRC := foo.c
> +CC := gcc
> +
> +$(APP): $(SRC)
> +$(CC) -o $(APP) $(SRC)
> +
> +The macro language replaces the variable references with their expanded form,
> +and handles as if the source file were input like follows:
> +
> +foo: foo.c
> +gcc -o foo foo.c
> +
> +Then, Make analyzes the dependency graph and determines the targets to be
> +updated.
> +
> +The idea is quite similar in Kconfig - it is possible to describe a Kconfig
> +file like this:
> +
> +CC := gcc
> +
> +config CC_HAS_FOO
> +def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
> +
> +The macro language in Kconfig processes the source file into the following
> +intermediate:
> +
> +config CC_HAS_FOO
> +def_bool y
> +
> +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> +dependency, which is explained in kconfig-language.txt.
> +
> +
> +Variables
> +-
> +
> +Like in Make, a variable in Kconfig works as a macro variable.  A macro
> +variable is expanded "in place" to yield a text string that may then expanded
> +further. To get the value of a variable, enclose the variable name in $( ).
> +As a special case, single-letter variable names can omit the parentheses and 
> is
> +simply referenced like $X. Unlike Make, Kconfig does not support curly braces
> +as in ${CC}.

Do we need single-letter variable names for anything? It looks like
we're deviating
a bit from Make behavior already.

I suspect they're just a side effect of Make having automatic variables like $@.
The Make manual discourages them otherwise:

"A dollar sign followed by a character other than a dollar sign,
open-parenthesis or
open-brace treats that single character as the variable name. Thus, you could
reference the variable x with `$x'. However, this practice is strongly
discouraged,
except in the case of the automatic variables (see section Automatic
Variables)."

Cheers,
Ulf

Re: [PATCH 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

[Greg Kroah-Hartman]

On Fri, Apr 13, 2018 at 03:07:18PM +0200, Steffen Maier wrote:
> Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block
> trace points to TRACE_EVENT()") to be equivalent to traditional blktrace
> output. Also this allows event filtering to not always get all (un)plug
> events.
> 
> NB: The NULL pointer check for q->kobj.parent is certainly racy and
> I don't have enough experience if it's good enough for a trace event.
> The change did work for my cases (block device read/write I/O on
> zfcp-attached SCSI disks and dm-mpath on top).
> 
> While I haven't seen any prior art using driver core (parent) relations
> for trace events, there are other cases using this when no direct pointer
> exists between objects, such as:
>  #define to_scsi_target(d)container_of(d, struct scsi_target, dev)
>  static inline struct scsi_target *scsi_target(struct scsi_device *sdev)
>  {
>   return to_scsi_target(sdev->sdev_gendev.parent);
>  }

That is because you "know" the parent of a target device is a
scsi_target.

> This is the object model we make use of here:
> 
> struct gendisk {
> struct hd_struct {
> struct device {  /*container_of*/
> struct kobject kobj; <--+
> dev_t  devt; /*deref*/  |
> } __dev;|
> } part0;|
> struct request_queue *queue; ..+|
> }  :|
>:|
> struct request_queue {  <..+|
> /* queue kobject */ |
> struct kobject {|
> struct kobject *parent; +

Are you sure about this?

> } kobj;
> }
> 
> The parent pointer comes from:
>  #define disk_to_dev(disk)(&(disk)->part0.__dev)
> int blk_register_queue(struct gendisk *disk)
>   struct device *dev = disk_to_dev(disk);
>   struct request_queue *q = disk->queue;
>   ret = kobject_add(&q->kobj, kobject_get(&dev->kobj), "%s", "queue");
>   ^^^parent
> 
> $ ls -d /sys/block/sdf/queue
> /sys/block/sda/queue
> $ cat /sys/block/sdf/dev
> 80:0
> 
> A partition does not have its own request queue:
> 
> $ cat /sys/block/sdf/sdf1/dev
> 8:81
> $ ls -d /sys/block/sdf/sdf1/queue
> ls: cannot access '/sys/block/sdf/sdf1/queue': No such file or directory
> 
> The difference to blktrace parsed output is that block events don't use the
> partition's minor number but the containing block device's minor number:

Why do you want the block device's minor number here?  What is wrong
with the partition's minor number?  I would think you want that instead.

> 
> $ dd if=/dev/sdf1 count=1
> 
> $ cat /sys/kernel/debug/tracing/trace
> block_bio_remap: 8,80 R 2048 + 32 <- (8,81) 0
> block_bio_queue: 8,80 R 2048 + 32 [dd]
> block_getrq: 8,80 R 2048 + 32 [dd]
> block_plug: 8,80 [dd]
> 
> block_rq_insert: 8,80 R 16384 () 2048 + 32 [dd]
> block_unplug: 8,80 [dd] 1 explicit
>   
> block_rq_issue: 8,80 R 16384 () 2048 + 32 [dd]
> block_rq_complete: 8,80 R () 2048 + 32 [0]
> 
> $ btrace /dev/sdf1
>   8,80   11 0.0 240240  A   R 2048 + 32 <- (8,81) 0
>   8,81   12 0.000220890 240240  Q   R 2048 + 32 [dd]
>   8,81   13 0.000229639 240240  G   R 2048 + 32 [dd]
>   8,81   14 0.000231805 240240  P   N [dd]
> ^^
>   8,81   15 0.000234671 240240  I   R 2048 + 32 [dd]
>   8,81   16 0.000236365 240240  U   N [dd] 1
> ^^
>   8,81   17 0.000238527 240240  D   R 2048 + 32 [dd]
>   8,81   22 0.000613741 0  C   R 2048 + 32 [0]
> 
> Signed-off-by: Steffen Maier 
> ---
>  include/trace/events/block.h | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/include/trace/events/block.h b/include/trace/events/block.h
> index a13613d27cee..cffedc26e8a3 100644
> --- a/include/trace/events/block.h
> +++ b/include/trace/events/block.h
> @@ -460,14 +460,18 @@ TRACE_EVENT(block_plug,
>   TP_ARGS(q),
>  
>   TP_STRUCT__entry(
> + __field( dev_t, dev )
>   __array( char,  comm,   TASK_COMM_LEN   )
>   ),
>  
>   TP_fast_assign(
> + __entry->dev = q->kobj.parent ?
> + container_of(q->kobj.parent, struct device, kobj)->devt : 0;

That really really really scares me.  It feels very fragile and messing
with parent pointers is ripe for things breaking in the future in odd
and unexplainable ways.

And how can the parent be NULL?

>   memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
>   ),
>  
> - TP_printk("[%s]", __entry->comm)
> + TP_printk("%d,%d [%s]",
> +   MAJOR(__entry->dev), MINOR(__entry->dev), __entry->comm)
>  );
>  
>  #define show_block_unplug_explicit(val) 

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

[Takashi Iwai]

On Thu, 12 Apr 2018 12:32:54 +0200,
Robin Murphy wrote:
> 
> On 12/04/18 09:27, Takashi Iwai wrote:
> > On Thu, 12 Apr 2018 10:19:05 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Thu, 12 Apr 2018 10:03:56 +0200,
> >> Takashi Iwai wrote:
> >>>
> >>> On Thu, 12 Apr 2018 08:02:27 +0200,
> >>> Christoph Hellwig wrote:
> 
>  On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> >> But we should try a GFP_DMA32 allocation first, so this is a bit
> >> surprising.
> >
> > Hm, do we really try that?
> > Through a quick glance, dma_alloc_coherent_gfp_flags() gives GFP_DMA32
> > only when coherent mask <= DMA_BIT_MASK(32); in the case of iwlwifi,
> > it's 36bit, so GFP_DMA isn't set.
> 
>  Oh, yes - it is using an odd dma mask, and amdgpu seems to use an
>  just as odd 40-bit dma mask.
> 
> > We had a fallback allocation with GFP_DMA32 in the past, but this
> > seems gone long time ago along with cleanups (commit c647c3bb2d16).
> >
> > But I haven't followed about this topic for long time, so I might have
> > missed obviously...
> 
>  I think a fallback would be much better here rather than relying on the
>  limited swiotlb buffer bool.  dma_direct_alloc (which in 4.17 is also
>  used for x86) already has a GFP_DMA fallback, so extending this for
>  GFP_DMA32 as well would seem reasonable.
> 
>  Any volunteers?
> >>>
> >>> Below is a quick attempt, totally untested.  Actually the retry with
> >>> GFP_DMA is superfluous for archs without it, so the first patch
> >>> corrects it.
> >>
> >> Gah, scratch this, it doesn't work.  A different check is needed...
> >
> > The v2 patches are below, replaced with IS_ENABLED(CONFIG_ZONE_DMA).
> 
> That looks pretty reasonable to me - I'd be tempted to try a factoring
> out a helper function to avoid the "goto again" logic, but that's
> hardly crucial.

Right, this change won't make the code flow more complex than before,
so I guess it's OK as a first step.

I'll submit this second patch as RFC while the first one as a safe
fix (in addition to another regression fix I stumbled on).

> What I'd really love to see is something like the alloc_pages_mask()
> proposal from years ago to come back such that GFP_DMA32 could die
> entirely, but I don't know anywhere near enough about the mm layer to
> consider taking that on myself :(

Yeah, it'd be lovely, but I'm afraid it's hard to fly high...


thanks,

Takashi

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Eduardo Valentin]

On Fri, Apr 13, 2018 at 12:27:17PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 13, 2018 03:08:03 AM Eduardo Valentin wrote:
> > On Fri, Apr 13, 2018 at 01:39:05PM +0800, Zhang Rui wrote:
> > > Hi, Eduardo,
> > > 
> > > On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > > > Hello,
> > > > 
> > > > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > > > > 
> > > > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > could you please illustrate me what the kconfig & warning is?
> > > > > Just "make allmodconfig" and the warning is about a uninitialized
> > > > > variable.
> > > > > 
> > > > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > > > > history
> > > > > is to be believed.
> > > > > 
> > > > > Linus
> > > > Yeah, this has also passed my local compilation error. Somehow my
> > > > gcc4.9
> > > > is not catching it. Using an older gcc (gcc4.6) does catch it.
> > > > 
> > > > Anyways, given that the conversion functions are written to cover
> > > > for unexpected cal_type, the right way of fixing this is to rewrite
> > > > the conversion functions to allow for returning error codes and
> > > > adjusting the callers as expected.
> > > > 
> > > > Rui, bzolnier, please consider the following fix:
> > > > 
> > > as it is late in this merge window, I'd prefer to
> > > 1. drop all the thermal-soc material in the first pull request which I
> > > will send out soon.
> > > 2. you can prepare another pull request containing the thermal-soc
> > > materials except the exynos fixes
> > > 3. exynos fixes with the problem solved can be queued for -rc2 or
> > > later.
> > > 
> > 
> > Agreed
> 
> What should I do now to help resolve the issue?

Please resend your series with the patches without the warnings..

Thanks,

Eduardo

[PATCH 0/2] swiotlb: Some regression fixes

[Takashi Iwai]

Hi,

this is a couple of small regression fixes I stumbled on recently.
The first one is a trivial one, and it was already posted in another
thread ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").


thanks,

Takashi

===

Takashi Iwai (2):
  dma-direct: Don't repeat allocation for no-op GFP_DMA
  swiotlb: Fix dma_supported() to consider direct allocation

 lib/dma-direct.c | 3 ++-
 lib/swiotlb.c| 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.16.3

[PATCH 2/2] swiotlb: Fix dma_supported() to consider direct allocation

[Takashi Iwai]

Along with the recent change to use the common swiotlb dma_ops, x86
also takes over the swiotlb_dma_supported().  This caused a regression
when a low bit DMA mask is set; e.g. parport_pc driver now fails to
set the 24bit DMA mask:

  parport_pc parport_pc.956: Unable to set coherent dma mask: disabling DMA

It's because swiotlb_dma_supported() only checks the swiotlb range,
and the 24bit DMA mask is below io_tlb_end.  OTOH, in the past kernel
versions, x86's swiotlb dma_supported() was NULL, which was
effectively evaluated as the direct DMA, hence the lower DMA mask was
allowed.

This patch fixes the regression by extending swiotlb_dma_supported()
to check the direct DMA at first for covering the primary allocation
before swiotlb.

Fixes: 6e4bf5867783 ("x86/dma: Use generic swiotlb_ops")
Signed-off-by: Takashi Iwai 
---
 lib/swiotlb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index de7cc540450f..a81502ea79e7 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -1042,6 +1042,10 @@ swiotlb_dma_mapping_error(struct device *hwdev, 
dma_addr_t dma_addr)
 int
 swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
+#ifdef CONFIG_DMA_DIRECT_OPS
+   if (dma_direct_supported(hwdev, mask))
+   return 1;
+#endif
return __phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
 }
 
-- 
2.16.3

[PATCH 1/2] dma-direct: Don't repeat allocation for no-op GFP_DMA

[Takashi Iwai]

When an allocation with lower dma_coherent mask fails,
dma_direct_alloc() retries the allocation with GFP_DMA.  But, it's
useless for architectures that has no ZONE_DMA, obviously.

Fix it by adding the check of CONFIG_ZONE_DMA before retrying the
allocation.

Fixes: 95f183916d4b ("dma-direct: retry allocations using GFP_DMA for small 
masks")
Signed-off-by: Takashi Iwai 
---
 lib/dma-direct.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index c0bba30fef0a..bbfb229aa067 100644
--- a/lib/dma-direct.c
+++ b/lib/dma-direct.c
@@ -84,7 +84,8 @@ void *dma_direct_alloc(struct device *dev, size_t size, 
dma_addr_t *dma_handle,
__free_pages(page, page_order);
page = NULL;
 
-   if (dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
+   if (IS_ENABLED(CONFIG_ZONE_DMA) &&
+   dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
!(gfp & GFP_DMA)) {
gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
goto again;
-- 
2.16.3

[GIT PULL] final round of SCSI updates for the 4.16+ merge window

[James Bottomley]

This is a set of minor (and safe changes) that didn't make the initial
pull request plus some bug fixes.  The status handling code is actually
a running regression from the previous merge window which had an
incomplete fix (now reverted) and most of the remaining bug fixes are
for problems older than the current merge window.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (3):
  scsi: core: Make scsi_result_to_blk_status() recognize CONDITION MET
  scsi: core: Rename __scsi_error_from_host_byte() into 
scsi_result_to_blk_status()
  Revert "scsi: core: return BLK_STS_OK for DID_OK in 
__scsi_error_from_host_byte()"

Ben Hutchings (2):
  scsi: qla2xxx: Fix race condition between iocb timeout and initialisation
  scsi: qla2xxx: Avoid double completion of abort command

Bill Kuzeja (1):
  scsi: qla2xxx: Fix small memory leak in qla2x00_probe_one on probe failure

Colin Ian King (1):
  scsi: core: remove redundant assignment to shost->use_blk_mq

Dan Carpenter (2):
  scsi: cxgb4i: silence overflow warning in t4_uld_rx_handler()
  scsi: dpt_i2o: Use after free in I2ORESETCMD ioctl

Dave Carroll (1):
  scsi: aacraid: Insure command thread is not recursively stopped

Johannes Thumshirn (3):
  scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION
  scsi: qla2xxx: correctly shift host byte
  scsi: scsi_dh: Don't look for NULL devices handlers by name

Ross Lagerwall (1):
  scsi: devinfo: Add Microsoft iSCSI target to 1024 sector blacklist

And the diffstat:

 drivers/scsi/aacraid/commsup.c |  4 +++-
 drivers/scsi/aacraid/linit.c   |  1 +
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |  8 +++
 drivers/scsi/dpt_i2o.c | 13 ++-
 drivers/scsi/hosts.c   |  1 -
 drivers/scsi/qla2xxx/qla_gs.c  | 12 ++-
 drivers/scsi/qla2xxx/qla_init.c| 41 +--
 drivers/scsi/qla2xxx/qla_inline.h  |  2 +-
 drivers/scsi/qla2xxx/qla_iocb.c|  8 ---
 drivers/scsi/qla2xxx/qla_isr.c |  8 +++
 drivers/scsi/qla2xxx/qla_mbx.c |  8 +++
 drivers/scsi/qla2xxx/qla_mid.c |  2 +-
 drivers/scsi/qla2xxx/qla_mr.c  |  5 +++--
 drivers/scsi/qla2xxx/qla_os.c  | 44 ++
 drivers/scsi/qla2xxx/qla_target.c  |  2 +-
 drivers/scsi/scsi_devinfo.c|  2 +-
 drivers/scsi/scsi_dh.c |  3 +++
 drivers/scsi/scsi_lib.c| 27 ++-
 18 files changed, 109 insertions(+), 82 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 84858d5c8257..0156c9623c35 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1502,9 +1502,10 @@ static int _aac_reset_adapter(struct aac_dev *aac, int 
forced, u8 reset_type)
host = aac->scsi_host_ptr;
scsi_block_requests(host);
aac_adapter_disable_int(aac);
-   if (aac->thread->pid != current->pid) {
+   if (aac->thread && aac->thread->pid != current->pid) {
spin_unlock_irq(host->host_lock);
kthread_stop(aac->thread);
+   aac->thread = NULL;
jafo = 1;
}
 
@@ -1591,6 +1592,7 @@ static int _aac_reset_adapter(struct aac_dev *aac, int 
forced, u8 reset_type)
  aac->name);
if (IS_ERR(aac->thread)) {
retval = PTR_ERR(aac->thread);
+   aac->thread = NULL;
goto out;
}
}
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 2664ea0df35f..f24fb942065d 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1562,6 +1562,7 @@ static void __aac_shutdown(struct aac_dev * aac)
up(&fib->event_wait);
}
kthread_stop(aac->thread);
+   aac->thread = NULL;
}
 
aac_send_shutdown(aac);
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 406e94312d4e..211da1d5a869 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -2108,12 +2108,12 @@ static int t4_uld_rx_handler(void *handle, const __be64 
*rsp,
log_debug(1 << CXGBI_DBG_TOE,
"cdev %p, opcode 0x%x(0x%x,0x%x), skb %p.\n",
 cdev, opc, rpl->ot.opcode_tid, ntohl(rpl->ot.opcode_tid), skb);
-   if (cxgb4i_cplhandlers[opc])
-   cxgb4i_cplhandlers[opc](cdev, skb);
-   else {
+   if (opc >= ARRAY_SIZE(cxgb4i_cplhandlers) || !cxgb4i_cplhandlers[opc]) {
pr_err("No handler for opcode 0x%x.\n", opc);
__kfree_skb(skb);
-   }
+   } else
+   cxgb4i_cplhandlers[opc](cdev, skb);
+
return 0;
 nomem:
 

[PATCH 1/3] perf: Return proper values for user stack errors

[Jiri Olsa]

Return immediately when we find issue in the user
stack checks. The error value could get overwritten
by following check for PERF_SAMPLE_REGS_INTR.

Signed-off-by: Jiri Olsa 
---
 kernel/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index fc1c330c6bd6..4d997bc064d2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10191,9 +10191,9 @@ static int perf_copy_attr(struct perf_event_attr __user 
*uattr,
 * __u16 sample size limit.
 */
if (attr->sample_stack_user >= USHRT_MAX)
-   ret = -EINVAL;
+   return -EINVAL;
else if (!IS_ALIGNED(attr->sample_stack_user, sizeof(u64)))
-   ret = -EINVAL;
+   return -EINVAL;
}
 
if (!attr->sample_max_stack)
-- 
2.13.6

[PATCH 3/3] perf: Remove superfluous allocation error check

[Jiri Olsa]

If the get_callchain_buffers fails to allocate the buffer
it will decrease the nr_callchain_events right away.

There's no point of checking the allocation error for
nr_callchain_events > 1. Removing that check.

Signed-off-by: Jiri Olsa 
---
 kernel/events/callchain.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 73cc26e321de..c187aa3df3c8 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -131,14 +131,8 @@ int get_callchain_buffers(int event_max_stack)
goto exit;
}
 
-   if (count > 1) {
-   /* If the allocation failed, give up */
-   if (!callchain_cpus_entries)
-   err = -ENOMEM;
-   goto exit;
-   }
-
-   err = alloc_callchain_buffers();
+   if (count == 1)
+   err = alloc_callchain_buffers();
 exit:
if (err)
atomic_dec(&nr_callchain_events);
-- 
2.13.6

[PATCH 2/3] perf: Fix sample_max_stack maximum check

[Jiri Olsa]

The syzbot hit KASAN bug in perf_callchain_store
having the entry stored behind the allocated bounds [1].

We miss the sample_max_stack check for the initial event
that allocates callchain buffers. This missing check allows
to create an event with sample_max_stack value bigger than
the global sysctl maximum:

  # sysctl -a | grep perf_event_max_stack
  kernel.perf_event_max_stack = 127

  # perf record -vv -C 1 -e cycles/max-stack=256/ kill
  ...
  perf_event_attr:
size 112
...
sample_max_stack 256
  
  sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8 = 4

Note the '-C 1', which forces perf record to create just
single event. Otherwise it opens event for every cpu, then
the sample_max_stack check fails on the second event and
all's fine.

The fix is to run the sample_max_stack check also for the
first event with callchains.

[1] https://marc.info/?l=linux-kernel&m=152352732920874&w=2

Reported-by: syzbot+7c449856228b63ac9...@syzkaller.appspotmail.com
Signed-off-by: Jiri Olsa 
---
 kernel/events/callchain.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 772a43fea825..73cc26e321de 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -119,19 +119,22 @@ int get_callchain_buffers(int event_max_stack)
goto exit;
}
 
+   /*
+* If requesting per event more than the global cap,
+* return a different error to help userspace figure
+* this out.
+*
+* And also do it here so that we have &callchain_mutex held.
+*/
+   if (event_max_stack > sysctl_perf_event_max_stack) {
+   err = -EOVERFLOW;
+   goto exit;
+   }
+
if (count > 1) {
/* If the allocation failed, give up */
if (!callchain_cpus_entries)
err = -ENOMEM;
-   /*
-* If requesting per event more than the global cap,
-* return a different error to help userspace figure
-* this out.
-*
-* And also do it here so that we have &callchain_mutex held.
-*/
-   if (event_max_stack > sysctl_perf_event_max_stack)
-   err = -EOVERFLOW;
goto exit;
}
 
-- 
2.13.6

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Masahiro Yamada]

2018-04-14 1:41 GMT+09:00 Kees Cook :
> On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
>  wrote:
>> +stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
>> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
>> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := 
>> -fstack-protector-strong
>> +
>> +KBUILD_CFLAGS += $(stackp-flags-y)
>
> So, technically, this works just fine. I wonder if it has an overly
> confusing result, in that the compiler under normal situations will
> see:
>
> gcc ... -fno-stack-protector -fstack-protector -fstack-protector-strong ...


Kees, you are wrong.

Look at my code closely.

I used := operator instead of +=.

$(stackp-flags-y) contains only one flag at most.



> How about something like this instead:
>
> ifdef CONFIG_CC_STACKPROTECTOR_STRONG
> KBUILD_CFLAGS += -fstack-protector-strong
> else
> ifdef CONFIG_CC_STACKPROTECTOR
> KBUILD_CFLAGS += -fstack-protector
> else
> KBUILD_CFLAGS += -fno-stack-protector
> endif
> endif
>

My code is much cleaner, and working fine.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] phy: Add a driver for the ATH79 USB phy

[Alban]

On Sat, 24 Mar 2018 23:38:40 +0100
Alban Bedel  wrote:

> The ATH79 USB phy is very simple, it only have a reset. On some SoC a
> second reset is used to force the phy in suspend mode regardless of the
> USB controller status.
> 
> This driver is added to the qualcom directory as atheros is now part
> of qualcom and newer SoC of this familly are marketed under the
> qualcom name.

Does this patch need any improvement or will it be applied?

Alban


pgpD3XbuhHG7R.pgp
Description: OpenPGP digital signature

[PATCH] staging: pi433: use help in Kconfig description

[Valentin Vidic]

Fixes checkpatch warning:

  WARNING: prefer 'help' over '---help---' for new help texts

Signed-off-by: Valentin Vidic 
---
 drivers/staging/pi433/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/pi433/Kconfig b/drivers/staging/pi433/Kconfig
index 87c2ee192cca..c7340129dd4c 100644
--- a/drivers/staging/pi433/Kconfig
+++ b/drivers/staging/pi433/Kconfig
@@ -1,7 +1,7 @@
 config PI433
 tristate "Pi433 - a 433MHz radio module for Raspberry Pi"
 depends on SPI
----help---
+help
   This option allows you to enable support for the radio module Pi433.
 
   Pi433 is a shield that fits onto the GPIO header of a Raspberry Pi
-- 
2.17.0

Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization

[Dietmar Eggemann]

On 03/16/2018 12:25 PM, Vincent Guittot wrote:

[...]


For a 15 seconds long test on a hikey 6220 (octo core cortex A53 platfrom),
the cpufreq statistics outputs (stats are reset just before the test) :
$ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
without patchset : 1230
with patchset : 14

If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
performance improvements:

- Without patchset :
Test execution summary:
 total time:  15.0009s
 total number of events:  4903
 total time taken by event execution: 14.9972
 per-request statistics:
  min:  1.23ms
  avg:  3.06ms
  max: 13.16ms
  approx.  95 percentile:  12.73ms

Threads fairness:
 events (avg/stddev):   4903./0.00
 execution time (avg/stddev):   14.9972/0.00

- With patchset:
Test execution summary:
 total time:  15.0014s
 total number of events:  7694
 total time taken by event execution: 14.9979
 per-request statistics:
  min:  1.23ms
  avg:  1.95ms
  max: 10.49ms
  approx.  95 percentile:  10.39ms

Threads fairness:
 events (avg/stddev):   7694./0.00
 execution time (avg/stddev):   14.9979/0.00

The performance improvement is 56% for this use case.


How do you get this number? Normally we use the 'total time' value.

[...]

Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file

[Dietmar Eggemann]

On 03/16/2018 12:25 PM, Vincent Guittot wrote:

[...]


diff --git a/kernel/sched/pelt.h b/kernel/sched/pelt.h
new file mode 100644
index 000..c312d8c
--- /dev/null
+++ b/kernel/sched/pelt.h
@@ -0,0 +1,17 @@
+#ifdef CONFIG_SMP
+
+int __update_load_avg_blocked_se(u64 now, int cpu, struct sched_entity *se);
+int __update_load_avg_se(u64 now, int cpu, struct cfs_rq *cfs_rq, struct 
sched_entity *se);
+int __update_load_avg_cfs_rq(u64 now, int cpu, struct cfs_rq *cfs_rq);
+
+#else
+
+static inline int
+update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
+{
+   return 0;
+}
+
+#endif


Exporting __update_load_avg_cfs_rq() for SMP and 
update_cfs_rq_load_avg() for !SMP seems weird.


[...]

Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file

[Dietmar Eggemann]

On 03/16/2018 12:25 PM, Vincent Guittot wrote:

We want to track rt_rq's utilization as a part of the estimation of the
whole rq's utilization. This is necessary because rt tasks can steal
utilization to cfs tasks and make them lighter than they are.
As we want to use the same load tracking mecanism for both and prevent
useless dependency between cfs and rt code, pelt code is moved in a
dedicated file.


This would mean that we introduce function calls into the cfs scheduler 
fast-path, something we avoided so far (e.g. the cpu and frequency 
invariance hooks). Are we OK with that?


Quentin mentioned this already during v3 review back in December.

[...]

Re: [PATCH v7 11/26] of: base: Add of_get_cpu_state_node() to get idle states for a CPU node

[Ulf Hansson]

On 13 April 2018 at 17:05, Rob Herring  wrote:
> On Thu, Apr 12, 2018 at 6:14 AM, Ulf Hansson  wrote:
>> The CPU's idle state nodes are currently parsed at the common cpuidle DT
>> library, but also when initializing back-end data for the arch specific CPU
>> operations, as in the PSCI driver case.
>>
>> To avoid open-coding, let's introduce of_get_cpu_state_node(), which takes
>> the device node for the CPU and the index to the requested idle state node,
>> as in-parameters. In case a corresponding idle state node is found, it
>> returns the node with the refcount incremented for it, else it returns
>> NULL.
>>
>> Moreover, for ARM, there are two generic methods, to describe the CPU's
>> idle states, either via the flattened description through the
>> "cpu-idle-states" binding [1] or via the hierarchical layout, using the
>> "power-domains" and the "domain-idle-states" bindings [2]. Hence, let's
>> take both options into account.
>>
>> [1]
>> Documentation/devicetree/bindings/arm/idle-states.txt
>> [2]
>> Documentation/devicetree/bindings/arm/psci.txt
>>
>> Cc: Rob Herring 
>> Cc: devicet...@vger.kernel.org
>> Cc: Lina Iyer 
>> Suggested-by: Sudeep Holla 
>> Co-developed-by: Lina Iyer 
>> Signed-off-by: Ulf Hansson 
>> ---
>>  drivers/of/base.c  | 35 +++
>>  include/linux/of.h |  8 
>>  2 files changed, 43 insertions(+)
>
> Some reason you didn't add my Reviewed-by from v6?

No, I was just sloppy. My apologies!

Kind regards
Uffe

Re: [PATCH 0/4 v4] sched/rt: track rt rq utilization

[Vincent Guittot]

Hi Dietmar,

On 15 April 2018 at 13:56, Dietmar Eggemann  wrote:
> On 03/16/2018 12:25 PM, Vincent Guittot wrote:
>
> [...]
>
>
>> For a 15 seconds long test on a hikey 6220 (octo core cortex A53
>> platfrom),
>> the cpufreq statistics outputs (stats are reset just before the test) :
>> $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
>> without patchset : 1230
>> with patchset : 14
>>
>> If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
>> performance improvements:
>>
>> - Without patchset :
>> Test execution summary:
>>  total time:  15.0009s
>>  total number of events:  4903
>>  total time taken by event execution: 14.9972
>>  per-request statistics:
>>   min:  1.23ms
>>   avg:  3.06ms
>>   max: 13.16ms
>>   approx.  95 percentile:  12.73ms
>>
>> Threads fairness:
>>  events (avg/stddev):   4903./0.00
>>  execution time (avg/stddev):   14.9972/0.00
>>
>> - With patchset:
>> Test execution summary:
>>  total time:  15.0014s
>>  total number of events:  7694
>>  total time taken by event execution: 14.9979
>>  per-request statistics:
>>   min:  1.23ms
>>   avg:  1.95ms
>>   max: 10.49ms
>>   approx.  95 percentile:  10.39ms
>>
>> Threads fairness:
>>  events (avg/stddev):   7694./0.00
>>  execution time (avg/stddev):   14.9979/0.00
>>
>> The performance improvement is 56% for this use case.
>
>
> How do you get this number? Normally we use the 'total time' value.

The test stop after an defined amount of time with --max-time=15 in my case

>
> [...]

Re: [PATCH v7 06/26] timer: Export next wakeup time of a CPU

[Ulf Hansson]

On 13 April 2018 at 10:47, Rafael J. Wysocki  wrote:
> On Thu, Apr 12, 2018 at 1:14 PM, Ulf Hansson  wrote:
>> From: Lina Iyer 
>>
>> Knowing the sleep duration of CPUs, is known to be needed while selecting
>> the most energy efficient idle state for a CPU or a group of CPUs.
>>
>> However, to be able to compute the sleep duration, we need to know at what
>> time the next expected wakeup is for the CPU. Therefore, let's export this
>> information via a new function, tick_nohz_get_next_wakeup(). Following
>> changes make use of it.
>>
>> Cc: Thomas Gleixner 
>> Cc: Daniel Lezcano 
>> Cc: Lina Iyer 
>> Cc: Frederic Weisbecker 
>> Cc: Ingo Molnar 
>> Signed-off-by: Lina Iyer 
>> Co-developed-by: Ulf Hansson 
>> Signed-off-by: Ulf Hansson 
>> ---
>>  include/linux/tick.h | 10 ++
>>  kernel/time/tick-sched.c | 11 +++
>>  2 files changed, 21 insertions(+)
>>
>> diff --git a/include/linux/tick.h b/include/linux/tick.h
>> index 389aa25..d341811 100644
>> --- a/include/linux/tick.h
>> +++ b/include/linux/tick.h
>> @@ -125,6 +125,7 @@ extern bool tick_nohz_idle_got_tick(void);
>>  extern ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next);
>>  extern unsigned long tick_nohz_get_idle_calls(void);
>>  extern unsigned long tick_nohz_get_idle_calls_cpu(int cpu);
>> +extern ktime_t tick_nohz_get_next_wakeup(int cpu);
>>  extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
>>  extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
>>
>> @@ -151,6 +152,15 @@ static inline ktime_t 
>> tick_nohz_get_sleep_length(ktime_t *delta_next)
>> *delta_next = TICK_NSEC;
>> return *delta_next;
>>  }
>> +
>> +static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
>> +{
>> +   ktime_t t;
>> +
>> +   /* Next wake up is the tick period, assume it starts now */
>> +   return ktime_add(tick_nohz_get_sleep_length(&t), ktime_get());
>> +}
>
> Well, given that tick_nohz_get_sleep_length() is just the above in
> this case, wouldn't it be simpler to return ktime_add(ktime_get(),
> TICK_NSEC) from here?

Yes!

>
>> +
>>  static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
>>  static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; 
>> }
>>
>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>> index 646645e..08db7f3 100644
>> --- a/kernel/time/tick-sched.c
>> +++ b/kernel/time/tick-sched.c
>> @@ -1098,6 +1098,17 @@ unsigned long tick_nohz_get_idle_calls(void)
>> return ts->idle_calls;
>>  }
>>
>> +/**
>> + * tick_nohz_get_next_wakeup - return the next wake up of the CPU
>> + */
>> +ktime_t tick_nohz_get_next_wakeup(int cpu)
>> +{
>> +   struct clock_event_device *dev =
>> +   per_cpu(tick_cpu_device.evtdev, cpu);
>
> I would avoid breaking the line, honestly.

Alright, I have no problem with that.

[,,,]

Thanks for reviewing!

Kind regards
Uffe

Re: [PATCH] IB: make INFINIBAND_ADDR_TRANS configurable

[Christoph Hellwig]

On Fri, Apr 13, 2018 at 12:06:44AM -0700, Greg Thelen wrote:
> Allow INFINIBAND without INFINIBAND_ADDR_TRANS.

Why?  We are pushing everyone heavily to use RDMA/CM, so making it
optional seems rather counter-intuitive.

You'll also have to fix tons of ULPs to explicitly depend on
INFINIBAND_ADDR_TRANS, or make code conditional on it.

Re: BUILD_BUG_ON_MSG

[Daniel Santos]

Hello Julia,

I'm CCing LKML on this so that others can be involved.


On 04/15/2018 12:43 AM, Julia Lawall wrote:
> Hello,
>
> I saw that you introduced BUILD_BUG_ON_MSG in the Linux kernel a few years
> ago.
>
> BUILD_BUG_ON_MSG is not safe when used in header files.  Via
> compiletime_assert, it makes a new function whose name is only determined
> by a line number.  When BUILD_BUG_ON_MSG is used in header files,
> multiple uses may end up at the same line, in different header files.  The
> reported errors are then quite confusing; I guess the last function with
> the given name is used.

Yes, This is an unfortunate side-effect of the implementation, since
"error" and "warning" are function attributes.  This issue was discussed
during review and it was decided that one should simply not use more
than one of such macro on the same line in an implementation file.  I
had thought we added a "don't use more than once per line" in the
documentation for these macros, but I'm not seeing it right now -- if
it's really missing then we probably want to add it.

>
> I tried incorporating __func__, but for some reason it didn't expand into
> anything.  Perhaps I used it incorrectly in some way.

Neither __func__ nor __FUNCTION__ are cpp macros, they are just static
const char arrays (see
https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html).  For some
reason I recall believing that __PRETTY_FUNCTION__ *is* a cpp macro, but
I'm probably wrong, and even if it was it wouldn't be a valid function
prefix.

> If it is not
> possible to get the name of the enclosing function, would it be reasonable
> to make a new kind of BUILD_BUG_ON call that takes an extra argument that
> can be used in the function name to make it unique?
>
> thanks,
> julia
>
You're still going to need the function name as a cpp macro.  If you
have that, you can just expand _compiletime_assert() directly.  Please
post your code when sending an inquiry like this -- it makes it easier
for others to help you and we don't have to waste as much time trying to
figure out exactly what you might be doing and how.  I don't remember if
doing this inside of an always_inline function (instead of a macro
expansion) works or not.

For a long time I've considered the merits of directly adding a gcc
extension to perform these checks without all of these side effects and
the lengthy macro expansion backtrace, which is also an ugly artifact of
this mechanism.  In fact, I was really disappointed with C11's
_Static_assert because I at first thought it was a generic solution, but
then came to find out otherwise.

IMO, the ideal mechanism would behave more like MAYBE_BUILD_BUG_ON, but
without all of the cpp fluff currently required.  Does anybody know if
this has been proposed or a gcc feature request filed for this yet?

Daniel

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

[Christoph Hellwig]

On Fri, Apr 06, 2018 at 06:37:18PM +1000, Benjamin Herrenschmidt wrote:
> > > implemented as DMA API which the virtio core understands. There is no
> > > need for an IOMMU to be involved for the device representation in this
> > > case IMHO.
> > 
> > This whole virtio translation issue is a mess.  I think we need to
> > switch it to the dma API, and then quirk the legacy case to always
> > use the direct mapping inside the dma API.
> 
> Fine with using a dma API always on the Linux side, but we do want to
> special case virtio still at the arch and qemu side to have a "direct
> mapping" mode. Not sure how (special flags on PCI devices) to avoid
> actually going through an emulated IOMMU on the qemu side, because that
> slows things down, esp. with vhost.
> 
> IE, we can't I think just treat it the same as a physical device.

We should have treated it like a physical device from the start, but
that device has unfortunately sailed.

But yes, we'll need a per-device quirk that says 'don't attach an
iommu'.

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Alan Jenkins]

On 14/04/18 20:52, Jens Axboe wrote:

On 4/14/18 1:46 PM, Alan Jenkins wrote:

On 13/04/18 09:31, Johannes Thumshirn wrote:

Hi Alan,

On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:

# dd if=/dev/sda of=/dev/null iflag=direct & \
while killall -SIGUSR1 dd; do sleep 0.1; done & \
echo mem > /sys/power/state ; \
sleep 5; killall dd  # stop after 5 seconds

Can you please also add a regression test to blktests[1] for this?

[1] https://github.com/osandov/blktests

Thanks,
Johannes

Good question. It would be nice to promote this test.

Template looks like I need the commit (sha1) first.

I had some ideas about automating it, so I wrote a standalone (see
end).  I can automate the wakeup by using pm_test, but this is still a
system suspend test.  Unfortunately I don't think there's any
alternative. To give the most dire example

  # This test is non-destructive, but it exercises suspend in all drivers.
  # If your system has a problem with suspend, it might not wake up again.


So I'm not sure if it would be acceptable for the default set?

How useful is this going to be? Is there an expanded/full set of tests
that gets run somewhere?

If you can't guarantee it's going to be run somewhere, I'd worry the
cost/benefit  feels a little narrow :-(. There were one or two further
"interesting" details, and it might theoretically bitrot if it's not run
periodically.

I run it, just last week we found two new bugs with it. I'm requiring
anyone that submits block patches to run the test suite, and also
working towards having it be part of the 0-day runs so it gets run
on posted patches automatically.

So yes, it's useful and it won't bitrot. Please do turn it into a blktests
test.


Thanks, it's really great to have a test suite. I was specifically 
checking in on how we can include a system suspend test.


I've been thinking the suspend test could be opt-in test (e.g. 
ALLOW_PM_TEST=1), and then we have some infrastructure (you or 0-day 
runs) that does the opt-in.  Without knowing anything about the 
infrastructure, I didn't want to assume that would work.


I'm aware of one particular suspend issue; inside virt-manager VMs I see 
Linux crashing with a null pointer in qxl_drm_freeze.  A regression soon 
after I learned how to use VMs for suspend tests :-( , and it's been 
long enough that I suspect few people use it.


Partly what you saw me fishing for in the comments, is the idea of some 
kernel code allowing more direct testing of the queue freeze / 
preempt_only flag.  That might be better engineering, but I don't know 
where I could put it.


Alan

Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file

[Vincent Guittot]

On 15 April 2018 at 13:58, Dietmar Eggemann  wrote:
> On 03/16/2018 12:25 PM, Vincent Guittot wrote:
>>
>> We want to track rt_rq's utilization as a part of the estimation of the
>> whole rq's utilization. This is necessary because rt tasks can steal
>> utilization to cfs tasks and make them lighter than they are.
>> As we want to use the same load tracking mecanism for both and prevent
>> useless dependency between cfs and rt code, pelt code is moved in a
>> dedicated file.
>
>
> This would mean that we introduce function calls into the cfs scheduler
> fast-path, something we avoided so far (e.g. the cpu and frequency
> invariance hooks). Are we OK with that?
>
> Quentin mentioned this already during v3 review back in December.

Yes and I hadn't seen any differences in the code size with the patch
which should have been the case if inline function where replaced by
function call


>
> [...]

Re: BUILD_BUG_ON_MSG

[Julia Lawall]

On Sun, 15 Apr 2018, Daniel Santos wrote:

> Hello Julia,
>
> I'm CCing LKML on this so that others can be involved.
>
>
> On 04/15/2018 12:43 AM, Julia Lawall wrote:
> > Hello,
> >
> > I saw that you introduced BUILD_BUG_ON_MSG in the Linux kernel a few years
> > ago.
> >
> > BUILD_BUG_ON_MSG is not safe when used in header files.  Via
> > compiletime_assert, it makes a new function whose name is only determined
> > by a line number.  When BUILD_BUG_ON_MSG is used in header files,
> > multiple uses may end up at the same line, in different header files.  The
> > reported errors are then quite confusing; I guess the last function with
> > the given name is used.
>
> Yes, This is an unfortunate side-effect of the implementation, since
> "error" and "warning" are function attributes.  This issue was discussed
> during review and it was decided that one should simply not use more
> than one of such macro on the same line in an implementation file.  I
> had thought we added a "don't use more than once per line" in the
> documentation for these macros, but I'm not seeing it right now -- if
> it's really missing then we probably want to add it.

The problem is not multiple calls on the same line.  The problem is that
every header file has eg a line 1, line 2, etc.  __LINE__ gives the line
number in the header file, and not in the result of expanding the header
file.  This line may be the same as the line in some other header file
that also has a BUILD_BUG_ON_MSG.

>
> >
> > I tried incorporating __func__, but for some reason it didn't expand into
> > anything.  Perhaps I used it incorrectly in some way.
>
> Neither __func__ nor __FUNCTION__ are cpp macros, they are just static
> const char arrays (see
> https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html).  For some
> reason I recall believing that __PRETTY_FUNCTION__ *is* a cpp macro, but
> I'm probably wrong, and even if it was it wouldn't be a valid function
> prefix.
>
> > If it is not
> > possible to get the name of the enclosing function, would it be reasonable
> > to make a new kind of BUILD_BUG_ON call that takes an extra argument that
> > can be used in the function name to make it unique?
> >
> > thanks,
> > julia
> >
> You're still going to need the function name as a cpp macro.  If you
> have that, you can just expand _compiletime_assert() directly.  Please
> post your code when sending an inquiry like this -- it makes it easier
> for others to help you and we don't have to waste as much time trying to
> figure out exactly what you might be doing and how.

Here are the adjustments I made for myself; obviously the names are not
ideal:

diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index 43d1fd5..43d6f67 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -43,6 +43,7 @@
  * See BUILD_BUG_ON for description.
  */
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+#define MY_BUILD_BUG_ON_MSG(cond, tok, msg) my_compiletime_assert(!(cond), 
tok, msg)

 /**
  * BUILD_BUG_ON - break compile if a condition is true.
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c..bb19c7a 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -338,6 +350,9 @@ unsigned long read_word_at_a_time(const void *addr)
 #define compiletime_assert(condition, msg) \
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)

+#define my_compiletime_assert(condition, tok, msg) \
+   _compiletime_assert(condition, msg, tok ## __my_compiletime_assert_, 
__LINE__)
+
 #define compiletime_assert_atomic_type(t)  \
compiletime_assert(__native_word(t),\
"Need native word sized stores/loads for atomicity.")

Then my uses would be eg

MY_BUILD_BUG_ON_MSG(cond1, callsite, "condition 1 holds");
MY_BUILD_BUG_ON_MSG(cond2, callsite, "condition 2 holds");
etc.

thanks,
julia


> I don't remember if
> doing this inside of an always_inline function (instead of a macro
> expansion) works or not.
>
> For a long time I've considered the merits of directly adding a gcc
> extension to perform these checks without all of these side effects and
> the lengthy macro expansion backtrace, which is also an ugly artifact of
> this mechanism.  In fact, I was really disappointed with C11's
> _Static_assert because I at first thought it was a generic solution, but
> then came to find out otherwise.
>
> IMO, the ideal mechanism would behave more like MAYBE_BUILD_BUG_ON, but
> without all of the cpp fluff currently required.  Does anybody know if
> this has been proposed or a gcc feature request filed for this yet?
>
> Daniel
>
>
>

[GIT PULL] Btrfs updates for 4.17, part 2

[David Sterba]

Hi,

we have queued a few more fixes (error handling, log replay, softlockup)
and the rest is SPDX update that touches almost all files so the
diffstat is long. The top patch is a fixup for excessive warning and
was not in linux-next but I've tested it locally.

Please pull, thanks.


The following changes since commit 57599c7e7722daf5f8c2dba4b0e4628f5c500771:

  btrfs: lift errors from add_extent_changeset to the callers (2018-03-31 
02:03:25 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git 
for-4.17-part2-tag

for you to fetch changes up to 5d41be6f702f19f72db816c17175caf9dbdcdfa6:

  btrfs: Only check first key for committed tree blocks (2018-04-13 16:16:15 
+0200)


David Sterba (3):
  btrfs: replace GPL boilerplate by SPDX -- headers
  btrfs: replace GPL boilerplate by SPDX -- sources
  btrfs: add SPDX header to Kconfig

Filipe Manana (1):
  Btrfs: fix loss of prealloc extents past i_size after fsync log replay

Liu Bo (3):
  Btrfs: fix NULL pointer dereference in log_dir_items
  Btrfs: bail out on error during replay_dir_deletes
  Btrfs: clean up resources during umount after trans is aborted

Nikolay Borisov (1):
  btrfs: Fix possible softlock on single core machines

Qu Wenruo (1):
  btrfs: Only check first key for committed tree blocks

 fs/btrfs/Kconfig   |  2 +
 fs/btrfs/acl.c | 15 +-
 fs/btrfs/async-thread.c| 15 +-
 fs/btrfs/async-thread.h| 21 ++--
 fs/btrfs/backref.c | 15 +-
 fs/btrfs/backref.h | 19 ++--
 fs/btrfs/btrfs_inode.h | 19 ++--
 fs/btrfs/check-integrity.c | 15 +-
 fs/btrfs/check-integrity.h | 19 ++--
 fs/btrfs/compression.c | 15 +-
 fs/btrfs/compression.h | 19 ++--
 fs/btrfs/ctree.c   | 15 +-
 fs/btrfs/ctree.h   | 20 ++--
 fs/btrfs/dedupe.h  | 20 ++--
 fs/btrfs/delayed-inode.c   | 15 +-
 fs/btrfs/delayed-inode.h   | 19 ++--
 fs/btrfs/delayed-ref.c | 15 +-
 fs/btrfs/delayed-ref.h | 21 ++--
 fs/btrfs/dev-replace.c | 16 +-
 fs/btrfs/dev-replace.h | 20 ++--
 fs/btrfs/dir-item.c| 15 +-
 fs/btrfs/disk-io.c | 26 +-
 fs/btrfs/disk-io.h | 20 ++--
 fs/btrfs/export.c  |  1 +
 fs/btrfs/export.h  |  1 +
 fs/btrfs/extent-tree.c | 17 ++-
 fs/btrfs/extent_io.c   |  1 +
 fs/btrfs/extent_io.h   |  6 ++-
 fs/btrfs/extent_map.c  |  1 +
 fs/btrfs/extent_map.h  |  6 ++-
 fs/btrfs/file-item.c   | 15 +-
 fs/btrfs/file.c| 15 +-
 fs/btrfs/free-space-cache.c| 15 +-
 fs/btrfs/free-space-cache.h| 19 ++--
 fs/btrfs/free-space-tree.c | 15 +-
 fs/btrfs/free-space-tree.h | 19 ++--
 fs/btrfs/inode-item.c  | 15 +-
 fs/btrfs/inode-map.c   | 15 +-
 fs/btrfs/inode-map.h   |  5 +-
 fs/btrfs/inode.c   | 15 +-
 fs/btrfs/ioctl.c   | 15 +-
 fs/btrfs/locking.c | 16 +-
 fs/btrfs/locking.h | 19 ++--
 fs/btrfs/lzo.c | 15 +-
 fs/btrfs/math.h| 20 ++--
 fs/btrfs/ordered-data.c| 15 +-
 fs/btrfs/ordered-data.h| 20 ++--
 fs/btrfs/orphan.c  | 15 +-
 fs/btrfs/print-tree.c  | 15 +-
 fs/btrfs/print-tree.h  | 21 ++--
 fs/btrfs/props.c   | 15 +-
 fs/btrfs/props.h   | 19 ++--
 fs/btrfs/qgroup.c  | 15 +-
 fs/btrfs/qgroup.h  | 22 ++---
 fs/btrfs/raid56.c  | 16 +-
 fs/btrfs/raid56.h  | 21 ++--
 fs/btrfs/rcu-string.h  | 20 +++-
 fs/btrfs/reada.c   | 15 +-
 fs/btrfs/ref-verify.c  | 15 +-
 fs/btrfs/ref-verify.h  | 23 +++--
 fs/btrfs/relocation.c  | 15 +-
 fs/btrfs/root-tree.c   | 15 +-
 fs/btrfs/scrub.c   | 15 +-
 fs/btrfs/send.c| 15 +-
 fs/btrfs/send.h| 20 +++-
 fs/btrfs/struct-funcs.c| 15 +-
 fs/btrfs/super.c   | 15 +-
 fs

(4) the implementation of the rights of separation control

[乐水廉]

especiallywiththecurrentscientificandtechnologicalproductivity阅览内容，预览附件

Re: [PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings

[Craig Tatlor]

On Fri, Apr 13, 2018 at 11:35:27AM -0500, Rob Herring wrote:
> On Sat, Apr 07, 2018 at 06:57:45PM +0100, Craig Tatlor wrote:
> > Add bindings for the Qualcomm Battery Monitoring system.
> > 
> > Signed-off-by: Craig Tatlor 
> > ---
> >  .../bindings/power/supply/qcom_bms.txt| 93 +++
> >  1 file changed, 93 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt 
> > b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> > new file mode 100644
> > index ..6296399edc09
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> > @@ -0,0 +1,93 @@
> > +Qualcomm Battery Measurement System
> > +
> > +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941
> 
> Is it Monitoring or Measurment?
> 
> > +PMICs. It provides OCV and coulomb counter registers that allow the kernel
> > +to infer a capacity level.
> 
> s/kernel/OS/
> 
> OCV?
> 
> > +
> > +Required properties:
> > +- compatible:   Should contain "qcom,pm8941-bms".
> > +- reg:  Specifies the SPMI address and length of the
> > +   controller's registers.
> > +- interrupts:   OCV threshold interrupt.
> > +- io-channels:  Should contain IIO channel specifier for the
> > +   ADC channel that reports battery temperature.
> > +- io-channel-names: Should contain "temp".
> > +- qcom,fcc-temp-legend: An array containing the temperature, in degC,
> > +   for each column of the FCC lookup table.
> 
> What's FCC?
> 
> > +- qcom,fcc-lut: An array of FCC values in mah, one entry for 
> > each
> > +   temperature defined in in qcom,fcc-temp-legend.
> > +- qcom,ocv-temp-legend: An array containing the temperature, in degC,
> > +   for each column of the OCV lookup table.
> > +- qcom,ocv-capacity-legend: An array containing the capacity for each
> > +   row of the OCV lookup table.
> > +- qcom,ocv-lut: An array of OCV values in mV, one entry for 
> > each
> > +   capacity defined in qcom,ocv-capacity-legend.
> 
> Need to specify the sizes of these if not 32-bit.
> 
> All these seem to have units, so add unit suffixes as defined in 
> property-units.txt.
Should i change code to use microamphours & microvolts or add a new
suffix?
> 
> > +
> > +Example:
> > +
> > +   pm8941_vadc: vadc@3100 {
> 
> adc@...
> 
> > +   compatible = "qcom,spmi-vadc";
> > +   reg = <0x3100>;
> > +   interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   #io-channel-cells = <1>;
> > +
> > +   bat_temp {
> > +   reg = ;
> > +   };
> > +   };
> > +
> > +   bms@4000 {
> > +   compatible = "qcom,pm8941-bms";
> > +   reg = <0x4000>;
> > +   interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>;
> > +   interrupt-names = "ocv_thr";
> > +
> > +   io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>;
> > +   io-channel-names = "temp";
> > +
> > +   qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>;
> > +   qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>;
> > +
> > +   qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85
> > +80 75 70 65
> > +60 55 50 45
> > +40 35 30 25
> > +20 15 10 9
> > +8 7 6 5 4
> > +3 2 1 0>;
> > +
> > +   qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>;
> > +   qcom,ocv-lut = /bits/ 16 <4288 4288 4306 4315 4315
> > + 4261 4241 4259 4266 4246
> > + 4201 4181 4201 4207 4187
> > + 4153 4133 4150 4155 4135
> > + 4105 4085 4100 4104 4084
> > + 4058 4038 4052 4058 4038
> > + 4012 3992 4004 4014 3994
> > + 3970 3950 3959 3971 3951
> > + 3931 3911 3915 3927 3907
> > + 3899 3879 3880 3884 3864
> > +   

Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement

[Fabio Estevam]

Hi Gustavo,

On Wed, Apr 11, 2018 at 4:40 AM, Gustavo Pimentel
 wrote:

> Can be this one?
>
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.

Subject says that this patch provides a computation improvement, but
as you said above the compiler
will perform the shift, so it doesn't seem we will get any benefit.

IMHO the original code has better readability as it makes easier to
understand that pp->cfg0_size will get the half of
resource_size(pp->cfg) size.

I would say it is better to drop this patch from the series.

Thanks

Re: [PATCH] KVM: Switch 'requests' to be 64-bit (explicitly)

[Raslan, KarimAllah]

On Sun, 2018-04-15 at 00:26 +0200, KarimAllah Ahmed wrote:
> Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
> use the size of "requests" instead of the hard-coded '32'.
> 
> That gives us a bit more room again for arch-specific requests as we
> already ran out of space for x86 due to the hard-coded check.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed 
> ---
>  include/linux/kvm_host.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 6930c63..fe4f46b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -129,7 +129,7 @@ static inline bool is_error_page(struct page *page)
>  #define KVM_REQUEST_ARCH_BASE 8
>  
>  #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
> - BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
> + BUILD_BUG_ON((unsigned)(nr) >= (sizeof(((struct kvm_vcpu 
> *)0)->requests) * 8) - KVM_REQUEST_ARCH_BASE); \

While looking at a completely unrelated code I realize that there 
is FIELD_SIZEOF that is doing exactly what I did. Will use it in v2.

>   (unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
>  })
>  #define KVM_ARCH_REQ(nr)   KVM_ARCH_REQ_FLAGS(nr, 0)
> @@ -223,7 +223,7 @@ struct kvm_vcpu {
>   int vcpu_id;
>   int srcu_idx;
>   int mode;
> - unsigned long requests;
> + u64 requests;
>   unsigned long guest_debug;
>  
>   int pre_pcpu;
> @@ -1122,7 +1122,7 @@ static inline void kvm_make_request(int req, struct 
> kvm_vcpu *vcpu)
>* caller.  Paired with the smp_mb__after_atomic in kvm_check_request.
>*/
>   smp_wmb();
> - set_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> + set_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>  }
>  
>  static inline bool kvm_request_pending(struct kvm_vcpu *vcpu)
> @@ -1132,12 +1132,12 @@ static inline bool kvm_request_pending(struct 
> kvm_vcpu *vcpu)
>  
>  static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
>  {
> - return test_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> + return test_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>  }
>  
>  static inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
>  {
> - clear_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> + clear_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>  }
>  
>  static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Russell King - ARM Linux]

On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin  wrote:
> >
> > Most uses I've seen do nothing more than use the FPE_xyz value to
> > format diagnostic messages while dying.  I struggled to find code that
> > made a meaningful functional decision based on the value, though that's
> > not proof...
> 
> Yeah. I've seen code that cares about SIGFPE deeply, but it's almost
> invariably about some emulated environment (eg Java VM, or CPU
> emulation).
> 
> And the siginfo data is basically never good enough for those
> environments anyway on its own, so they will go and look at the actual
> instruction that caused the fault and the register state instead,
> because they need *all* the information.
> 
> The cases that use si_code are the ones that just trapped signals in
> order to give a more helpful abort message.
> 
> So I could certainly imagine that si_code is actually used by somebody
> who then decides to actuall act differently on it, but aside from
> perhaps printing out a different message, it sounds far-fetched.

Okay, in that case let's just use FPE_FLTINV.  That makes the patch
easily back-portable for stable kernels.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH 1/4 v4] sched/pelt: Move pelt related code in a dedicated file

[Dietmar Eggemann]

On 04/15/2018 02:16 PM, Vincent Guittot wrote:

On 15 April 2018 at 13:58, Dietmar Eggemann  wrote:

On 03/16/2018 12:25 PM, Vincent Guittot wrote:


We want to track rt_rq's utilization as a part of the estimation of the
whole rq's utilization. This is necessary because rt tasks can steal
utilization to cfs tasks and make them lighter than they are.
As we want to use the same load tracking mecanism for both and prevent
useless dependency between cfs and rt code, pelt code is moved in a
dedicated file.



This would mean that we introduce function calls into the cfs scheduler
fast-path, something we avoided so far (e.g. the cpu and frequency
invariance hooks). Are we OK with that?

Quentin mentioned this already during v3 review back in December.


Yes and I hadn't seen any differences in the code size with the patch
which should have been the case if inline function where replaced by
function call


I see a diff (e.g. for arm64 defconfig):

6d626e0aaf91 - (HEAD -> tip/sched/core_rt_rq_util_tracking) sched/nohz: 
monitor rt utilization (2018-04-15 Vincent Guittot)
3111c6206f0c - cpufreq/schedutil: add rt utilization tracking 
(2018-04-15 Vincent Guittot)
62e103d266ed - sched/rt: add rt_rq utilization tracking (2018-04-15 
Vincent Guittot)
8f78fef6b1a2 - sched/pelt: Move pelt related code in a dedicated file 
(2018-04-15 Vincent Guittot)
31e77c93e432 - (tip/sched/core_rt_rq_util_tracking_base) sched/fair: 
Update blocked load when newly idle (2018-03-09 Vincent Guittot)


deggeman-mac:/opt/git/kernel_org:tip/sched/core_rt_rq_util_tracking$ 
size vmlinux

   textdata bss dec hex filename
112868566154896  410296 178520481106690 vmlinux

versus:

31e77c93e432 - (HEAD -> tip/sched/core_rt_rq_util_tracking_base) 
sched/fair: Update blocked load when ne$

ly idle (2018-03-09 Vincent Guittot)

deggeman-mac:/opt/git/kernel_org:tip/sched/core_rt_rq_util_tracking_base$ 
size vmlinux
   textdata bss dec hex filename 


112950486154896  410296 178602401108690 vmlinux

So I assume that in kernel/sched/fair.o:

U __update_load_avg_blocked_se
U __update_load_avg_cfs_rq
U __update_load_avg_se

are function calls now.

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Masahiro Yamada]

2018-04-14 3:11 GMT+09:00 Linus Torvalds :
> On Fri, Apr 13, 2018 at 9:41 AM, Kees Cook  wrote:
>>
>> How about something like this instead:
>
> I'd rather avoid the ifdef's in the Makefile if at all possible.
>
> I'd rather expose this as a Kconfig rule, and in the Kconfig just have
> an entry something like this
>
> config STACKPROTECTOR_FLAGS
> string
> default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
> default "-fstack-protector" if CC_STACKPROTECTOR
> default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
> default ""
>
> which is really simple and straightforward. In the presense of
> multiple defaults, the first is picked, so this _automatically_ does
> that whole priority ordering.
>
> And then the Makefile can just have
>
> KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS)
>
> which seems much simpler.

This has a minor problem.

A string type symbol encloses a value with "..." like
CONFIG_STACKPROTECTOR_FLAGS="-fstack-protector-strong"


I think the least ugliest notation to rip off "..."
is to do like follows:

KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS:"%"=%)



> It also makes more complex conditionals easier (ie different compilers
> with different flags, since clang sometimes does the same thing with
> another flag name), so I'd rather see this pattern in general.
>
> I'd also *much* rather do as much as possible at Kconfig time compared
> to build time. Maybe it's just shifting the costs around, but the less
> "clever" things we ask "make" to do, the better.
>
> I find our Makefiles an odd combination of really clean and simply
> (the ones that just have "obj-$(CONFIG_X) += xyz.o" are just lovely)
> and completely incomprehensible (all of our infrastructure support for
> the simple stuff).
>
> I'd rather have more of the simple stuff in Makefiles, less of the
> complex conditionals.
>
>   Linus


You showed a preference of the following,

CONFIG_XYZ
bool "Enable xyz"
depends on $(cc-option -fxyz)

CONFIG_XYZ_FLAGS
string "-fxyz" if XYZ

Then, in Makefile

KBUILD_CFLAGS += $(CONFIG_XYZ_FLAGS:"%"=%)


Users usually say y/n to a question "do you want to use xyz?"
So, if you make this a general pattern,
it would require one additional symbol
to convert a bool symbol to a string.




I think the following was your original idea.

CONFIG_XYZ
bool "xyz"
depends on $(cc-option -fxyz)

Then, in Makefile

KBUILD_CFLAGS-$(CONFIG_XYZ) += -fxyz



Both notations have pros/cons, but
I slightly prefer the latter at the moment of time.




There are some complicated cases such as stack protector flags.


Your idea,

config STACKPROTECTOR_FLAGS
string
default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
default "-fstack-protector" if CC_STACKPROTECTOR
default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
default ""

works fine since the first visible default is picked.




In my Makefile ...

stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong

KBUILD_CFLAGS += $(stackp-flags-y)



the last one is picked.


IMHO, they are tied in terms of "cleanness".



Perhaps I may miss something, but we will have more time
to consider which approach is better.


-- 
Best Regards
Masahiro Yamada

[RFC PATCH] kernel/sched/core: busy wait before going idle

[Nicholas Piggin]

This is a quick hack for comments, but I've always wondered --
if we have a short term polling idle states in cpuidle for performance
-- why not skip the context switch and entry into all the idle states,
and just wait for a bit to see if something wakes up again.

It's not uncommon to see various going-to-idle work in kernel profiles.
This might be a way to reduce that (and just the cost of switching
registers and kernel stack to idle thread). This can be an important
path for single thread request-response throughput.

tbench bandwidth seems to be improved (the numbers aren't too stable
but they pretty consistently show some gain). 10-20% would be a pretty
nice gain for such workloads

clients 1 2 4 816   128
vanilla   232   467   823  1819  3218  9065
patched   310   503   962  2465  3743  9820

---
 kernel/sched/core.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e8afd6086f23..30a0b13edfa5 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3404,6 +3404,7 @@ static void __sched notrace __schedule(bool preempt)
struct rq_flags rf;
struct rq *rq;
int cpu;
+   bool do_idle_spin = true;
 
cpu = smp_processor_id();
rq = cpu_rq(cpu);
@@ -3428,6 +3429,7 @@ static void __sched notrace __schedule(bool preempt)
rq_lock(rq, &rf);
smp_mb__after_spinlock();
 
+idle_spin_end:
/* Promote REQ to ACT */
rq->clock_update_flags <<= 1;
update_rq_clock(rq);
@@ -3437,6 +3439,32 @@ static void __sched notrace __schedule(bool preempt)
if (unlikely(signal_pending_state(prev->state, prev))) {
prev->state = TASK_RUNNING;
} else {
+   /*
+* Busy wait before switching to idle thread. This
+* is marked unlikely because we're idle so jumping
+* out of line doesn't matter too much.
+*/
+   if (unlikely(do_idle_spin && rq->nr_running == 1)) {
+   u64 start;
+
+   do_idle_spin = false;
+
+   rq->clock_update_flags &= 
~(RQCF_ACT_SKIP|RQCF_REQ_SKIP);
+   rq_unlock_irq(rq, &rf);
+
+   spin_begin();
+   start = local_clock();
+   while (!need_resched() && prev->state &&
+   !signal_pending_state(prev->state, 
prev)) {
+   spin_cpu_relax();
+   if (local_clock() - start > 100)
+   break;
+   }
+   spin_end();
+
+   rq_lock_irq(rq, &rf);
+   goto idle_spin_end;
+   }
deactivate_task(rq, prev, DEQUEUE_SLEEP | 
DEQUEUE_NOCLOCK);
prev->on_rq = 0;
 
-- 
2.17.0

Re: [GIT PULL] auxdisplay for v4.17-rc1

[Miguel Ojeda]

On Sat, Apr 14, 2018 at 12:50 AM, Linus Torvalds
 wrote:
> On Thu, Apr 12, 2018 at 11:37 AM, Miguel Ojeda
>  wrote:
>>
>> Please pull these fixes and cleanups for auxdisplay.
>
> As far as I can tell, none of this has been in linux-next.
>
> By the end of the merge window, I styart getting a whole lot more anal
> about what I pull. In particular, if people send me pull requests
> late, I had better get the warm fuzzy feeling of "at least it's been
> tested in linux-next".

Yeah, no worries -- I was late, so I suspected as much :-)

Do you prefer I re-send it for -rc2, send it to linux-next, wait for
4.18 or just wait until you pull at some point?

Thanks,
Miguel

Re: INFO: rcu detected stall in n_tty_receive_char_special

[syzbot]

syzbot has found reproducer for the following crash on upstream commit
18b7fd1c93e5204355ddbf2608a097d64df81b88 (Sat Apr 14 15:50:50 2018 +)
Merge branch 'akpm' (patches from Andrew)
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=18df353d7540aa6b5467


So far this crash happened 2 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5283196245639168
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5978502260064256
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=4993708470566912
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-8852471259444315113

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+18df353d7540aa6b5...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

INFO: rcu_sched self-detected stall on CPU
	1-: (124999 ticks this GP) idle=792/1/4611686018427387906  
softirq=9920/9920 fqs=31243

 (t=125000 jiffies g=4830 c=4829 q=20)
NMI backtrace for cpu 1
CPU: 1 PID: 4467 Comm: syzkaller756606 Not tainted 4.16.0+ #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
 trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
 rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
 print_cpu_stall kernel/rcu/tree.c:1525 [inline]
 check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
 __rcu_pending kernel/rcu/tree.c:3356 [inline]
 rcu_pending kernel/rcu/tree.c:3401 [inline]
 rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
 update_process_times+0x2d/0x70 kernel/time/timer.c:1636
 tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:173
 tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1283
 __run_hrtimer kernel/time/hrtimer.c:1386 [inline]
 __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1448
 hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1506
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
 smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862
 
RIP: 0010:echo_char+0x96/0x2e0 drivers/tty/n_tty.c:915
RSP: 0018:8801b079f6f8 EFLAGS: 0293 ORIG_RAX: ff13
RAX: 8801b06ee1c0 RBX: c90001e64000 RCX: 837ab4a7
RDX:  RSI: 837ab4b6 RDI: 0001
RBP: 8801b079f728 R08: 8801b06ee1c0 R09: 0001
R10: 8801b06eea20 R11: 8801b06ee1c0 R12: 000f
R13: 8801b02b0dc0 R14: 00012b1bcc47 R15: 0c47
 n_tty_receive_char_special+0x13b3/0x31c0 drivers/tty/n_tty.c:1306
 n_tty_receive_buf_fast drivers/tty/n_tty.c:1577 [inline]
 __receive_buf drivers/tty/n_tty.c:1611 [inline]
 n_tty_receive_buf_common+0x20ca/0x2c50 drivers/tty/n_tty.c:1709
 n_tty_receive_buf+0x30/0x40 drivers/tty/n_tty.c:1738
 tiocsti drivers/tty/tty_io.c:2171 [inline]
 tty_ioctl+0x7e7/0x1870 drivers/tty/tty_io.c:2557
 vfs_ioctl fs/ioctl.c:46 [inline]
 file_ioctl fs/ioctl.c:500 [inline]
 do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
 SYSC_ioctl fs/ioctl.c:708 [inline]
 SyS_ioctl+0x24/0x30 fs/ioctl.c:706
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4404b9
RSP: 002b:7ffee94bd7f8 EFLAGS: 0213 ORIG_RAX: 0010
RAX: ffda RBX: 26c0 RCX: 004404b9
RDX: 20c0 RSI: 5412 RDI: 0012
RBP: 6d74702f7665642f R08: 000a R09: 
R10:  R11: 0213 R12: 00401c30
R13: 00401cc0 R14:  R15: 

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Al Viro]

On Sun, Apr 15, 2018 at 03:39:44AM +0100, Al Viro wrote:

> I really wonder if we should just do the following in
> d_invalidate():
>   * grab ->d_lock on victim, check if it's unhashed,
> unlock and bugger off if it is.  Otherwise, unhash and unlock.
> >From that point on any d_set_mounted() in the subtree will
> fail.
>   * shrink_dcache_parent() to reduce the subtree size.
>   * go through the (hopefully shrunk) subtree, picking
> mountpoints.  detach_mounts() for each of them.
>   * shrink_dcache_parent() if any points had been
> encountered, to kick the now-unpinned stuff.
> 
> As a side benefit, we could probably be gentler on rename_lock
> in d_set_mounted() after that change...

Something like this, IOW:

diff --git a/fs/dcache.c b/fs/dcache.c
index 86d2de63461e..e61c07ff2d95 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1230,13 +1230,11 @@ enum d_walk_ret {
  * @parent:start of walk
  * @data:  data passed to @enter() and @finish()
  * @enter: callback when first entering the dentry
- * @finish:callback when successfully finished the walk
  *
  * The @enter() and @finish() callbacks are called with d_lock held.
  */
 static void d_walk(struct dentry *parent, void *data,
-  enum d_walk_ret (*enter)(void *, struct dentry *),
-  void (*finish)(void *))
+  enum d_walk_ret (*enter)(void *, struct dentry *))
 {
struct dentry *this_parent;
struct list_head *next;
@@ -1325,8 +1323,6 @@ static void d_walk(struct dentry *parent, void *data,
if (need_seqretry(&rename_lock, seq))
goto rename_retry;
rcu_read_unlock();
-   if (finish)
-   finish(data);
 
 out_unlock:
spin_unlock(&this_parent->d_lock);
@@ -1375,7 +1371,7 @@ int path_has_submounts(const struct path *parent)
struct check_mount data = { .mnt = parent->mnt, .mounted = 0 };
 
read_seqlock_excl(&mount_lock);
-   d_walk(parent->dentry, &data, path_check_mount, NULL);
+   d_walk(parent->dentry, &data, path_check_mount);
read_sequnlock_excl(&mount_lock);
 
return data.mounted;
@@ -1483,7 +1479,7 @@ void shrink_dcache_parent(struct dentry *parent)
data.start = parent;
data.found = 0;
 
-   d_walk(parent, &data, select_collect, NULL);
+   d_walk(parent, &data, select_collect);
if (!data.found)
break;
 
@@ -1518,7 +1514,7 @@ static enum d_walk_ret umount_check(void *_data, struct 
dentry *dentry)
 static void do_one_tree(struct dentry *dentry)
 {
shrink_dcache_parent(dentry);
-   d_walk(dentry, dentry, umount_check, NULL);
+   d_walk(dentry, dentry, umount_check);
d_drop(dentry);
dput(dentry);
 }
@@ -1542,78 +1538,48 @@ void shrink_dcache_for_umount(struct super_block *sb)
}
 }
 
-struct detach_data {
-   struct select_data select;
-   struct dentry *mountpoint;
-};
-static enum d_walk_ret detach_and_collect(void *_data, struct dentry *dentry)
+static enum d_walk_ret find_submount(void *_data, struct dentry *dentry)
 {
-   struct detach_data *data = _data;
-
if (d_mountpoint(dentry)) {
__dget_dlock(dentry);
-   data->mountpoint = dentry;
+   *(struct dentry **)_data = dentry;
return D_WALK_QUIT;
}
 
-   return select_collect(&data->select, dentry);
-}
-
-static void check_and_drop(void *_data)
-{
-   struct detach_data *data = _data;
-
-   if (!data->mountpoint && list_empty(&data->select.dispose))
-   __d_drop(data->select.start);
+   return D_WALK_CONTINUE;
 }
 
 /**
  * d_invalidate - detach submounts, prune dcache, and drop
  * @dentry: dentry to invalidate (aka detach, prune and drop)
- *
- * no dcache lock.
- *
- * The final d_drop is done as an atomic operation relative to
- * rename_lock ensuring there are no races with d_set_mounted.  This
- * ensures there are no unhashed dentries on the path to a mountpoint.
  */
 void d_invalidate(struct dentry *dentry)
 {
-   /*
-* If it's already been dropped, return OK.
-*/
+   bool had_submounts = false;
spin_lock(&dentry->d_lock);
if (d_unhashed(dentry)) {
spin_unlock(&dentry->d_lock);
return;
}
+   __d_drop(dentry);
spin_unlock(&dentry->d_lock);
 
/* Negative dentries can be dropped without further checks */
-   if (!dentry->d_inode) {
-   d_drop(dentry);
+   if (!dentry->d_inode)
return;
-   }
 
+   shrink_dcache_parent(dentry);
for (;;) {
-   struct detach_data data;
-
-   data.mountpoint = NULL;
-   INIT_LIST_HEAD(&data.select.dispose);
-   data.select.start = dentry;
-   data.select.found = 0;
-
-   d_walk(dentry, &data, detach_and_collect, check_and

Dear Talented

[Ms.Lisa Clement]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Spies in Disguise (Spies in Disguise 2019) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: blueskystudi...@gmail.com
All Reply to: blueskystudi...@gmail.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.

Talent Scout
Kim Sharma

Re: [PATCH AUTOSEL for 4.15 019/189] printk: Add console owner and waiter logic to load balance console writes

[Sasha Levin]

On Mon, Apr 09, 2018 at 10:15:35AM +0200, Petr Mladek wrote:
>On Mon 2018-04-09 00:16:59, Sasha Levin wrote:
>> From: "Steven Rostedt (VMware)" 
>>
>> [ Upstream commit dbdda842fe96f8932bae554f0adf463c27c42bc7 ]
>>
>> This patch implements what I discussed in Kernel Summit. I added
>> lockdep annotation (hopefully correctly), and it hasn't had any splats
>> (since I fixed some bugs in the first iterations). It did catch
>> problems when I had the owner covering too much. But now that the owner
>> is only set when actively calling the consoles, lockdep has stayed
>> quiet.
>
>I do not think that this is a material for stable backports. Yes, it
>is a fix but it is not trivial. There are already 3 follow up commits:
>
>c162d5b4338d72deed6 ("printk: Hide console waiter logic into helpers")
>fd5f7cde1b85d4c8e09 ("printk: Never set console_may_schedule in
>   console_trylock()")
>c14376de3a1befa70d9 ("printk: Wake klogd when passing console_lock owner")
>
>One is just a code clean up but the other two are changes/fixes that
>should go together with Steven's patch.
>
>These changes tries to prevent softlockups. It is a problem that is
>being discussed for years. We are still waiting for feedback to see if
>more changes will be necessary. IMHO, there is no reason to hurry and
>backport it everywhere.
>
>Best Regards,
>Petr

I'll remove it, thanks Petr!

Re: [PATCH AUTOSEL for 4.15 044/189] ASoC: bcm2835: fix hw_params error when device is in prepared state

[Sasha Levin]

On Mon, Apr 09, 2018 at 10:27:24AM +0100, Mark Brown wrote:
>On Mon, Apr 09, 2018 at 12:17:20AM +, Sasha Levin wrote:
>
>> ---
>>  sound/soc/bcm/bcm2835-i2s.c | 20 ++--
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>
>This is a relatively big refactoring, including moving things from one
>userspace operation to another.  I'd not be 100% sure it doesn't have
>any extra implicit or explicit dependencies.

I'll remove it, thanks Mark!

Re: [PATCH AUTOSEL for 4.15 168/189] nfsd: return RESOURCE not GARBAGE_ARGS on too many ops

[Sasha Levin]

On Mon, Apr 09, 2018 at 11:27:47AM -0400, J. Bruce Fields wrote:
>What's your default on these patches on these AUTOSEL patches if you
>don't get an ACK or NACK?  Do you apply them anyway?

Right now it's opt-out, so it'll get merged unless you NACK it.

In general, these patches get higher visibility as a notice will be sent
a few times for each of these, when:

1. I added it to my queue
2. When Greg sends his review cycle
3. Once a stable kernel is released

>(I'd skip this one as it doesn't meet the "It must fix a real bug that
>bothers people" criterion.  But I don't recall it *causing* any bugs
>either, so the stakes are low, I'm mainly just curious.)

I'll drop it, thanks!

Re: [PATCH AUTOSEL for 4.15 048/189] clk: ingenic: Fix recalc_rate for clocks with fixed divider

[Sasha Levin]

On Mon, Apr 09, 2018 at 09:12:42PM +0100, James Hogan wrote:
>On Mon, Apr 09, 2018 at 12:17:24AM +, Sasha Levin wrote:
>> From: Paul Cercueil 
>>
>> [ Upstream commit e6cfa64375d34a6c8c1861868a381013b2d3b921 ]
>>
>> Previously, the clocks with a fixed divider would report their rate
>> as being the same as the one of their parent, independently of the
>> divider in use. This commit fixes this behaviour.
>>
>> This went unnoticed as neither the jz4740 nor the jz4780 CGU code
>> have clocks with fixed dividers yet.
>
>FYI this one isn't strictly necessary for backport since JZ4770 support
>is new in 4.16, but its probably harmless too.
>
>Cheers
>James

I'll drop it, thanks James!

Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes

[Sasha Levin]

On Mon, Apr 09, 2018 at 10:22:46AM +0200, Petr Mladek wrote:
>PS: I wonder how much time you give people to react before releasing
>this. The number of autosel mails is increasing and I am involved
>only in very small amount of them. I wonder if some other people
>gets overwhelmed by this.

My review cycle gives at least a week, and there's usually another week
until Greg releases them.

I know it's a lot of mails, but in reality it's a lot of commits that
should go in -stable.

Would a different format for review would make it easier?

Re: [PATCH AUTOSEL for 4.14 039/161] IB/cq: Don't force IB_POLL_DIRECT poll context for ib_process_cq_direct

[Sasha Levin]

Grabbed it for both 4.14 and 4.15, thanks Max!

On Mon, Apr 09, 2018 at 07:21:29PM +0300, Max Gurtovoy wrote:
>Hi Sasha,
>please consider taking a small fix for this one (also useful for 4.15):
>
>commit d3b9e8ad425cfd5b9116732e057f1b48e4d3bcb8
>Author: Max Gurtovoy 
>Date:   Mon Mar 5 20:09:48 2018 +0200
>
>RDMA/core: Reduce poll batch for direct cq polling
>
>Fix warning limit for kernel stack consumption:
>
>drivers/infiniband/core/cq.c: In function 'ib_process_cq_direct':
>drivers/infiniband/core/cq.c:78:1: error: the frame size of 1032 bytes
>is larger than 1024 bytes [-Werror=frame-larger-than=]
>
>Using smaller ib_wc array on the stack brings us comfortably below that
>limit again.
>
>Fixes: 246d8b184c10 ("IB/cq: Don't force IB_POLL_DIRECT poll 
>context for ib_process_cq_direct")
>Reported-by: Arnd Bergmann 
>Reviewed-by: Sergey Gorenko 
>Signed-off-by: Max Gurtovoy 
>Signed-off-by: Leon Romanovsky 
>Reviewed-by: Bart Van Assche 
>Acked-by: Arnd Bergmann 
>Signed-off-by: Jason Gunthorpe 
>
>
>-Max.
>
>
>On 4/9/2018 3:20 AM, Sasha Levin wrote:
>>From: Sagi Grimberg 
>>
>>[ Upstream commit 246d8b184c100e8eb6b4e8c88f232c2ed2a4e672 ]
>>
>>polling the completion queue directly does not interfere
>>with the existing polling logic, hence drop the requirement.
>>Be aware that running ib_process_cq_direct with non IB_POLL_DIRECT
>>CQ may trigger concurrent CQ processing.
>>
>>This can be used for polling mode ULPs.
>>
>>Cc: Bart Van Assche 
>>Reported-by: Steve Wise 
>>Signed-off-by: Sagi Grimberg 
>>[maxg: added wcs array argument to __ib_process_cq]
>>Signed-off-by: Max Gurtovoy 
>>Signed-off-by: Doug Ledford 
>>Signed-off-by: Sasha Levin 
>>---
>>  drivers/infiniband/core/cq.c | 23 +--
>>  1 file changed, 13 insertions(+), 10 deletions(-)
>>
>>diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
>>index f2ae75fa3128..c8c5a5a7f433 100644
>>--- a/drivers/infiniband/core/cq.c
>>+++ b/drivers/infiniband/core/cq.c
>>@@ -25,9 +25,10 @@
>>  #define IB_POLL_FLAGS \
>>  (IB_CQ_NEXT_COMP | IB_CQ_REPORT_MISSED_EVENTS)
>>-static int __ib_process_cq(struct ib_cq *cq, int budget)
>>+static int __ib_process_cq(struct ib_cq *cq, int budget, struct ib_wc 
>>*poll_wc)
>>  {
>>  int i, n, completed = 0;
>>+ struct ib_wc *wcs = poll_wc ? : cq->wc;
>>  /*
>>   * budget might be (-1) if the caller does not
>>@@ -35,9 +36,9 @@ static int __ib_process_cq(struct ib_cq *cq, int budget)
>>   * minimum here.
>>   */
>>  while ((n = ib_poll_cq(cq, min_t(u32, IB_POLL_BATCH,
>>- budget - completed), cq->wc)) > 0) {
>>+ budget - completed), wcs)) > 0) {
>>  for (i = 0; i < n; i++) {
>>- struct ib_wc *wc = &cq->wc[i];
>>+ struct ib_wc *wc = &wcs[i];
>>  if (wc->wr_cqe)
>>  wc->wr_cqe->done(cq, wc);
>>@@ -60,18 +61,20 @@ static int __ib_process_cq(struct ib_cq *cq, int budget)
>>   * @cq: CQ to process
>>   * @budget: number of CQEs to poll for
>>   *
>>- * This function is used to process all outstanding CQ entries on a
>>- * %IB_POLL_DIRECT CQ.  It does not offload CQ processing to a different
>>- * context and does not ask for completion interrupts from the HCA.
>>+ * This function is used to process all outstanding CQ entries.
>>+ * It does not offload CQ processing to a different context and does
>>+ * not ask for completion interrupts from the HCA.
>>+ * Using direct processing on CQ with non IB_POLL_DIRECT type may trigger
>>+ * concurrent processing.
>>   *
>>   * Note: do not pass -1 as %budget unless it is guaranteed that the number
>>   * of completions that will be processed is small.
>>   */
>>  int ib_process_cq_direct(struct ib_cq *cq, int budget)
>>  {
>>- WARN_ON_ONCE(cq->poll_ctx != IB_POLL_DIRECT);
>>+ struct ib_wc wcs[IB_POLL_BATCH];
>>- return __ib_process_cq(cq, budget);
>>+ return __ib_process_cq(cq, budget, wcs);
>>  }
>>  EXPORT_SYMBOL(ib_process_cq_direct);
>>@@ -85,7 +88,7 @@ static int ib_poll_handler(struct irq_poll *iop, int budget)
>>  struct ib_cq *cq = container_of(iop, struct ib_cq, iop);
>>  int completed;
>>- completed = __ib_process_cq(cq, budget);
>>+ completed = __ib_process_cq(cq, budget, NULL);
>>  if (completed < budget) {
>>  irq_poll_complete(&cq->iop);
>>  if (ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>>@@ -105,7 +108,7 @@ static void ib_cq_poll_work(struct work_struct *work)
>>  struct ib_cq *cq = container_of(work, struct ib_cq, work);
>>  int completed;
>>- completed = __ib_process_cq(cq, IB_POLL_BUDGET_WORKQUEUE);
>>+ completed = __ib_process_cq(cq, IB_POLL_BUDGET_WORKQUEUE, NULL);
>>  if (completed >= IB_POLL_BUDGET_WORKQUEUE ||
>>  ib_req_notify_cq(cq, IB_POLL_FLAGS) > 0)
>>  queue_work(ib_comp_wq, &cq->work);
>

Re: [PATCH AUTOSEL for 4.14 043/161] MIPS: JZ4770: Work around config2 misreporting associativity

[Sasha Levin]

On Mon, Apr 09, 2018 at 09:08:38PM +0100, James Hogan wrote:
>On Mon, Apr 09, 2018 at 12:20:20AM +, Sasha Levin wrote:
>> From: Maarten ter Huurne 
>>
>> [ Upstream commit 1f7412e0e2f327fe7dc5a0c2fc36d7b319d05d47 ]
>>
>> According to config2, the associativity would be 5-ways, but the
>> documentation states 4-ways, which also matches the documented
>> L2 cache size of 256 kB.
>
>JZ4770 support is new in 4.16, so no need for this to be backported.
>More likely it'll just break the build due to references to
>MACH_INGENIC_JZ4770.
>
>Cheers
>James

Now removed, thanks James!

io_pgetevents & aio fsync V3

[Christoph Hellwig]

Hi all,

this patch adds workqueue based fsync offload.  Version of this
patch have been floating around for a couple years, but we now
have a user with seastar used by ScyllaDB (who sponsored this
work) that really wants this in addition to the aio poll support.
More details are in the patch itself.

Because the iocb types have been defined sine day one (and probably
were supported by RHEL3) libaio already supports these calls as-is.

This also pulls in the aio cleanups and io_pgetevents support previously
submitted and review as part of the aio poll series.  The aio poll
series will be resubmitted on top of this series

A git tree is available here:

git://git.infradead.org/users/hch/vfs.git aio-fsync.3

Gitweb:

http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/aio-fsync.3

Changes since V2:
 - don't introduce a use after free for lockdep sb release tracking
 - set up list for cancellation before I/O submission

Changes since V1:
 - remove a BUG_ON_ONE(is_sync_kiocb(kiocb));
 - moved cancellation patches to the poll series
 - improve a list_empty check

[PATCH 6/7] aio: implement IOCB_CMD_FSYNC and IOCB_CMD_FDSYNC

[Christoph Hellwig]

Simple workqueue offload for now, but prepared for adding a real aio_fsync
method if the need arises.  Based on an earlier patch from Dave Chinner.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong 
---
 fs/aio.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/fs/aio.c b/fs/aio.c
index d4dd002712c8..de56496ba86c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -156,6 +156,12 @@ struct kioctx {
unsignedid;
 };
 
+struct fsync_iocb {
+   struct work_struct  work;
+   struct file *file;
+   booldatasync;
+};
+
 /*
  * We use ki_cancel == KIOCB_CANCELLED to indicate that a kiocb has been either
  * cancelled or completed (this makes a certain amount of sense because
@@ -172,6 +178,7 @@ struct kioctx {
 struct aio_kiocb {
union {
struct kiocbrw;
+   struct fsync_iocb   fsync;
};
 
struct kioctx   *ki_ctx;
@@ -1571,6 +1578,36 @@ static ssize_t aio_write(struct kiocb *req, struct iocb 
*iocb, bool vectored,
return ret;
 }
 
+static void aio_fsync_work(struct work_struct *work)
+{
+   struct fsync_iocb *req = container_of(work, struct fsync_iocb, work);
+   int ret;
+
+   ret = vfs_fsync(req->file, req->datasync);
+   fput(req->file);
+   aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
+}
+
+static int aio_fsync(struct fsync_iocb *req, struct iocb *iocb, bool datasync)
+{
+   if (unlikely(iocb->aio_buf || iocb->aio_offset || iocb->aio_nbytes ||
+   iocb->aio_rw_flags))
+   return -EINVAL;
+
+   req->file = fget(iocb->aio_fildes);
+   if (unlikely(!req->file))
+   return -EBADF;
+   if (unlikely(!req->file->f_op->fsync)) {
+   fput(req->file);
+   return -EINVAL;
+   }
+
+   req->datasync = datasync;
+   INIT_WORK(&req->work, aio_fsync_work);
+   schedule_work(&req->work);
+   return -EIOCBQUEUED;
+}
+
 static int io_submit_one(struct kioctx *ctx, struct iocb __user *user_iocb,
 struct iocb *iocb, bool compat)
 {
@@ -1634,6 +1671,12 @@ static int io_submit_one(struct kioctx *ctx, struct iocb 
__user *user_iocb,
case IOCB_CMD_PWRITEV:
ret = aio_write(&req->rw, iocb, true, compat);
break;
+   case IOCB_CMD_FSYNC:
+   ret = aio_fsync(&req->fsync, iocb, false);
+   break;
+   case IOCB_CMD_FDSYNC:
+   ret = aio_fsync(&req->fsync, iocb, true);
+   break;
default:
pr_debug("invalid aio operation %d\n", iocb->aio_lio_opcode);
ret = -EINVAL;
-- 
2.17.0

Re: [PATCH AUTOSEL for 4.4 065/162] tcp: Add a tcp_filter hook before handle ack packet

[Sasha Levin]

On Mon, Apr 09, 2018 at 11:00:06AM -0700, Chenbo Feng wrote:
>On Sun, Apr 8, 2018 at 5:28 PM, Sasha Levin
> wrote:
>> From: Chenbo Feng 
>>
>> [ Upstream commit 8fac365f63c866a00015fa13932d8ffc584518b8 ]
>>
>> Currently in both ipv4 and ipv6 code path, the ack packet received when
>> sk at TCP_NEW_SYN_RECV state is not filtered by socket filter or cgroup
>> filter since it is handled from tcp_child_process and never reaches the
>> tcp_filter inside tcp_v4_rcv or tcp_v6_rcv. Adding a tcp_filter hooks
>> here can make sure all the ingress tcp packet can be correctly filtered.
>>
>> Signed-off-by: Chenbo Feng 
>> Signed-off-by: David S. Miller 
>> Signed-off-by: Sasha Levin 
>> ---
>>  net/ipv4/tcp_ipv4.c | 2 ++
>>  net/ipv6/tcp_ipv6.c | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index 61c93a93f228..2eb9a1747f25 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -1639,6 +1639,8 @@ process:
>> }
>> if (nsk == sk) {
>> reqsk_put(req);
>> +   } else if (tcp_filter(sk, skb)) {
>> +   goto discard_and_relse;
>> } else if (tcp_child_process(sk, nsk, skb)) {
>> tcp_v4_send_reset(nsk, skb);
>> goto discard_and_relse;
>> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
>> index 74cbcc4b399c..7d7f0999a919 100644
>> --- a/net/ipv6/tcp_ipv6.c
>> +++ b/net/ipv6/tcp_ipv6.c
>> @@ -1428,6 +1428,8 @@ process:
>> if (nsk == sk) {
>> reqsk_put(req);
>> tcp_v6_restore_cb(skb);
>> +   } else if (tcp_filter(sk, skb)) {
>> +   goto discard_and_relse;
>> } else if (tcp_child_process(sk, nsk, skb)) {
>> tcp_v6_send_reset(nsk, skb);
>> goto discard_and_relse;
>> --
>> 2.15.1
>There is a bug fix for this patch upstream:
>"d624d276d1ddacbcb12ad96832ce0c7b82cd25db tcp: fix possible deadlock
>in TCP stack vs BPF filter", Please make you include that as well if
>you want to add this patch to stable.

That commit had quite a few conflicts, so I dropped this commit instead.
Thanks!

[PATCH 4/7] aio: remove the extra get_file/fput pair in io_submit_one

[Christoph Hellwig]

If we release the lockdep write protection token before calling into
->write_iter and thus never access the file pointer after an -EIOCBQUEUED
return from ->write_iter or ->read_iter we don't need this extra
reference.

Signed-off-by: Christoph Hellwig 
---
 fs/aio.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 18507743757a..d7be32cdd1db 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1515,16 +1515,17 @@ static ssize_t aio_write(struct kiocb *req, struct iocb 
*iocb, bool vectored,
return ret;
ret = rw_verify_area(WRITE, file, &req->ki_pos, iov_iter_count(&iter));
if (!ret) {
-   req->ki_flags |= IOCB_WRITE;
-   file_start_write(file);
-   ret = aio_ret(req, call_write_iter(file, req, &iter));
/*
 * We release freeze protection in aio_complete().  Fool lockdep
 * by telling it the lock got released so that it doesn't
 * complain about held lock when we return to userspace.
 */
-   if (S_ISREG(file_inode(file)->i_mode))
+   if (S_ISREG(file_inode(file)->i_mode)) {
+   __sb_start_write(file_inode(file)->i_sb, 
SB_FREEZE_WRITE, true);
__sb_writers_release(file_inode(file)->i_sb, 
SB_FREEZE_WRITE);
+   }
+   req->ki_flags |= IOCB_WRITE;
+   ret = aio_ret(req, call_write_iter(file, req, &iter));
}
kfree(iovec);
return ret;
@@ -1599,7 +1600,6 @@ static int io_submit_one(struct kioctx *ctx, struct iocb 
__user *user_iocb,
req->ki_user_iocb = user_iocb;
req->ki_user_data = iocb->aio_data;
 
-   get_file(file);
switch (iocb->aio_lio_opcode) {
case IOCB_CMD_PREAD:
ret = aio_read(&req->common, iocb, false, compat);
@@ -1618,7 +1618,6 @@ static int io_submit_one(struct kioctx *ctx, struct iocb 
__user *user_iocb,
ret = -EINVAL;
break;
}
-   fput(file);
 
if (ret && ret != -EIOCBQUEUED)
goto out_put_req;
-- 
2.17.0

[PATCH 5/7] aio: refactor read/write iocb setup

[Christoph Hellwig]

Don't reference the kiocb structure from the common aio code, and move
any use of it into helper specific to the read/write path.  This is in
preparation for aio_poll support that wants to use the space for different
fields.

Signed-off-by: Christoph Hellwig 
Acked-by: Jeff Moyer 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong 
---
 fs/aio.c | 159 +++
 1 file changed, 91 insertions(+), 68 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index d7be32cdd1db..d4dd002712c8 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -170,7 +170,9 @@ struct kioctx {
 #define KIOCB_CANCELLED((void *) (~0ULL))
 
 struct aio_kiocb {
-   struct kiocbcommon;
+   union {
+   struct kiocbrw;
+   };
 
struct kioctx   *ki_ctx;
kiocb_cancel_fn *ki_cancel;
@@ -549,7 +551,7 @@ static int aio_setup_ring(struct kioctx *ctx, unsigned int 
nr_events)
 
 void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel)
 {
-   struct aio_kiocb *req = container_of(iocb, struct aio_kiocb, common);
+   struct aio_kiocb *req = container_of(iocb, struct aio_kiocb, rw);
struct kioctx *ctx = req->ki_ctx;
unsigned long flags;
 
@@ -581,7 +583,7 @@ static int kiocb_cancel(struct aio_kiocb *kiocb)
cancel = cmpxchg(&kiocb->ki_cancel, old, KIOCB_CANCELLED);
} while (cancel != old);
 
-   return cancel(&kiocb->common);
+   return cancel(&kiocb->rw);
 }
 
 /*
@@ -1046,15 +1048,6 @@ static inline struct aio_kiocb *aio_get_req(struct 
kioctx *ctx)
return NULL;
 }
 
-static void kiocb_free(struct aio_kiocb *req)
-{
-   if (req->common.ki_filp)
-   fput(req->common.ki_filp);
-   if (req->ki_eventfd != NULL)
-   eventfd_ctx_put(req->ki_eventfd);
-   kmem_cache_free(kiocb_cachep, req);
-}
-
 static struct kioctx *lookup_ioctx(unsigned long ctx_id)
 {
struct aio_ring __user *ring  = (void __user *)ctx_id;
@@ -1085,27 +1078,14 @@ static struct kioctx *lookup_ioctx(unsigned long ctx_id)
 /* aio_complete
  * Called when the io request on the given iocb is complete.
  */
-static void aio_complete(struct kiocb *kiocb, long res, long res2)
+static void aio_complete(struct aio_kiocb *iocb, long res, long res2)
 {
-   struct aio_kiocb *iocb = container_of(kiocb, struct aio_kiocb, common);
struct kioctx   *ctx = iocb->ki_ctx;
struct aio_ring *ring;
struct io_event *ev_page, *event;
unsigned tail, pos, head;
unsigned long   flags;
 
-   if (kiocb->ki_flags & IOCB_WRITE) {
-   struct file *file = kiocb->ki_filp;
-
-   /*
-* Tell lockdep we inherited freeze protection from submission
-* thread.
-*/
-   if (S_ISREG(file_inode(file)->i_mode))
-   __sb_writers_acquired(file_inode(file)->i_sb, 
SB_FREEZE_WRITE);
-   file_end_write(file);
-   }
-
if (!list_empty_careful(&iocb->ki_list)) {
unsigned long flags;
 
@@ -1167,11 +1147,12 @@ static void aio_complete(struct kiocb *kiocb, long res, 
long res2)
 * eventfd. The eventfd_signal() function is safe to be called
 * from IRQ context.
 */
-   if (iocb->ki_eventfd != NULL)
+   if (iocb->ki_eventfd) {
eventfd_signal(iocb->ki_eventfd, 1);
+   eventfd_ctx_put(iocb->ki_eventfd);
+   }
 
-   /* everything turned out well, dispose of the aiocb. */
-   kiocb_free(iocb);
+   kmem_cache_free(kiocb_cachep, iocb);
 
/*
 * We have to order our ring_info tail store above and test
@@ -1434,6 +1415,45 @@ SYSCALL_DEFINE1(io_destroy, aio_context_t, ctx)
return -EINVAL;
 }
 
+static void aio_complete_rw(struct kiocb *kiocb, long res, long res2)
+{
+   struct aio_kiocb *iocb = container_of(kiocb, struct aio_kiocb, rw);
+
+   if (kiocb->ki_flags & IOCB_WRITE) {
+   struct inode *inode = file_inode(kiocb->ki_filp);
+
+   /*
+* Tell lockdep we inherited freeze protection from submission
+* thread.
+*/
+   if (S_ISREG(inode->i_mode))
+   __sb_writers_acquired(inode->i_sb, SB_FREEZE_WRITE);
+   file_end_write(kiocb->ki_filp);
+   }
+
+   fput(kiocb->ki_filp);
+   aio_complete(iocb, res, res2);
+}
+
+static int aio_prep_rw(struct kiocb *req, struct iocb *iocb)
+{
+   int ret;
+
+   req->ki_filp = fget(iocb->aio_fildes);
+   if (unlikely(!req->ki_filp))
+   return -EBADF;
+   req->ki_complete = aio_complete_rw;
+   req->ki_pos = iocb->aio_offset;
+   req->ki_flags = iocb_flags(req->ki_filp);
+   if (iocb->aio_flags & IOCB_FLAG_RESFD)
+   req->ki_flags |= IOCB_EVENTFD;
+   req->ki_hint = file_write_hint(req->ki_filp);

[PATCH 2/7] aio: remove an outdated BUG_ON and comment in aio_complete

[Christoph Hellwig]

These days we don't treat sync iocbs special in the aio completion code as
they never use it.  Remove the old comment and BUG_ON given that the
current definition of is_sync_kiocb makes it impossible to hit.

Signed-off-by: Christoph Hellwig 
---
 fs/aio.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index add46b06be86..7c1855afd723 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1107,15 +1107,6 @@ static void aio_complete(struct kiocb *kiocb, long res, 
long res2)
file_end_write(file);
}
 
-   /*
-* Special case handling for sync iocbs:
-*  - events go directly into the iocb for fast handling
-*  - the sync task with the iocb in its stack holds the single iocb
-*ref, no other paths have a way to get another ref
-*  - the sync task helpfully left a reference to itself in the iocb
-*/
-   BUG_ON(is_sync_kiocb(kiocb));
-
if (iocb->ki_list.next) {
unsigned long flags;
 
-- 
2.17.0

[PATCH 7/7] aio: implement io_pgetevents

[Christoph Hellwig]

This is the io_getevents equivalent of ppoll/pselect and allows to
properly mix signals and aio completions (especially with IOCB_CMD_POLL)
and atomically executes the following sequence:

sigset_t origmask;

pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ret = io_getevents(ctx, min_nr, nr, events, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);

Note that unlike many other signal related calls we do not pass a sigmask
size, as that would get us to 7 arguments, which aren't easily supported
by the syscall infrastructure.  It seems a lot less painful to just add a
new syscall variant in the unlikely case we're going to increase the
sigset size.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong 
---
 arch/x86/entry/syscalls/syscall_32.tbl |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl |   1 +
 fs/aio.c   | 114 ++---
 include/linux/compat.h |   7 ++
 include/linux/syscalls.h   |   6 ++
 include/uapi/asm-generic/unistd.h  |   4 +-
 include/uapi/linux/aio_abi.h   |   6 ++
 kernel/sys_ni.c|   2 +
 8 files changed, 130 insertions(+), 11 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index c58f75b088c5..99b6f7a36178 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -391,3 +391,4 @@
 382i386pkey_free   sys_pkey_free
 383i386statx   sys_statx
 384i386arch_prctl  sys_arch_prctl  
compat_sys_arch_prctl
+385i386io_pgetevents   sys_io_pgetevents   
compat_sys_io_pgetevents
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
b/arch/x86/entry/syscalls/syscall_64.tbl
index 5aef183e2f85..e995cd2b4e65 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -339,6 +339,7 @@
 330common  pkey_alloc  sys_pkey_alloc
 331common  pkey_free   sys_pkey_free
 332common  statx   sys_statx
+333common  io_pgetevents   sys_io_pgetevents
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/fs/aio.c b/fs/aio.c
index de56496ba86c..5cfeb5bc3a7d 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1303,10 +1303,6 @@ static long read_events(struct kioctx *ctx, long min_nr, 
long nr,
wait_event_interruptible_hrtimeout(ctx->wait,
aio_read_events(ctx, min_nr, nr, event, &ret),
until);
-
-   if (!ret && signal_pending(current))
-   ret = -EINTR;
-
return ret;
 }
 
@@ -1913,13 +1909,60 @@ SYSCALL_DEFINE5(io_getevents, aio_context_t, ctx_id,
struct timespec __user *, timeout)
 {
struct timespec64   ts;
+   int ret;
+
+   if (timeout && unlikely(get_timespec64(&ts, timeout)))
+   return -EFAULT;
+
+   ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? &ts : NULL);
+   if (!ret && signal_pending(current))
+   ret = -EINTR;
+   return ret;
+}
 
-   if (timeout) {
-   if (unlikely(get_timespec64(&ts, timeout)))
+SYSCALL_DEFINE6(io_pgetevents,
+   aio_context_t, ctx_id,
+   long, min_nr,
+   long, nr,
+   struct io_event __user *, events,
+   struct timespec __user *, timeout,
+   const struct __aio_sigset __user *, usig)
+{
+   struct __aio_sigset ksig = { NULL, };
+   sigset_tksigmask, sigsaved;
+   struct timespec64   ts;
+   int ret;
+
+   if (timeout && unlikely(get_timespec64(&ts, timeout)))
+   return -EFAULT;
+
+   if (usig && copy_from_user(&ksig, usig, sizeof(ksig)))
+   return -EFAULT;
+
+   if (ksig.sigmask) {
+   if (ksig.sigsetsize != sizeof(sigset_t))
+   return -EINVAL;
+   if (copy_from_user(&ksigmask, ksig.sigmask, sizeof(ksigmask)))
return -EFAULT;
+   sigdelsetmask(&ksigmask, sigmask(SIGKILL) | sigmask(SIGSTOP));
+   sigprocmask(SIG_SETMASK, &ksigmask, &sigsaved);
+   }
+
+   ret = do_io_getevents(ctx_id, min_nr, nr, events, timeout ? &ts : NULL);
+   if (signal_pending(current)) {
+   if (ksig.sigmask) {
+   current->saved_sigmask = sigsaved;
+   set_restore_sigmask();
+   }
+
+   if (!ret)
+   ret = -ERESTARTNOHAND;
+   } else {
+   if (ksig.sigmask)
+   sigprocmask(SIG_SETMASK, &sigsaved, NULL);
}
 
-   return do_io_getevents(ctx_id, min_nr, nr, events, timeout ? &ts : 
NULL);
+   

Re: [PATCH AUTOSEL for 3.18 059/101] x86/um: thin archives build fix

[Sasha Levin]

On Mon, Apr 09, 2018 at 02:29:11PM +1000, Nicholas Piggin wrote:
>On Mon, 9 Apr 2018 00:41:22 +
>Sasha Levin  wrote:
>
>> From: Nicholas Piggin 
>>
>> [ Upstream commit 827880ec260ba048f95fe646b96a205c394fa0f0 ]
>>
>> The linker does not like vdso-syms.lds in input archive files.
>> Make it an extra-y instead.
>
>I wouldn't say these should be needed on kernels without thin
>archives build.
>
>It shouldn't hurt, but no point risking stable breakage.
>
>Thanks,
>Nick

Now dropped, thanks Nick!

Re: [PATCH v2 01/14] staging: iio: ad7746: Automatically swap values in readings/writings

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:38 -0300
Hernán Gonzalez  wrote:

> Data to read or write was being handled with the swab16() macro instead
> of using i2c_smbus_{read,write}_swapped.
> 
> Signed-off-by: Hernán Gonzalez 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/cdc/ad7746.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 4882dbc..53e28ae 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -451,7 +451,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
>   goto out;
>   }
>  
> - ret = i2c_smbus_write_word_data(chip->client, reg, swab16(val));
> + ret = i2c_smbus_write_word_swapped(chip->client, reg, val);
>   if (ret < 0)
>   goto out;
>  
> @@ -462,8 +462,8 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
>   ret = -EINVAL;
>   goto out;
>   }
> - ret = i2c_smbus_write_word_data(chip->client,
> - AD7746_REG_CAP_OFFH, swab16(val));
> + ret = i2c_smbus_write_word_swapped(chip->client,
> +AD7746_REG_CAP_OFFH, val);
>   if (ret < 0)
>   goto out;
>  
> @@ -594,21 +594,21 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   goto out;
>   }
>  
> - ret = i2c_smbus_read_word_data(chip->client, reg);
> + ret = i2c_smbus_read_word_swapped(chip->client, reg);
>   if (ret < 0)
>   goto out;
>   /* 1 + gain_val / 2^16 */
>   *val = 1;
> - *val2 = (15625 * swab16(ret)) / 1024;
> + *val2 = (15625 * ret) / 1024;
>  
>   ret = IIO_VAL_INT_PLUS_MICRO;
>   break;
>   case IIO_CHAN_INFO_CALIBBIAS:
> - ret = i2c_smbus_read_word_data(chip->client,
> -AD7746_REG_CAP_OFFH);
> + ret = i2c_smbus_read_word_swapped(chip->client,
> +   AD7746_REG_CAP_OFFH);
>   if (ret < 0)
>   goto out;
> - *val = swab16(ret);
> + *val = ret;
>  
>   ret = IIO_VAL_INT;
>   break;

[PATCH 3/7] aio: sanitize ki_list handling

[Christoph Hellwig]

Instead of handcoded non-null checks always initialize ki_list to an
empty list and use list_empty / list_empty_careful on it.  While we're
at it also error out on a double call to kiocb_set_cancel_fn instead
of ignoring it.

Signed-off-by: Christoph Hellwig 
Acked-by: Jeff Moyer 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong 
---
 fs/aio.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 7c1855afd723..18507743757a 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -553,13 +553,12 @@ void kiocb_set_cancel_fn(struct kiocb *iocb, 
kiocb_cancel_fn *cancel)
struct kioctx *ctx = req->ki_ctx;
unsigned long flags;
 
-   spin_lock_irqsave(&ctx->ctx_lock, flags);
-
-   if (!req->ki_list.next)
-   list_add(&req->ki_list, &ctx->active_reqs);
+   if (WARN_ON_ONCE(!list_empty(&req->ki_list)))
+   return;
 
+   spin_lock_irqsave(&ctx->ctx_lock, flags);
+   list_add_tail(&req->ki_list, &ctx->active_reqs);
req->ki_cancel = cancel;
-
spin_unlock_irqrestore(&ctx->ctx_lock, flags);
 }
 EXPORT_SYMBOL(kiocb_set_cancel_fn);
@@ -1039,7 +1038,7 @@ static inline struct aio_kiocb *aio_get_req(struct kioctx 
*ctx)
goto out_put;
 
percpu_ref_get(&ctx->reqs);
-
+   INIT_LIST_HEAD(&req->ki_list);
req->ki_ctx = ctx;
return req;
 out_put:
@@ -1107,7 +1106,7 @@ static void aio_complete(struct kiocb *kiocb, long res, 
long res2)
file_end_write(file);
}
 
-   if (iocb->ki_list.next) {
+   if (!list_empty_careful(&iocb->ki_list)) {
unsigned long flags;
 
spin_lock_irqsave(&ctx->ctx_lock, flags);
-- 
2.17.0

Re: [PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

[Masahiro Yamada]

2018-04-15 16:41 GMT+09:00 Ulf Magnusson :
> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>  wrote:
>> Kconfig got text processing tools like we see in Make.  Add Kconfig
>> helper macros to scripts/Kconfig.include like we collect Makefile
>> macros in scripts/Kbuild.include.
>>
>> Signed-off-by: Masahiro Yamada 
>> Reviewed-by: Kees Cook 
>> Reviewed-by: Ulf Magnusson 
>> ---
>>
>> Changes in v3:
>>   - Move helpers to scripts/Kconfig.include
>>
>> Changes in v2: None
>>
>>  Kconfig |  2 ++
>>  MAINTAINERS |  1 +
>>  scripts/Kconfig.include | 17 +
>>  3 files changed, 20 insertions(+)
>>  create mode 100644 scripts/Kconfig.include
>>
>> diff --git a/Kconfig b/Kconfig
>> index 5b55d87..a90d9f9 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel 
>> Configuration"
>>
>>  comment "Compiler: $(CC_VERSION_TEXT)"
>>
>> +source "scripts/Kconfig.include"
>> +
>>  source "arch/$(SRCARCH)/Kconfig"
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b9dab38..d962f4a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
>>  S: Maintained
>>  F: Documentation/kbuild/kconfig*
>>  F: scripts/kconfig/
>> +F: scripts/Kconfig.include
>>
>>  KDUMP
>>  M: Dave Young 
>> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
>> new file mode 100644
>> index 000..cac7a81
>> --- /dev/null
>> +++ b/scripts/Kconfig.include
>> @@ -0,0 +1,17 @@
>> +# Kconfig helper macros
>> +
>> +# Convenient variables
>> +comma   := ,
>> +quote   := "
>> +squote  := '
>> +empty   :=
>> +space   := $(empty) $(empty)
>> +
>> +# y if the command exits with 0, n otherwise
>> +success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
>
> '{ $(1); }' might work here, to avoid the extra subshell.
>
> Shaves 20-30% off the runtime here in a silly
> system("(true) >/dev/null 2>&1 && echo y || echo n") vs.
> system("{ true; } >/dev/null 2>&1 && echo y || echo n")
> comparison.


You are right.   Will do so in the next version.






-- 
Best Regards
Masahiro Yamada

Re: [tip:x86/urgent] swiotlb: Use dma_direct_supported() for swiotlb_ops

[Christoph Hellwig]

Do you plan to send this on to Linus?  Would be great to have this in
for rc1..

Re: [PATCH v2 02/14] staging: iio: ad7746: Adjust arguments to match open parenthesis

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:39 -0300
Hernán Gonzalez  wrote:

> Clear a couple more checkpatch.pl CHECKS.
> 
> Signed-off-by: Hernán Gonzalez 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/cdc/ad7746.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 53e28ae..516aa93 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -556,7 +556,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   /* Now read the actual register */
>  
>   ret = i2c_smbus_read_i2c_block_data(chip->client,
> - chan->address >> 8, 3, &chip->data.d8[1]);
> + chan->address >> 8, 3,
> + &chip->data.d8[1]);
>  
>   if (ret < 0)
>   goto out;
> @@ -614,7 +615,7 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   break;
>   case IIO_CHAN_INFO_OFFSET:
>   *val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
> - [chan->differential]) * 338646;
> +   [chan->differential]) * 338646;
>  
>   ret = IIO_VAL_INT;
>   break;

[PATCH 1/7] aio: don't print the page size at boot time

[Christoph Hellwig]

The page size is in no way related to the aio code, and printing it in
the (debug) dmesg at every boot serves no purpose.

Signed-off-by: Christoph Hellwig 
Acked-by: Jeff Moyer 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Darrick J. Wong 
---
 fs/aio.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 88d7927ffbc6..add46b06be86 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -264,9 +264,6 @@ static int __init aio_setup(void)
 
kiocb_cachep = KMEM_CACHE(aio_kiocb, SLAB_HWCACHE_ALIGN|SLAB_PANIC);
kioctx_cachep = KMEM_CACHE(kioctx,SLAB_HWCACHE_ALIGN|SLAB_PANIC);
-
-   pr_debug("sizeof(struct page) = %zu\n", sizeof(struct page));
-
return 0;
 }
 __initcall(aio_setup);
-- 
2.17.0

Re: [PATCH v2 03/14] staging: iio: ad7746: Fix bound checkings

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:40 -0300
Hernán Gonzalez  wrote:

> Also remove unnecessary parenthesis
I am probably missing something.  I'm not sure what you mean
by fix bound checking?   There are superfluous brackets, but
I don't see any functional change to indicate there was anything
wrong with the original checks.

> 
> Signed-off-by: Hernán Gonzalez 
> ---
>  drivers/staging/iio/cdc/ad7746.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 516aa93..d793785 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -458,7 +458,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
>   ret = 0;
>   break;
>   case IIO_CHAN_INFO_CALIBBIAS:
> - if ((val < 0) | (val > 0x)) {
> + if (val < 0 || val > 0x) {
>   ret = -EINVAL;
>   goto out;
>   }
> @@ -470,7 +470,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
>   ret = 0;
>   break;
>   case IIO_CHAN_INFO_OFFSET:
> - if ((val < 0) | (val > 43008000)) { /* 21pF */
> + if (val < 0 || val > 43008000) { /* 21pF */
>   ret = -EINVAL;
>   goto out;
>   }

Re: [PATCH v2 04/14] staging: iio: ad7746: Fix multiple line dereference

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:41 -0300
Hernán Gonzalez  wrote:

> Clear checkpatch.pl WARNING about multiple line derefence but creates a
> new one of line over 80 characters. In my opinion, it improves
> readability.
> 
> Signed-off-by: Hernán Gonzalez 
I wouldn't say I personally have strong views either way on this, but
your version is fine so I'll apply it.

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/cdc/ad7746.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index d793785..82fac76 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -410,8 +410,7 @@ static struct attribute *ad7746_attributes[] = {
>   &iio_dev_attr_in_capacitance1_calibbias_calibration.dev_attr.attr,
>   &iio_dev_attr_in_voltage0_calibscale_calibration.dev_attr.attr,
>   &iio_const_attr_in_voltage_sampling_frequency_available.dev_attr.attr,
> - &iio_const_attr_in_capacitance_sampling_frequency_available.
> - dev_attr.attr,
> + 
> &iio_const_attr_in_capacitance_sampling_frequency_available.dev_attr.attr,
>   NULL,
>  };
>  

Re: [PATCH v2 05/14] staging: iio: ad7746: Reorder includes alphabetically

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:42 -0300
Hernán Gonzalez  wrote:

> Signed-off-by: Hernán Gonzalez 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/staging/iio/cdc/ad7746.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 82fac76..9ef476a 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -6,15 +6,15 @@
>   * Licensed under the GPL-2.
>   */
>  
> -#include 
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include 
>  #include 

Re: [PATCH v2 06/14] staging: iio: ad7746: Reorder variable declarations

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:43 -0300
Hernán Gonzalez  wrote:

> Reorder some variable declarations in an inverse-pyramid scheme.
> 
> Signed-off-by: Hernán Gonzalez 
Applied,

Thanks,

Jonathan
> ---
>  drivers/staging/iio/cdc/ad7746.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 9ef476a..f53612a 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -220,8 +220,8 @@ static int ad7746_select_channel(struct iio_dev 
> *indio_dev,
>struct iio_chan_spec const *chan)
>  {
>   struct ad7746_chip_info *chip = iio_priv(indio_dev);
> - int ret, delay, idx;
>   u8 vt_setup, cap_setup;
> + int ret, delay, idx;
>  
>   switch (chan->type) {
>   case IIO_CAPACITANCE:
> @@ -289,8 +289,8 @@ static inline ssize_t ad7746_start_calib(struct device 
> *dev,
>  {
>   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>   struct ad7746_chip_info *chip = iio_priv(indio_dev);
> - bool doit;
>   int ret, timeout = 10;
> + bool doit;
>  
>   ret = strtobool(buf, &doit);
>   if (ret < 0)
> @@ -680,8 +680,8 @@ static int ad7746_probe(struct i2c_client *client,
>   struct ad7746_platform_data *pdata = client->dev.platform_data;
>   struct ad7746_chip_info *chip;
>   struct iio_dev *indio_dev;
> - int ret = 0;
>   unsigned char regval = 0;
> + int ret = 0;
>  
>   indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip));
>   if (!indio_dev)

Re: [PATCH 08/30] kconfig: add built-in function support

[Masahiro Yamada]

2018-04-15 16:57 GMT+09:00 Ulf Magnusson :
> On Fri, Apr 13, 2018 at 7:06 AM, Masahiro Yamada
>  wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>   $(function arg1, arg2, arg3, ...)
>>
>> This commit adds the basic infrastructure to expand functions.
>> Change the text expansion helpers to take arguments.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v3:
>>   - Split base infrastructure and 'shell' function
>> into separate patches.
>>
>> Changes in v2:
>>   - Use 'shell' for getting stdout from the comment.
>> It was 'shell-stdout' in the previous version.
>>   - Symplify the implementation since the expansion has been moved to
>> lexer.
>>
>>  scripts/kconfig/preprocess.c | 142 
>> +++
>>  1 file changed, 130 insertions(+), 12 deletions(-)
>>
>> diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
>> index fa4abc8..e77cf7c 100644
>> --- a/scripts/kconfig/preprocess.c
>> +++ b/scripts/kconfig/preprocess.c
>> @@ -8,6 +8,10 @@
>>
>>  #include "list.h"
>>
>> +#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
>> +
>> +static char *expand_string_with_args(const char *in, int argc, char 
>> *argv[]);
>> +
>>  /*
>>   * Environment variables
>>   */
>> @@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
>> }
>>  }
>>
>> -static char *eval_clause(const char *in)
>> +/*
>> + * Built-in Functions
>> + */
>> +struct function {
>> +   char *name;
>> +   char *(*func)(int argc, char *argv[]);
>> +};
>> +
>> +static const struct function function_table[] = {
>> +};
>> +
>> +static char *function_call(const char *name, int argc, char *argv[])
>>  {
>> -   char *res, *name;
>> +   const struct function *f;
>> +   int i;
>> +
>> +   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
>> +   f = &function_table[i];
>> +   if (!strcmp(f->name, name))
>> +   return f->func(argc, argv);
>> +   }
>> +
>> +   return NULL;
>> +}
>> +
>> +#define FUNCTION_MAX_ARGS  16
>> +
>> +/*
>> + * Evaluate a clause with arguments.  argc/argv are arguments from the upper
>> + * function call.
>> + *
>> + * Returned string must be freed when done
>> + */
>> +static char *eval_clause(const char *in, int argc, char *argv[])
>> +{
>> +   char *tmp, *prev, *p, *res, *name;
>> +   char delim = ' ';
>> +   int new_argc = 0;
>> +   char *new_argv[FUNCTION_MAX_ARGS];
>> +   int nest = 0;
>> +   int i;
>>
>> /*
>>  * Returns an empty string because '$()' should be evaluated
>> @@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
>> if (!*in)
>> return xstrdup("");
>>
>> -   name = expand_string(in);
>> +   tmp = xstrdup(in);
>> +
>> +   prev = p = tmp;
>>
>> -   res = env_expand(name);
>> +   /*
>> +* Split into tokens
>> +* The function name and the first argument are separated by a space.
>> +* Arguments are separated by a comma.
>> +* For example, if the function call is like this:
>> +*   $(foo abc,$(x),$(y))
>> +*
>> +* The input string for this helper should be:
>> +*   foo abc,$(x),$(y)
>> +*
>> +* and split into:
>> +*   new_argv[0]: foo
>> +*   new_argv[1]: abc
>> +*   new_argv[2]: $(x)
>> +*   new_argv[3]: $(y)
>> +*/
>> +   while (*p) {
>> +   if (nest == 0 && *p == delim) {
>> +   *p = 0;
>> +   new_argv[new_argc++] = prev;
>
> Erroring out would be nicer than overflowing the array.


OK, will do.





-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 07/14] staging: iio: ad7746: Remove unused defines

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:44 -0300
Hernán Gonzalez  wrote:

> Signed-off-by: Hernán Gonzalez 
> ---
>  drivers/staging/iio/cdc/ad7746.c | 7 ---
>  drivers/staging/iio/cdc/ad7746.h | 5 -
>  2 files changed, 12 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index f53612a..d39ab34 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -25,7 +25,6 @@
>   * AD7746 Register Definition
>   */
>  
> -#define AD7746_REG_STATUS0
>  #define AD7746_REG_CAP_DATA_HIGH 1
>  #define AD7746_REG_VT_DATA_HIGH  4
>  #define AD7746_REG_CAP_SETUP 7
> @@ -38,12 +37,6 @@
>  #define AD7746_REG_CAP_GAINH 15
>  #define AD7746_REG_VOLT_GAINH17
>  
> -/* Status Register Bit Designations (AD7746_REG_STATUS) */
> -#define AD7746_STATUS_EXCERR BIT(3)
> -#define AD7746_STATUS_RDYBIT(2)
> -#define AD7746_STATUS_RDYVT  BIT(1)
> -#define AD7746_STATUS_RDYCAP BIT(0)
> -
There is a pretty strong argument that the driver 'should' be
checking the status register...

I would leave it the defines here.  When they are acting
as 'documentation' of the register layout of a device, they
do little harm and can be very useful.

>  /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) 
> */
>  #define AD7746_CAPSETUP_CAPENBIT(7)
>  #define AD7746_CAPSETUP_CIN2 BIT(6) /* AD7746 only */
> diff --git a/drivers/staging/iio/cdc/ad7746.h 
> b/drivers/staging/iio/cdc/ad7746.h
> index ea8572d..2fbcee8 100644
> --- a/drivers/staging/iio/cdc/ad7746.h
> +++ b/drivers/staging/iio/cdc/ad7746.h
> @@ -13,11 +13,6 @@
>   * TODO: struct ad7746_platform_data needs to go into include/linux/iio
>   */
>  
> -#define AD7466_EXCLVL_0  0 /* +-VDD/8 */
> -#define AD7466_EXCLVL_1  1 /* +-VDD/4 */
> -#define AD7466_EXCLVL_2  2 /* +-VDD * 3/8 */
> -#define AD7466_EXCLVL_3  3 /* +-VDD/2 */
> -

Think about what these are for They aren't unused
if you are actually using platform data on a given oard.

>  struct ad7746_platform_data {
>   unsigned char exclvl;   /*Excitation Voltage Level */
>   bool exca_en;   /* enables EXCA pin as the excitation output */

Re: Linux 3.18.105

[Harsh Shandilya]

On 14 April 2018 1:54:59 AM IST, Greg KH  wrote:
>I'm announcing the release of the 3.18.105 kernel.
>
>All users of the 3.18 kernel series must upgrade.
>
>The updated 3.18.y git tree can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>linux-3.18.y
>and can be browsed at the normal kernel.org git web browser:
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
>
>thanks,
>
>greg k-h
Just realised I actually forgot to report back here after yesterday's tests, 
insomnia's a bitch.

Everything's hunky dory on the OnePlus3T, clean merge and no regressions 
noticed over the past day. Thanks for your continued work on this!
-- 
Harsh Shandilya, PRJKT Development LLC

Re: [PATCH v2 08/14] staging: iio: ad7746: Add dt-bindings

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:45 -0300
Hernán Gonzalez  wrote:

> This patch adds dt bindings by populating a pdata struct in order to
> modify as little as possible the existing code. It supports both
> platform_data and dt-bindings but uses only one depending on
> CONFIG_OF's value.
> 
> Signed-off-by: Hernán Gonzalez 

Please reorder the patches in the next version to put the bindings
patch next to this one (before preferably, but after is fine as
well.)

Hmm. I can see why you want to minimize the effect of the older
code, but given that we will probably (eventually) drop the
platform data option, I wonder if it wouldn't be better
to move the data to a sensible location rather than faking
platform_data.

The pdata is only used in probe and only two bits of
it at that so it would be fine to use some local variables and
fill them from platform data or device tree as appropriate.

Jonathan

> ---
>  drivers/staging/iio/cdc/ad7746.c | 54 
> +++-
>  1 file changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index d39ab34..c29a221 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -666,6 +666,43 @@ static const struct iio_info ad7746_info = {
>  /*
>   * device probe and remove
>   */
> +#ifdef CONFIG_OF
> +static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct ad7746_platform_data *pdata;
> + unsigned int tmp;
> + int ret;
> +
> + /* The default excitation outputs are not inverted, it should be stated
Please use standard multiline comment syntax.

/*
 * The...
 */
> +  * in the dt if needed.
> +  */
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> +
> + ret = of_property_read_u32(np, "adi,exclvl", &tmp);
> + if (ret || tmp > 3) {
> + dev_warn(dev, "Wrong exclvl value, using default\n");

Seems a little odd to have the check in here rather than generic.

> + pdata->exclvl = 3; /* default value */
> + } else {
> + pdata->exclvl = tmp;
> + }
> +
> + pdata->exca_en = true;
> + pdata->excb_en = true;
> + pdata->exca_inv_en = of_property_read_bool(np, "adi,nexca_en");
> + pdata->excb_inv_en = of_property_read_bool(np, "adi,nexcb_en");
> +
> + return pdata;
> +}
> +#else
> +static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
> +{
> + return NULL;
> +}
> +#endif
>  
>  static int ad7746_probe(struct i2c_client *client,
>   const struct i2c_device_id *id)
> @@ -676,6 +713,11 @@ static int ad7746_probe(struct i2c_client *client,
>   unsigned char regval = 0;
>   int ret = 0;
>  
> + if (client->dev.of_node)
> + pdata = ad7746_parse_dt(&client->dev);
> + else
> + pdata = client->dev.platform_data;
> +
>   indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip));
>   if (!indio_dev)
>   return -ENOMEM;
> @@ -739,12 +781,22 @@ static const struct i2c_device_id ad7746_id[] = {
>   { "ad7747", 7747 },
>   {}
>  };
> -
>  MODULE_DEVICE_TABLE(i2c, ad7746_id);
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id ad7746_of_match[] = {
> + { .compatible = "adi,ad7745" },
> + { .compatible = "adi,ad7746" },
> + { .compatible = "adi,ad7747" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ad7746_of_match);
> +#endif
> +
>  static struct i2c_driver ad7746_driver = {
>   .driver = {
>   .name = KBUILD_MODNAME,
> + .of_match_table = of_match_ptr(ad7746_of_match),
>   },
>   .probe = ad7746_probe,
>   .id_table = ad7746_id,

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Eric W. Biederman]

Russell King - ARM Linux  writes:

> On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
>> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin  wrote:
>> >
>> > Most uses I've seen do nothing more than use the FPE_xyz value to
>> > format diagnostic messages while dying.  I struggled to find code that
>> > made a meaningful functional decision based on the value, though that's
>> > not proof...
>> 
>> Yeah. I've seen code that cares about SIGFPE deeply, but it's almost
>> invariably about some emulated environment (eg Java VM, or CPU
>> emulation).
>> 
>> And the siginfo data is basically never good enough for those
>> environments anyway on its own, so they will go and look at the actual
>> instruction that caused the fault and the register state instead,
>> because they need *all* the information.
>> 
>> The cases that use si_code are the ones that just trapped signals in
>> order to give a more helpful abort message.
>> 
>> So I could certainly imagine that si_code is actually used by somebody
>> who then decides to actuall act differently on it, but aside from
>> perhaps printing out a different message, it sounds far-fetched.
>
> Okay, in that case let's just use FPE_FLTINV.  That makes the patch
> easily back-portable for stable kernels.

If we want to I don't think  backporting 266da65e9156 ("signal: Add
FPE_FLTUNK si_code for undiagnosable fp exceptions") would be at
all difficult.

What it is changing has been stable for quite a while.  The surroundings
might change and so it might require some trivial manual fixup but I
don't expect any problems.

Not that I want to derail the consensus but if we want to backport
similar fixes for arm64 or the other architectures that wind up using
FPE_FLTUNK for their fix we would need to backport 266da65e9156 anyway.

Eric

Re: [PATCH v2 09/14] staging: iio: ad7746: Add remove()

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:46 -0300
Hernán Gonzalez  wrote:

> This allows the driver to be probed and removed as a module powering it
> down on remove().
> 
> Signed-off-by: Hernán Gonzalez 
> ---
>  drivers/staging/iio/cdc/ad7746.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index c29a221..05506bf9 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -775,6 +775,31 @@ static int ad7746_probe(struct i2c_client *client,
>   return 0;
>  }
>  
> +static int ad7746_remove(struct i2c_client *client)
> +{
> + struct iio_dev *indio_dev = i2c_get_clientdata(client);
> + struct ad7746_chip_info *chip = iio_priv(indio_dev);
> + unsigned char regval;
> + int ret;
> +
> + mutex_lock(&chip->lock);
> +
> + regval = chip->config | AD7746_CONF_MODE_PWRDN;
> + ret = i2c_smbus_write_byte_data(chip->client, AD7746_REG_CFG, regval);
As this is a one off operation, perhaps it would be better to factor
it out to a utility function then use devm_add_action_or_reset in
the probe?

Also, I am nervous about this change as there doesn't seem to be
path in probe by which this is deliberately reversed?
It seems to be 'accidentally' handled by the read_raw write to the
CFG register.

The data sheet doesn't really mention much about this register
at all.  It may have special requirements to exit from power down - I have
no idea, but if it is costless, why do we bother with idle mode?

Perhaps Michael can confirm if this is safe to do or not.


> +
> + mutex_unlock(&chip->lock);
> +
> + if (ret < 0) {
> + dev_warn(&client->dev, "Could NOT Power Down!\n");
> + goto out;
> + }
> +
> + iio_device_unregister(indio_dev);
You can't safely do this against the devm_iio_device_register.

> +
> +out:
> + return ret;
> +}
> +
>  static const struct i2c_device_id ad7746_id[] = {
>   { "ad7745", 7745 },
>   { "ad7746", 7746 },
> @@ -799,6 +824,7 @@ static struct i2c_driver ad7746_driver = {
>   .of_match_table = of_match_ptr(ad7746_of_match),
>   },
>   .probe = ad7746_probe,
> + .remove = ad7746_remove,
>   .id_table = ad7746_id,
>  };
>  module_i2c_driver(ad7746_driver);

Re: [PATCH v2 10/14] staging: iio: ad7746: Add comments

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:47 -0300
Hernán Gonzalez  wrote:

> Add comments to clarify some of the calculations made, specially when
> reading or writing values.
> 
Mostly good, but a few minor comments.

Jonathan

> Signed-off-by: Hernán Gonzalez 
> ---
>  drivers/staging/iio/cdc/ad7746.c | 32 +++-
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> index 05506bf9..ef0ebb5 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -429,6 +429,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
>   goto out;
>   }
>  
> + /* 2^16 in micro */
I'm not seeing the connection...  what is 2^16?

>   val = (val2 * 1024) / 15625;
>  
>   switch (chan->type) {
> @@ -554,6 +555,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out;
>  
> + /*
> +  * Either for Capacitance, Voltage or Temperature,
> +  * the 0x00 code represents negative full scale,
> +  * the 0x80 code represents zero scale, and
> +  * the 0xFF code represents positive full scale.
> +  */
> +
>   *val = (be32_to_cpu(chip->data.d32) & 0xFF) - 0x80;
>  
>   switch (chan->type) {
> @@ -565,7 +573,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   *val = (*val * 125) / 256;
>   break;
>   case IIO_VOLTAGE:
> - if (chan->channel == 1) /* supply_raw*/
> +
> + /*
> +  * The voltage from the VDD pin is internally
> +  * attenuated by 6.
> +  */
> +
> + if (chan->channel == 1) /* supply_raw */
>   *val = *val * 6;
>   break;
>   default:
> @@ -606,6 +620,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   ret = IIO_VAL_INT;
>   break;
>   case IIO_CHAN_INFO_OFFSET:
> +
> + /*
> +  * CAPDAC Scale = 21pF_typ / 127
> +  * CIN Scale = 8.192pF / 2^24
> +  * Offset Scale = CAPDAC Scale / CIN Scale = 338646
> +  */
I don't think the following blank line does much other than make
it less clear what the comment is about.

Same in other locations. Allow the absence of a blank line on one
side of the comment to indicate it's association.


> +
>   *val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
> [chan->differential]) * 338646;
>  
> @@ -614,13 +635,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_SCALE:
>   switch (chan->type) {
>   case IIO_CAPACITANCE:
> - /* 8.192pf / 2^24 */
> + /* CIN Scale: 8.192pf / 2^24 */
>   *val =  0;
>   *val2 = 488;
>   ret = IIO_VAL_INT_PLUS_NANO;
>   break;
>   case IIO_VOLTAGE:
> - /* 1170mV / 2^23 */
> + /* VIN Scale: 1170mV / 2^23 */
>   *val = 1170;
>   *val2 = 23;
>   ret = IIO_VAL_FRACTIONAL_LOG2;
> @@ -674,7 +695,8 @@ static struct ad7746_platform_data 
> *ad7746_parse_dt(struct device *dev)
>   unsigned int tmp;
>   int ret;
>  
> - /* The default excitation outputs are not inverted, it should be stated
> + /*
> +  * The default excitation outputs are not inverted, it should be stated
>* in the dt if needed.
>*/
>  
> @@ -685,7 +707,7 @@ static struct ad7746_platform_data 
> *ad7746_parse_dt(struct device *dev)
>   ret = of_property_read_u32(np, "adi,exclvl", &tmp);
>   if (ret || tmp > 3) {
>   dev_warn(dev, "Wrong exclvl value, using default\n");
> - pdata->exclvl = 3; /* default value */
> + pdata->exclvl = 3;
>   } else {
>   pdata->exclvl = tmp;
>   }

Re: [PATCH v2 11/14] staging: iio: ad7746: Add devicetree bindings documentation

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:48 -0300
Hernán Gonzalez  wrote:

> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Hernán Gonzalez 
A few comments inline.

Thanks,

Jonathan

> ---
>  .../devicetree/bindings/staging/iio/cdc/ad7746.txt | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
> 
> diff --git a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt 
> b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
> new file mode 100644
> index 000..7740f05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
> @@ -0,0 +1,34 @@
> +Analog Devices AD7746/5/7 capacitive sensor driver
> +
> +Required properties:
> + - compatible: Should be one of
> + * "adi,ad7745"
> + * "adi,ad7746"
> +   * "adi,ad7747"
> + - reg: The 7-bits long I2c address of the device
> +
> +Optional properties:
> + - adi,exclvl: This property defines the excitation voltage level for the
> +capacitance to be measured. Possible values are:
> +  * 0 = +-VDD/8
> +  * 1 = +-VDD/4
> +  * 2 = +-VDD * 3/8
> +  * 3 = +-VDD/2 (Default)
> + - adi,nexca_en: Invert excitation output A.

The naming is rather odd.  Why _en?

> + - adi,nexcb_en: Invert excitation output B.
> +
> +Example:
> +Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
> +Excitation pin B would NOT be inverted.
> +
> +i2c2 {
> +
> +  < . . . >
What does this spacer add to the example?
Sure, there can be other devices, but no need to illustrate that here.

> +
> +  ad7746: ad7746@60 {
> +  compatible = "ad7746";
> +  reg = <0x60>;
> +  adi,exclvl = <1>;
> +  adi,nexca_en;
> +  };
> +};

Re: [PATCH v2 12/14] staging: iio: ad7746: Add ABI documentation

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:49 -0300
Hernán Gonzalez  wrote:

> The use cases for this driver don't comply with the current ABI. The
> ad7746 and ad7152 need an external capacitance or voltage reference to
> automatically calibrate themselves which is not the normal use case of
> the calibscale and calibbias ABIs, a new ABI was needed.

I agree with the general aim here.  Would appreciate input from Michael
in particular on these + ideally others!

One comment inline,

Thanks,

Jonathan

> 
> Signed-off-by: Hernán Gonzalez 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio-ad7746 | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-ad7746
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-ad7746 
> b/Documentation/ABI/testing/sysfs-bus-iio-ad7746
> new file mode 100644
> index 000..96a41b7
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-ad7746
> @@ -0,0 +1,17 @@
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_capacitanceX_calibscale_calibration
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_voltage0_calibscale_calibration

Hmm. I wonder if indicating that it causes calibration would be better done by
in_voltage0_calibscale_calibrate

> +KernelVersion:   4.17.0
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Enter gain calibration mode, in which a full-scale
> + {capacitance, voltage reference} must be connected to the
> + {capacitance, voltage} input beforehand to automatically
> + calibrate the device.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_capacitanceX_calibbias_calibration
> +KernelVersion:   4.17.0
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Enter offset calibration mode, in which a zero-scale
> + capacitance must be connected to the capacitance input
> + beforehand to automatically calibrate the device.

Re: [PATCH v2 14/14] staging: iio: Remove ad7746 from staging

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:51 -0300
Hernán Gonzalez  wrote:

> Signed-off-by: Hernán Gonzalez 
Please have a single patch (with move detection turned off) for this and the
previous.

Allows easy review by showing us the code but doesn't lead to a stage in which
two different versions will build and hence probably break bisectiblity.

Jonathan

> ---
>  .../devicetree/bindings/staging/iio/cdc/ad7746.txt |  34 -
>  drivers/staging/iio/cdc/Kconfig|  10 -
>  drivers/staging/iio/cdc/Makefile   |   1 -
>  drivers/staging/iio/cdc/ad7746.c   | 856 
> -
>  drivers/staging/iio/cdc/ad7746.h   |  24 -
>  5 files changed, 925 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
>  delete mode 100644 drivers/staging/iio/cdc/ad7746.c
>  delete mode 100644 drivers/staging/iio/cdc/ad7746.h
> 
> diff --git a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt 
> b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
> deleted file mode 100644
> index 7740f05..000
> --- a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -Analog Devices AD7746/5/7 capacitive sensor driver
> -
> -Required properties:
> - - compatible: Should be one of
> - * "adi,ad7745"
> - * "adi,ad7746"
> -   * "adi,ad7747"
> - - reg: The 7-bits long I2c address of the device
> -
> -Optional properties:
> - - adi,exclvl: This property defines the excitation voltage level for the
> -capacitance to be measured. Possible values are:
> -  * 0 = +-VDD/8
> -  * 1 = +-VDD/4
> -  * 2 = +-VDD * 3/8
> -  * 3 = +-VDD/2 (Default)
> - - adi,nexca_en: Invert excitation output A.
> - - adi,nexcb_en: Invert excitation output B.
> -
> -Example:
> -Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
> -Excitation pin B would NOT be inverted.
> -
> -i2c2 {
> -
> -  < . . . >
> -
> -  ad7746: ad7746@60 {
> -  compatible = "ad7746";
> -  reg = <0x60>;
> -  adi,exclvl = <1>;
> -  adi,nexca_en;
> -  };
> -};
> diff --git a/drivers/staging/iio/cdc/Kconfig b/drivers/staging/iio/cdc/Kconfig
> index 80211df..a170ab3 100644
> --- a/drivers/staging/iio/cdc/Kconfig
> +++ b/drivers/staging/iio/cdc/Kconfig
> @@ -23,14 +23,4 @@ config AD7152
> To compile this driver as a module, choose M here: the
> module will be called ad7152.
>  
> -config AD7746
> - tristate "Analog Devices AD7745, AD7746 AD7747 capacitive sensor driver"
> - depends on I2C
> - help
> -   Say yes here to build support for Analog Devices capacitive sensors.
> -   (AD7745, AD7746, AD7747) Provides direct access via sysfs.
> -
> -   To compile this driver as a module, choose M here: the
> -   module will be called ad7746.
> -
>  endmenu
> diff --git a/drivers/staging/iio/cdc/Makefile 
> b/drivers/staging/iio/cdc/Makefile
> index a5fbabf..5db1acd 100644
> --- a/drivers/staging/iio/cdc/Makefile
> +++ b/drivers/staging/iio/cdc/Makefile
> @@ -4,4 +4,3 @@
>  
>  obj-$(CONFIG_AD7150) += ad7150.o
>  obj-$(CONFIG_AD7152) += ad7152.o
> -obj-$(CONFIG_AD7746) += ad7746.o
> diff --git a/drivers/staging/iio/cdc/ad7746.c 
> b/drivers/staging/iio/cdc/ad7746.c
> deleted file mode 100644
> index ef0ebb5..000
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ /dev/null
> @@ -1,856 +0,0 @@
> -/*
> - * AD7746 capacitive sensor driver supporting AD7745, AD7746 and AD7747
> - *
> - * Copyright 2011 Analog Devices Inc.
> - *
> - * Licensed under the GPL-2.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -#include "ad7746.h"
> -
> -/*
> - * AD7746 Register Definition
> - */
> -
> -#define AD7746_REG_CAP_DATA_HIGH 1
> -#define AD7746_REG_VT_DATA_HIGH  4
> -#define AD7746_REG_CAP_SETUP 7
> -#define AD7746_REG_VT_SETUP  8
> -#define AD7746_REG_EXC_SETUP 9
> -#define AD7746_REG_CFG   10
> -#define AD7746_REG_CAPDACA   11
> -#define AD7746_REG_CAPDACB   12
> -#define AD7746_REG_CAP_OFFH  13
> -#define AD7746_REG_CAP_GAINH 15
> -#define AD7746_REG_VOLT_GAINH17
> -
> -/* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) 
> */
> -#define AD7746_CAPSETUP_CAPENBIT(7)
> -#define AD7746_CAPSETUP_CIN2 BIT(6) /* AD7746 only */
> -#define AD7746_CAPSETUP_CAPDIFF  BIT(5)
> -#define AD7746_CAPSETUP_CACHOP   BIT(0)
> -
> -/* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) 
> */
> -#define AD7746_VTSETUP_VTEN  (1 << 7)
> -#define AD7746_VTSETUP_VTMD_INT_TEMP (0 << 5)
> -#define AD7746_VTSETUP_VTMD_EXT_TEMP (1 << 5)
> -#define AD7746_VTSETUP_VTMD_VDD_MON  (

[RFC PATCH 0/3] Dealing with the aliases of SI_USER

[Eric W. Biederman]

Linus,

Would you consider the patchset below for -rc2?

Dealing with the aliases of SI_USER has been a challenge as we have had
a b0rked ABI in some cases since 2.5.

So far no one except myself has suggested that changing the si_code of
from 0 to something else for those problematic aliases of SI_USER is
going to be a problem.  So it looks like just fixing the issue is a real
possibility.

Fixing the cases that do kill(SIGFPE, ...) because at least test cases
care seems important.

The best fixes to backport appear to be the real architecture fixes that
remove the aliases for SI_USER as those are deep fixes that
fundamentally fix the problems, and are also very small changes.

I am not yet brave enough to merge architectural fixes like that without
arch maintainers buy-in.   Getting at least an ack if nothing else takes
a little bit of time.

Still we have a arm fix upthread and David Miller has given his nod
to a sparc fix that uses FPE_FLTUNK.  So it appears real architecture
fixes are progressing.  Further I have looked and that leaves only
powerpc, parisc, ia64, and alpha.   The new si_code FPE_FLTUNK appears
to address most of those, and there is an untested patch for parisc.

So real progress appears possible.

The generic code can do better, and that is what this rfc patchset is
about.  It ensures siginfo is fully initialized and uses copy_to_user
to copy siginfo to userspace.  This takes siginfo_layout out of
the picture and so for non-compat non-signalfd siginfos the status
quo returns to what it was before I introduced siginfo_layout (AKA
regressions go bye-bye).

I believe given the issues these changes are a candiate for -rc2.
Otherwise I will keep these changes for the next merge window.

Eric W. Biederman (3):
  signal: Ensure every siginfo we send has all bits initialized
  signal: Reduce copy_siginfo_to_user to just copy_to_user
  signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

 arch/alpha/kernel/osf_sys.c   |  1 +
 arch/alpha/kernel/signal.c|  2 +
 arch/alpha/kernel/traps.c |  5 ++
 arch/alpha/mm/fault.c |  2 +
 arch/arc/mm/fault.c   |  2 +
 arch/arm/kernel/ptrace.c  |  1 +
 arch/arm/kernel/swp_emulate.c |  1 +
 arch/arm/kernel/traps.c   |  5 ++
 arch/arm/mm/alignment.c   |  1 +
 arch/arm/mm/fault.c   |  5 ++
 arch/arm/vfp/vfpmodule.c  |  3 +-
 arch/arm64/kernel/fpsimd.c|  2 +-
 arch/arm64/kernel/sys_compat.c|  1 +
 arch/arm64/kernel/traps.c |  1 +
 arch/arm64/mm/fault.c | 18 --
 arch/c6x/kernel/traps.c   |  1 +
 arch/hexagon/kernel/traps.c   |  1 +
 arch/hexagon/mm/vm_fault.c|  1 +
 arch/ia64/kernel/brl_emu.c|  1 +
 arch/ia64/kernel/signal.c |  2 +
 arch/ia64/kernel/traps.c  | 27 -
 arch/ia64/kernel/unaligned.c  |  1 +
 arch/ia64/mm/fault.c  |  4 +-
 arch/m68k/kernel/traps.c  |  2 +
 arch/microblaze/kernel/exceptions.c   |  1 +
 arch/microblaze/mm/fault.c|  4 +-
 arch/mips/mm/fault.c  |  1 +
 arch/nds32/kernel/traps.c |  6 +-
 arch/nds32/mm/fault.c |  1 +
 arch/nios2/kernel/traps.c |  1 +
 arch/openrisc/kernel/traps.c  |  5 +-
 arch/openrisc/mm/fault.c  |  1 +
 arch/parisc/kernel/ptrace.c   |  1 +
 arch/parisc/kernel/traps.c|  2 +
 arch/parisc/kernel/unaligned.c|  1 +
 arch/parisc/math-emu/driver.c |  1 +
 arch/parisc/mm/fault.c|  1 +
 arch/powerpc/kernel/process.c |  1 +
 arch/powerpc/kernel/traps.c   |  3 +-
 arch/powerpc/mm/fault.c   |  1 +
 arch/powerpc/platforms/cell/spufs/fault.c |  2 +-
 arch/riscv/kernel/traps.c |  1 +
 arch/s390/kernel/traps.c  |  5 +-
 arch/s390/mm/fault.c  |  2 +
 arch/sh/kernel/hw_breakpoint.c|  1 +
 arch/sh/kernel/traps_32.c |  2 +
 arch/sh/math-emu/math.c   |  1 +
 arch/sh/mm/fault.c|  1 +
 arch/sparc/kernel/process_64.c|  1 +
 arch/sparc/kernel/sys_sparc_32.c  |  1 +
 arch/sparc/kernel/traps_32.c  | 10 
 arch/sparc/kernel/traps_64.c  | 14 +
 arch/sparc/kernel/unaligned_32.c  |  1 +
 arch/sparc/mm/fault_32.c  |  1 +
 arch/sparc/mm/fault_64.c  |  1 +
 arch/um/kernel/trap.c |  2 +
 arch/unicore32/kernel/fpu-ucf64.c |  2 +-
 arch/unicore32/mm/fault.c |  3 +
 arch/x86/entry/vsyscall/vsyscall_64.c |  2 +-
 arch/x86/kernel/ptrace.c  |  2 +

[RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

[Eric W. Biederman]

Call clear_siginfo to ensure every stack allocated siginfo is properly
initialized before being passed to the signal sending functions.

Note: It is not safe to depend on C initializers to initialize struct
siginfo on the stack because C is allowed to skip holes when
initializing a structure.

The initialization of struct siginfo in tracehook_report_syscall_exit
was moved from the helper user_single_step_siginfo into
tracehook_report_syscall_exit itself, to make it clear that the local
variable siginfo gets fully initialized.

In a few cases the scope of struct siginfo has been reduced to make it
clear that siginfo siginfo is not used on other paths in the function
in which it is declared.

Instances of using memset to initialize siginfo have been replaced
with calls clear_siginfo for clarity.

Signed-off-by: "Eric W. Biederman" 
---
 arch/alpha/kernel/osf_sys.c   |  1 +
 arch/alpha/kernel/signal.c|  2 ++
 arch/alpha/kernel/traps.c |  5 +
 arch/alpha/mm/fault.c |  2 ++
 arch/arc/mm/fault.c   |  2 ++
 arch/arm/kernel/ptrace.c  |  1 +
 arch/arm/kernel/swp_emulate.c |  1 +
 arch/arm/kernel/traps.c   |  5 +
 arch/arm/mm/alignment.c   |  1 +
 arch/arm/mm/fault.c   |  5 +
 arch/arm/vfp/vfpmodule.c  |  3 +--
 arch/arm64/kernel/fpsimd.c|  2 +-
 arch/arm64/kernel/sys_compat.c|  1 +
 arch/arm64/kernel/traps.c |  1 +
 arch/arm64/mm/fault.c | 18 --
 arch/c6x/kernel/traps.c   |  1 +
 arch/hexagon/kernel/traps.c   |  1 +
 arch/hexagon/mm/vm_fault.c|  1 +
 arch/ia64/kernel/brl_emu.c|  1 +
 arch/ia64/kernel/signal.c |  2 ++
 arch/ia64/kernel/traps.c  | 27 ---
 arch/ia64/kernel/unaligned.c  |  1 +
 arch/ia64/mm/fault.c  |  4 +++-
 arch/m68k/kernel/traps.c  |  2 ++
 arch/microblaze/kernel/exceptions.c   |  1 +
 arch/microblaze/mm/fault.c|  4 +++-
 arch/mips/mm/fault.c  |  1 +
 arch/nds32/kernel/traps.c |  6 +-
 arch/nds32/mm/fault.c |  1 +
 arch/nios2/kernel/traps.c |  1 +
 arch/openrisc/kernel/traps.c  |  5 -
 arch/openrisc/mm/fault.c  |  1 +
 arch/parisc/kernel/ptrace.c   |  1 +
 arch/parisc/kernel/traps.c|  2 ++
 arch/parisc/kernel/unaligned.c|  1 +
 arch/parisc/math-emu/driver.c |  1 +
 arch/parisc/mm/fault.c|  1 +
 arch/powerpc/kernel/process.c |  1 +
 arch/powerpc/kernel/traps.c   |  3 +--
 arch/powerpc/mm/fault.c   |  1 +
 arch/powerpc/platforms/cell/spufs/fault.c |  2 +-
 arch/riscv/kernel/traps.c |  1 +
 arch/s390/kernel/traps.c  |  5 -
 arch/s390/mm/fault.c  |  2 ++
 arch/sh/kernel/hw_breakpoint.c|  1 +
 arch/sh/kernel/traps_32.c |  2 ++
 arch/sh/math-emu/math.c   |  1 +
 arch/sh/mm/fault.c|  1 +
 arch/sparc/kernel/process_64.c|  1 +
 arch/sparc/kernel/sys_sparc_32.c  |  1 +
 arch/sparc/kernel/traps_32.c  | 10 ++
 arch/sparc/kernel/traps_64.c  | 14 ++
 arch/sparc/kernel/unaligned_32.c  |  1 +
 arch/sparc/mm/fault_32.c  |  1 +
 arch/sparc/mm/fault_64.c  |  1 +
 arch/um/kernel/trap.c |  2 ++
 arch/unicore32/kernel/fpu-ucf64.c |  2 +-
 arch/unicore32/mm/fault.c |  3 +++
 arch/x86/entry/vsyscall/vsyscall_64.c |  2 +-
 arch/x86/kernel/ptrace.c  |  2 +-
 arch/x86/kernel/traps.c   |  3 +++
 arch/x86/kernel/umip.c|  1 +
 arch/x86/kvm/mmu.c|  1 +
 arch/x86/mm/fault.c   |  1 +
 arch/xtensa/kernel/traps.c|  1 +
 arch/xtensa/mm/fault.c|  1 +
 include/linux/ptrace.h|  1 -
 include/linux/tracehook.h |  1 +
 virt/kvm/arm/mmu.c|  1 +
 69 files changed, 163 insertions(+), 24 deletions(-)

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 89faa6f4de47..8ad689d6a0e4 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -881,6 +881,7 @@ SYSCALL_DEFINE5(osf_setsysinfo, unsigned long, op, void 
__user *, buffer,
if (fex & IEEE_TRAP_ENABLE_DZE) si_code = FPE_FLTDIV;
if (fex & IEEE_TRAP_ENABLE_INV) si_code = FPE_FLTINV;
 
+   clear_siginfo(&info);
info.si_signo = SIGFPE;
   

[RFC PATCH 2/3] signal: Reduce copy_siginfo_to_user to just copy_to_user

[Eric W. Biederman]

Now that every instance of struct siginfo is now initialized it is no
longer necessary to copy struct siginfo piece by piece to userspace
but instead the entire structure can be copied.

As well as making the code simpler and more efficient this means that
copy_sinfo_to_user no longer cares which union member of struct
siginfo is in use.

In practice this means that all 32bit architectures that define
FPE_FIXME will handle properly send SI_USER when kill(SIGFPE) is sent.
While still performing their historic architectural brokenness when 0
is used a floating pointer signal.  This matches the current behavior
of 64bit architectures that define FPE_FIXME who get lucky and an
overloaded SI_USER has continuted to work through copy_siginfo_to_user
because the 8 byte si_addr occupies the same bytes in struct siginfo
as the 4 byte si_pid and the 4 byte si_uid.

Problematic architectures still need to fix their ABI so that signalfd
and 32bit compat code will work properly.

Signed-off-by: "Eric W. Biederman" 
---
 kernel/signal.c | 84 ++---
 1 file changed, 2 insertions(+), 82 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index d4ccea599692..d56f4d496c89 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2850,89 +2850,9 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
 
 int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
 {
-   int err;
-
-   if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t)))
+   if (copy_to_user(to, from , sizeof(struct siginfo)))
return -EFAULT;
-   if (from->si_code < 0)
-   return __copy_to_user(to, from, sizeof(siginfo_t))
-   ? -EFAULT : 0;
-   /*
-* If you change siginfo_t structure, please be sure
-* this code is fixed accordingly.
-* Please remember to update the signalfd_copyinfo() function
-* inside fs/signalfd.c too, in case siginfo_t changes.
-* It should never copy any pad contained in the structure
-* to avoid security leaks, but must copy the generic
-* 3 ints plus the relevant union member.
-*/
-   err = __put_user(from->si_signo, &to->si_signo);
-   err |= __put_user(from->si_errno, &to->si_errno);
-   err |= __put_user(from->si_code, &to->si_code);
-   switch (siginfo_layout(from->si_signo, from->si_code)) {
-   case SIL_KILL:
-   err |= __put_user(from->si_pid, &to->si_pid);
-   err |= __put_user(from->si_uid, &to->si_uid);
-   break;
-   case SIL_TIMER:
-   /* Unreached SI_TIMER is negative */
-   break;
-   case SIL_POLL:
-   err |= __put_user(from->si_band, &to->si_band);
-   err |= __put_user(from->si_fd, &to->si_fd);
-   break;
-   case SIL_FAULT:
-   err |= __put_user(from->si_addr, &to->si_addr);
-#ifdef __ARCH_SI_TRAPNO
-   err |= __put_user(from->si_trapno, &to->si_trapno);
-#endif
-#ifdef __ia64__
-   err |= __put_user(from->si_imm, &to->si_imm);
-   err |= __put_user(from->si_flags, &to->si_flags);
-   err |= __put_user(from->si_isr, &to->si_isr);
-#endif
-   /*
-* Other callers might not initialize the si_lsb field,
-* so check explicitly for the right codes here.
-*/
-#ifdef BUS_MCEERR_AR
-   if (from->si_signo == SIGBUS && from->si_code == BUS_MCEERR_AR)
-   err |= __put_user(from->si_addr_lsb, &to->si_addr_lsb);
-#endif
-#ifdef BUS_MCEERR_AO
-   if (from->si_signo == SIGBUS && from->si_code == BUS_MCEERR_AO)
-   err |= __put_user(from->si_addr_lsb, &to->si_addr_lsb);
-#endif
-#ifdef SEGV_BNDERR
-   if (from->si_signo == SIGSEGV && from->si_code == SEGV_BNDERR) {
-   err |= __put_user(from->si_lower, &to->si_lower);
-   err |= __put_user(from->si_upper, &to->si_upper);
-   }
-#endif
-#ifdef SEGV_PKUERR
-   if (from->si_signo == SIGSEGV && from->si_code == SEGV_PKUERR)
-   err |= __put_user(from->si_pkey, &to->si_pkey);
-#endif
-   break;
-   case SIL_CHLD:
-   err |= __put_user(from->si_pid, &to->si_pid);
-   err |= __put_user(from->si_uid, &to->si_uid);
-   err |= __put_user(from->si_status, &to->si_status);
-   err |= __put_user(from->si_utime, &to->si_utime);
-   err |= __put_user(from->si_stime, &to->si_stime);
-   break;
-   case SIL_RT:
-   err |= __put_user(from->si_pid, &to->si_pid);
-   err |= __put_user(from->si_uid, &to->si_uid);
-   err |= __put_user(from->si_ptr, &to->si_ptr);
-   break;
-   case SIL_SYS:
-   err |= __put_user(from->si_call_addr, &to->si_call_addr);

[RFC PATCH 3/3] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout

[Eric W. Biederman]

After more experience with the cases where no one the si_code of 0 is
used both as a signal specific si_code, and as SI_USER it appears that
no one cares about the signal specific si_code case and the good
solution is to just fix the architectures by using a different si_code.

In none of the conversations has anyone even suggested that anything
depends on the signal specific redefinition of SI_USER.

There are at least test cases that care when si_code as 0 does not work
as si_user.

So make things simple and keep the generic code from introducing
problems by removing the special casing of TRAP_FIXME and FPE_FIXME.
This will ensure the generic case of sending a signal with kill will
always set SI_USER and work.

The architecture specific, and signal specific overloads that set
si_code to 0 will now have problems with signalfd and the 32bit compat
versions of siginfo copying.  At least until they are fixed.

Signed-off-by: "Eric W. Biederman" 
---
 kernel/signal.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index d56f4d496c89..fc82d2c0918f 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2835,15 +2835,6 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
layout = SIL_POLL;
else if (si_code < 0)
layout = SIL_RT;
-   /* Tests to support buggy kernel ABIs */
-#ifdef TRAP_FIXME
-   if ((sig == SIGTRAP) && (si_code == TRAP_FIXME))
-   layout = SIL_FAULT;
-#endif
-#ifdef FPE_FIXME
-   if ((sig == SIGFPE) && (si_code == FPE_FIXME))
-   layout = SIL_FAULT;
-#endif
}
return layout;
 }
-- 
2.14.1

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Kees Cook]

On Sun, Apr 15, 2018 at 6:28 AM, Masahiro Yamada
 wrote:
> In my Makefile ...
>
> stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
> stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
> stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong
>
> KBUILD_CFLAGS += $(stackp-flags-y)
>
> the last one is picked.

Ah! Yes, sorry for the noise. I see the := instead of += now. Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[PATCH] arm64: export tishift functions to modules

[Jason A. Donenfeld]

Otherwise modules that use these arithmetic operations will fail to
link. We accomplish this with EXPORT_SYMBOL in the .S file, but because
of symbol versioning, we actually need to have a declaration of these
too in C. So, we introduce asm-prototypes.h, which is the same file name
and technique used for similar reasons in the m68k arch tree.

While we're at it, we also fix this up to use SPDX, and I personally
choose to relicense this as GPL2||BSD so that these symbols don't need
to be export_symbol_gpl, so all modules can use the routines, since
these are important general purpose compiler-generated function calls.

Signed-off-by: Jason A. Donenfeld 
Reported-by: PaX Team 
Cc: sta...@vger.kernel.org
---
 arch/arm64/include/asm/asm-prototypes.h | 11 +++
 arch/arm64/lib/tishift.S| 19 ++-
 2 files changed, 17 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm64/include/asm/asm-prototypes.h

diff --git a/arch/arm64/include/asm/asm-prototypes.h 
b/arch/arm64/include/asm/asm-prototypes.h
new file mode 100644
index ..8f1919e44f51
--- /dev/null
+++ b/arch/arm64/include/asm/asm-prototypes.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+ *
+ * Copyright (C) 2017-2018 Jason A. Donenfeld . All Rights 
Reserved.
+ */
+
+/* These functions are defined in lib/tishift.S, but need to be declared
+ * here so that symbol versioning picks them up.
+ */
+extern long long __ashlti3(long long a, int b);
+extern long long __ashrti3(long long a, int b);
+extern long long __lshrti3(long long a, int b);
diff --git a/arch/arm64/lib/tishift.S b/arch/arm64/lib/tishift.S
index d3db9b2cd479..3bca433973cb 100644
--- a/arch/arm64/lib/tishift.S
+++ b/arch/arm64/lib/tishift.S
@@ -1,20 +1,10 @@
-/*
- * Copyright (C) 2017 Jason A. Donenfeld . All Rights 
Reserved.
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
+ * Copyright (C) 2017-2018 Jason A. Donenfeld . All Rights 
Reserved.
  */
 
 #include 
+#include 
 
 ENTRY(__ashlti3)
cbz x2, 1f
@@ -36,6 +26,7 @@ ENTRY(__ashlti3)
mov x0, x2
ret
 ENDPROC(__ashlti3)
+EXPORT_SYMBOL(__ashlti3)
 
 ENTRY(__ashrti3)
cbz x2, 1f
@@ -57,6 +48,7 @@ ENTRY(__ashrti3)
mov x1, x2
ret
 ENDPROC(__ashrti3)
+EXPORT_SYMBOL(__ashrti3)
 
 ENTRY(__lshrti3)
cbz x2, 1f
@@ -78,3 +70,4 @@ ENTRY(__lshrti3)
mov x1, x2
ret
 ENDPROC(__lshrti3)
+EXPORT_SYMBOL(__lshrti3)
-- 
2.17.0

Re: linux-next on x60: network manager often complains "network is disabled" after resume

[Pavel Machek]

On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:
> Woody Suwalski wrote:
> >Pavel Machek wrote:
> >>On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> >>>Pavel Machek wrote:
> Hi!
> 
> With recent linux-next, after resume networkmanager often claims that
> "network is disabled". Sometimes suspend/resume clears that.
> 
> Any ideas? Does it work for you?
>     Pavel
> >>>Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> >>Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> >>problem will appear in 4.17-rc1.
> >>
> >Works here OK. Tried ~10 suspends, all restarted OK.
> >kernel next-20180320
> >nmcli shows that Wifi always connects OK
> >
> >Woody
> >
> Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
> I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
> hibernate results in a message:
> Failed to hibernate system via logind: There's already a shutdown or sleep
> operation in progress.
> 
> And ps shows "Ds /lib/systemd/systemd-sleep suspend"...

Problem now seems to be in the mainline.

But no, I don't see systemd-sleep in my process list :-(.

I guess you can't reproduce it easily? I tried bisecting, but while it
happens often enough to make v4.17 hard to use, it does not permit
reliable bisect.

These should be bad according to my notes

b04240a33b99b32cf6fbdf5c943c04e505a0cb07 
 ed80dc19e4dd395c951f745acd1484d61c4cfb20
 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
 4fc97ef94bbfa185d16b3e44199b7559d0668747
 14ebdb2c814f508936fe178a2abc906a16a3ab48
 639adbeef5ae1bb8eeebbb0cde0b885397bde192

bisection claimed

c16add24522547bf52c189b3c0d1ab6f5c2b4375

is first bad commit, but I'm not sure if I trust that.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: linux-next on x60: network manager often complains "network is disabled" after resume

[Pavel Machek]

On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > > 
> > > > Broken state.
> > > > 
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE  TYPE  STATECONNECTION
> > > > eth1ethernet  unavailable  --
> > > > lo  loopback  unmanaged--
> > > > wlan0   wifi  unmanaged--
> > > 
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > > 
> > > We should probably move this discussion to the NM lists to debug
> > > further.  Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> > 
> > Hmm :-)
> > 
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
> 
> What NM version?  'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it.  Anyway, debug would do.

Hmm.

pavel@duo:~$ /usr/sbin/NetworkManager --version
You must be root to run NetworkManager!
pavel@duo:~$ sudo /usr/sbin/NetworkManager --version
0.9.10.0

So I set the log level, but I still don't see much in the log:

Apr 14 18:14:29 duo dbus[3009]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Apr 14 18:14:29 duo nm-dispatcher: Dispatching action 'down' for wlan1
Apr 14 18:14:29 duo systemd[1]: Started Network Manager Script
Dispatcher Service.
Apr 14 18:14:29 duo systemd-sleep[6853]: Suspending system...
Apr 14 21:27:53 duo systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
pavel@duo:~$ date
Sun Apr 15 12:26:32 CEST 2018
pavel@duo:~$

Is it possible that time handling accross suspend changed in v4.17?

I get some weird effects. With display backlight...

> > Where do I get the logs? I don't see much in the syslog...
> 
> > And.. It seems that it is "every other suspend". One resume results
> > in
> > broken network, one in working one, one in broken one...
> 
> Does your distro use pm-utils, upower, or systemd for suspend/resume
> handling?

upower, I guess:

pavel@duo:/data/l/linux$ ps aux | grep upower
root  3820  0.0  0.1  42848  7984 ?Ssl  Apr14   0:01
/usr/lib/upower/upowerd

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] arm64: support __int128 with clang

[Jason A. Donenfeld]

Hi Will,

Would you review/merge this when you have a chance?

Thanks,
Jason

On Sat, Dec 23, 2017 at 1:43 AM, Jason A. Donenfeld  wrote:
> Commit fb8722735f50 ("arm64: support __int128 on gcc 5+") added support
> for arm64 __int128 with gcc with a version-conditional, but neglected to
> enable this for clang, which in fact appears to support aarch64 __int128.
> This commit therefore enables it if the compiler is clang, using the
> same type of makefile conditional used elsewhere in the tree.
>
> Signed-off-by: Jason A. Donenfeld 
> ---
>  arch/arm64/Makefile | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index b481b4a7c011..16c2e8b58546 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -57,7 +57,11 @@ KBUILD_AFLAGS+= $(lseinstr) $(brokengasinst)
>  KBUILD_CFLAGS  += $(call cc-option,-mabi=lp64)
>  KBUILD_AFLAGS  += $(call cc-option,-mabi=lp64)
>
> +ifeq ($(cc-name),clang)
> +KBUILD_CFLAGS  += -DCONFIG_ARCH_SUPPORTS_INT128
> +else
>  KBUILD_CFLAGS  += $(call cc-ifversion, -ge, 0500, 
> -DCONFIG_ARCH_SUPPORTS_INT128)
> +endif
>
>  ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
>  KBUILD_CPPFLAGS+= -mbig-endian
> --
> 2.15.1
>

Re: [PATCH v2 13/14] Move ad7746 out of staging

[Jonathan Cameron]

On Fri, 13 Apr 2018 13:36:50 -0300
Hernán Gonzalez  wrote:

> Signed-off-by: Hernán Gonzalez 
A few comments inline.

Also nice to have a bit of a description of the driver in the patch
moving it out of staging.  It's a patch people might actually notice
as to many people it is some new hardware support (as they won't run
staging drivers).

A few comments inline, including some I missed in earlier patches that
could do with tidying up.  Ideally I'd like to see if Michael can
sanity check that the driver actually works.  If that is going to
take a while, I don't mind moving it on the basis we'll fix up any
issues that show up at a later date.

Thanks for your hard work on this.

Jonathan

> ---
>  .../devicetree/bindings/iio/cdc/ad7746.txt |  34 +

Hmm. Thinking about it, there is no actual need for the driver to be out of 
staging
to put the devicetree bindings in place outside staging.
I would do that in the first place rather than introducing them then moving 
them a few patches later.


>  drivers/iio/Kconfig|   1 +
>  drivers/iio/Makefile   |   1 +
>  drivers/iio/cdc/Kconfig|  16 +
>  drivers/iio/cdc/Makefile   |   5 +
>  drivers/iio/cdc/ad7746.c   | 855 
> +
>  include/linux/iio/cdc/ad7746.h |  20 +
>  7 files changed, 932 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/cdc/ad7746.txt
>  create mode 100644 drivers/iio/cdc/Kconfig
>  create mode 100644 drivers/iio/cdc/Makefile
>  create mode 100644 drivers/iio/cdc/ad7746.c
>  create mode 100644 include/linux/iio/cdc/ad7746.h
> 
> diff --git a/Documentation/devicetree/bindings/iio/cdc/ad7746.txt 
> b/Documentation/devicetree/bindings/iio/cdc/ad7746.txt
> new file mode 100644
> index 000..7740f05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/cdc/ad7746.txt
> @@ -0,0 +1,34 @@
> +Analog Devices AD7746/5/7 capacitive sensor driver
> +
> +Required properties:
> + - compatible: Should be one of
> + * "adi,ad7745"
> + * "adi,ad7746"
> +   * "adi,ad7747"
> + - reg: The 7-bits long I2c address of the device
> +
> +Optional properties:
> + - adi,exclvl: This property defines the excitation voltage level for the
> +capacitance to be measured. Possible values are:
> +  * 0 = +-VDD/8
> +  * 1 = +-VDD/4
> +  * 2 = +-VDD * 3/8
> +  * 3 = +-VDD/2 (Default)
> + - adi,nexca_en: Invert excitation output A.
> + - adi,nexcb_en: Invert excitation output B.
> +
> +Example:
> +Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
> +Excitation pin B would NOT be inverted.
> +
> +i2c2 {
> +
> +  < . . . >
> +
> +  ad7746: ad7746@60 {
> +  compatible = "ad7746";
> +  reg = <0x60>;
> +  adi,exclvl = <1>;
> +  adi,nexca_en;
> +  };
> +};
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index b3c8c6e..d1c309b 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -71,6 +71,7 @@ config IIO_TRIGGERED_EVENT
>  source "drivers/iio/accel/Kconfig"
>  source "drivers/iio/adc/Kconfig"
>  source "drivers/iio/amplifiers/Kconfig"
> +source "drivers/iio/cdc/Kconfig"
>  source "drivers/iio/chemical/Kconfig"
>  source "drivers/iio/common/Kconfig"
>  source "drivers/iio/counter/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index b16b2e9..18bea8d 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -17,6 +17,7 @@ obj-y += accel/
>  obj-y += adc/
>  obj-y += amplifiers/
>  obj-y += buffer/
> +obj-y += cdc/
>  obj-y += chemical/
>  obj-y += common/
>  obj-y += counter/
> diff --git a/drivers/iio/cdc/Kconfig b/drivers/iio/cdc/Kconfig
> new file mode 100644
> index 000..d3a8600
> --- /dev/null
> +++ b/drivers/iio/cdc/Kconfig
> @@ -0,0 +1,16 @@
> +#
> +# CDC drivers
> +#
> +menu "Capacitance to digital converters"
> +
> +config AD7746
> + tristate "Analog Devices AD7745, AD7746 AD7747 capacitive sensor driver"
> + depends on I2C
> + help
> +   Say yes here to build support for Analog Devices capacitive sensors.
> +   (AD7745, AD7746, AD7747) Provides direct access via sysfs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ad7746.
> +
> +endmenu
> diff --git a/drivers/iio/cdc/Makefile b/drivers/iio/cdc/Makefile
> new file mode 100644
> index 000..1f71283
> --- /dev/null
> +++ b/drivers/iio/cdc/Makefile
> @@ -0,0 +1,5 @@
> +#
> +#Makeefile for industrial I/O CDC drivers
> +#
> +
> +obj-$(CONFIG_AD7746) += ad7746.o
> diff --git a/drivers/iio/cdc/ad7746.c b/drivers/iio/cdc/ad7746.c
> new file mode 100644
> index 000..f283819
> --- /dev/null
> +++ b/drivers/iio/cdc/ad7746.c
> @@ -0,0 +1,855 @@
> +/*
> + * AD7746 capacitive sensor driver supporting AD7745, AD7746 and AD7747
> + *
> + * Copyrigh

Re: [PATCH 1/2] iio: potentiometer: mcp4018: switch to using .probe_new

[Jonathan Cameron]

On Wed, 11 Apr 2018 14:49:14 +0200
Peter Rosin  wrote:

> Use the new probe style for i2c drivers.
> 
> Signed-off-by: Peter Rosin 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/potentiometer/mcp4018.c | 41 
> ++---
>  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/iio/potentiometer/mcp4018.c 
> b/drivers/iio/potentiometer/mcp4018.c
> index 601b25d1f387..320a7c929777 100644
> --- a/drivers/iio/potentiometer/mcp4018.c
> +++ b/drivers/iio/potentiometer/mcp4018.c
> @@ -99,6 +99,23 @@ static const struct iio_info mcp4018_info = {
>   .write_raw = mcp4018_write_raw,
>  };
>  
> +static const struct i2c_device_id mcp4018_id[] = {
> + { "mcp4017-502", MCP4018_502 },
> + { "mcp4017-103", MCP4018_103 },
> + { "mcp4017-503", MCP4018_503 },
> + { "mcp4017-104", MCP4018_104 },
> + { "mcp4018-502", MCP4018_502 },
> + { "mcp4018-103", MCP4018_103 },
> + { "mcp4018-503", MCP4018_503 },
> + { "mcp4018-104", MCP4018_104 },
> + { "mcp4019-502", MCP4018_502 },
> + { "mcp4019-103", MCP4018_103 },
> + { "mcp4019-503", MCP4018_503 },
> + { "mcp4019-104", MCP4018_104 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, mcp4018_id);
> +
>  #ifdef CONFIG_OF
>  
>  #define MCP4018_COMPATIBLE(of_compatible, cfg) { \
> @@ -125,8 +142,7 @@ MODULE_DEVICE_TABLE(of, mcp4018_of_match);
>  
>  #endif
>  
> -static int mcp4018_probe(struct i2c_client *client,
> -  const struct i2c_device_id *id)
> +static int mcp4018_probe(struct i2c_client *client)
>  {
>   struct device *dev = &client->dev;
>   struct mcp4018_data *data;
> @@ -150,7 +166,7 @@ static int mcp4018_probe(struct i2c_client *client,
>   if (match)
>   data->cfg = of_device_get_match_data(dev);
>   else
> - data->cfg = &mcp4018_cfg[id->driver_data];
> + data->cfg = &mcp4018_cfg[i2c_match_id(mcp4018_id, 
> client)->driver_data];
>  
>   indio_dev->dev.parent = dev;
>   indio_dev->info = &mcp4018_info;
> @@ -161,29 +177,12 @@ static int mcp4018_probe(struct i2c_client *client,
>   return devm_iio_device_register(dev, indio_dev);
>  }
>  
> -static const struct i2c_device_id mcp4018_id[] = {
> - { "mcp4017-502", MCP4018_502 },
> - { "mcp4017-103", MCP4018_103 },
> - { "mcp4017-503", MCP4018_503 },
> - { "mcp4017-104", MCP4018_104 },
> - { "mcp4018-502", MCP4018_502 },
> - { "mcp4018-103", MCP4018_103 },
> - { "mcp4018-503", MCP4018_503 },
> - { "mcp4018-104", MCP4018_104 },
> - { "mcp4019-502", MCP4018_502 },
> - { "mcp4019-103", MCP4018_103 },
> - { "mcp4019-503", MCP4018_503 },
> - { "mcp4019-104", MCP4018_104 },
> - {}
> -};
> -MODULE_DEVICE_TABLE(i2c, mcp4018_id);
> -
>  static struct i2c_driver mcp4018_driver = {
>   .driver = {
>   .name   = "mcp4018",
>   .of_match_table = of_match_ptr(mcp4018_of_match),
>   },
> - .probe  = mcp4018_probe,
> + .probe_new  = mcp4018_probe,
>   .id_table   = mcp4018_id,
>  };
>  

Re: [PATCH 2/2] iio: potentiometer: mcp4531: switch to using .probe_new

[Jonathan Cameron]

On Wed, 11 Apr 2018 14:49:15 +0200
Peter Rosin  wrote:

> Use the new probe style for i2c drivers.
> 
> Signed-off-by: Peter Rosin 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/potentiometer/mcp4531.c | 145 
> ++--
>  1 file changed, 72 insertions(+), 73 deletions(-)
> 
> diff --git a/drivers/iio/potentiometer/mcp4531.c 
> b/drivers/iio/potentiometer/mcp4531.c
> index 114ab876fcc6..df894af6cccb 100644
> --- a/drivers/iio/potentiometer/mcp4531.c
> +++ b/drivers/iio/potentiometer/mcp4531.c
> @@ -209,6 +209,75 @@ static const struct iio_info mcp4531_info = {
>   .write_raw = mcp4531_write_raw,
>  };
>  
> +static const struct i2c_device_id mcp4531_id[] = {
> + { "mcp4531-502", MCP453x_502 },
> + { "mcp4531-103", MCP453x_103 },
> + { "mcp4531-503", MCP453x_503 },
> + { "mcp4531-104", MCP453x_104 },
> + { "mcp4532-502", MCP453x_502 },
> + { "mcp4532-103", MCP453x_103 },
> + { "mcp4532-503", MCP453x_503 },
> + { "mcp4532-104", MCP453x_104 },
> + { "mcp4541-502", MCP454x_502 },
> + { "mcp4541-103", MCP454x_103 },
> + { "mcp4541-503", MCP454x_503 },
> + { "mcp4541-104", MCP454x_104 },
> + { "mcp4542-502", MCP454x_502 },
> + { "mcp4542-103", MCP454x_103 },
> + { "mcp4542-503", MCP454x_503 },
> + { "mcp4542-104", MCP454x_104 },
> + { "mcp4551-502", MCP455x_502 },
> + { "mcp4551-103", MCP455x_103 },
> + { "mcp4551-503", MCP455x_503 },
> + { "mcp4551-104", MCP455x_104 },
> + { "mcp4552-502", MCP455x_502 },
> + { "mcp4552-103", MCP455x_103 },
> + { "mcp4552-503", MCP455x_503 },
> + { "mcp4552-104", MCP455x_104 },
> + { "mcp4561-502", MCP456x_502 },
> + { "mcp4561-103", MCP456x_103 },
> + { "mcp4561-503", MCP456x_503 },
> + { "mcp4561-104", MCP456x_104 },
> + { "mcp4562-502", MCP456x_502 },
> + { "mcp4562-103", MCP456x_103 },
> + { "mcp4562-503", MCP456x_503 },
> + { "mcp4562-104", MCP456x_104 },
> + { "mcp4631-502", MCP463x_502 },
> + { "mcp4631-103", MCP463x_103 },
> + { "mcp4631-503", MCP463x_503 },
> + { "mcp4631-104", MCP463x_104 },
> + { "mcp4632-502", MCP463x_502 },
> + { "mcp4632-103", MCP463x_103 },
> + { "mcp4632-503", MCP463x_503 },
> + { "mcp4632-104", MCP463x_104 },
> + { "mcp4641-502", MCP464x_502 },
> + { "mcp4641-103", MCP464x_103 },
> + { "mcp4641-503", MCP464x_503 },
> + { "mcp4641-104", MCP464x_104 },
> + { "mcp4642-502", MCP464x_502 },
> + { "mcp4642-103", MCP464x_103 },
> + { "mcp4642-503", MCP464x_503 },
> + { "mcp4642-104", MCP464x_104 },
> + { "mcp4651-502", MCP465x_502 },
> + { "mcp4651-103", MCP465x_103 },
> + { "mcp4651-503", MCP465x_503 },
> + { "mcp4651-104", MCP465x_104 },
> + { "mcp4652-502", MCP465x_502 },
> + { "mcp4652-103", MCP465x_103 },
> + { "mcp4652-503", MCP465x_503 },
> + { "mcp4652-104", MCP465x_104 },
> + { "mcp4661-502", MCP466x_502 },
> + { "mcp4661-103", MCP466x_103 },
> + { "mcp4661-503", MCP466x_503 },
> + { "mcp4661-104", MCP466x_104 },
> + { "mcp4662-502", MCP466x_502 },
> + { "mcp4662-103", MCP466x_103 },
> + { "mcp4662-503", MCP466x_503 },
> + { "mcp4662-104", MCP466x_104 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, mcp4531_id);
> +
>  #ifdef CONFIG_OF
>  
>  #define MCP4531_COMPATIBLE(of_compatible, cfg) { \
> @@ -286,8 +355,7 @@ static const struct of_device_id mcp4531_of_match[] = {
>  MODULE_DEVICE_TABLE(of, mcp4531_of_match);
>  #endif
>  
> -static int mcp4531_probe(struct i2c_client *client,
> -  const struct i2c_device_id *id)
> +static int mcp4531_probe(struct i2c_client *client)
>  {
>   struct device *dev = &client->dev;
>   struct mcp4531_data *data;
> @@ -311,7 +379,7 @@ static int mcp4531_probe(struct i2c_client *client,
>   if (match)
>   data->cfg = of_device_get_match_data(dev);
>   else
> - data->cfg = &mcp4531_cfg[id->driver_data];
> + data->cfg = &mcp4531_cfg[i2c_match_id(mcp4531_id, 
> client)->driver_data];
>  
>   indio_dev->dev.parent = dev;
>   indio_dev->info = &mcp4531_info;
> @@ -322,81 +390,12 @@ static int mcp4531_probe(struct i2c_client *client,
>   return devm_iio_device_register(dev, indio_dev);
>  }
>  
> -static const struct i2c_device_id mcp4531_id[] = {
> - { "mcp4531-502", MCP453x_502 },
> - { "mcp4531-103", MCP453x_103 },
> - { "mcp4531-503", MCP453x_503 },
> - { "mcp4531-104", MCP453x_104 },
> - { "mcp4532-502", MCP453x_502 },
> - { "mcp4532-103", MCP453x_103 },
> - { "mcp4532-503", MCP453x_503 },
> - { "mcp4532-104", MCP453x_104 },
> - { "mcp4541-502", MCP454x_502 },
> - { "mcp4541-103", MCP454x_103 },
> - { "mcp4541-503", MCP454x_503 },
> - { "mcp4541-104", MCP454x_104 },
> - { "mcp4542-502", MCP454x_50

Re: [PATCH v3 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

[Pali Rohár]

On Saturday 14 April 2018 13:17:11 Lukas Wunner wrote:
> On Sat, Apr 14, 2018 at 12:49:50PM +0200, Pali Rohár wrote:
> > On Saturday 14 April 2018 12:45:12 Lukas Wunner wrote:
> > > On Thu, Apr 12, 2018 at 10:15:41PM +0800, Kai-Heng Feng wrote:
> > > > Do you have any suggestion to check if it connects to the system via
> > > > Thunderbolt?
> > > 
> > > Just use pci_is_thunderbolt_attached(), introduced by 8531e283bee6,
> > > like this:
> > > 
> > > if (check_dell_switchable_gfx(pci) && !pci_is_thunderbolt_attached(pci))
> > 
> > And what about PCI-e device attached to ExpressCard slot?
> 
> I don't know of a bullet-proof way to recognize those.  In theory
> one could check if the PCIe port above the GPU is a non-hotplug
> root port, but I think there are machines with hotplug capable
> root ports with GPUs below them that aren't actually removable.
> 
> However I think ExpressCard-attached GPUs were rare, much less ones
> with integrated HDA controller, so in reality that's probably a
> non-issue.

Hm... maybe another idea: Is it possible to detect which audio pci
device belongs to graphics card via vga_switcheroo? Currently, looking
at output it is same PCI device as graphic card, just different PCI
function.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

[GIT pull] efi updates for 4.17

[Thomas Gleixner]

Linus,

please pull the latest efi-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
efi-urgent-for-linus

A single fix for an early boot warning caused by invoking this_cpu_has()
before SMP initialization.

Thanks,

tglx

-->
Sai Praneeth (1):
  x86/mm: Fix bogus warning during EFI bootup, use boot_cpu_has() instead 
of this_cpu_has() in build_cr3_noflush()


 arch/x86/include/asm/tlbflush.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 84137c22fdfa..6690cd3fc8b1 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -131,7 +131,12 @@ static inline unsigned long build_cr3(pgd_t *pgd, u16 asid)
 static inline unsigned long build_cr3_noflush(pgd_t *pgd, u16 asid)
 {
VM_WARN_ON_ONCE(asid > MAX_ASID_AVAILABLE);
-   VM_WARN_ON_ONCE(!this_cpu_has(X86_FEATURE_PCID));
+   /*
+* Use boot_cpu_has() instead of this_cpu_has() as this function
+* might be called during early boot. This should work even after
+* boot because all CPU's the have same capabilities:
+*/
+   VM_WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_PCID));
return __sme_pa(pgd) | kern_pcid(asid) | CR3_NOFLUSH;
 }
 

Re: [PATCH 00/32] docs/vm: convert to ReST format

[Mike Rapoport]

On Fri, Apr 13, 2018 at 01:21:08PM -0700, Matthew Wilcox wrote:
> On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> > > I believe that keeping the mm docs together will give better visibility of
> > > what (little) mm documentation we have and will make the updates easier.
> > > The documents that fit well into a certain topic could be linked there. 
> > > For
> > > instance:
> > 
> > ...but this sounds like just the opposite...?  
> > 
> > I've had this conversation with folks in a number of subsystems.
> > Everybody wants to keep their documentation together in one place - it's
> > easier for the developers after all.  But for the readers I think it's
> > objectively worse.  It perpetuates the mess that Documentation/ is, and
> > forces readers to go digging through all kinds of inappropriate material
> > in the hope of finding something that tells them what they need to know.
> > 
> > So I would *really* like to split the documentation by audience, as has
> > been done for a number of other kernel subsystems (and eventually all, I
> > hope).
> > 
> > I can go ahead and apply the RST conversion, that seems like a step in
> > the right direction regardless.  But I sure hope we don't really have to
> > keep it as an unorganized jumble of stuff...
> 
> I've started on Documentation/core-api/memory.rst which covers just
> memory allocation.  So far it has the Overview and GFP flags sections
> written and an outline for 'The slab allocator', 'The page allocator',
> 'The vmalloc allocator' and 'The page_frag allocator'.  And typing this
> up, I realise we need a 'The percpu allocator'.  I'm thinking that this
> is *not* the right document for the DMA memory allocators (although it
> should link to that documentation).
> 
> I suspect the existing Documentation/vm/ should probably stay as an
> unorganised jumble of stuff.  Developers mostly talking to other MM
> developers.  Stuff that people outside the MM fraternity should know
> about needs to be centrally documented.  By all means convert it to
> ReST ... I don't much care, and it may make it easier to steal bits
> or link to it from the organised documentation.
 
The existing Documentation/vm contains different types of documents. Some
are indeed "Developers mostly talking to other MM developers". Some are
really user/administrator guides. Others are somewhat in between.

I took another look at what's there and I think we can actually move part
of Documentation/vm to Documentation/admin-guide. We can add
Documentation/admin-guide/vm/ and title it "Memory Management Tuning" or
something like that. And several files, e.g. hugetlbpage, ksm, soft-dirty
can be moved there.

-- 
Sincerely yours,
Mike.

Re: [PATCH v3 2/2] iio: afe: unit-converter: new driver

[Jonathan Cameron]

On Tue, 10 Apr 2018 17:28:02 +0200
Peter Rosin  wrote:

> If an ADC channel measures the midpoint of a voltage divider, the
> interesting voltage is often the voltage over the full resistance.
> E.g. if the full voltage is too big for the ADC to handle.
> Likewise, if an ADC channel measures the voltage across a shunt
> resistor, the interesting value is often the current through the
> resistor.
> 
> This driver solves both problems by allowing to linearly scale a channel
> and by allowing changes to the type of the channel. Or both.
> 
> Signed-off-by: Peter Rosin 
So I 'think' the only outstanding question is Andrew's one about the driver
name.  We aren't in a hurry at this point in the kernel cycle, so lets
wait until that discussion has ended.  Assuming that we do possibly end
up with a change, then please roll all the patches up into a single series
to avoid me getting confusion.

Thanks,

Jonathan

> ---
>  MAINTAINERS  |   1 +
>  drivers/iio/Kconfig  |   1 +
>  drivers/iio/Makefile |   1 +
>  drivers/iio/afe/Kconfig  |  18 +++
>  drivers/iio/afe/Makefile |   6 +
>  drivers/iio/afe/iio-unit-converter.c | 291 
> +++
>  6 files changed, 318 insertions(+)
>  create mode 100644 drivers/iio/afe/Kconfig
>  create mode 100644 drivers/iio/afe/Makefile
>  create mode 100644 drivers/iio/afe/iio-unit-converter.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 237fcdfdddc6..d2a28b915fca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6893,6 +6893,7 @@ L:  linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
>  F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> +F:   drivers/iio/afe/iio-unit-converter.c
>  
>  IKANOS/ADI EAGLE ADSL USB DRIVER
>  M:   Matthieu Castet 
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index b3c8c6ef0dff..d69e85a8bdc3 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -70,6 +70,7 @@ config IIO_TRIGGERED_EVENT
>  
>  source "drivers/iio/accel/Kconfig"
>  source "drivers/iio/adc/Kconfig"
> +source "drivers/iio/afe/Kconfig"
>  source "drivers/iio/amplifiers/Kconfig"
>  source "drivers/iio/chemical/Kconfig"
>  source "drivers/iio/common/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index b16b2e9ddc40..d8cba9c229c0 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_IIO_TRIGGERED_EVENT) += 
> industrialio-triggered-event.o
>  
>  obj-y += accel/
>  obj-y += adc/
> +obj-y += afe/
>  obj-y += amplifiers/
>  obj-y += buffer/
>  obj-y += chemical/
> diff --git a/drivers/iio/afe/Kconfig b/drivers/iio/afe/Kconfig
> new file mode 100644
> index ..642ce4eb12a6
> --- /dev/null
> +++ b/drivers/iio/afe/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# Analog Front End drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Analog Front Ends"
> +
> +config IIO_UNIT_CONVERTER
> + tristate "IIO unit converter"
> + depends on OF || COMPILE_TEST
> + help
> +   Say yes here to build support for the IIO unit converter
> +   that handles voltage dividers and current sense shunts.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called iio-unit-converter.
> +
> +endmenu
> diff --git a/drivers/iio/afe/Makefile b/drivers/iio/afe/Makefile
> new file mode 100644
> index ..7691cc5b809a
> --- /dev/null
> +++ b/drivers/iio/afe/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for industrial I/O Analog Front Ends (AFE)
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_IIO_UNIT_CONVERTER) += iio-unit-converter.o
> diff --git a/drivers/iio/afe/iio-unit-converter.c 
> b/drivers/iio/afe/iio-unit-converter.c
> new file mode 100644
> index ..fc50290d7e5e
> --- /dev/null
> +++ b/drivers/iio/afe/iio-unit-converter.c
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IIO unit converter
> + *
> + * Copyright (C) 2018 Axentia Technologies AB
> + *
> + * Author: Peter Rosin 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct unit_converter;
> +
> +struct unit_converter_cfg {
> + enum iio_chan_type type;
> + int (*props)(struct device *dev, struct unit_converter *uc);
> +};
> +
> +struct unit_converter {
> + const struct unit_converter_cfg *cfg;
> + struct iio_channel *source;
> + struct iio_chan_spec chan;
> + struct iio_chan_spec_ext_info *ext_info;
> + s32 numerator;
> + s32 denominator;
> +};
> +
> +static int unit_converter_read_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int *val, int *val2, long mask)
> +{
> + struct unit_converter 

[GIT pull] perf updates for 4.17

[Thomas Gleixner]

Linus,

please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

A rather large set of perf updates:

   - Show only failing syscalls with 'perf trace --failure' (Arnaldo Carvalho 
de Melo)

e.g: See what 'openat' syscalls are failing:

  # perf trace --failure -e openat
   762.323 ( 0.007 ms): VideoCapture/4566 openat(dfd: CWD, filename: 
/dev/video2) = -1 ENOENT No such file or directory
   
   790.228 ( 0.008 ms): VideoCapture/4566 openat(dfd: CWD, filename: 
/dev/video63) = -1 ENOENT No such file or directory
  ^C#

- Show information about the event (freq, nr_samples, total 
period/nr_events) in
  the annotate --tui and --stdio2 'perf annotate' output, similar to the
  first line in the 'perf report --tui', but just for the samples for a
  the annotated symbol (Arnaldo Carvalho de Melo)

- Introduce 'perf version --build-options' to show what features were
  linked, aliased as well as a shorter 'perf -vv' (Jin Yao)

- Add a "dso_size" sort order (Kim Phillips)

- Remove redundant ')' in the tracepoint output in 'perf trace' (Changbin 
Du)

- Synchronize x86's cpufeatures.h, no effect on toolss (Arnaldo Carvalho de 
Melo)

- Show group details on the title line in the annotate browser
  and 'perf annotate --stdio2' output, so that the per-event
  columns can have headers (Arnaldo Carvalho de Melo)

- Fixup vertical line separating metrics from instructions and
  cleaning unused lines at the bottom, both in the annotate TUI
  browser (Arnaldo Carvalho de Melo)

- Remove duplicated 'samples' in lost samples warning in
  'perf report' (Arnaldo Carvalho de Melo)

- Synchronize i915_drm.h, silencing the perf build process,
  automagically adding support for the new DRM_I915_QUERY
  ioctl (Arnaldo Carvalho de Melo)

- Make auxtrace_queues__add_buffer() allocate struct buffer,
  from a patchkit already applied (Adrian Hunter)

. Fix the --stdio2/TUI annotate output to include group details,
  be it for a recorded '{a,b,f}' explicit event group or when
  forcing group display using 'perf report --group' for a set of
  events not recorded as a group (Arnaldo Carvalho de Melo)

. Fix display artifacts in the ui browser (base class for the
  annotate and main report/top TUI browser) related to the extra
  title lines work (Arnaldo Carvalho de Melo)

. perf auxtrace refactorings, leftovers from a previously partially
  processed patchset (Adrian Hunter)

. Fix the builtin clang build (Sandipan Das, Arnaldo Carvalho de Melo)

- Synchronize i915_drm.h, silencing a perf build warning and
  in the process automagically adding support for a new ioctl
  command (Arnaldo Carvalho de Melo)

- Fix various initialization issues

- Prevent creating [ku]probes for not CAP_SYS_ADMIN users

- Fix a strncpy issue in uprobe tracing

Thanks,

tglx

-->
Adrian Hunter (2):
  perf auxtrace: Make auxtrace_queues__add_buffer() allocate struct buffer
  perf auxtrace: Make auxtrace_queues__add_buffer() do CPU filtering

Arnaldo Carvalho de Melo (17):
  tools headers: Synchronize x86's cpufeatures.h
  perf trace: Show only failing syscalls
  perf hists browser: Rename perf_evsel_browser_title to a more descriptive 
name
  perf hists: Introduce hists__scnprint_title()
  perf hists: Move hists__scnprintf_title() away from the TUI code
  perf ui browser: Move the extra title lines from the hists browser
  perf annotate: Introduce annotation__scnprintf_samples_period() method
  perf annotate browser: Show extra title line with event information
  perf annotate stdio2: Print more descriptive event information header
  perf annotate: Show group details on the title line
  perf annotate browser: Fixup vertical line separating metrics from 
instructions
  perf ui browser: Fixup cleaning unused lines at the bottom
  perf report: Remove duplicated 'samples' in lost samples warning
  tools headers uapi: Synchronize i915_drm.h
  perf hists browser: Show extra_title_lines in the 'D' debug hotkey
  perf hists browser: Remove leftover from row returned from refresh
  perf tools: No need to include namespaces.h in util.h

Changbin Du (1):
  perf trace: Remove redundant ')'

Jin Yao (5):
  perf config: Add some new -DHAVE_XXX to CFLAGS
  perf config: Rename to HAVE_DWARF_GETLOCATIONS_SUPPORT
  perf version: Print the compiled-in status of libraries
  perf tools: Add 'perf -vv' as an alias to 'perf version --build-options'
  perf version: Add man page

Jiri Olsa (1):
  tools include: Add config.h header file

Kim Phillips (1):
  perf tools: Add a "dso_size" sort order

Masami Hiramatsu (2):
  per

Re: [PATCH 00/32] docs/vm: convert to ReST format

[Mike Rapoport]

On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> Sorry for the silence, I'm pedaling as fast as I can, honest...
> 
> On Sun, 1 Apr 2018 09:38:58 +0300
> Mike Rapoport  wrote:
> 
> > My thinking was to start with mechanical RST conversion and then to start
> > working on the contents and ordering of the documentation. Some of the
> > existing files, e.g. ksm.txt, can be moved as is into the appropriate
> > places, others, like transhuge.txt should be at least split into admin/user
> > and developer guides.
> > 
> > Another problem with many of the existing mm docs is that they are rather
> > developer notes and it wouldn't be really straight forward to assign them
> > to a particular topic.
> 
> All this sounds good.
> 
> > I believe that keeping the mm docs together will give better visibility of
> > what (little) mm documentation we have and will make the updates easier.
> > The documents that fit well into a certain topic could be linked there. For
> > instance:
> 
> ...but this sounds like just the opposite...?  
> 
> I've had this conversation with folks in a number of subsystems.
> Everybody wants to keep their documentation together in one place - it's
> easier for the developers after all.  But for the readers I think it's
> objectively worse.  It perpetuates the mess that Documentation/ is, and
> forces readers to go digging through all kinds of inappropriate material
> in the hope of finding something that tells them what they need to know.
> 
> So I would *really* like to split the documentation by audience, as has
> been done for a number of other kernel subsystems (and eventually all, I
> hope).
> 
> I can go ahead and apply the RST conversion, that seems like a step in
> the right direction regardless.  But I sure hope we don't really have to
> keep it as an unorganized jumble of stuff...

I didn't mean we should keep it as unorganized jumble of stuff and I agree
that splitting the documentation by audience is better because developers
are already know how to find it :)

I just thought that putting the doc into the place should not be done
immediately after mechanical ReST conversion but rather after improving the
contents. Although I'd agree that part of the documentation in
Documentation/vm is in pretty good shape already.

 
> Thanks,
> 
> jon
> 

-- 
Sincerely yours,
Mike.

[regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

[Pavel Machek]

Hi!

> Thanks.
> 
> Ok, let me try to bisect it. Compile-problem should be easy...
> 
> Hmm. And as it is compile-problem in single file, it should even be
> reasonably fast. I did not realize how easy it would be:
> 
> #!/bin/bash
> set -e
> cp config.ok .config
> yes '' | ARCH=arm make lib/string.o
> 
> And the winner is:
> 
> ee333554fed5a986a90bb097ac7f9d6f05bf is the first bad commit
> commit ee333554fed5a986a90bb097ac7f9d6f05bf
> Author: Jinbum Park 
> Date:   Tue Mar 6 01:39:24 2018 +0100
...

> Acked-by: Kees Cook 
> Signed-off-by: Jinbum Park 
> Signed-off-by: Russell King 

So I bisect a problem in -next, and patch is merged to Linus,
_anyway_, breaking compilation there? Neither Jinbum nor Russell even
bother to comment.

And BTW, Russell, there's another regression I bisected to your
commit, that one is like two releases old, and "only" causes
compilation warnings during build with non-US locale. I even proposed
fix for that. Guess what? Ignored too.


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 0/2] iio: add unit converter

[Jonathan Cameron]

On Wed, 11 Apr 2018 16:15:53 +0200
Peter Rosin  wrote:

> Hi!
> 
> I'm now following up with one more binding for the unit-converter.
> This time with a real IC, namely LT6106 from Analog Devices. It's
> a current sense amplifier. I was a but unsure if I should have
> the Rin and Rout resistors in the binding or if I instead should
> have used the "gain". In the end I went with the resistors since
> while the normal case is an integer gain, that may not always be
> the case. And when it's not, that could get tricky. But I'm open
> for arguments on that.
> 
> Cheers,
> Peter
Trivial complaint of the day - why the same title for this email
as the previous series?  Had me really confused for a minute ;)

Seems like the whole driver is stabilizing.  If we do a v4 please
pull the whole lot into one series.

Jonathan

> 
> Peter Rosin (2):
>   dt-bindings: iio: afe: add binding for adi,lt6106
>   iio: afe: unit-converter: add support for adi,lt6106
> 
>  .../devicetree/bindings/iio/afe/adi,lt6106.txt | 50 
>  MAINTAINERS|  1 +
>  drivers/iio/afe/Kconfig|  3 +-
>  drivers/iio/afe/iio-unit-converter.c   | 54 
> ++
>  4 files changed, 107 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/iio/afe/adi,lt6106.txt
>