[RFC][PATCH v4 00/32] objtool: Make recordmcount a subcommand

[Matt Helsley]

recordmcount has its own ELF wrapper code and could utilize
objtool's ELF code to more-portably handle architecture variations.
This series makes recordmcount a subcommand of objtool. It  very
gradually convert recordmcount to become a subcommand of objtool and
then reuses parts of objtool's ELF code. recordmcount maps the file in
and collects simple information it needs to append a section to the
object file. The only part of the original file it modifies is the
address of new section tables -- interestingly enough this
resembles RCU in that we don't really trim the old tables so
much as unlink them via a critical offset and then rely on
future tooling, in this case, to drop the unused bits. Much of
the recordmcount ELF code is only reading and walking the data
structures to collect the mcount locations it records in a separate
area of memory. This means it's safe to mix access to the mapped
file with access to the objtool-style linked data
structures as we gradually convert it to using only the linked data
structures. Once the old ELF code is no longer in use we can drop it
and use objtool to take over the task of writing the results without
using the RCU-like trick any more.

Testing:

I've been using scripts to test cross compilation and execution of
objtool, and mcount on objects built for x86, ppc64le, arm64, s390, and
sparc. I used PowerPC as a sample arch for fixing a bug (see Changes)
and confirmed it builds a full zImage with defconfig
(CONFIG_DYNAMIC_FTRACE=y).

Changes
v4:
Split out recordmcount cleanups and upstreamed.
[ 
https://lore.kernel.org/lkml/20190802134712.2d8cc...@gandalf.local.home/ ]

Split out and iterated on objtool multi-arch support.
[ 
https://lore.kernel.org/lkml/cover.1586468801.git.mhels...@vmware.com/ ]

Split out expanded relocation support, renamed types, and functions
to reflect expanded relocation support, and posted.
[ 
https://lore.kernel.org/lkml/cover.1590785960.git.mhels...@vmware.com/ ]

This set is based on the patches sent upstream and posted above.

Adapted to renames by Ingo and Peter: s/elf_open/elf_open_read/

Added weak symbols for mcount subcommand
This nicely eliminated the need for the mcount.h header.

Added tools/objtool/Makefile per-arch SUBCMD_ blocks for each
arch recordmcount / mcount supports.

Moved ftrace/mcount/record.h from objtool_dep to recordmcount_dep
This keeps the dependencies better organized.

Fixed Makefile issue reported for PowerPC and a couple other archs
by kbuild test robot. The always-$(BUILD_C_RECORDMCOUNT)
line wasn't sufficiently replaced. Added to prepare-objtool
target in top level Makefile.

Split up dependencies to be independent of CONFIG_STACK_VALIDATION
and CONFIG_UNWINDER_ORC since these are x86-specific.
Now any arch which uses the C version of recordmcount
will build objtool if dynamic tracing is enabled.

Added a second rename at the end to be consistent with other
objtool subcommands.

v3:
Rebased on mainline. s/elf_open/elf_read/ in recordmcount.c

v2:
Fix whitespace before line continuation

Add ftrace/mcount/record.h to objtool_dep

Rename the Makefile variable BUILD_C_RECORDMCOUNT to
better reflect its purpose

Similar: rename recordmcount_source => recordmcount_dep
When using objtool we can just depend on the
binary rather than the source the binary is
built from. This should address Josh's feedback and
make the Makefile code a bit clearer

Add a comment to make reading the Makefile a little
easier

Rebased to latest mainline -rc


Matt Helsley (32):
  objtool: Prepare to merge recordmcount
  objtool: Make recordmcount into mcount subcmd
  objtool: recordmcount: Start using objtool's elf wrapper
  objtool: recordmcount: Search for __mcount_loc before walking the
sections
  objtool: recordmcount: Convert do_func() relhdrs
  objtool: mcount: Remove unused fname parameter
  objtool: mcount: Use libelf for section header names
  objtool: mcount: Walk objtool Elf structs in find_secsym_ndx
  objtool: mcount: Use symbol structs to find mcount relocations
  objtool: mcount: Walk relocation lists
  objtool: mcount: Move get_mcountsym
  objtool: mcount: Replace MIPS offset types
  objtool: mcount: Move is_fake_mcount()
  objtool: mcount: Stop using ehdr in find_section_sym_index
  objtool: mcount: Move find_section_sym_index()
  objtool: mcount: Restrict using ehdr in append_func()
  objtool: mcount: Use objtool ELF to write
  objtool: mcount: Move nop_mcount()
  objtool: mcount: Move has_rel_mcount() and tot_relsize()
  objtool: mcount: Move relocation entry size detection
  objtool: mcount: Only keep ELF file 

[RFC][PATCH v4 03/32] objtool: recordmcount: Start using objtool's elf wrapper

[Matt Helsley]

Use struct elf to grab the file descriptor. We will later
move these calls into other functions as we expand the
lifetime of the struct elf so that it can be passed to
objtool elf.[ch] functions.

This creates the libelf/objtool data structures and gives
us two separate ways to walk the ELF file -- the libelf/objtool
way and the old recordmcount wrapper way which avoids these
extra data structures by using indices, offsets, and pointers
into the mmapped ELF file.

Subsequent patches will convert from the old recordmcount
accessors to the libelf/objtool accessors.

Signed-off-by: Matt Helsley 
---
 tools/objtool/recordmcount.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/objtool/recordmcount.c b/tools/objtool/recordmcount.c
index 601e83840085..b2c606eb269b 100644
--- a/tools/objtool/recordmcount.c
+++ b/tools/objtool/recordmcount.c
@@ -33,6 +33,8 @@
 
 #include "objtool.h"
 
+#include "elf.h"
+
 #ifndef EM_AARCH64
 #define EM_AARCH64 183
 #define R_AARCH64_NONE 0
@@ -57,6 +59,8 @@ static void *file_ptr;/* current file pointer 
location */
 static void *file_append; /* added to the end of the file */
 static size_t file_append_size; /* how much is added to end of file */
 
+static struct elf *lf;
+
 /* Per-file resource cleanup when multiple files. */
 static void file_append_cleanup(void)
 {
@@ -73,6 +77,9 @@ static void mmap_cleanup(void)
else
free(file_map);
file_map = NULL;
+   if (lf)
+   elf_close(lf);
+   lf = NULL;
 }
 
 /* ulseek, uwrite, ...:  Check return value for errors. */
@@ -170,11 +177,12 @@ static void *mmap_file(char const *fname)
file_updated = 0;
sb.st_size = 0;
 
-   fd_map = open(fname, O_RDONLY);
-   if (fd_map < 0) {
+   lf = elf_open_read(fname, O_RDONLY);
+   if (!lf) {
perror(fname);
return NULL;
}
+   fd_map = lf->fd;
if (fstat(fd_map, ) < 0) {
perror(fname);
goto out;
@@ -194,14 +202,14 @@ static void *mmap_file(char const *fname)
}
if (read(fd_map, file_map, sb.st_size) != sb.st_size) {
perror(fname);
-   free(file_map);
-   file_map = NULL;
+   mmap_cleanup();
goto out;
}
} else
mmap_failed = 0;
 out:
-   close(fd_map);
+   elf_close(lf);
+   lf = NULL;
fd_map = -1;
 
file_end = file_map + sb.st_size;
-- 
2.20.1

[RFC][PATCH v4 01/32] objtool: Prepare to merge recordmcount

[Matt Helsley]

Move recordmcount into the objtool directory. We keep this step separate
so changes which turn recordmcount into a subcommand of objtool don't
get obscured.

Signed-off-by: Matt Helsley 
---
 Documentation/trace/ftrace-design.rst  |  4 ++--
 Documentation/trace/ftrace.rst |  2 +-
 Makefile   | 15 +--
 scripts/.gitignore |  1 -
 scripts/Makefile   |  1 -
 scripts/Makefile.build | 11 ++-
 tools/objtool/.gitignore   |  1 +
 tools/objtool/Build|  2 ++
 tools/objtool/Makefile | 13 -
 {scripts => tools/objtool}/recordmcount.c  |  0
 {scripts => tools/objtool}/recordmcount.h  |  0
 {scripts => tools/objtool}/recordmcount.pl |  0
 12 files changed, 33 insertions(+), 17 deletions(-)
 rename {scripts => tools/objtool}/recordmcount.c (100%)
 rename {scripts => tools/objtool}/recordmcount.h (100%)
 rename {scripts => tools/objtool}/recordmcount.pl (100%)

diff --git a/Documentation/trace/ftrace-design.rst 
b/Documentation/trace/ftrace-design.rst
index a8e22e0db63c..dea8db5e79d0 100644
--- a/Documentation/trace/ftrace-design.rst
+++ b/Documentation/trace/ftrace-design.rst
@@ -261,7 +261,7 @@ You need very few things to get the syscalls tracing in an 
arch.
 HAVE_FTRACE_MCOUNT_RECORD
 -
 
-See scripts/recordmcount.pl for more info.  Just fill in the arch-specific
+See tools/objtool/recordmcount.pl for more info.  Just fill in the 
arch-specific
 details for how to locate the addresses of mcount call sites via objdump.
 This option doesn't make much sense without also implementing dynamic ftrace.
 
@@ -379,7 +379,7 @@ linux/ftrace.h for the functions::
ftrace_make_call()
 
 The rec->ip value is the address of the mcount call site that was collected
-by the scripts/recordmcount.pl during build time.
+by the tools/objtool/recordmcount.pl during build time.
 
 The last function is used to do runtime patching of the active tracer.  This
 will be modifying the assembly code at the location of the ftrace_call symbol
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 3b5614b1d1a5..9adefcc3c7a8 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -2685,7 +2685,7 @@ starts of pointing to a simple return. (Enabling FTRACE 
will
 include the -pg switch in the compiling of the kernel.)
 
 At compile time every C file object is run through the
-recordmcount program (located in the scripts directory). This
+recordmcount program (located in the tools/objtool directory). This
 program will parse the ELF headers in the C object to find all
 the locations in the .text section that call mcount. Starting
 with gcc version 4.6, the -mfentry has been added for x86, which
diff --git a/Makefile b/Makefile
index 04f5662ae61a..d353a0a65a71 100644
--- a/Makefile
+++ b/Makefile
@@ -844,6 +844,7 @@ ifdef CONFIG_DYNAMIC_FTRACE
ifdef CONFIG_HAVE_C_RECORDMCOUNT
BUILD_C_RECORDMCOUNT := y
export BUILD_C_RECORDMCOUNT
+   objtool_target := tools/objtool FORCE
endif
 endif
 endif
@@ -1023,10 +1024,10 @@ endif
 export mod_sign_cmd
 
 HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
+has_libelf := $(call try-run,\
+   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null 
$(HOST_LIBELF_LIBS) -,1,0)
 
 ifdef CONFIG_STACK_VALIDATION
-  has_libelf := $(call try-run,\
-   echo "int main() {}" | $(HOSTCC) -xc -o /dev/null 
$(HOST_LIBELF_LIBS) -,1,0)
   ifeq ($(has_libelf),1)
 objtool_target := tools/objtool FORCE
   else
@@ -1163,13 +1164,15 @@ uapi-asm-generic:
 
 PHONY += prepare-objtool
 prepare-objtool: $(objtool_target)
-ifeq ($(SKIP_STACK_VALIDATION),1)
-ifdef CONFIG_UNWINDER_ORC
+ifneq ($(has_libelf),1)
+  ifdef CONFIG_UNWINDER_ORC
@echo "error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, 
please install libelf-dev, libelf-devel or elfutils-libelf-devel" >&2
@false
-else
+  else
+ifeq ($(SKIP_STACK_VALIDATION),1)
@echo "warning: Cannot use CONFIG_STACK_VALIDATION=y, please install 
libelf-dev, libelf-devel or elfutils-libelf-devel" >&2
-endif
+endif
+  endif
 endif
 
 # Generate some files
diff --git a/scripts/.gitignore b/scripts/.gitignore
index 0d1c8e217cd7..dafda6d2c306 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -2,7 +2,6 @@
 bin2c
 kallsyms
 unifdef
-recordmcount
 sorttable
 asn1_compiler
 extract-cert
diff --git a/scripts/Makefile b/scripts/Makefile
index 95ecf970c74c..d8d81de4f1cb 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -5,7 +5,6 @@
 
 always-$(CONFIG_BUILD_BIN2C)   += bin2c
 always-$(CONFIG_KALLSYMS)  += kallsyms
-always-$(BUILD_C_RECORDMCOUNT) += recordmcount
 always-$(CONFIG_BUILDTIME_TABLE_SORT)  += 

[RFC][PATCH v4 07/32] objtool: mcount: Use libelf for section header names

[Matt Helsley]

Rather than passing in the string table contents as a parameter,
pass in the section index of the string table and rely on libelf
string table accessor functions to look up section names.

Note that modifying the string table with libelf will come later
so append_func() is unchanged.

Signed-off-by: Matt Helsley 
---
 tools/objtool/elf.c  |  3 +-
 tools/objtool/elf.h  |  1 +
 tools/objtool/recordmcount.c |  2 +-
 tools/objtool/recordmcount.h | 89 ++--
 4 files changed, 37 insertions(+), 58 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 067e2850a116..2e8f5f90e264 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -138,8 +138,7 @@ struct section *find_section_by_name(const struct elf *elf, 
const char *name)
return NULL;
 }
 
-static struct section *find_section_by_index(struct elf *elf,
-unsigned int idx)
+struct section *find_section_by_index(const struct elf *elf, unsigned int idx)
 {
struct section *sec;
 
diff --git a/tools/objtool/elf.h b/tools/objtool/elf.h
index 78a2db23b8b6..ae82479a8259 100644
--- a/tools/objtool/elf.h
+++ b/tools/objtool/elf.h
@@ -125,6 +125,7 @@ int elf_write(const struct elf *elf);
 void elf_close(struct elf *elf);
 
 struct section *find_section_by_name(const struct elf *elf, const char *name);
+struct section *find_section_by_index(const struct elf *elf, unsigned int idx);
 struct symbol *find_func_by_offset(struct section *sec, unsigned long offset);
 struct symbol *find_symbol_by_offset(struct section *sec, unsigned long 
offset);
 struct symbol *find_symbol_by_name(const struct elf *elf, const char *name);
diff --git a/tools/objtool/recordmcount.c b/tools/objtool/recordmcount.c
index 9941683b3f60..f20582ac99e2 100644
--- a/tools/objtool/recordmcount.c
+++ b/tools/objtool/recordmcount.c
@@ -177,7 +177,7 @@ static void *mmap_file(char const *fname)
file_updated = 0;
sb.st_size = 0;
 
-   lf = elf_open_read(fname, O_RDONLY);
+   lf = elf_open_read(fname, O_RDWR);
if (!lf) {
perror(fname);
return NULL;
diff --git a/tools/objtool/recordmcount.h b/tools/objtool/recordmcount.h
index 3250a461895d..b487308992ce 100644
--- a/tools/objtool/recordmcount.h
+++ b/tools/objtool/recordmcount.h
@@ -25,7 +25,6 @@
 #undef sift_rel_mcount
 #undef nop_mcount
 #undef find_secsym_ndx
-#undef __has_rel_mcount
 #undef has_rel_mcount
 #undef tot_relsize
 #undef get_mcountsym
@@ -55,7 +54,6 @@
 # define sift_rel_mcount   sift64_rel_mcount
 # define nop_mcountnop_mcount_64
 # define find_secsym_ndx   find64_secsym_ndx
-# define __has_rel_mcount  __has64_rel_mcount
 # define has_rel_mcounthas64_rel_mcount
 # define tot_relsize   tot64_relsize
 # define get_sym_str_and_relp  get_sym_str_and_relp_64
@@ -88,7 +86,6 @@
 # define sift_rel_mcount   sift32_rel_mcount
 # define nop_mcountnop_mcount_32
 # define find_secsym_ndx   find32_secsym_ndx
-# define __has_rel_mcount  __has32_rel_mcount
 # define has_rel_mcounthas32_rel_mcount
 # define tot_relsize   tot32_relsize
 # define get_sym_str_and_relp  get_sym_str_and_relp_32
@@ -197,6 +194,7 @@ static int append_func(Elf_Ehdr *const ehdr,
 
shstr->sh_size = _w(t);
shstr->sh_offset = _w(sb.st_size);
+
t += sb.st_size;
t += (_align & -t);  /* word-byte align */
new_e_shoff = t;
@@ -260,7 +258,7 @@ static int append_func(Elf_Ehdr *const ehdr,
return -1;
if (uwrite(ehdr, sizeof(*ehdr)) < 0)
return -1;
-   return 0;
+   return elf_write(lf);
 }
 
 static unsigned get_mcountsym(Elf_Sym const *const sym0,
@@ -285,7 +283,7 @@ static unsigned get_mcountsym(Elf_Sym const *const sym0,
return mcountsym;
 }
 
-static void get_sym_str_and_relp(GElf_Shdr const *const relhdr,
+static void get_sym_str_and_relp(const struct section * const rels,
 Elf_Ehdr const *const ehdr,
 Elf_Sym const **sym0,
 char const **str0,
@@ -293,10 +291,10 @@ static void get_sym_str_and_relp(GElf_Shdr const *const 
relhdr,
 {
Elf_Shdr *const shdr0 = (Elf_Shdr *)(_w(ehdr->e_shoff)
+ (void *)ehdr);
-   unsigned const symsec_sh_link = relhdr->sh_link;
+   unsigned const symsec_sh_link = rels->sh.sh_link;
Elf_Shdr const *const symsec = [symsec_sh_link];
Elf_Shdr const *const strsec = [w(symsec->sh_link)];
-   Elf_Rel const *const rel0 = (Elf_Rel const *)(relhdr->sh_offset
+   Elf_Rel const *const rel0 = (Elf_Rel const *)(rels->sh.sh_offset
+ (void *)ehdr);
 
*sym0 = (Elf_Sym const *)(_w(symsec->sh_offset)
@@ -316,7 +314,7 @@ static void get_sym_str_and_relp(GElf_Shdr const *const 
relhdr,
 static uint_t *sift_rel_mcount(uint_t *mlocp,

[PATCH] sched/deadline: Fix a typo in a comment

[Christophe JAILLET]

s/deadine/deadline/

Signed-off-by: Christophe JAILLET 
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 504d2f51b0d6..cc2066e25dcf 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1098,7 +1098,7 @@ void init_dl_task_timer(struct sched_dl_entity *dl_se)
  * cannot use the runtime, and so it replenishes the task. This rule
  * works fine for implicit deadline tasks (deadline == period), and the
  * CBS was designed for implicit deadline tasks. However, a task with
- * constrained deadline (deadine < period) might be awakened after the
+ * constrained deadline (deadline < period) might be awakened after the
  * deadline, but before the next period. In this case, replenishing the
  * task would allow it to run for runtime / deadline. As in this case
  * deadline < period, CBS enables a task to run for more than the
-- 
2.25.1

Re: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()

[Andy Lutomirski]

> On Jun 2, 2020, at 10:27 AM, Shuah Khan  wrote:
> 
> On 6/2/20 11:03 AM, Andy Lutomirski wrote:
>>> On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov  wrote:
>>> 
>>> Hi,
>>> 
>>> On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote:
 The kernel module is not actually x86-specific, even though it is
 currently only enabled for x86. amdgpu driver already does kernel mode
 floating point operations on PPC64 also, and the same module could be
 used to test the same thing there.
>>> 
>>> Then make it generic please and put the user portion in, say,
>>> tools/testing/selftests/fpu/ and we can ask ppc people to test it too.
>>> People might wanna add more stuff to it in the future, which would be
>>> good.
>>> 
 To deterministically trigger the bug, the syscall has to come from the
 same thread that has modified MXCSR. Going through /usr/sbin/modprobe
 won't work, and manually doing the necessary syscalls for module loading
 seems too complicated.
>>> 
>>> Ok, fair enough. But put that file in debugfs pls.
>> I think I agree.  While it would be delightful to have general
>> selftest tooling for kernel modules, we don't have that right now, and
>> having the test just work with an appropriately configured kernel
>> would be nice.
> 
> Let's extend it to do what we want it to do. I will happy to take
> patches. If you have some concrete ideas on what we can add, please
> do a short summary of what is missing. I will find a way to get this
> done.
> 
>> How about putting the file you frob in
>> /sys/kernel/debug/selftest_helpers/something_or_other.  The idea would
>> be that /sys/kernel/debug/selftest_helpers would be a general place
>> for kernel helpers needed to make selftests work.
> 
> Is this a workaround for the lack of selftest tooling for kernel
> modules? In which case, let's us focus on fix selftest tooling.

The goal here is to have a selftest that runs kernel code as part of its 
operation. That is, the selftest is, logically, starting in userspace:

setup_evil_state();
ret = call_kernel_helper();
check_some_other_stuff();
undo_evil_state();

And the call_kernel_helper() could be moderately specific to the test.

> 
> thanks,
> -- Shuah

Re: [PATCH 04/10] dt-bindings: spi: Add bindings for spi-dw-mchp

[Serge Semin]

On Wed, May 13, 2020 at 04:00:25PM +0200, Lars Povlsen wrote:
> This add DT bindings for the Microsemi/Microchip SPI controller used
> in various SoC's. It describes the "mscc,ocelot-spi" and
> "mscc,jaguar2-spi" bindings.

As I see it, there is no need in this patch at all. Current DT binding file
describes the MSCC version of the DW APB SSI IP pretty well. You can add an
example to the DT schema though with "mscc,ocelot-spi" or "mscc,jaguar2-spi"
compatible string and additional registers range. 

-Sergey

> 
> Reviewed-by: Alexandre Belloni 
> Signed-off-by: Lars Povlsen 
> ---
>  .../bindings/spi/mscc,ocelot-spi.yaml | 60 +++
>  .../bindings/spi/snps,dw-apb-ssi.txt  |  7 +--
>  MAINTAINERS   |  1 +
>  3 files changed, 63 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml 
> b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> new file mode 100644
> index 0..a3ac0fa576553
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/spi/mscc,ocelot-spi.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Microsemi Vcore-III SPI Communication Controller
> +
> +maintainers:
> +  - Alexandre Belloni 
> +  - Lars Povlsen 
> +
> +allOf:
> +  - $ref: "spi-controller.yaml#"
> +
> +description: |
> +  The Microsemi Vcore-III SPI controller is a general purpose SPI
> +  controller based upon the Designware SPI controller. It uses an 8
> +  byte rx/tx fifo.
> +
> +properties:
> +  compatible:
> +enum:
> +  - mscc,ocelot-spi
> +  - mscc,jaguar2-spi
> +
> +  interrupts:
> +maxItems: 1
> +
> +  reg:
> +minItems: 2
> +items:
> +  - description: Designware SPI registers
> +  - description: CS override registers
> +
> +  clocks:
> +maxItems: 1
> +
> +  reg-io-width:
> +description: |
> +  The I/O register width (in bytes) implemented by this device.
> +items:
> +   enum: [ 2, 4 ]
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +
> +examples:
> +  - |
> +spi0: spi@101000 {
> +  compatible = "mscc,ocelot-spi";
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +  reg = <0x101000 0x100>, <0x3c 0x18>;
> +  interrupts = <9>;
> +  clocks = <_clk>;
> +};
> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt 
> b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> index 3ed08ee9feba4..5e1849be7bae5 100644
> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> @@ -1,10 +1,8 @@
>  Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
> 
>  Required properties:
> -- compatible : "snps,dw-apb-ssi" or "mscc,-spi", where soc is "ocelot" 
> or
> -  "jaguar2", or "amazon,alpine-dw-apb-ssi"
> -- reg : The register base for the controller. For "mscc,-spi", a second
> -  register set is required (named ICPU_CFG:SPI_MST)
> +- compatible : "snps,dw-apb-ssi" or "amazon,alpine-dw-apb-ssi"
> +- reg : The register base for the controller.
>  - interrupts : One interrupt, used by the controller.
>  - #address-cells : <1>, as required by generic SPI binding.
>  - #size-cells : <0>, also as required by generic SPI binding.
> @@ -38,4 +36,3 @@ Example:
>   cs-gpios = < 13 0>,
>  < 14 0>;
>   };
> -
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1db598723a1d8..6472240b8391b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11231,6 +11231,7 @@ L:linux-m...@vger.kernel.org
>  S:   Supported
>  F:   Documentation/devicetree/bindings/mips/mscc.txt
>  F:   Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> +F:   Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
>  F:   arch/mips/boot/dts/mscc/
>  F:   arch/mips/configs/generic/board-ocelot.config
>  F:   arch/mips/generic/board-ocelot.c
> --
> 2.26.2
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Victor Julien]

On 02-06-2020 21:29, Jakub Kicinski wrote:
> On Tue, 2 Jun 2020 21:22:11 +0200 Victor Julien wrote:
>> - receiver uses nfp (netronome) driver: TP_STATUS_CSUM_VALID set for
>> every packet, including the bad TCP ones
>> - receiver uses ixgbe driver: TP_STATUS_CSUM_VALID not set for the bad
>> packets.
>>
>> Again purely based on 'git grep' it seems nfp does not support
>> UNNECESSARY, while ixgbe does.
>>
>> (my original testing was with the nfp only, so now I at least understand
>> my original thinking)
> 
> FWIW nfp defaults to CHECKSUM_COMPLETE if the device supports it (see
> if you have RXCSUM_COMPLETE in the probe logs). It supports UNNECESSARY
> as well, but IDK if there is a way to choose  the preferred checksum
> types in the stack :( You'd have to edit the driver and remove the
> NFP_NET_CFG_CTRL_CSUM_COMPLETE from the NFP_NET_CFG_CTRL_RXCSUM_ANY
> mask to switch to using UNNECESSARY.
> 

I indeed have RXCSUM_COMPLETE, so that should mean it uses
CHECKSUM_COMPLETE indeed.

nfp :43:00.0 eth0: CAP: 0x78140233 PROMISC RXCSUM TXCSUM GATHER TSO2
RSS2 AUTOMASK IRQMOD RXCSUM_COMPLETE

-- 
-
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
-

Re: kobject_init_and_add is easy to misuse

[Jason Gunthorpe]

On Tue, Jun 02, 2020 at 05:10:35AM -0700, Matthew Wilcox wrote:
> On Tue, Jun 02, 2020 at 07:50:33PM +0800, Wang Hai wrote:
> > syzkaller reports for memory leak when kobject_init_and_add()
> > returns an error in the function sysfs_slab_add() [1]
> > 
> > When this happened, the function kobject_put() is not called for the
> > corresponding kobject, which potentially leads to memory leak.
> > 
> > This patch fixes the issue by calling kobject_put() even if
> > kobject_init_and_add() fails.
> 
> I think this speaks to a deeper problem with kobject_init_and_add()
> to most users.  This same bug appears in the first three users of
> kobject_init_and_add() that I checked --
> arch/ia64/kernel/topology.c
> drivers/firmware/dmi-sysfs.c
> drivers/firmware/efi/esrt.c
> drivers/scsi/iscsi_boot_sysfs.c
> 
> Some do get it right --
> arch/powerpc/kernel/cacheinfo.c
> drivers/gpu/drm/ttm/ttm_bo.c
> drivers/gpu/drm/ttm/ttm_memory.c
> drivers/infiniband/hw/mlx4/sysfs.c
> 
> I'd argue that the current behaviour is wrong, that kobject_init_and_add()
> should call kobject_put() if the add fails.  

There are APIs that auto-free their argument on failure and last times
I checked one, about half the tree had a tricky use-after free bug on
the error path.

> This would need a tree-wide audit.  But somebody needs to do that
> anyway because based on my random sampling, half of the users
> currently get it wrong.

IMHO these functions that hide an 'init' inside (eg the switch from
kfree to refcount in the error unwind) are tricky. The caller must
switch from some kfree goto error unwind to a put goto error unwind,
which is very unnatural and strange.

I think it is better if the init is near the kalloc and the entire
error unwind always uses put. No switching.

Jason

[tip:sched/core] BUILD SUCCESS 25de110d148666752dc0e0da7a0b69de31cd7098

[kbuild test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
sched/core
branch HEAD: 25de110d148666752dc0e0da7a0b69de31cd7098  irq_work: Define 
irq_work_single() on !CONFIG_IRQ_WORK too

i386-tinyconfig vmlinux size:

==
 TOTAL  TEXT  try_invoke_on_locked_down_task()  
arch/x86/events/zhaoxin/built-in.*  
  
==
-1 0  
-136  c6e7bd7afaeb sched/core: Optimize ttwu() spinning on p->on_cpu
 0 0  
+136  2ebb17717550 sched/core: Offload wakee task activation if it the wakee is 
 0 0  
-136  498bdcdb949e Merge branch 'sched/urgent' into sched/core, to pick up fix  
  +172  +172   +76  
58ef57b16d9e Merge branch 'core/rcu' into sched/core, to pick up dependen 
 0 0 0  
19a1f5ec6999 sched: Fix smp_call_function_single_async() usage for ILB
 0 0 0  
52103be07d8b smp: Optimize flush_smp_call_function_queue()
 0 0 0  
afaa653c564d smp: Move irq_work_run() out of flush_smp_call_function_queu 
 0 0 0  
b2a02fc43a1f smp: Optimize send_call_function_single_ipi()
+1+1 0  
4b44a21dd640 irq_work, smp: Allow irq_work on call_single_queue   
   -31 0 0  
126c2092e5c8 sched: Add rq::ttwu_pending  
 0 0 0  
a148866489fb sched: Replace rq::wake_list 
 0 0 0
+136  1f8db4150536 sched/headers: Split out open-coded prototypes into kernel/s 
-1 0 0  
 0  25de110d1486 irq_work: Define irq_work_single() on !CONFIG_IRQ_WORK too   
  +140  +173   +76  
 0  d505b8af5891..25de110d1486 (ALL COMMITS)  
==

elapsed time: 485m

configs tested: 111
configs skipped: 10

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm   allnoconfig
arc haps_hs_defconfig
sparc64 defconfig
arm  pxa255-idp_defconfig
sh shx3_defconfig
arm  alldefconfig
mips   ip28_defconfig
xtensageneric_kc705_defconfig
arc nps_defconfig
armkeystone_defconfig
armmulti_v5_defconfig
nios2   defconfig
armshmobile_defconfig
mips   xway_defconfig
arm  ixp4xx_defconfig
sh   se7780_defconfig
arm  moxart_defconfig
sh   j2_defconfig
sparc64  allyesconfig
armmps2_defconfig
powerpc pseries_defconfig
arm   netwinder_defconfig
xtensa   common_defconfig
mips  ath79_defconfig
armvt8500_v6_v7_defconfig
arm hackkit_defconfig
mips cu1000-neo_defconfig
x86_64  defconfig
ia64 allmodconfig
powerpc  storcenter_defconfig
mips  

Re: [PATCH] kunit: Fix TabError, remove defconfig code and handle when there is no kunitconfig

[Shuah Khan]

On 5/29/20 1:28 PM, Vitor Massaru Iha wrote:

The identation before this code (`if not os.path.exists(cli_args.build_dir):``)
was with spaces instead of tabs after fixed up merge conflits,
this commit revert spaces to tabs:




Applied to linux-kselftest kunit branch for Linux 5.8-rc1

thanks,
-- Shuah

[PATCH] serial: kgdboc: Fix bad line wrapping in comment

[Douglas Anderson]

In commit a4912303ac6f ("serial: kgdboc: Allow earlycon initialization
to be deferred") it looks like Daniel really took Linus's new
suggestion about not needing to wrap at 80 columns to heart and he
jammed two full lines of comments into one line.  Either that or he
just somehow accidentally deleted a carriage return when doing final
edits on the patch.  In either case let's make it look prettier.

Signed-off-by: Douglas Anderson 
---

 drivers/tty/serial/kgdboc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
index 41396982e9e0..fe6ae98360a2 100644
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -538,7 +538,8 @@ static int __init kgdboc_earlycon_init(char *opt)
 
if (!con) {
/*
-* Both earlycon and kgdboc_earlycon are initialized during 
 * early parameter parsing. We cannot guarantee earlycon gets
+* Both earlycon and kgdboc_earlycon are initialized during
+* early parameter parsing. We cannot guarantee earlycon gets
 * in first and, in any case, on ACPI systems earlycon may
 * defer its own initialization (usually to somewhere within
 * setup_arch() ). To cope with either of these situations
-- 
2.27.0.rc2.251.g90737beb825-goog

Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot

[John Stultz]

On Tue, Jun 2, 2020 at 12:16 PM Brian Norris  wrote:
>
> + Sibi
>
> On Mon, Jun 1, 2020 at 10:25 PM John Stultz  wrote:
> >
> > Ever since 5.7-rc1, if we call
> > ath10k_qmi_remove_msa_permission(), the db845c hard crashes on
> > reboot, resulting in the device getting stuck in the usb crash
> > debug mode and not coming back up wihthout a hard power off.
> >
> > This hack avoids the issue by returning early in
> > ath10k_qmi_event_server_exit().
> >
> > A better solution is very much desired!
>
> Any chance you can bisect what caused this? There are a lot of
> non-ath10k pieces involved in this stuff.

Amit had spent some work on chasing it down to the in kernel qrtr-ns
work, and reported it here:
  https://lists.infradead.org/pipermail/ath10k/2020-April/014970.html

But that discussion seemingly stalled out, so I came up with this hack
to workaround it for us.

thanks
-john

Re: [PATCH v3 0/6] Enable as many KUnit tests as possible

[Shuah Khan]

On 5/28/20 1:13 PM, Shuah Khan wrote:

On 5/28/20 1:07 PM, Brendan Higgins wrote:
On Wed, May 27, 2020 at 4:49 AM Anders Roxell 
 wrote:


Hi all,

Friendly ping: who can take this?


Sorry, I just reviewed the last patch.

Shuah, do you mind picking this up for 5.8?



Yup. Will do. I was watching this thread waiting for your
Ack. I will apply it once.



Applied to linux-kselftest kunit branch for Linux 5.8-rc1

thanks,
-- Shuah

Re: [PATCH 02/10] spi: dw: Add support for RX sample delay register

[Serge Semin]

On Wed, May 13, 2020 at 04:00:23PM +0200, Lars Povlsen wrote:
> This add support for the RX_SAMPLE_DLY register. If enabled in the
> Designware IP, it allows tuning of the rx data signal by means of an
> internal rx sample fifo.
> 
> The register is located at offset 0xf0, and if the option is not
> enabled in the IP, changing the register will have no effect.
> 
> Reviewed-by: Alexandre Belloni 
> Signed-off-by: Lars Povlsen 
> ---
>  drivers/spi/spi-dw.c | 7 +++
>  drivers/spi/spi-dw.h | 2 ++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index e572eb34a3c1a..32997f28fa5bb 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -81,6 +81,9 @@ static ssize_t dw_spi_show_regs(struct file *file, char 
> __user *user_buf,
>   "DMATDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMATDLR));
>   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
>   "DMARDLR: \t0x%08x\n", dw_readl(dws, DW_SPI_DMARDLR));

> + len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
> +  "RX_SAMPLE_DLY: \t0x%08x\n",
> +  dw_readl(dws, DW_SPI_RX_SAMPLE_DLY));

debugfs_reg32 interface is now utilized in the driver to dump the registers
state. So this will have to be converted to just a new entry in the
dw_spi_dbgfs_regs array.

>   len += scnprintf(buf + len, SPI_REGS_BUFSIZE - len,
>   "=\n");
> 
> @@ -315,6 +318,10 @@ static int dw_spi_transfer_one(struct spi_controller 
> *master,
>   spi_set_clk(dws, chip->clk_div);
>   }
> 

> + /* Apply RX sample delay, iff requested (nonzero) */

s/iff/if

> + if (dws->rx_sample_dly)
> + dw_writel(dws, DW_SPI_RX_SAMPLE_DLY, dws->rx_sample_dly);
> +
>   dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
>   dws->dma_width = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
> 
> diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
> index 1bf5713e047d3..ed6e47b3f50da 100644
> --- a/drivers/spi/spi-dw.h
> +++ b/drivers/spi/spi-dw.h
> @@ -31,6 +31,7 @@
>  #define DW_SPI_IDR   0x58
>  #define DW_SPI_VERSION   0x5c
>  #define DW_SPI_DR0x60
> +#define DW_SPI_RX_SAMPLE_DLY 0xf0
>  #define DW_SPI_CS_OVERRIDE   0xf4
> 
>  /* Bit fields in CTRLR0 */
> @@ -111,6 +112,7 @@ struct dw_spi {
> 
>   int cs_override;
>   u32 reg_io_width;   /* DR I/O width in bytes */

> + u8  rx_sample_dly;  /* RX fifo tuning (option) */

This doesn't seem like a good place for this parameter. The sample delay is
SPI-slave specific. So as I see it, the parameter should be moved to the
chip_data.

-Sergey

>   u16 bus_num;
>   u16 num_cs; /* supported slave numbers */
>   void (*set_cs)(struct spi_device *spi, bool enable);
> --
> 2.26.2
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Willem de Bruijn]

On Tue, Jun 2, 2020 at 3:22 PM Victor Julien  wrote:
>
> On 02-06-2020 21:03, Willem de Bruijn wrote:
> > On Tue, Jun 2, 2020 at 2:31 PM Victor Julien  wrote:
> >> On 02-06-2020 19:37, Willem de Bruijn wrote:
> >>> On Tue, Jun 2, 2020 at 1:03 PM Victor Julien  wrote:
> 
>  On 02-06-2020 16:29, Willem de Bruijn wrote:
> > On Tue, Jun 2, 2020 at 4:05 AM Victor Julien  
> > wrote:
> >>
> >> Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
> >> that the driver has completely validated the checksums in the packet.
> >>
> >> The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
> >> in that the new flag will only be set if all the layers are valid,
> >> while TP_STATUS_CSUM_VALID is set as well if only the IP layer is 
> >> valid.
> >
> > transport, not ip checksum.
> 
>  Allow me a n00b question: what does transport refer to here? Things like
>  ethernet? It isn't clear to me from the doc.
> >>>
> >>> The TCP/UDP/.. transport protocol checksum.
> >>
> >> Hmm that is what I thought originally, but then it didn't seem to work.
> >> Hence my patch.
> >>
> >> However I just redid my testing. I took the example tpacketv3 program
> >> and added the status flag checks to the 'display()' func:
> >>
> >> if (ppd->tp_status & TP_STATUS_CSUM_VALID) {
> >> printf("TP_STATUS_CSUM_VALID, ");
> >> }
> >> if (ppd->tp_status & (1<<8)) {
> >> printf("TP_STATUS_CSUM_UNNECESSARY, ");
> >>
> >> }
> >>
> >> Then using scapy sent some packets in 2 variants:
> >> - default (good csums)
> >> - deliberately bad csums
> >> (then also added a few things like ip6 over ip)
> >>
> >>
> >> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(),
> >> iface="enp1s0") // good csums
> >>
> >> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(chksum=1),
> >> iface="enp1s0") //bad tcp
> >
> > Is this a test between two machines? What is the device driver of the
> > machine receiving and printing the packet? It would be helpful to know
> > whether this uses CHECKSUM_COMPLETE or CHECKSUM_UNNECESSARY.
>
> Yes 2 machines, or actually 2 machines and a VM. The receiving Linux
> sits in a kvm vm with network pass through and uses the virtio driver
> (host uses e1000e). Based on a quick 'git grep CHECKSUM_UNNECESSARY'
> virtio seems to support that.
>
> I've done some more tests. In a pcap replay that I know contains packet
> with bad TCP csums (but good IP csums for those pkts), to a physical
> host running Ubuntu Linux kernel 5.3:
>
> - receiver uses nfp (netronome) driver: TP_STATUS_CSUM_VALID set for
> every packet, including the bad TCP ones
> - receiver uses ixgbe driver: TP_STATUS_CSUM_VALID not set for the bad
> packets.

Great. Thanks a lot for running all these experiments.

We might have to drop the TP_STATUS_CSUM_VALID with CHECKSUM_COMPLETE
unless skb->csum_valid.

For packets with multiple transport layer checksums,
CHECKSUM_UNNECESSARY should mean that all have been verified.

I believe that in the case of multiple transport headers, csum_valid
similarly ensures all checksums up to csum_start are valid. Will need
to double check.

If so, there probably is no need for a separate new TP_STATUS.
TP_STATUS_CSUM_VALID is reported only when all checksums are valid.

> Again purely based on 'git grep' it seems nfp does not support
> UNNECESSARY, while ixgbe does.
>
> (my original testing was with the nfp only, so now I at least understand
> my original thinking)
>
>
> >>
> >> 1.2.3.4 -> 5.6.7.8, TP_STATUS_CSUM_VALID, TP_STATUS_CSUM_UNNECESSARY,
> >> rxhash: 0x81ad5744
> >> 1.2.3.4 -> 5.6.7.8, rxhash: 0x81ad5744
> >>
> >> So this suggests that what you're saying is correct, that it sets
> >> TP_STATUS_CSUM_VALID if the TCP/UDP csum (and IPv4 csum) is valid, and
> >> does not set it when either of them are invalid.
> >
> > That's not exactly what I said. It looks to me that a device that sets
> > CHECKSUM_COMPLETE will return TP_STATUS_CSUM_VALID from
> > __netif_receive_skb_core even if the TCP checksum turns out to be bad.
> > If a driver would insert such packets into the stack, that is.
>
> Ok, this might be confirmed by my nfp vs virtio/ixgbe observations
> mentioned above.
>
>
> >> I'll also re-evaluate things in Suricata.
> >>
> >>
> >> One thing I wonder if what this "at least" from the 682f048bd494 commit
> >> message means:
> >>
> >> "Introduce TP_STATUS_CSUM_VALID tp_status flag to tell the
> >>  af_packet user that at least the transport header checksum
> >>  has been already validated."
> >>
> >> For TCP/UDP there wouldn't be a higher layer with csums, right? And
> >> based on my testing it seems lower levels (at least IP) is also
> >> included. Or would that perhaps refer to something like VXLAN or Geneve
> >> over UDP? That the csums of packets on top of those layers aren't
> >> (necessarily) considered?
> >
> > The 

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Peter Zijlstra]

On Tue, Jun 02, 2020 at 09:25:47PM +0200, Marco Elver wrote:
> On Tue, 2 Jun 2020 at 21:19, Peter Zijlstra  wrote:

> > Currently x86 only, but I know other arch maintainers are planning to
> > have a hard look at their code based on our findings.
> 
> I've already spotted a bunch of 'noinstr' outside arch/x86 e.g. in
> kernel/{locking,rcu}, and a bunch of these functions use atomic_*, all
> of which are __always_inline. The noinstr uses outside arch/x86 would
> break builds on all architecture with GCC <= 7 when using sanitizers.
> At least that's what led me to conclude we need this for all
> architectures.

True; but !x86 could, probably, get away with not fully respecting
noinstr at this time. But that'd make a mess of things again, so my
preference is as you did, unilaterally raise the min version for *SAN.

That said; noinstr's __no_sanitize combined with atomic_t might be
'interesting', because the regular atomic things have explicit
annotations in them. That should give validation warnings for the right
.config, I'll have to go try -- so far I've made sure to never enable
the *SAN stuff.

[PATCH] i2c: pxa: don't error out if there's no pinctrl

[Lubomir Rintel]

The bus recovery patch regresses on OLPC XO-1.75 that has no pinctrl in
its DT.

Fixes: 7c9ec2c52518 ("i2c: pxa: implement generic i2c bus recovery")'
Signed-off-by: Lubomir Rintel 
---
 drivers/i2c/busses/i2c-pxa.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index a7885b8b5031c..35ca2c02c9b9b 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1348,6 +1348,8 @@ static int i2c_pxa_init_recovery(struct pxa_i2c *i2c)
return 0;
 
i2c->pinctrl = devm_pinctrl_get(dev);
+   if (PTR_ERR(i2c->pinctrl) == -ENODEV)
+   i2c->pinctrl = NULL;
if (IS_ERR(i2c->pinctrl))
return PTR_ERR(i2c->pinctrl);
 
-- 
2.26.2

Re: [PATCH v2 1/4] remoteproc: Introduce rproc_of_parse_firmware() helper

[Mathieu Poirier]

On Wed, May 20, 2020 at 07:10:03PM -0500, Suman Anna wrote:
> Add a new helper function rproc_of_parse_firmware() to the remoteproc
> core that can be used by various remoteproc drivers to look up the
> the "firmware-name" property from a rproc device node. This property
> is already being used by multiple drivers, so this helper can avoid
> repeating equivalent code in remoteproc drivers.
> 
> Signed-off-by: Suman Anna 
> ---
> v2: New patch
> 
>  drivers/remoteproc/remoteproc_core.c | 23 +++
>  drivers/remoteproc/remoteproc_internal.h |  2 ++
>  2 files changed, 25 insertions(+)
> 

Reviewed-by: Mathieu Poirier 

> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 9f04c30c4aaf..c458b218d524 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1034,6 +1034,29 @@ rproc_of_resm_mem_entry_init(struct device *dev, u32 
> of_resm_idx, size_t len,
>  }
>  EXPORT_SYMBOL(rproc_of_resm_mem_entry_init);
>  
> +/**
> + * rproc_of_parse_firmware() - parse and return the firmware-name
> + * @dev: pointer on device struct representing a rproc
> + * @index: index to use for the firmware-name retrieval
> + * @fw_name: pointer to a character string, in which the firmware
> + *   name is returned on success and unmodified otherwise.
> + *
> + * This is an OF helper function that parses a device's DT node for
> + * the "firmware-name" property and returns the firmware name pointer
> + * in @fw_name on success.
> + *
> + * Return: 0 on success, or an appropriate failure.
> + */
> +int rproc_of_parse_firmware(struct device *dev, int index, const char 
> **fw_name)
> +{
> + int ret;
> +
> + ret = of_property_read_string_index(dev->of_node, "firmware-name",
> + index, fw_name);
> + return ret ? ret : 0;
> +}
> +EXPORT_SYMBOL(rproc_of_parse_firmware);
> +
>  /*
>   * A lookup table for resource handlers. The indices are defined in
>   * enum fw_resource_type.
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index 4ba7cb59d3e8..e5341e91d2fc 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -28,6 +28,8 @@ struct rproc_debug_trace {
>  void rproc_release(struct kref *kref);
>  irqreturn_t rproc_vq_interrupt(struct rproc *rproc, int vq_id);
>  void rproc_vdev_release(struct kref *ref);
> +int rproc_of_parse_firmware(struct device *dev, int index,
> + const char **fw_name);
>  
>  /* from remoteproc_virtio.c */
>  int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id);
> -- 
> 2.26.0
> 

[PATCH v2] x86/resctrl: fix a NULL vs IS_ERR() static checker warning

[Dan Carpenter]

The callers don't expect *d_cdp to be set to an error pointer, they only
check for NULL.  This leads to a static checker warning:

arch/x86/kernel/cpu/resctrl/rdtgroup.c:2648 __init_one_rdt_domain()
warn: 'd_cdp' could be an error pointer

This would not trigger a bug in this specific case because
__init_one_rdt_domain() calls it with a valid domain that would not have
a negative id and thus not trigger the return of the ERR_PTR(). If this
was a negative domain id then the call to rdt_find_domain() in
domain_add_cpu() would have returned the ERR_PTR() much earlier and the
creation of the domain with an invalid id would have been prevented.

Even though a bug is not triggered currently the right and safe thing to
do is to set the pointer to NULL because that is what can be checked for
when the caller is handling the CDP and non-CDP cases.

Fixes: 52eb74339a62 ("x86/resctrl: Fix rdt_find_domain() return value and 
checks")
Signed-off-by: Dan Carpenter 
Acked-by: Reinette Chatre 
---
v2: improve commit message with extra information from the maintainer

 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c 
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 23b4b61319d3f..3f844f14fc0a6 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -1117,6 +1117,7 @@ static int rdt_cdp_peer_get(struct rdt_resource *r, 
struct rdt_domain *d,
_d_cdp = rdt_find_domain(_r_cdp, d->id, NULL);
if (WARN_ON(IS_ERR_OR_NULL(_d_cdp))) {
_r_cdp = NULL;
+   _d_cdp = NULL;
ret = -EINVAL;
}
 
-- 
2.26.2

Re: spi: spi-ti-qspi: call pm_runtime_put on pm_runtime_get failure

[Navid Emamdoost]

On Tue, Jun 2, 2020 at 1:36 PM Mark Brown  wrote:
>
> On Tue, Jun 02, 2020 at 05:05:18PM +0200, Markus Elfring wrote:
> > >> I find this commit message improvable also according to Linux software
> > >> development documentation.
>
> > > Causing people to send out new versions of things for tweaks to the
> > > commit log consumes time for them and everyone they're sending changes to.
>
> > Improving patches (besides source code adjustments) is an usual software
> > development activity, isn't it?
>
> Your updates were not improvements.  The formatting was worse and to my
> native speaker eyes the grammar was worse.  With this sort of stylistic
> thing it's especially important that any review aligns with the needs
> and practices of the subsystem, there is opinion in there and multiple
> opinions just makes things harder for submitters.

Thanks Mark for your constructive opinion,
In most cases, such stylistic comments become confusing and
discouraging to those who are trying to chip in. Personally I think as
long as the patch does not contain typo and is not ambiguous from the
maintainer's perspective, it should be fine to let it go forward.



-- 
Navid.

[PATCH 1/2] dt-bindings: ASoc: Fix tdm-slot documentation spelling error

[Dan Murphy]

Fix the spelling of 'specified'.  Also fix grammarical issue with the
use of 'a' over 'an'

Signed-off-by: Dan Murphy 
---
 Documentation/devicetree/bindings/sound/tdm-slot.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt 
b/Documentation/devicetree/bindings/sound/tdm-slot.txt
index 34cf70e2cbc4..4bb513ae62fc 100644
--- a/Documentation/devicetree/bindings/sound/tdm-slot.txt
+++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -14,8 +14,8 @@ For instance:
dai-tdm-slot-tx-mask = <0 1>;
dai-tdm-slot-rx-mask = <1 0>;
 
-And for each spcified driver, there could be one .of_xlate_tdm_slot_mask()
-to specify a explicit mapping of the channels and the slots. If it's absent
+And for each specified driver, there could be one .of_xlate_tdm_slot_mask()
+to specify an explicit mapping of the channels and the slots. If it's absent
 the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the
 tx and rx masks.
 
-- 
2.26.2

[PATCH 2/2] dt-bindings: tas2562: Convert the tas2562 binding to yaml

[Dan Murphy]

Convert the TAS2562 text file to yaml format.

Signed-off-by: Dan Murphy 
---
 .../devicetree/bindings/sound/tas2562.txt | 34 --
 .../devicetree/bindings/sound/tas2562.yaml| 65 +++
 2 files changed, 65 insertions(+), 34 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/tas2562.txt
 create mode 100644 Documentation/devicetree/bindings/sound/tas2562.yaml

diff --git a/Documentation/devicetree/bindings/sound/tas2562.txt 
b/Documentation/devicetree/bindings/sound/tas2562.txt
deleted file mode 100644
index 94796b547184..
--- a/Documentation/devicetree/bindings/sound/tas2562.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Texas Instruments TAS2562 Smart PA
-
-The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
-efficiently driving high peak power into small loudspeakers.
-Integrated speaker voltage and current sense provides for
-real time monitoring of loudspeaker behavior.
-
-Required properties:
- - #address-cells  - Should be <1>.
- - #size-cells - Should be <0>.
- - compatible:- Should contain "ti,tas2562", "ti,tas2563".
- - reg:   - The i2c address. Should be 0x4c, 0x4d, 0x4e or 
0x4f.
- - ti,imon-slot-no:- TDM TX current sense time slot.
-
-Optional properties:
-- interrupt-parent: phandle to the interrupt controller which provides
-the interrupt.
-- interrupts: (GPIO) interrupt to which the chip is connected.
-- shut-down: GPIO used to control the state of the device.
-
-Examples:
-tas2562@4c {
-#address-cells = <1>;
-#size-cells = <0>;
-compatible = "ti,tas2562";
-reg = <0x4c>;
-
-interrupt-parent = <>;
-interrupts = <14>;
-
-   shut-down = < 15 0>;
-ti,imon-slot-no = <0>;
-};
-
diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml 
b/Documentation/devicetree/bindings/sound/tas2562.yaml
new file mode 100644
index ..11e0269d03b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2562.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/sound/tas2562.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Texas Instruments TAS2562 Smart PA
+
+maintainers:
+  - Dan Murphy 
+
+description: |
+  The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
+  efficiently driving high peak power into small loudspeakers.
+  Integrated speaker voltage and current sense provides for
+  real time monitoring of loudspeaker behavior.
+
+properties:
+  compatible:
+enum:
+  - ti,tas2562
+  - ti,tas2563
+
+  reg:
+maxItems: 1
+description: |
+   I2C addresss of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
+
+  shut-down:
+description: GPIO used to control the state of the device.
+
+  interrupts:
+maxItems: 1
+
+  ti,imon-slot-no:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: TDM TX current sense time slot.
+
+  '#sound-dai-cells':
+const: 1
+
+required:
+  - compatible
+  - reg
+additionalProperties: false
+
+examples:
+  - |
+   #include 
+   i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec: codec@4c {
+   compatible = "ti,tas2562";
+   reg = <0x4c>;
+   #sound-dai-cells = <1>;
+   interrupt-parent = <>;
+   interrupts = <14>;
+
+   shut-down = < 15 0>;
+   ti,imon-slot-no = <0>;
+ };
+   };
+
-- 
2.26.2

Re: [RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION

[Alex Williamson]

On Tue, 2 Jun 2020 04:28:58 -0400
Yan Zhao  wrote:

> On Mon, Jun 01, 2020 at 10:43:07AM -0600, Alex Williamson wrote:
> > On Mon, 1 Jun 2020 02:57:26 -0400
> > Yan Zhao  wrote:
> >   
> > > On Fri, May 29, 2020 at 03:45:47PM -0600, Alex Williamson wrote:  
> > > > On Sun, 17 May 2020 22:52:45 -0400
> > > > Yan Zhao  wrote:
> > > > 
> > > > > This is a virtual irq type.
> > > > > vendor driver triggers this irq when it wants to notify userspace to
> > > > > remap PCI BARs.
> > > > > 
> > > > > 1. vendor driver triggers this irq and packs the target bar number in
> > > > >the ctx count. i.e. "1 << bar_number".
> > > > >if a bit is set, the corresponding bar is to be remapped.
> > > > > 
> > > > > 2. userspace requery the specified PCI BAR from kernel and if flags of
> > > > > the bar regions are changed, it removes the old subregions and 
> > > > > attaches
> > > > > subregions according to the new flags.
> > > > > 
> > > > > 3. userspace notifies back to kernel by writing one to the eventfd of
> > > > > this irq.
> > > > > 
> > > > > Please check the corresponding qemu implementation from the reply of 
> > > > > this
> > > > > patch, and a sample usage in vendor driver in patch [10/10].
> > > > > 
> > > > > Cc: Kevin Tian 
> > > > > Signed-off-by: Yan Zhao 
> > > > > ---
> > > > >  include/uapi/linux/vfio.h | 11 +++
> > > > >  1 file changed, 11 insertions(+)
> > > > > 
> > > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > > > index 2d0d85c7c4d4..55895f75d720 100644
> > > > > --- a/include/uapi/linux/vfio.h
> > > > > +++ b/include/uapi/linux/vfio.h
> > > > > @@ -704,6 +704,17 @@ struct vfio_irq_info_cap_type {
> > > > >   __u32 subtype;  /* type specific */
> > > > >  };
> > > > >  
> > > > > +/* Bar Region Query IRQ TYPE */
> > > > > +#define VFIO_IRQ_TYPE_REMAP_BAR_REGION   (1)
> > > > > +
> > > > > +/* sub-types for VFIO_IRQ_TYPE_REMAP_BAR_REGION */
> > > > > +/*
> > > > > + * This irq notifies userspace to re-query BAR region and remaps the
> > > > > + * subregions.
> > > > > + */
> > > > > +#define VFIO_IRQ_SUBTYPE_REMAP_BAR_REGION(0)
> > > > 
> > > > Hi Yan,
> > > > 
> > > > How do we do this in a way that's backwards compatible?  Or maybe, how
> > > > do we perform a handshake between the vendor driver and userspace to
> > > > indicate this support?
> > > hi Alex
> > > thank you for your thoughtful review!
> > > 
> > > do you think below sequence can provide enough backwards compatibility?
> > > 
> > > - on vendor driver opening, it registers an irq of type
> > >   VFIO_IRQ_TYPE_REMAP_BAR_REGION, and reports to driver vfio-pci there's
> > >   1 vendor irq.
> > > 
> > > - after userspace detects the irq of type VFIO_IRQ_TYPE_REMAP_BAR_REGION
> > >   it enables it by signaling ACTION_TRIGGER.
> > >   
> > > - on receiving this ACTION_TRIGGER, vendor driver will try to setup a
> > >   virqfd to monitor file write to the fd of this irq, enable this irq
> > >   and return its enabling status to userspace.  
> > 
> > I'm not sure I follow here, what's the purpose of the irqfd?  When and
> > what does the user signal by writing to the irqfd?  Is this an ACK
> > mechanism?  Is this a different fd from the signaling eventfd?  
> it's not the kvm irqfd.
> in the vendor driver side, once ACTION_TRIGGER is received for the remap irq,
> interface vfio_virqfd_enable() is called to monitor writes to the eventfd of
> this irq.
> 
> when vendor driver signals the eventfd, remap handler in QEMU is
> called and it writes to the eventfd after remapping is done.
> Then the virqfd->handler registered in vendor driver is called to receive
> the QEMU ack.

This seems racy to use the same fd as both an eventfd and irqfd, does
the host need to wait for the user to service the previous IRQ before
sending a new one?  Don't we have gaps where the user is either reading
or writing where we can lose an interrupt?  Does the user also write a
bitmap?  How do we avoid getting out of sync?  Why do we even need
this, can't the vendor driver look for vm_ops.close callbacks for the
offending vma mmaps?

> > > > Would the vendor driver refuse to change
> > > > device_state in the migration region if the user has not enabled this
> > > > IRQ?
> > > yes, vendor driver can refuse to change device_state if the irq
> > > VFIO_IRQ_TYPE_REMAP_BAR_REGION is not enabled.
> > > in my sample i40e_vf driver (patch 10/10), it implemented this logic
> > > like below:
> > > 
> > > i40e_vf_set_device_state
> > > |-> case VFIO_DEVICE_STATE_SAVING | VFIO_DEVICE_STATE_RUNNING:
> > > |  ret = i40e_vf_prepare_dirty_track(i40e_vf_dev);
> > >   |->ret = i40e_vf_remap_bars(i40e_vf_dev, 
> > > true);
> > >|->if 
> > > (!i40e_vf_dev->remap_irq_ctx.init)
> > > return -ENODEV;
> > > 
> > > 
> > > (i40e_vf_dev->remap_irq_ctx.init is set in 

Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ

[Brendan Higgins]

On Mon, Jun 1, 2020 at 10:42 PM David Gow  wrote:
>
> Add an FAQ entry to the KUnit documentation with some tips for
> troubleshooting KUnit and kunit_tool.
>
> These suggestions largely came from an email thread:
> https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03
>
> Signed-off-by: David Gow 

Looks good to me + Alan's suggestion.

Reviewed-by: Brendan Higgins 

[PATCH v2] x86_64: fix jiffies ODR violation

[Bob Haarman]

'jiffies' and 'jiffies_64' are meant to alias (two different symbols
that share the same address).  Most architectures make the symbols alias
to the same address via linker script assignment in their
arch//kernel/vmlinux.lds.S:

jiffies = jiffies_64;

which is effectively a definition of jiffies.

jiffies and jiffies_64 are both forward declared for all arch's in:
include/linux/jiffies.h.

jiffies_64 is defined in kernel/time/timer.c for all arch's.

x86_64 was peculiar in that it wasn't doing the above linker script
assignment, but rather was:
1. defining jiffies in arch/x86/kernel/time.c instead via linker script.
2. overriding the symbol jiffies_64 from kernel/time/timer.c in
arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'.

As Fangrui notes:

  In LLD, symbol assignments in linker scripts override definitions in
  object files. GNU ld appears to have the same behavior. It would
  probably make sense for LLD to error "duplicate symbol" but GNU ld
  is unlikely to adopt for compatibility reasons.

So we have an ODR violation (UB), which we seem to have gotten away
with thus far. Where it becomes harmful is when we:

1. Use -fno-semantic-interposition.

As Fangrui notes:

  Clang after LLVM commit 5b22bcc2b70d
  ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local")
  defaults to -fno-semantic-interposition similar semantics which help
  -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined
  within the same translation unit. Unlike GCC
  -fno-semantic-interposition, Clang emits such relocations referencing
  local symbols for non-pic code as well.

This causes references to jiffies to refer to '.Ljiffies$local' when
jiffies is defined in the same translation unit. Likewise, references
to jiffies_64 become references to '.Ljiffies_64$local' in translation
units that define jiffies_64.  Because these differ from the names
used in the linker script, they will not be rewritten to alias one
another.

Combined with ...

2. Full LTO effectively treats all source files as one translation
unit, causing these local references to be produced everywhere.  When
the linker processes the linker script, there are no longer any
references to jiffies_64' anywhere to replace with 'jiffies'.  And
thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias
at all.

In the process of porting patches enabling Full LTO from arm64 to
x86_64, we observe spooky bugs where the kernel appeared to boot, but
init doesn't get scheduled.

Instead, we can avoid the ODR violation by matching other arch's by
defining jiffies only by linker script.  For -fno-semantic-interposition
+ Full LTO, there is no longer a global definition of jiffies for the
compiler to produce a local symbol which the linker script won't ensure
aliases to jiffies_64.

Link: https://github.com/ClangBuiltLinux/linux/issues/852
Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible")
Cc: sta...@vger.kernel.org
Reported-by: Nathan Chancellor 
Reported-by: Alistair Delva 
Suggested-by: Fangrui Song 
Debugged-by: Nick Desaulniers 
Debugged-by: Sami Tolvanen 
Signed-off-by: Bob Haarman 
Reviewed-by: Andi Kleen 
Reviewed-by: Josh Poimboeuf 
---
v2:
* Changed commit message as requested by Josh Poimboeuf
  (no code change)

---
 arch/x86/kernel/time.c| 4 
 arch/x86/kernel/vmlinux.lds.S | 4 ++--
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index 371a6b348e44..e42faa792c07 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -25,10 +25,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_X86_64
-__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = 
INITIAL_JIFFIES;
-#endif
-
 unsigned long profile_pc(struct pt_regs *regs)
 {
unsigned long pc = instruction_pointer(regs);
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1bf7e312361f..7c35556c7827 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -40,13 +40,13 @@ OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT)
 #ifdef CONFIG_X86_32
 OUTPUT_ARCH(i386)
 ENTRY(phys_startup_32)
-jiffies = jiffies_64;
 #else
 OUTPUT_ARCH(i386:x86-64)
 ENTRY(phys_startup_64)
-jiffies_64 = jiffies;
 #endif
 
+jiffies = jiffies_64;
+
 #if defined(CONFIG_X86_64)
 /*
  * On 64-bit, align RODATA to 2MB so we retain large page mappings for
-- 
2.27.0.rc2.251.g90737beb825-goog

Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable

[Eric Anholt]

On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
 wrote:
>
> Hi Maxime and Eric
>
> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard  wrote:
> >
> > Hi Eric
> >
> > On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
> > > On Wed, May 27, 2020 at 8:50 AM Maxime Ripard  wrote:
> > > >
> > > > The VIDEN bit in the pixelvalve currently being used to enable or 
> > > > disable
> > > > the pixelvalve seems to not be enough in some situations, which whill 
> > > > end
> > > > up with the pixelvalve stalling.
> > > >
> > > > In such a case, even re-enabling VIDEN doesn't bring it back and we 
> > > > need to
> > > > clear the FIFO. This can only be done if the pixelvalve is disabled 
> > > > though.
> > > >
> > > > In order to overcome this, we can configure the pixelvalve during
> > > > mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO
> > > > there, and in atomic_disable disable the pixelvalve again.
> > >
> > > What displays has this been tested with?  Getting this sequencing
> > > right is so painful, and things like DSI are tricky to get to light
> > > up.
> >
> > That FIFO is between the HVS and the HDMI PVs, so this was obviously
> > tested against that. Dave also tested the DSI output IIRC, so we should
> > be covered here.
>
> DSI wasn't working on the first patch set that Maxime sent - I haven't
> tested this one as yet but will do so.
> DPI was working early on to both an Adafruit 800x480 DPI panel, and
> via a VGA666 as VGA.
> HDMI is obviously working.
> VEC is being ignored now. The clock structure is more restricted than
> earlier chips, so to get the required clocks for the VEC without using
> fractional divides it compromises the clock that other parts of the
> system can run at (IIRC including the ARM). That's why the VEC has to
> be explicitly enabled for the firmware to enable it as the only
> output. It's annoying, but that's just a restriction of the chip.

I'm more concerned with "make sure we don't regress pre-pi4 with this
series" than "pi4 displays all work from the beginning"

Re: [PATCH RESEND v3 0/6] arm64: add the time namespace support

[Dmitry Safonov]

Hi Andrei,

On 6/2/20 7:02 PM, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
> 
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is replaced with a namespace specific page
> which has the same layout as the VVAR page. That page has vdso_data->seq
> set to 1 to enforce the slow path and vdso_data->clock_mode set to
> VCLOCK_TIMENS to enforce the time namespace handling path.
> 
> The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
> update of the VDSO data is in progress, is not really affecting regular
> tasks which are not part of a time namespace as the task is spin waiting
> for the update to finish and vdso_data->seq to become even again.
> 
> If a time namespace task hits that code path, it invokes the corresponding
> time getter function which retrieves the real VVAR page, reads host time
> and then adds the offset for the requested clock which is stored in the
> special VVAR page.
> 
> v2: Code cleanups suggested by Vincenzo.
> v3: add a comment in __arch_get_timens_vdso_data.
> 
> Reviewed-by: Vincenzo Frascino 
> Cc: Thomas Gleixner 
> Cc: Dmitry Safonov 
> 
> v3 on github (if someone prefers `git pull` to `git am`):
> https://github.com/avagin/linux-task-diag/tree/arm64/timens-v3

Thanks for adding arm64 support, I've looked through patches and don't
see any major problems.

Reviewed-by: Dmitry Safonov 

> 
> Andrei Vagin (6):
>   arm64/vdso: use the fault callback to map vvar pages
>   arm64/vdso: Zap vvar pages when switching to a time namespace
>   arm64/vdso: Add time napespace page
>   arm64/vdso: Handle faults on timens page
>   arm64/vdso: Restrict splitting VVAR VMA
>   arm64: enable time namespace support
> 
>  arch/arm64/Kconfig|   1 +
>  .../include/asm/vdso/compat_gettimeofday.h|  11 ++
>  arch/arm64/include/asm/vdso/gettimeofday.h|   8 ++
>  arch/arm64/kernel/vdso.c  | 134 --
>  arch/arm64/kernel/vdso/vdso.lds.S |   3 +-
>  arch/arm64/kernel/vdso32/vdso.lds.S   |   3 +-
>  include/vdso/datapage.h   |   1 +
>  7 files changed, 147 insertions(+), 14 deletions(-)
> 

Thanks,
  Dmitry

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Jakub Kicinski]

On Tue, 2 Jun 2020 21:22:11 +0200 Victor Julien wrote:
> - receiver uses nfp (netronome) driver: TP_STATUS_CSUM_VALID set for
> every packet, including the bad TCP ones
> - receiver uses ixgbe driver: TP_STATUS_CSUM_VALID not set for the bad
> packets.
> 
> Again purely based on 'git grep' it seems nfp does not support
> UNNECESSARY, while ixgbe does.
> 
> (my original testing was with the nfp only, so now I at least understand
> my original thinking)

FWIW nfp defaults to CHECKSUM_COMPLETE if the device supports it (see
if you have RXCSUM_COMPLETE in the probe logs). It supports UNNECESSARY
as well, but IDK if there is a way to choose  the preferred checksum
types in the stack :( You'd have to edit the driver and remove the
NFP_NET_CFG_CTRL_CSUM_COMPLETE from the NFP_NET_CFG_CTRL_RXCSUM_ANY
mask to switch to using UNNECESSARY.

Re: [PATCH 3/6] arm64/vdso: Add time namespace page

[Dmitry Safonov]

Hi Andrei,

On 6/2/20 7:02 PM, Andrei Vagin wrote:
[..]
> --- a/arch/arm64/include/asm/vdso.h
> +++ b/arch/arm64/include/asm/vdso.h
> @@ -12,6 +12,12 @@
>   */
>  #define VDSO_LBASE   0x0
>  
> +#ifdef CONFIG_TIME_NS
> +#define __VVAR_PAGES2
> +#else
> +#define __VVAR_PAGES1
> +#endif
> +
>  #ifndef __ASSEMBLY__

Not an issue as-is, but:

on x86 vdso+vvar is always the same size with/without CONFIG_TIME_NAMESPACE.

Timens page isn't allocated on !CONFIG_TIME_NAMESPACE, but vma is the
same size. Which simplifies criu/vdso migration between different kernel
configs.

Not any critical, but just to note..

Thanks,
  Dima

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Marco Elver]

On Tue, 2 Jun 2020 at 21:19, Peter Zijlstra  wrote:
>
> On Tue, Jun 02, 2020 at 11:57:15AM -0700, Nick Desaulniers wrote:
> > On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
> >  wrote:
> > >
> > > Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> > > have a compiler that does not fail builds due to no_sanitize functions.
> > > This does not yet mean they work as intended, but for automated
> > > build-tests, this is the minimum requirement.
> > >
> > > For example, we require that __always_inline functions used from
> > > no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> > > fails to build entirely, therefore we make the minimum version GCC 8.
> > >
> > > For KCSAN this is a non-functional change, however, we should add it in
> > > case this variable changes in future.
> > >
> > > Link: 
> > > https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
> > > Suggested-by: Peter Zijlstra 
> > > Signed-off-by: Marco Elver 
> >
> > Is this a problem only for x86?  If so, that's quite a jump in minimal
> > compiler versions for a feature that I don't think is currently
> > problematic for other architectures?  (Based on
> > https://lore.kernel.org/lkml/20200529171104.gd706...@hirez.programming.kicks-ass.net/
> > )
>
> Currently x86 only, but I know other arch maintainers are planning to
> have a hard look at their code based on our findings.

I've already spotted a bunch of 'noinstr' outside arch/x86 e.g. in
kernel/{locking,rcu}, and a bunch of these functions use atomic_*, all
of which are __always_inline. The noinstr uses outside arch/x86 would
break builds on all architecture with GCC <= 7 when using sanitizers.
At least that's what led me to conclude we need this for all
architectures.

Thanks,
-- Marco

[PATCH v2] s390: vdso: Use $(LD) instead of $(CC) to link vDSO

[Nathan Chancellor]

Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.

When clang is built in a default configuration, it first attempts to use
the target triple's default linker, which is just ld. However, the user
can override this through the CLANG_DEFAULT_LINKER cmake define so that
clang uses another linker by default, such as LLVM's own linker, ld.lld.
This can be useful to get more optimized links across various different
projects.

However, this is problematic for the s390 vDSO because ld.lld does not
have any s390 emulatiom support:

https://github.com/llvm/llvm-project/blob/llvmorg-10.0.1-rc1/lld/ELF/Driver.cpp#L132-L150

Thus, if a user is using a toolchain with ld.lld as the default, they
will see an error, even if they have specified ld.bfd through the LD
make variable:

$ make -j"$(nproc)" -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- LLVM=1 \
   LD=s390x-linux-gnu-ld \
   defconfig arch/s390/kernel/vdso64/
ld.lld: error: unknown emulation: elf64_s390
clang-11: error: linker command failed with exit code 1 (use -v to see 
invocation)

Normally, '-fuse-ld=bfd' could be used to get around this; however, this
can be fragile, depending on paths and variable naming. The cleaner
solution for the kernel is to take advantage of the fact that $(LD) can
be invoked directly, which bypasses the heuristics of $(CC) and respects
the user's choice. Similar changes have been done for ARM, ARM64, and
MIPS.

Link: https://github.com/ClangBuiltLinux/linux/issues/1041
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Add -fPIC per GCC's documentation, as pointed out by Nick.

 arch/s390/kernel/vdso64/Makefile | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/s390/kernel/vdso64/Makefile b/arch/s390/kernel/vdso64/Makefile
index bec19e7e6e1c..67c14732c304 100644
--- a/arch/s390/kernel/vdso64/Makefile
+++ b/arch/s390/kernel/vdso64/Makefile
@@ -18,8 +18,8 @@ KBUILD_AFLAGS_64 += -m64 -s
 
 KBUILD_CFLAGS_64 := $(filter-out -m64,$(KBUILD_CFLAGS))
 KBUILD_CFLAGS_64 += -m64 -fPIC -shared -fno-common -fno-builtin
-KBUILD_CFLAGS_64 += -nostdlib -Wl,-soname=linux-vdso64.so.1 \
-   -Wl,--hash-style=both
+ldflags-y := -fPIC -shared -nostdlib -soname=linux-vdso64.so.1 \
+--hash-style=both -T
 
 $(targets:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_64)
 $(targets:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_64)
@@ -37,8 +37,8 @@ KASAN_SANITIZE := n
 $(obj)/vdso64_wrapper.o : $(obj)/vdso64.so
 
 # link rule for the .so file, .lds has to be first
-$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) FORCE
-   $(call if_changed,vdso64ld)
+$(obj)/vdso64.so.dbg: $(obj)/vdso64.lds $(obj-vdso64) FORCE
+   $(call if_changed,ld)
 
 # strip rule for the .so file
 $(obj)/%.so: OBJCOPYFLAGS := -S
@@ -50,8 +50,6 @@ $(obj-vdso64): %.o: %.S FORCE
$(call if_changed_dep,vdso64as)
 
 # actual build commands
-quiet_cmd_vdso64ld = VDSO64L $@
-  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $(filter %.lds %.o,$^) -o $@
 quiet_cmd_vdso64as = VDSO64A $@
   cmd_vdso64as = $(CC) $(a_flags) -c -o $@ $<
 

base-commit: e1750a3d9abbea2ece29cac8dc5a6f5bc19c1492
-- 
2.27.0.rc2

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Victor Julien]

On 02-06-2020 21:03, Willem de Bruijn wrote:
> On Tue, Jun 2, 2020 at 2:31 PM Victor Julien  wrote:
>> On 02-06-2020 19:37, Willem de Bruijn wrote:
>>> On Tue, Jun 2, 2020 at 1:03 PM Victor Julien  wrote:

 On 02-06-2020 16:29, Willem de Bruijn wrote:
> On Tue, Jun 2, 2020 at 4:05 AM Victor Julien  wrote:
>>
>> Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
>> that the driver has completely validated the checksums in the packet.
>>
>> The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
>> in that the new flag will only be set if all the layers are valid,
>> while TP_STATUS_CSUM_VALID is set as well if only the IP layer is valid.
>
> transport, not ip checksum.

 Allow me a n00b question: what does transport refer to here? Things like
 ethernet? It isn't clear to me from the doc.
>>>
>>> The TCP/UDP/.. transport protocol checksum.
>>
>> Hmm that is what I thought originally, but then it didn't seem to work.
>> Hence my patch.
>>
>> However I just redid my testing. I took the example tpacketv3 program
>> and added the status flag checks to the 'display()' func:
>>
>> if (ppd->tp_status & TP_STATUS_CSUM_VALID) {
>> printf("TP_STATUS_CSUM_VALID, ");
>> }
>> if (ppd->tp_status & (1<<8)) {
>> printf("TP_STATUS_CSUM_UNNECESSARY, ");
>>
>> }
>>
>> Then using scapy sent some packets in 2 variants:
>> - default (good csums)
>> - deliberately bad csums
>> (then also added a few things like ip6 over ip)
>>
>>
>> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(),
>> iface="enp1s0") // good csums
>>
>> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(chksum=1),
>> iface="enp1s0") //bad tcp
> 
> Is this a test between two machines? What is the device driver of the
> machine receiving and printing the packet? It would be helpful to know
> whether this uses CHECKSUM_COMPLETE or CHECKSUM_UNNECESSARY.

Yes 2 machines, or actually 2 machines and a VM. The receiving Linux
sits in a kvm vm with network pass through and uses the virtio driver
(host uses e1000e). Based on a quick 'git grep CHECKSUM_UNNECESSARY'
virtio seems to support that.

I've done some more tests. In a pcap replay that I know contains packet
with bad TCP csums (but good IP csums for those pkts), to a physical
host running Ubuntu Linux kernel 5.3:

- receiver uses nfp (netronome) driver: TP_STATUS_CSUM_VALID set for
every packet, including the bad TCP ones
- receiver uses ixgbe driver: TP_STATUS_CSUM_VALID not set for the bad
packets.

Again purely based on 'git grep' it seems nfp does not support
UNNECESSARY, while ixgbe does.

(my original testing was with the nfp only, so now I at least understand
my original thinking)


>>
>> 1.2.3.4 -> 5.6.7.8, TP_STATUS_CSUM_VALID, TP_STATUS_CSUM_UNNECESSARY,
>> rxhash: 0x81ad5744
>> 1.2.3.4 -> 5.6.7.8, rxhash: 0x81ad5744
>>
>> So this suggests that what you're saying is correct, that it sets
>> TP_STATUS_CSUM_VALID if the TCP/UDP csum (and IPv4 csum) is valid, and
>> does not set it when either of them are invalid.
> 
> That's not exactly what I said. It looks to me that a device that sets
> CHECKSUM_COMPLETE will return TP_STATUS_CSUM_VALID from
> __netif_receive_skb_core even if the TCP checksum turns out to be bad.
> If a driver would insert such packets into the stack, that is.

Ok, this might be confirmed by my nfp vs virtio/ixgbe observations
mentioned above.


>> I'll also re-evaluate things in Suricata.
>>
>>
>> One thing I wonder if what this "at least" from the 682f048bd494 commit
>> message means:
>>
>> "Introduce TP_STATUS_CSUM_VALID tp_status flag to tell the
>>  af_packet user that at least the transport header checksum
>>  has been already validated."
>>
>> For TCP/UDP there wouldn't be a higher layer with csums, right? And
>> based on my testing it seems lower levels (at least IP) is also
>> included. Or would that perhaps refer to something like VXLAN or Geneve
>> over UDP? That the csums of packets on top of those layers aren't
>> (necessarily) considered?
> 
> The latter. All these checksums are about transport layer checksums
> (the ip header checksum is cheap to compute). Multiple checksums
> refers to packets encapsulated in other protocols with checksum, such
> as GRE or UDP based like Geneve.

If nothing else comes from this I'll at least propose doc patch to
clarify this for ppl like myself.

Thanks,
Victor

-- 
-
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
-

Re: [PATCH 4.19 00/95] 4.19.126-rc1 review

[Greg Kroah-Hartman]

On Mon, Jun 01, 2020 at 09:17:25PM +, Chris Paterson wrote:
> Hi Greg,
> 
> > From: stable-ow...@vger.kernel.org  On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 01 June 2020 18:53
> > 
> > This is the start of the stable review cycle for the 4.19.126 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> No build/boot issues seen for CIP configs for Linux 4.19.126-rc1 
> (47f49ba00628).
> 
> Build/test pipeline/logs: 
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/151700942
> GitLab CI pipeline: 
> https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> Relevant LAVA jobs: 
> https://lava.ciplatform.org/scheduler/alljobs?length=25=47f49b#table

Thanks for testing and letting me know.

greg k-h

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Peter Zijlstra]

On Tue, Jun 02, 2020 at 11:57:15AM -0700, Nick Desaulniers wrote:
> On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
>  wrote:
> >
> > Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> > have a compiler that does not fail builds due to no_sanitize functions.
> > This does not yet mean they work as intended, but for automated
> > build-tests, this is the minimum requirement.
> >
> > For example, we require that __always_inline functions used from
> > no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> > fails to build entirely, therefore we make the minimum version GCC 8.
> >
> > For KCSAN this is a non-functional change, however, we should add it in
> > case this variable changes in future.
> >
> > Link: 
> > https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
> > Suggested-by: Peter Zijlstra 
> > Signed-off-by: Marco Elver 
> 
> Is this a problem only for x86?  If so, that's quite a jump in minimal
> compiler versions for a feature that I don't think is currently
> problematic for other architectures?  (Based on
> https://lore.kernel.org/lkml/20200529171104.gd706...@hirez.programming.kicks-ass.net/
> )

Currently x86 only, but I know other arch maintainers are planning to
have a hard look at their code based on our findings.

[rcu:rcu/test] BUILD SUCCESS 0c1b20be12a0b937b76c34fb481b2e881c01fa10

[kbuild test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/test
branch HEAD: 0c1b20be12a0b937b76c34fb481b2e881c01fa10  torture:  Remove qemu 
dependency on EFI firmware

elapsed time: 911m

configs tested: 115
configs skipped: 7

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm  allyesconfig
arm  allmodconfig
arm   allnoconfig
arm64allyesconfig
arm64   defconfig
arm64allmodconfig
arm64 allnoconfig
arm cm_x300_defconfig
arm64alldefconfig
arm   milbeaut_m10v_defconfig
arm  ep93xx_defconfig
mips loongson1b_defconfig
shsh7763rdp_defconfig
ia64  allnoconfig
sh   se7619_defconfig
armqcom_defconfig
sh  kfr2r09_defconfig
sh  r7780mp_defconfig
riscvnommu_virt_defconfig
sparc   sparc32_defconfig
sh  urquell_defconfig
mips  pic32mzda_defconfig
mips   bmips_be_defconfig
alphaalldefconfig
mips  maltasmvp_eva_defconfig
shdreamcast_defconfig
sh  lboxre2_defconfig
arm   corgi_defconfig
arm bcm2835_defconfig
sh microdev_defconfig
powerpcmpc7448_hpc2_defconfig
armu300_defconfig
arm  simpad_defconfig
arm  moxart_defconfig
sh   j2_defconfig
sparc64  allyesconfig
armmps2_defconfig
armvt8500_v6_v7_defconfig
arm hackkit_defconfig
mips cu1000-neo_defconfig
x86_64  defconfig
ia64 allmodconfig
powerpc  storcenter_defconfig
mips  decstation_64_defconfig
sh   rts7751r2dplus_defconfig
sh magicpanelr2_defconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
i386  allnoconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nds32 allnoconfig
csky allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
h8300allmodconfig
xtensa  defconfig
arc defconfig
arc  allyesconfig
sh   allmodconfig
shallnoconfig
microblazeallnoconfig
nios2   defconfig
nios2allyesconfig
openriscdefconfig
c6x  allyesconfig
c6x   allnoconfig
openrisc allyesconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
sparcallyesconfig
sparc   

Re: [PATCH v3 3/4] iio: chemical: scd30: add serial interface driver

[Tomasz Duszynski]

On Tue, Jun 02, 2020 at 07:57:23PM +0200, Tomasz Duszynski wrote:
> On Tue, Jun 02, 2020 at 08:04:16PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> >  wrote:
> > >
> > > Add serial interface driver for the SCD30 sensor.
> >
> > ...
> >
> > > +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> > > +   [CMD_START_MEAS] = 0x0036,
> > > +   [CMD_STOP_MEAS] = 0x0037,
> > > +   [CMD_MEAS_INTERVAL] = 0x0025,
> > > +   [CMD_MEAS_READY] = 0x0027,
> > > +   [CMD_READ_MEAS] = 0x0028,
> > > +   [CMD_ASC] = 0x003a,
> > > +   [CMD_FRC] = 0x0039,
> > > +   [CMD_TEMP_OFFSET] = 0x003b,
> > > +   [CMD_FW_VERSION] = 0x0020,
> > > +   [CMD_RESET] = 0x0034,
> >
> > Hmm... Can't we keep them ordered by value?
> >
> > > +};
> >
> > ...
> >
> > > +   ret = wait_for_completion_interruptible_timeout(>meas_ready,
> > > +   
> > > SCD30_SERDEV_TIMEOUT);
> > > +   if (ret > 0)
> > > +   ret = 0;
> > > +   else if (!ret)
> > > +   ret = -ETIMEDOUT;
> > > +
> > > +   return ret;
> >
> > Perhaps
> >
> >   if (ret < 0)
> > return ret;
> >   if (ret == 0)
> > return -ETIMEDOUT;
> >   return 0;
> >
> > ?
>
> Matter of style but since I will be doing other changes I can touch that
> too.
>
> >
> > ...
> >
> > > +   char txbuf[SCD30_SERDEV_MAX_BUF_SIZE] = { SCD30_SERDEV_ADDR },
> > > +rxbuf[SCD30_SERDEV_MAX_BUF_SIZE], *rsp = response;
> >
> > Please, apply type to each variable separately.
> >
>
> Fine.
>
> > ...
> >
> > > +   switch (txbuf[1]) {
> > > +   case SCD30_SERDEV_WRITE:
> >
> > > +   if (memcmp(txbuf, txbuf, txsize)) {
> >
> > I'm not sure I understand this.
> >
>
> Ah, thanks for catching this. tx should be compared to rx.
>
> > > +   dev_err(state->dev, "wrong message received\n");
> > > +   return -EIO;
> > > +   }
> > > +   break;
> > > +   case SCD30_SERDEV_READ:
> >
> > > +   if (rxbuf[2] != (rxsize -
> > > +SCD30_SERDEV_RX_HEADER_SIZE -
> > > +SCD30_SERDEV_CRC_SIZE)) {
> >
> > Perhaps you can come up with better indentation/ line split?
> >
>
> I'd rather leave it as is.
>

On the second thought, that would fit 100 column line.

> > > +   dev_err(state->dev,
> > > +   "received data size does not match 
> > > header\n");
> > > +   return -EIO;
> > > +   }
> > > +
> > > +   rxsize -= SCD30_SERDEV_CRC_SIZE;
> > > +   crc = get_unaligned_le16(rxbuf + rxsize);
> > > +   if (crc != scd30_serdev_calc_crc(rxbuf, rxsize)) {
> > > +   dev_err(state->dev, "data integrity check 
> > > failed\n");
> > > +   return -EIO;
> > > +   }
> > > +
> > > +   rxsize -= SCD30_SERDEV_RX_HEADER_SIZE;
> > > +   memcpy(rsp, rxbuf + SCD30_SERDEV_RX_HEADER_SIZE, rxsize);
> > > +   break;
> > > +   default:
> > > +   dev_err(state->dev, "received unknown op code\n");
> > > +   return -EIO;
> > > +   }
> > > +
> > > +   return 0;
> > > +}
> >
> > ...
> >
> > > +static struct serdev_device_driver scd30_serdev_driver = {
> > > +   .driver = {
> >
> > > +   .name = KBUILD_MODNAME,
> >
> > This is not the best what we can do. The name is an ABI and better if
> > it will be constant (independent on file name).
> >
> > > +   .of_match_table = scd30_serdev_of_match,
> > > +   .pm = _pm_ops,
> > > +   },
> > > +   .probe = scd30_serdev_probe,
> > > +};
> >
> > --
> > With Best Regards,
> > Andy Shevchenko

Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot

[Brian Norris]

+ Sibi

On Mon, Jun 1, 2020 at 10:25 PM John Stultz  wrote:
>
> Ever since 5.7-rc1, if we call
> ath10k_qmi_remove_msa_permission(), the db845c hard crashes on
> reboot, resulting in the device getting stuck in the usb crash
> debug mode and not coming back up wihthout a hard power off.
>
> This hack avoids the issue by returning early in
> ath10k_qmi_event_server_exit().
>
> A better solution is very much desired!

Any chance you can bisect what caused this? There are a lot of
non-ath10k pieces involved in this stuff.

Brian

Re: [GIT PULL] x86/mm changes for v5.8

[Linus Torvalds]

On Tue, Jun 2, 2020 at 11:29 AM Thomas Gleixner  wrote:
>
> It's trivial enough to fix. We have a static key already which is
> telling us whether SMT scheduling is active.

.. but should we do it here, in switch_mm() in the first place?

Should it perhaps just return an error if user land tries to set the
"flush L1$" thing on an SMT system? And no, I don't think we care at
all if people then start playing games and enabling/disabling SMT
dynamically while applications are working. At that point the admin
kets to keep both of the broken pieces.

Also, see my other point about how "switch_mm()" really isn't even a
protection domain switch to begin with. We're still in the exact same
protection domain we used to be in, with the exact same direct access
to L1D$.

Why would we flush the caches on a random and irrelevant event in
kernel space? switch_mm() simply isn't relevant for caches (well,
unless you have fully virtual ones, but that's a completely different
issue).

Wouldn't it be more sensible to treat it more like TIF_NEED_FPU_LOAD -
have a per-cpu "I need to flush the cache" variable, and then the only
thing a context switch does is to see if the user changed (or
whatever) and then set the bit, and set TIF_NOTIFY_RESUME in the
thread.

Because the L1D$ flush isn't a kernel issue, it's a "don't let user
space try to attack it" issue. The kernel can already read it if it
wants to.

And that's just the "big picture" issues I see. In the big picture,
doing this when SMT is enabled is unbelievably stupid. And in the big
picture, context switch really isn't a security domain change wrt the
L1D$.

The more I look at those patches, the more I go "that's just wrong" on
some of the "small picture" implementation details.

Here's just a few cases that I reacted to

Actual low-level flushing code:

 (1) the SW fallback

 (a) is only defined on Intel, and initializing the silly cache
flush pages on any other vendor will fail.

 (b) seems to assume that 16 pages (order-4) is sufficient and
necessary. Probably "good enough", but it's also an example of "yeah,
that's expensive".

 (c) and if I read the code correctly, trying to flush the L1D$ on
non-intel without the HW support, it causes a WARN_ON_ONCE()! WTF?

 (2) the HW case is done for any vendor, if it reports the "I have the MSR"

 (3) the VMX support certainly has various sanity checks like "oh, CPU
doesn't have X86_BUG_L1TF, then I won't do this even if there was some
kernel command line to say I should". But the new prctrl doesn't have
anything like that. It just enables that L1D$ thing mindlessly,
thinking that user-land software somehow knows what it's doing. BS.

 (4) what does L1D_FLUSH_POPULATE_TLB mean?

   That "option" makes zero sense. It pre-populates the TLB before
doing the accesses to the L1D$ pages in the SW case, but nothing at
all explains why that is needed. It's clearly not needed for the
caller, since the TLB population only happens for the SW fallback, not
for the HW one.

   No documentation, no nothing. It's enabled for the VMX case, not
for the non-vmx case, which makes me suspect it's some crazy "work
around vm monitor page faults, because we know our SW flush fallback
is just random garbage".

In other words, there are those big "high-level design" questions, but
also several oddities in just the implementation details.

I really get the feeling that this feature just isn't ready.

Ingo - would you mind sending me a pull request for the (independent)
TLB cleanups part of that x86/mm tree? Because everything up to and
including commit bd1de2a7aace ("x86/tlb/uv: Add a forward declaration
for struct flush_tlb_info") looks sane.

It's only this L1D$ flushing thing at the end of that branch that I
think isn't fully cooked.

   Linus

Re: [PATCH 5.6 000/174] 5.6.16-rc2 review

[Guenter Roeck]

On Tue, Jun 02, 2020 at 12:24:19PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.16 release.
> There are 174 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Jun 2020 10:16:52 +.
> Anything received after that time might be too late.
> 
Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 429 pass: 429 fail: 0

Guenter

Re: [PATCH 5.4 000/139] 5.4.44-rc2 review

[Guenter Roeck]

On Tue, Jun 02, 2020 at 12:24:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.44 release.
> There are 139 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Jun 2020 10:16:52 +.
> Anything received after that time might be too late.
> 

Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 430 pass: 430 fail: 0

Guenter

Re: linux-next: build failure after merge of the akpm tree

[Andrew Morton]

On Tue, 2 Jun 2020 19:57:41 +1000 Stephen Rothwell  
wrote:

> Subject: [PATCH] turns out that probe_user_write is used in modular code
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  mm/maccess.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/maccess.c b/mm/maccess.c
> index ddfda8e6f4a5..88845eda5047 100644
> --- a/mm/maccess.c
> +++ b/mm/maccess.c
> @@ -246,6 +246,7 @@ long probe_user_write(void __user *dst, const void *src, 
> size_t size)
>   return -EFAULT;
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(probe_user_write);

Thanks, I shall squish that in and make the appropriate changelog update.

Re: [PATCH 4.19 00/92] 4.19.126-rc2 review

[Guenter Roeck]

On Tue, Jun 02, 2020 at 12:23:49PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.126 release.
> There are 92 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Jun 2020 10:16:52 +.
> Anything received after that time might be too late.
> 

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 421 pass: 421 fail: 0

Guenter

Re: [PATCH 4.4 00/47] 4.4.226-rc2 review

[Guenter Roeck]

On Tue, Jun 02, 2020 at 12:16:07PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.226 release.
> There are 47 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Jun 2020 09:57:12 +.
> Anything received after that time might be too late.
> 

Build results:
total: 169 pass: 169 fail: 0
Qemu test results:
total: 331 pass: 331 fail: 0

Guenter

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Andrey Konovalov]

On Tue, Jun 2, 2020 at 9:07 PM Marco Elver  wrote:
>
> On Tue, 2 Jun 2020 at 20:53, Andrey Konovalov  wrote:
> >
> > On Tue, Jun 2, 2020 at 8:44 PM Marco Elver  wrote:
> > >
> > > Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> > > have a compiler that does not fail builds due to no_sanitize functions.
> > > This does not yet mean they work as intended, but for automated
> > > build-tests, this is the minimum requirement.
> > >
> > > For example, we require that __always_inline functions used from
> > > no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> > > fails to build entirely, therefore we make the minimum version GCC 8.
> >
> > Could you also update KASAN docs to mention this requirement? As a
> > separate patch or in v2, up to you.
>
> I can do a v2 tomorrow. But all this is once again tangled up with
> KCSAN, so I was hoping to keep changes minimal. ;-)

OK, we can do a separate patch after all this is merged.

Re: [PATCH 4.14 00/76] 4.14.183-rc2 review

[Guenter Roeck]

On Tue, Jun 02, 2020 at 12:23:33PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.183 release.
> There are 76 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu, 04 Jun 2020 10:16:52 +.
> Anything received after that time might be too late.
> 

Build results:
total: 171 pass: 171 fail: 0
Qemu test results:
total: 407 pass: 407 fail: 0

Guenter

Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT

[Serge Semin]

On Wed, May 13, 2020 at 04:00:22PM +0200, Lars Povlsen wrote:
> With this change a SPI controller can be added without having a IRQ
> associated, and causing all transfers to be polled. For SPI controllers
> without DMA, this can significantly improve performance by less
> interrupt handling overhead.
> 
> Reviewed-by: Alexandre Belloni 
> Signed-off-by: Lars Povlsen 
> ---
>  drivers/spi/spi-dw.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
> index 31e3f866d11a7..e572eb34a3c1a 100644
> --- a/drivers/spi/spi-dw.c
> +++ b/drivers/spi/spi-dw.c
> @@ -19,6 +19,8 @@
>  #include 
>  #endif
> 

> +#define VALID_IRQ(i) (i >= 0)

Mark and Andy are right. It is a good candidate to be in a generic IRQ-related
code as Anyd suggested:

> > drivers/rtc/rtc-cmos.c:95:#define is_valid_irq(n)   ((n) > 0)
> > Candidate to be in include/linux/irq.h ?

So if you feel like to author additional useful patch integrated into the
kernel, this one is a good chance for it.

> +
>  /* Slave spi_dev related */
>  struct chip_data {
>   u8 tmode;   /* TR/TO/RO/EEPROM */
> @@ -359,7 +361,7 @@ static int dw_spi_transfer_one(struct spi_controller 
> *master,
>   spi_enable_chip(dws, 1);
>   return ret;
>   }
> - } else if (!chip->poll_mode) {
> + } else if (!chip->poll_mode && VALID_IRQ(dws->irq)) {
>   txlevel = min_t(u16, dws->fifo_len / 2, dws->len / 
> dws->n_bytes);
>   dw_writel(dws, DW_SPI_TXFLTR, txlevel);
> 
> @@ -379,7 +381,7 @@ static int dw_spi_transfer_one(struct spi_controller 
> *master,
>   return ret;
>   }
> 
> - if (chip->poll_mode)
> + if (chip->poll_mode || !VALID_IRQ(dws->irq))
>   return poll_transfer(dws);

Please note. The chip->poll and the poll_transfer() methods've been discarded
from the driver, since commit 1ceb09717e98 ("spi: dw: remove cs_control and
poll_mode members from chip_data"). So you gonna have to get the
poll_transfer-like method back.

-Sergey

> 
>   return 1;
> @@ -487,11 +489,13 @@ int dw_spi_add_host(struct device *dev, struct dw_spi 
> *dws)
> 
>   spi_controller_set_devdata(master, dws);
> 
> - ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dev_name(dev),
> -   master);
> - if (ret < 0) {
> - dev_err(dev, "can not get IRQ\n");
> - goto err_free_master;
> + if (VALID_IRQ(dws->irq)) {
> + ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED,
> +   dev_name(dev), master);
> + if (ret < 0) {
> + dev_err(dev, "can not get IRQ\n");
> + goto err_free_master;
> + }
>   }
> 
>   master->use_gpio_descriptors = true;
> @@ -539,7 +543,8 @@ int dw_spi_add_host(struct device *dev, struct dw_spi 
> *dws)
>   if (dws->dma_ops && dws->dma_ops->dma_exit)
>   dws->dma_ops->dma_exit(dws);
>   spi_enable_chip(dws, 0);
> - free_irq(dws->irq, master);
> + if (VALID_IRQ(dws->irq))
> + free_irq(dws->irq, master);
>  err_free_master:
>   spi_controller_put(master);
>   return ret;
> --
> 2.26.2
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the block tree with the rdma tree

[Jason Gunthorpe]

On Tue, Jun 02, 2020 at 01:02:55PM -0600, Jens Axboe wrote:
> On 6/2/20 1:01 PM, Jason Gunthorpe wrote:
> > On Tue, Jun 02, 2020 at 11:37:26AM +0300, Max Gurtovoy wrote:
> >>
> >> On 6/2/2020 5:56 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>
> >> Hi,
> >>
> >> This looks good to me.
> >>
> >> Can you share a pointer to the tree so we'll test it in our labs ?
> >>
> >> need to re-test:
> >>
> >> 1. srq per core
> >>
> >> 2. srq per core + T10-PI
> >>
> >> And both will run with shared CQ.
> > 
> > Max, this is too much conflict to send to Linus between your own
> > patches. I am going to drop the nvme part of this from RDMA.
> > 
> > Normally I don't like applying partial series, but due to this tree
> > split, you can send the rebased nvme part through the nvme/block tree
> > at rc1 in two weeks..
> 
> Was going to comment that this is probably how it should have been
> done to begin with. If we have multiple conflicts like that between
> two trees, someone is doing something wrong...

Well, on the other hand having people add APIs in one tree and then
(promised) consumers in another tree later on has proven problematic
in the past. It is best to try to avoid that, but in this case I don't
think Max will have any delay to get the API consumer into nvme in two
weeks.

Jason

Re: [PATCH 04/13] perf tests: Add another metric parsing test

[Jiri Olsa]

On Tue, Jun 02, 2020 at 10:58:32AM -0700, Ian Rogers wrote:

SNIP

> > +static int check_parse_fake(const char *id)
> > +{
> > +   struct parse_events_error error;
> 
> nit: this reads funny as it isn't clear, without looking at
> check_parse_id, that error is zero initialized.

right, how about something like below?

thanks,
jirka


---
diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index d3343827eb4d..c745b6e13cbe 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -403,7 +403,6 @@ static int check_parse_id(const char *id, struct 
parse_events_error *error,
evlist = evlist__new();
if (!evlist)
return -ENOMEM;
-   memset(error, 0, sizeof(*error));
ret = parse_events(evlist, id, error, fake_pmu);
evlist__delete(evlist);
return ret;
@@ -411,7 +410,7 @@ static int check_parse_id(const char *id, struct 
parse_events_error *error,
 
 static int check_parse_cpu(const char *id, bool same_cpu, struct pmu_event *pe)
 {
-   struct parse_events_error error;
+   struct parse_events_error error = { 0 };
 
int ret = check_parse_id(id, , false);
if (ret && same_cpu) {
@@ -433,7 +432,7 @@ static int check_parse_cpu(const char *id, bool same_cpu, 
struct pmu_event *pe)
 
 static int check_parse_fake(const char *id)
 {
-   struct parse_events_error error;
+   struct parse_events_error error = { 0 };
int ret = check_parse_id(id, , true);
 
free(error.str);

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Marco Elver]

On Tue, 2 Jun 2020 at 20:53, Andrey Konovalov  wrote:
>
> On Tue, Jun 2, 2020 at 8:44 PM Marco Elver  wrote:
> >
> > Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> > have a compiler that does not fail builds due to no_sanitize functions.
> > This does not yet mean they work as intended, but for automated
> > build-tests, this is the minimum requirement.
> >
> > For example, we require that __always_inline functions used from
> > no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> > fails to build entirely, therefore we make the minimum version GCC 8.
>
> Could you also update KASAN docs to mention this requirement? As a
> separate patch or in v2, up to you.

I can do a v2 tomorrow. But all this is once again tangled up with
KCSAN, so I was hoping to keep changes minimal. ;-)

Thanks,
-- Marco

Re: [PATCH] s390: vdso: Use $(LD) instead of $(CC) to link vDSO

[Nick Desaulniers]

On Wed, May 27, 2020 at 11:06 PM Nathan Chancellor
 wrote:
>
> Currently, the VDSO is being linked through $(CC). This does not match
> how the rest of the kernel links objects, which is through the $(LD)
> variable.
>
> When clang is built in a default configuration, it first attempts to use
> the target triple's default linker, which is just ld. However, the user
> can override this through the CLANG_DEFAULT_LINKER cmake define so that
> clang uses another linker by default, such as LLVM's own linker, ld.lld.
> This can be useful to get more optimized links across various different
> projects.
>
> However, this is problematic for the s390 vDSO because ld.lld does not
> have any s390 emulatiom support:
>
> https://github.com/llvm/llvm-project/blob/llvmorg-10.0.1-rc1/lld/ELF/Driver.cpp#L132-L150
>
> Thus, if a user is using a toolchain with ld.lld as the default, they
> will see an error, even if they have specified ld.bfd through the LD
> make variable:
>
> $ make -j"$(nproc)" -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- LLVM=1 \
>LD=s390x-linux-gnu-ld \
>defconfig arch/s390/kernel/vdso64/
> ld.lld: error: unknown emulation: elf64_s390
> clang-11: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> Normally, '-fuse-ld=bfd' could be used to get around this; however, this
> can be fragile, depending on paths and variable naming. The cleaner
> solution for the kernel is to take advantage of the fact that $(LD) can
> be invoked directly, which bypasses the heuristics of $(CC) and respects
> the user's choice. Similar changes have been done for ARM, ARM64, and
> MIPS.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1041
> Signed-off-by: Nathan Chancellor 
> ---
>  arch/s390/kernel/vdso64/Makefile | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/arch/s390/kernel/vdso64/Makefile 
> b/arch/s390/kernel/vdso64/Makefile
> index bec19e7e6e1c..b8db1ffbc2b9 100644
> --- a/arch/s390/kernel/vdso64/Makefile
> +++ b/arch/s390/kernel/vdso64/Makefile
> @@ -18,8 +18,8 @@ KBUILD_AFLAGS_64 += -m64 -s
>
>  KBUILD_CFLAGS_64 := $(filter-out -m64,$(KBUILD_CFLAGS))
>  KBUILD_CFLAGS_64 += -m64 -fPIC -shared -fno-common -fno-builtin
> -KBUILD_CFLAGS_64 += -nostdlib -Wl,-soname=linux-vdso64.so.1 \
> -   -Wl,--hash-style=both
> +ldflags-y := -shared -nostdlib -soname=linux-vdso64.so.1 \
> +--hash-style=both -T

I'm happy with the rest of the patch, and the intent of the patch.
The one part I'm worried about is the above hunk.  Since -shared is
now repeated between the compiler and the linker flags, I looked up
the documentation on -shared.
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
>> For predictable results, you must also specify the same set of options used 
>> for compilation (-fpic, -fPIC, or model suboptions) when you specify this 
>> linker option.
So it seems that -shared should be used for BOTH compiler and linker,
but it seems like -fPIC should be, too.  It may be fine without, but I
would be more comfortable signing off if -fPIC was specified in both.
Otherwise the rest of the patch LGTM, and thanks for sending.

>
>  $(targets:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_64)
>  $(targets:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_64)
> @@ -37,8 +37,8 @@ KASAN_SANITIZE := n
>  $(obj)/vdso64_wrapper.o : $(obj)/vdso64.so
>
>  # link rule for the .so file, .lds has to be first
> -$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) FORCE
> -   $(call if_changed,vdso64ld)
> +$(obj)/vdso64.so.dbg: $(obj)/vdso64.lds $(obj-vdso64) FORCE
> +   $(call if_changed,ld)
>
>  # strip rule for the .so file
>  $(obj)/%.so: OBJCOPYFLAGS := -S
> @@ -50,8 +50,6 @@ $(obj-vdso64): %.o: %.S FORCE
> $(call if_changed_dep,vdso64as)
>
>  # actual build commands
> -quiet_cmd_vdso64ld = VDSO64L $@
> -  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $(filter %.lds %.o,$^) -o $@
>  quiet_cmd_vdso64as = VDSO64A $@
>cmd_vdso64as = $(CC) $(a_flags) -c -o $@ $<
>
>
> base-commit: 9cb1fd0efd195590b828b9b865421ad345a4a145
> --


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Willem de Bruijn]

On Tue, Jun 2, 2020 at 2:31 PM Victor Julien  wrote:
>
> Hi Willem,
>
> On 02-06-2020 19:37, Willem de Bruijn wrote:
> > On Tue, Jun 2, 2020 at 1:03 PM Victor Julien  wrote:
> >>
> >> On 02-06-2020 16:29, Willem de Bruijn wrote:
> >>> On Tue, Jun 2, 2020 at 4:05 AM Victor Julien  wrote:
> 
>  Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
>  that the driver has completely validated the checksums in the packet.
> 
>  The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
>  in that the new flag will only be set if all the layers are valid,
>  while TP_STATUS_CSUM_VALID is set as well if only the IP layer is valid.
> >>>
> >>> transport, not ip checksum.
> >>
> >> Allow me a n00b question: what does transport refer to here? Things like
> >> ethernet? It isn't clear to me from the doc.
> >
> > The TCP/UDP/.. transport protocol checksum.
>
> Hmm that is what I thought originally, but then it didn't seem to work.
> Hence my patch.
>
> However I just redid my testing. I took the example tpacketv3 program
> and added the status flag checks to the 'display()' func:
>
> if (ppd->tp_status & TP_STATUS_CSUM_VALID) {
> printf("TP_STATUS_CSUM_VALID, ");
> }
> if (ppd->tp_status & (1<<8)) {
> printf("TP_STATUS_CSUM_UNNECESSARY, ");
>
> }
>
> Then using scapy sent some packets in 2 variants:
> - default (good csums)
> - deliberately bad csums
> (then also added a few things like ip6 over ip)
>
>
> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(),
> iface="enp1s0") // good csums
>
> srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(chksum=1),
> iface="enp1s0") //bad tcp

Is this a test between two machines? What is the device driver of the
machine receiving and printing the packet? It would be helpful to know
whether this uses CHECKSUM_COMPLETE or CHECKSUM_UNNECESSARY.

>
> 1.2.3.4 -> 5.6.7.8, TP_STATUS_CSUM_VALID, TP_STATUS_CSUM_UNNECESSARY,
> rxhash: 0x81ad5744
> 1.2.3.4 -> 5.6.7.8, rxhash: 0x81ad5744
>
> So this suggests that what you're saying is correct, that it sets
> TP_STATUS_CSUM_VALID if the TCP/UDP csum (and IPv4 csum) is valid, and
> does not set it when either of them are invalid.

That's not exactly what I said. It looks to me that a device that sets
CHECKSUM_COMPLETE will return TP_STATUS_CSUM_VALID from
__netif_receive_skb_core even if the TCP checksum turns out to be bad.
If a driver would insert such packets into the stack, that is.

> I'll also re-evaluate things in Suricata.
>
>
> One thing I wonder if what this "at least" from the 682f048bd494 commit
> message means:
>
> "Introduce TP_STATUS_CSUM_VALID tp_status flag to tell the
>  af_packet user that at least the transport header checksum
>  has been already validated."
>
> For TCP/UDP there wouldn't be a higher layer with csums, right? And
> based on my testing it seems lower levels (at least IP) is also
> included. Or would that perhaps refer to something like VXLAN or Geneve
> over UDP? That the csums of packets on top of those layers aren't
> (necessarily) considered?

The latter. All these checksums are about transport layer checksums
(the ip header checksum is cheap to compute). Multiple checksums
refers to packets encapsulated in other protocols with checksum, such
as GRE or UDP based like Geneve.

>
> Thanks,
> Victor
>
>
> >> (happy to follow up with a patch to clarify the doc when I understand
> >> things better)
> >>
> >>> But as I understand it drivers set CHECKSUM_COMPLETE if they fill in
> >>> skb->csum over the full length of the packet. This does not
> >>> necessarily imply that any of the checksum fields in the packet are
> >>> valid yet (see also skb->csum_valid). Protocol code later compares
> >>> checksum fields against this using __skb_checksum_validate_complete and 
> >>> friends.
> >>>
> >>> But packet sockets may be called before any of this, however. So I wonder
> >>> how valid the checksum really is right now when setting 
> >>> TP_STATUS_CSUM_VALID.
> >>> I assume it's correct, but don't fully understand where the validation
> >>> has taken place..
> >>
> >> I guess I'm more confused now about what TP_STATUS_CSUM_VALID actually
> >> means. It sounds almost like the opposite of TP_STATUS_CSUMNOTREADY, but
> >> I'm not sure I understand what the value would be.
> >>
> >> It would be great if someone could help clear this up. Everything I
> >> thought I knew/understood so far has been proven wrong, so I'm not too
> >> confident about my patch anymore...
> >
> > Agreed that we should clear this up.
> >
> >>> Similar to commit 682f048bd494 ("af_packet: pass checksum validation
> >>> status to the user"), please update tpacket_rcv and packet_rcv.
> >>
> >> Ah yes, good catch. Will add it there as well.
> >>
> >>> Note also that net-next is currently closed.
> >>
> >> Should I hold off on sending a v3 until it reopens?
> >
> > Yep, thanks. You 

Re: [PATCH 04/13] perf tests: Add another metric parsing test

[Jiri Olsa]

On Tue, Jun 02, 2020 at 10:58:32AM -0700, Ian Rogers wrote:
> On Tue, Jun 2, 2020 at 4:51 AM Jiri Olsa  wrote:
> >
> > The test goes through all metrics compiled for arch
> > within pmu events and try to parse them.
> >
> > This test is different from 'test_parsing' in that
> > we go through all the events in the current arch,
> > not just one defined for current CPU model. Using
> > 'fake_pmu' to parse events which do not have PMUs
> > defined in the system.
> >
> > Say there's bad change in ivybridge metrics file, like:
> >
> >   --- a/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
> >   +++ b/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
> >   @@ -8,7 +8,7 @@
> >   -"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * ((
> >   +"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / / (4 *
> >
> > the test fails with (on my kabylake laptop):
> >
> >   $ perf test 'Parsing of PMU event table metrics with fake PMUs' -v
> >   parsing 'idq_uops_not_delivered.core / / (4 * (( ( cpu_clk_unh...
> >   syntax error, line 1
> >   expr__parse failed
> >   test child finished with -1
> >   ...
> 
> For this example as the problem is the expression, presumably this was
> "passing" with test_parsing due to returning TEST_SKIP? I did this
> initially so that we could get the test merged and then the metrics
> fixed. I'd prefer if test_parsing were returning TEST_FAIL.

it will fail:

[jolsa@krava perf]$ git diff
diff --git a/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json 
b/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
index 28e25447d3ef..0cad6b709f96 100644
--- a/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
+++ b/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
@@ -1,7 +1,7 @@
 [
 {
 "BriefDescription": "This category represents fraction of 
slots where the processor's Frontend undersupplies its Backend",
-"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * cycles)",
+"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / / (4 * cycles)",
 "MetricGroup": "TopdownL1",
 "MetricName": "Frontend_Bound",

[jolsa@krava perf]$ ./perf test  'Parsing of PMU event table metrics 
with fake PMUs' 
10: PMU events:
10.4: Parsing of PMU event table metrics with fake PMUs   : FAILED!

because the metric is malformed

jirka

Re: linux-next: manual merge of the block tree with the rdma tree

[Jason Gunthorpe]

On Tue, Jun 02, 2020 at 11:37:26AM +0300, Max Gurtovoy wrote:
> 
> On 6/2/2020 5:56 AM, Stephen Rothwell wrote:
> > Hi all,
> 
> Hi,
> 
> This looks good to me.
> 
> Can you share a pointer to the tree so we'll test it in our labs ?
> 
> need to re-test:
> 
> 1. srq per core
> 
> 2. srq per core + T10-PI
> 
> And both will run with shared CQ.

Max, this is too much conflict to send to Linus between your own
patches. I am going to drop the nvme part of this from RDMA.

Normally I don't like applying partial series, but due to this tree
split, you can send the rebased nvme part through the nvme/block tree
at rc1 in two weeks..

Jason

Re: linux-next: manual merge of the block tree with the rdma tree

[Jens Axboe]

On 6/2/20 1:01 PM, Jason Gunthorpe wrote:
> On Tue, Jun 02, 2020 at 11:37:26AM +0300, Max Gurtovoy wrote:
>>
>> On 6/2/2020 5:56 AM, Stephen Rothwell wrote:
>>> Hi all,
>>
>> Hi,
>>
>> This looks good to me.
>>
>> Can you share a pointer to the tree so we'll test it in our labs ?
>>
>> need to re-test:
>>
>> 1. srq per core
>>
>> 2. srq per core + T10-PI
>>
>> And both will run with shared CQ.
> 
> Max, this is too much conflict to send to Linus between your own
> patches. I am going to drop the nvme part of this from RDMA.
> 
> Normally I don't like applying partial series, but due to this tree
> split, you can send the rebased nvme part through the nvme/block tree
> at rc1 in two weeks..

Was going to comment that this is probably how it should have been
done to begin with. If we have multiple conflicts like that between
two trees, someone is doing something wrong...

-- 
Jens Axboe

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Marco Elver]

On Tue, 2 Jun 2020 at 20:57, Nick Desaulniers  wrote:
>
> On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
>  wrote:
> >
> > Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> > have a compiler that does not fail builds due to no_sanitize functions.
> > This does not yet mean they work as intended, but for automated
> > build-tests, this is the minimum requirement.
> >
> > For example, we require that __always_inline functions used from
> > no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> > fails to build entirely, therefore we make the minimum version GCC 8.
> >
> > For KCSAN this is a non-functional change, however, we should add it in
> > case this variable changes in future.
> >
> > Link: 
> > https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
> > Suggested-by: Peter Zijlstra 
> > Signed-off-by: Marco Elver 
>
> Is this a problem only for x86?  If so, that's quite a jump in minimal
> compiler versions for a feature that I don't think is currently
> problematic for other architectures?  (Based on
> https://lore.kernel.org/lkml/20200529171104.gd706...@hirez.programming.kicks-ass.net/
> )

__always_inline void foo(void) {}
__no_sanitize_address void bar(void) { foo(); }

where __no_sanitize_address is implied by 'noinstr' now, and 'noinstr'
is no longer just x86.

Therefore, it's broken on *all* architectures. The compiler will just
break the build with an error. I don't think we can fix that.

Thanks,
-- Marco

Re: [PATCH v7 1/4] bitops: Introduce the the for_each_set_clump macro

[Rikard Falkeborn]

On Mon, Jun 01, 2020 at 11:33:30AM +0300, Andy Shevchenko wrote:
> On Mon, Jun 01, 2020 at 12:37:16AM +0200, Rikard Falkeborn wrote:
> > + Emil who was working on a patch for this
> > 
> > On Sun, May 31, 2020 at 02:00:45PM +0300, Andy Shevchenko wrote:
> > > On Sun, May 31, 2020 at 4:11 AM Syed Nayyar Waris  
> > > wrote:
> > > > On Sat, May 30, 2020 at 2:50 PM Andy Shevchenko
> > > >  wrote:
> > > > > On Sat, May 30, 2020 at 11:45 AM Syed Nayyar Waris 
> > > > >  wrote:
> > > > > > On Sat, May 30, 2020 at 3:49 AM Andy Shevchenko
> > > > > >  wrote:
> > > 
> > > ...
> > > 
> > Sorry about that, it seems it's only triggered by gcc-9, that's why I
> > missed it.
> 
> I guess every compiler (more or less recent) will warn here.
> (Sorry, there is a cut in the thread, the problem is with comparison unsigned
>  type(s) to 0).
> 
> > > > #if (l) == 0
> > > > #define GENMASK_INPUT_CHECK(h, l)  0
> > > > #elif
> > > > #define GENMASK_INPUT_CHECK(h, l) \
> > > > (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > > > __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> > > > #endif
> > > >
> > > > I have verified that this works. Basically this just avoids the sanity
> > > > check when the 'lower' bound 'l' is zero. Let me know if it looks
> > > > fine.
> > 
> > I don't understand how you mean this? You can't use l before you have
> > defined GENMASK_INPUT_CHECK to take l as input? Am I missing something?
> > 
> > How about the following (with an added comment about why the casts are
> > necessary):
> > 
> > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > index 4671fbf28842..5fdb9909fbff 100644
> > --- a/include/linux/bits.h
> > +++ b/include/linux/bits.h
> > @@ -23,7 +23,7 @@
> >  #include 
> >  #define GENMASK_INPUT_CHECK(h, l) \
> > (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > -   __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> > +   __builtin_constant_p((int)(l) > (int)(h)), (int)(l) > 
> > (int)(h), 0)))
> >  #else
> >  /*
> >   * BUILD_BUG_ON_ZERO is not available in h files included from asm files,
> > 
> > I can send a proper patch if this is ok.
> > > 
> > > Unfortunately, it's not enough. We need to take care about the following 
> > > cases
> > 
> > The __GENMASK macro is only valid for values of h and l between 0 and 63
> > (or 31, if unsigned long is 32 bits). Negative values or values >=
> > sizeof(unsigned long) (or unsigned long long for GENMASK_ULL) result in
> > compiler warnings (-Wshift-count-negative or -Wshift-count-overflow). So
> > when I wrote the GENMASK_INPUT_CHECK macro, the intention was to catch
> > cases where l and h were swapped and let the existing compiler warnings
> > catch negative or too large values.
> 
> GENAMSK sometimes is used with non-constant arguments that's why your check
> made a regression.
> 
> What I described below are the cases to consider w/o what should we do. What
> you answered is the same what I implied. So, we are on the same page here.
> 
> > > 1) h or l negative;
> > 
> > Any of these cases will trigger a compiler warning (h negative triggers 
> > Wshift-count-overflow, l negative triggers Wshift-count-negative).
> > 
> > > 2) h == 0, if l == 0, I dunno what is this. it's basically either 0 or 
> > > warning;
> > 
> > h == l == 0 is a complicated way of saying 1 (or BIT(0)). l negative
> > triggers compiler warning.
> 
> Oh, yes GENMASK(h, l), when h==l==0 should be equivalent to BIT(0) with no
> warning given.
> 
> > > 3) l == 0;
> > 
> > if h is negative, compiler warning (see 1). If h == 0, see 2. If h is
> > positive, there is no error in GENMASK_INPUT_CHECK.
> > 
> > > 4) h and l > 0.
> > 
> > The comparisson works as intended.
> 
> > > Now, on top of that (since it's a macro) we have to keep in mind that
> > > h and l can be signed and / or unsigned types.
> > > And macro shall work for all 4 cases (by type signedess).
> > 
> > If we cast to int, we don't need to worry about the signedness. If
> > someone enters a value that can't be cast to int, there will still
> > be a compiler warning about shift out of range.
> 
> If the argument unsigned long long will it be the warning (it should not)?

No, there should be no warning there.

The inputs to GENMASK() needs to be between 0 and 31 (or 63 depending on the
size of unsigned long). For any other values, there will be undefined behaviour,
since the operands to the shifts in __GENMASK will be too large (or negative).

Rikard

> 
> > > > Regarding min, max macro that you suggested I am also looking further 
> > > > into it.
> > > 
> > > Since this has been introduced in v5.7 and not only your code is
> > > affected by this I think we need to ping original author either to fix
> > > or revert.
> > > 
> > > So, I Cc'ed to the author and reviewers, because they probably know
> > > better why that had been done in the first place and breaking existing
> > > code.
> 
> Please, when you do something there, add a test case to test_bitops.c.

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Nick Desaulniers]

On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
 wrote:
>
> Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> have a compiler that does not fail builds due to no_sanitize functions.
> This does not yet mean they work as intended, but for automated
> build-tests, this is the minimum requirement.
>
> For example, we require that __always_inline functions used from
> no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> fails to build entirely, therefore we make the minimum version GCC 8.
>
> For KCSAN this is a non-functional change, however, we should add it in
> case this variable changes in future.
>
> Link: 
> https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Marco Elver 

Is this a problem only for x86?  If so, that's quite a jump in minimal
compiler versions for a feature that I don't think is currently
problematic for other architectures?  (Based on
https://lore.kernel.org/lkml/20200529171104.gd706...@hirez.programming.kicks-ass.net/
)

> ---
> Apply after:
> https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
> ---
>  init/Kconfig  | 3 +++
>  lib/Kconfig.kasan | 1 +
>  lib/Kconfig.kcsan | 1 +
>  lib/Kconfig.ubsan | 1 +
>  4 files changed, 6 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 0f72eb4ffc87..3e8565bc8376 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -39,6 +39,9 @@ config TOOLS_SUPPORT_RELR
>  config CC_HAS_ASM_INLINE
> def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) 
> -x c - -c -o /dev/null)
>
> +config CC_HAS_WORKING_NOSANITIZE
> +   def_bool !CC_IS_GCC || GCC_VERSION >= 8
> +
>  config CONSTRUCTORS
> bool
> depends on !UML
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 81f5464ea9e1..15e6c4b26a40 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -20,6 +20,7 @@ config KASAN
> depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
>(HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
> depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
>   designed to find out-of-bounds accesses and use-after-free bugs.
> diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
> index 5ee88e5119c2..2ab4a7f511c9 100644
> --- a/lib/Kconfig.kcsan
> +++ b/lib/Kconfig.kcsan
> @@ -5,6 +5,7 @@ config HAVE_ARCH_KCSAN
>
>  config HAVE_KCSAN_COMPILER
> def_bool CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm 
> -tsan-distinguish-volatile=1)
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   For the list of compilers that support KCSAN, please see
>   .
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index a5ba2fd51823..f725d126af7d 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -4,6 +4,7 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL
>
>  menuconfig UBSAN
> bool "Undefined behaviour sanity checker"
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   This option enables the Undefined Behaviour sanity checker.
>   Compile-time instrumentation is used to detect various undefined
> --

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] pinctrl: sirf: Add missing put_device() call in sirfsoc_gpio_probe()

[Markus Elfring]

> in sirfsoc_gpio_probe(), if of_find_device_by_node() succeed,
> put_device() is missing in the error handling patch.

How do you think about another wording variant?

   A coccicheck run provided information like the following.

   drivers/pinctrl/sirf/pinctrl-sirf.c:798:2-8: ERROR: missing put_device;
   call of_find_device_by_node on line 792, but without a corresponding
   object release within this function.

   Generated by: scripts/coccinelle/free/put_device.cocci

   Thus add a jump target to fix the exception handling for this
   function implementation.


Would you like to add the tag “Fixes” to the commit message?

Regards,
Markus

Re: [PATCH] staging: rtl8712: switch to common ieee80211 headers

[Dan Carpenter]

On Tue, Jun 02, 2020 at 04:58:46PM +0100, Pascal Terjan wrote:
> On Tue, 2 Jun 2020 at 15:57, Larry Finger  wrote:
> >
> > On 6/1/20 3:24 PM, Pascal Terjan wrote:
> > > This patch switches to  and  and
> > > deletes a lot of duplicate definitions plus many unused ones.
> > >
> > > Non obvious changes:
> > > - struct ieee80211_ht_cap is different enough that I preferred to keep
> > >(and rename) it for now.
> > > - mcs_rate in translate_scan was not read after being set, so I deleted
> > >that part rather than using the renamed struct
> > > - WLAN_CAPABILITY_BSS is replaced with WLAN_CAPABILITY_ESS which is the
> > >corresponding one with same value
> > >
> > > Signed-off-by: Pascal Terjan 
> >
> > This patch does not apply to the staging repo, current mainline, or
> > wireless-drivers-next. Where did you intend it to go? Staging is the 
> > correct tree.
> 
> It was against staging-testing as there is a (trivial) merge conflict
> in there with 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=2aaeaaff1ae21b2817256435c7fc0095eeda61ae
> which is also in staging-next
> What is the best practice in such case?

It has to apply against staging-next so that's fine.

> 
> Thanks to kbuild test robot I found that it is failing to build there
> because I forgot to add a dependency on CFG80211 in Kconfig, so I will
> need to send a v2.

Yup.

regards,
dan carpenter

Re: [PATCH -tip 2/2] compiler_types.h: Add __no_sanitize_{address,undefined} to noinstr

[Marco Elver]

On Tue, 2 Jun 2020 at 20:49, 'Nick Desaulniers' via kasan-dev
 wrote:
>
> On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
>  wrote:
> >
> > Adds the portable definitions for __no_sanitize_address, and
> > __no_sanitize_undefined, and subsequently changes noinstr to use the
> > attributes to disable instrumentation via KASAN or UBSAN.
> >
> > Link: https://lore.kernel.org/lkml/d2474c05a6c93...@google.com/
> > Reported-by: syzbot+dc1fa714cb070b184...@syzkaller.appspotmail.com
> > Signed-off-by: Marco Elver 
>
> Currently most of our compiler attribute detection is done in
> include/linux/compiler_attributes.h; I think this should be handled
> there. +Miguel Ojeda

GCC and Clang define these very differently, and the way to query for
them is different too. All we want is a portable __no_sanitize, and
compiler-{gcc,clang}.h is the right place for that. Similar to why we
define the other __no_sanitize above the places they were added.

Thanks,
-- Marco

Re: [PATCH] serial: 8250_port: Fix imprecise external abort for mctrl if inactive

[Tony Lindgren]

* Tony Lindgren  [200602 13:38]:
> * Andy Shevchenko  [200602 08:33]:
> Now that we can detach and reattach the kernel serial console,
> there should not be any need for pm_runtime_irq_safe() anymore :)

Below is a hastily tested RFC patch to remove pm_runtime_irq_safe()
for 8250_omap.c that seems to work for idle use case :)

> And the UART wake-up from deeper idle states can only happen with
> help of external hardware like GPIO controller or pinctrl controller.

It does not yet include the check for configured wakeirq though.
And omap-serial.c needs a similar patch or maybe we can attempt
to just drop it this time as 8250_omap.c should be used nowadays.
Or just drop PM from omap-serial.c if it can't be dropped.

Andy, is the change below the only remaining blocker now for
your serial PM runtime changes?

Regards,

Tony

8< ---
diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -123,6 +123,7 @@ struct omap8250_priv {
spinlock_t rx_dma_lock;
bool rx_dma_broken;
bool throttled;
+   unsigned int active:1;
 };
 
 struct omap8250_dma_params {
@@ -598,9 +599,13 @@ static irqreturn_t omap8250_irq(int irq, void *dev_id)
 {
struct uart_port *port = dev_id;
struct uart_8250_port *up = up_to_u8250p(port);
+   struct omap8250_priv *priv = up->port.private_data;
unsigned int iir;
int ret;
 
+   if (!priv->active)
+   return IRQ_NONE;
+
 #ifdef CONFIG_SERIAL_8250_DMA
if (up->dma) {
ret = omap_8250_dma_handle_irq(port);
@@ -608,10 +613,10 @@ static irqreturn_t omap8250_irq(int irq, void *dev_id)
}
 #endif
 
-   serial8250_rpm_get(up);
iir = serial_port_in(port, UART_IIR);
ret = serial8250_handle_irq(port, iir);
-   serial8250_rpm_put(up);
+
+   pm_runtime_mark_last_busy(port->dev);
 
return IRQ_RETVAL(ret);
 }
@@ -1110,13 +1115,9 @@ static int omap_8250_dma_handle_irq(struct uart_port 
*port)
unsigned long flags;
u8 iir;
 
-   serial8250_rpm_get(up);
-
iir = serial_port_in(port, UART_IIR);
-   if (iir & UART_IIR_NO_INT) {
-   serial8250_rpm_put(up);
+   if (iir & UART_IIR_NO_INT)
return IRQ_HANDLED;
-   }
 
spin_lock_irqsave(>lock, flags);
 
@@ -1144,7 +1145,7 @@ static int omap_8250_dma_handle_irq(struct uart_port 
*port)
}
 
uart_unlock_and_check_sysrq(port, flags);
-   serial8250_rpm_put(up);
+
return 1;
 }
 
@@ -1329,11 +1330,10 @@ static int omap8250_probe(struct platform_device *pdev)
if (!of_get_available_child_count(pdev->dev.of_node))
pm_runtime_set_autosuspend_delay(>dev, -1);
 
-   pm_runtime_irq_safe(>dev);
-
pm_runtime_get_sync(>dev);
 
omap_serial_fill_features_erratas(, priv);
+   priv->active = pm_runtime_enabled(>dev);
up.port.handle_irq = omap8250_no_handle_irq;
priv->rx_trigger = RX_TRIGGER;
priv->tx_trigger = TX_TRIGGER;
@@ -1517,6 +1517,8 @@ static int omap8250_runtime_suspend(struct device *dev)
if (!priv)
return 0;
 
+   priv->active = 0;
+
up = serial8250_get_port(priv->line);
/*
 * When using 'no_console_suspend', the console UART must not be
@@ -1575,6 +1577,8 @@ static int omap8250_runtime_resume(struct device *dev)
 
pinctrl_pm_select_default_state(dev);
 
+   priv->active = 1;
+
return 0;
 }
 #endif
-- 
2.26.2

Re: [PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Andrey Konovalov]

On Tue, Jun 2, 2020 at 8:44 PM Marco Elver  wrote:
>
> Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
> have a compiler that does not fail builds due to no_sanitize functions.
> This does not yet mean they work as intended, but for automated
> build-tests, this is the minimum requirement.
>
> For example, we require that __always_inline functions used from
> no_sanitize functions do not generate instrumentation. On GCC <= 7 this
> fails to build entirely, therefore we make the minimum version GCC 8.

Could you also update KASAN docs to mention this requirement? As a
separate patch or in v2, up to you.

>
> For KCSAN this is a non-functional change, however, we should add it in
> case this variable changes in future.
>
> Link: 
> https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Marco Elver 
> ---
> Apply after:
> https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
> ---
>  init/Kconfig  | 3 +++
>  lib/Kconfig.kasan | 1 +
>  lib/Kconfig.kcsan | 1 +
>  lib/Kconfig.ubsan | 1 +
>  4 files changed, 6 insertions(+)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 0f72eb4ffc87..3e8565bc8376 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -39,6 +39,9 @@ config TOOLS_SUPPORT_RELR
>  config CC_HAS_ASM_INLINE
> def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) 
> -x c - -c -o /dev/null)
>
> +config CC_HAS_WORKING_NOSANITIZE
> +   def_bool !CC_IS_GCC || GCC_VERSION >= 8
> +
>  config CONSTRUCTORS
> bool
> depends on !UML
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 81f5464ea9e1..15e6c4b26a40 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -20,6 +20,7 @@ config KASAN
> depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
>(HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
> depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
>   designed to find out-of-bounds accesses and use-after-free bugs.
> diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
> index 5ee88e5119c2..2ab4a7f511c9 100644
> --- a/lib/Kconfig.kcsan
> +++ b/lib/Kconfig.kcsan
> @@ -5,6 +5,7 @@ config HAVE_ARCH_KCSAN
>
>  config HAVE_KCSAN_COMPILER
> def_bool CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm 
> -tsan-distinguish-volatile=1)
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   For the list of compilers that support KCSAN, please see
>   .
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index a5ba2fd51823..f725d126af7d 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -4,6 +4,7 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL
>
>  menuconfig UBSAN
> bool "Undefined behaviour sanity checker"
> +   depends on CC_HAS_WORKING_NOSANITIZE
> help
>   This option enables the Undefined Behaviour sanity checker.
>   Compile-time instrumentation is used to detect various undefined
> --
> 2.27.0.rc2.251.g90737beb825-goog
>

Re: [PATCH -tip 2/2] compiler_types.h: Add __no_sanitize_{address,undefined} to noinstr

[Nick Desaulniers]

On Tue, Jun 2, 2020 at 11:44 AM 'Marco Elver' via Clang Built Linux
 wrote:
>
> Adds the portable definitions for __no_sanitize_address, and
> __no_sanitize_undefined, and subsequently changes noinstr to use the
> attributes to disable instrumentation via KASAN or UBSAN.
>
> Link: https://lore.kernel.org/lkml/d2474c05a6c93...@google.com/
> Reported-by: syzbot+dc1fa714cb070b184...@syzkaller.appspotmail.com
> Signed-off-by: Marco Elver 

Currently most of our compiler attribute detection is done in
include/linux/compiler_attributes.h; I think this should be handled
there. +Miguel Ojeda

> ---
>
> Note: __no_sanitize_coverage (for KCOV) isn't possible right now,
> because neither GCC nor Clang support such an attribute. This means
> going and changing the compilers again (for Clang it's fine, for GCC,
> it'll take a while).
>
> However, it looks like that KCOV_INSTRUMENT := n is currently in all the
> right places. Short-term, this should be reasonable.
> ---
>  include/linux/compiler-clang.h | 8 
>  include/linux/compiler-gcc.h   | 6 ++
>  include/linux/compiler_types.h | 3 ++-
>  3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 2cb42d8bdedc..c0e4b193b311 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -33,6 +33,14 @@
>  #define __no_sanitize_thread
>  #endif
>
> +#if __has_feature(undefined_behavior_sanitizer)
> +/* GCC does not have __SANITIZE_UNDEFINED__ */
> +#define __no_sanitize_undefined \
> +   __attribute__((no_sanitize("undefined")))
> +#else
> +#define __no_sanitize_undefined
> +#endif
> +
>  /*
>   * Not all versions of clang implement the the type-generic versions
>   * of the builtin overflow checkers. Fortunately, clang implements
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 7dd4e0349ef3..1c74464c80c6 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -150,6 +150,12 @@
>  #define __no_sanitize_thread
>  #endif
>
> +#if __has_attribute(__no_sanitize_undefined__)
> +#define __no_sanitize_undefined __attribute__((no_sanitize_undefined))
> +#else
> +#define __no_sanitize_undefined
> +#endif
> +
>  #if GCC_VERSION >= 50100
>  #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
>  #endif
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 02becd21d456..89b8c1ae18a1 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -198,7 +198,8 @@ struct ftrace_likely_data {
>
>  /* Section for code which can't be instrumented at all */
>  #define noinstr  
>   \
> -   noinline notrace __attribute((__section__(".noinstr.text"))) 
> __no_kcsan
> +   noinline notrace __attribute((__section__(".noinstr.text")))\
> +   __no_kcsan __no_sanitize_address __no_sanitize_undefined
>
>  #endif /* __KERNEL__ */
>
> --

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq

[Saidi, Ali]

On 5/31/20, 9:40 PM, "Herrenschmidt, Benjamin"  wrote:

On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
> 
> 
> > Not great indeed. But this is not, as far as I can tell, a GIC
> > driver problem.
> > 
> > The semantic of activate/deactivate (which maps to started/shutdown
> > in the IRQ code) is that the HW resources for a given interrupt are
> > only committed when the interrupt is activated. Trying to perform
> > actions involving the HW on an interrupt that isn't active cannot be
> > guaranteed to take effect.
> > 
> > I'd rather address it in the core code, by preventing set_affinity (and
> > potentially others) to take place when the interrupt is not in the
> > STARTED state. Userspace would get an error, which is perfectly
> > legitimate, and which it already has to deal with it for plenty of
> > other
> > reasons.

So I finally found time to dig a bit in there :) Code has changed a bit
since last I looked. But I have memories of the startup code messing
around with the affinity, and here it is. In irq_startup() :


switch (__irq_startup_managed(desc, aff, force)) {
case IRQ_STARTUP_NORMAL:
ret = __irq_startup(desc);
irq_setup_affinity(desc);
break;
case IRQ_STARTUP_MANAGED:
irq_do_set_affinity(d, aff, false);
ret = __irq_startup(desc);
break;
case IRQ_STARTUP_ABORT:
irqd_set_managed_shutdown(d);
return 0;

So we have two cases here. Normal and managed.

In the managed case, we set the affinity before startup. I feel like your
patch might break that or am I missing something ?

Additionally, your patch would break any userspace program that expects to
be able to change the affinity on an interrupt before it's been started.
I don't know if such a thing exsits but the fact that we hit that bug
makes me think it might.

Now most controller drivers (at least that I'm familiar with, which doesn't
include GiC at this point) can deal with that just fine.

Now there's also another possible issue:

Your patch checks irqd_is_started(). Now I always mixup irqd vs irq_state 
these
days so I may be wrong but irq_state_set_started() is only done in 
__irq_startup
which will *not* be called if the interrupt has NOAUTOEN.

Is that ok ? Do we intend for affinity setting not to work until the first
enable_irq() for such an interrupt ? We could check activated instead of
started I suppose. (again provided I didn't mixup two different things
between the irqd and the irq_state stuff).

For these reasons my gut feeling is we should just fix GIC as Ali wanted to
do initially.

The basic idea is simply to defer the HW configuration until the interrupt
has been started. I don't see why that would be an issue. Have set_affinity 
just
store the mask (and apply whatever other sanity checking it might want to 
do)
until the itnerrupt is started and when started, apply things to HW.

I might be missing a reason why it's more complicated than that :) But I do
feel a bit uncomfortable with your approach.

Looks like the x86 apic set_affinity call explicitly checks for if it’s 
activated in the managed case which makes sense given the code Ben posted above:
  /*
   * Core code can call here for inactive interrupts. For inactive
   * interrupts which use managed or reservation mode there is no
   * point in going through the vector assignment right now as the
   * activation will assign a vector which fits the destination
   * cpumask. Let the core code store the destination mask and be
   * done with it.
   */
  if (!irqd_is_activated(irqd) &&
  (apicd->is_managed || apicd->can_reserve))

My original patch should certain check activated and not disabled. With that do 
you still have reservations Marc?

Thanks,
Ali

Re: [PATCH 11/14] x86/entry: Clarify irq_{enter,exit}_rcu()

[Qian Cai]

On Tue, Jun 02, 2020 at 05:05:11PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 02, 2020 at 10:42:35AM -0400, Qian Cai wrote:
> 
> > Reverted this commit fixed the POWER9 boot warning,
> 
> ARGH, I'm an idiot. Please try this instead:
>
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index a3eb6eba8c41..c4201b7f42b1 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -438,7 +438,7 @@ void irq_exit_rcu(void)
>   */
>  void irq_exit(void)
>  {
> - irq_exit_rcu();
> + __irq_exit_rcu();
>   rcu_irq_exit();
>/* must be last! */
>   lockdep_hardirq_exit();

This works fine.

Re: [RESEND PATCH v9 3/5] powerpc/papr_scm: Fetch nvdimm health information from PHYP

[Ira Weiny]

On Tue, Jun 02, 2020 at 03:44:36PM +0530, Vaibhav Jain wrote:
> Implement support for fetching nvdimm health information via
> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
> of 64-bit bitmap, bitwise-and of which is then stored in
> 'struct papr_scm_priv' and subsequently partially exposed to
> user-space via newly introduced dimm specific attribute
> 'papr/flags'. Since the hcall is costly, the health information is
> cached and only re-queried, 60s after the previous successful hcall.
> 
> The patch also adds a  documentation text describing flags reported by
> the the new sysfs attribute 'papr/flags' is also introduced at
> Documentation/ABI/testing/sysfs-bus-papr-pmem.
> 
> [1] commit 58b278f568f0 ("powerpc: Provide initial documentation for
> PAPR hcalls")
> 
> Cc: "Aneesh Kumar K . V" 
> Cc: Dan Williams 
> Cc: Michael Ellerman 
> Cc: Ira Weiny 
> Reviewed-by: Aneesh Kumar K.V 
> Signed-off-by: Vaibhav Jain 
> ---
> Changelog:
> 
> Resend:
> * Added ack from Aneesh.
> 
> v8..v9:
> * Rename some variables and defines to reduce usage of term SCM
>   replacing it with PMEM [Dan Williams, Aneesh]
> * s/PAPR_SCM_DIMM/PAPR_PMEM/g
> * s/papr_scm_nd_attributes/papr_nd_attributes/g
> * s/papr_scm_nd_attribute_group/papr_nd_attribute_group/g
> * s/papr_scm_dimm_attr_groups/papr_nd_attribute_groups/g
> * Renamed file sysfs-bus-papr-scm to sysfs-bus-papr-pmem
> 
> v7..v8:
> * Update type of variable 'rc' in __drc_pmem_query_health() and
>   drc_pmem_query_health() to long and int respectively. [ Ira ]
> * Updated the patch description to s/64 bit Big Endian Number/64-bit
>   bitmap/ [ Ira, Aneesh ].
> 
> Resend:
> * None
> 
> v6..v7 :
> * Used the exported buf_seq_printf() function to generate content for
>   'papr/flags'
> * Moved the PAPR_SCM_DIMM_* bit-flags macro definitions to papr_scm.c
>   and removed the papr_scm.h file [Mpe]
> * Some minor consistency issued in sysfs-bus-papr-scm
>   documentation. [Mpe]
> * s/dimm_mutex/health_mutex/g [Mpe]
> * Split drc_pmem_query_health() into two function one of which takes
>   care of caching and locking. [Mpe]
> * Fixed a local copy creation of dimm health information using
>   READ_ONCE(). [Mpe]
> 
> v5..v6 :
> * Change the flags sysfs attribute from 'papr_flags' to 'papr/flags'
>   [Dan Williams]
> * Include documentation for 'papr/flags' attr [Dan Williams]
> * Change flag 'save_fail' to 'flush_fail' [Dan Williams]
> * Caching of health bitmap to reduce expensive hcalls [Dan Williams]
> * Removed usage of PPC_BIT from 'papr-scm.h' header [Mpe]
> * Replaced two __be64 integers from papr_scm_priv to a single u64
>   integer [Mpe]
> * Updated patch description to reflect the changes made in this
>   version.
> * Removed avoidable usage of 'papr_scm_priv.dimm_mutex' from
>   flags_show() [Dan Williams]
> 
> v4..v5 :
> * None
> 
> v3..v4 :
> * None
> 
> v2..v3 :
> * Removed PAPR_SCM_DIMM_HEALTH_NON_CRITICAL as a condition for
>NVDIMM unarmed [Aneesh]
> 
> v1..v2 :
> * New patch in the series.
> ---
>  Documentation/ABI/testing/sysfs-bus-papr-pmem |  27 +++
>  arch/powerpc/platforms/pseries/papr_scm.c | 169 +-
>  2 files changed, 194 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-papr-pmem
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem 
> b/Documentation/ABI/testing/sysfs-bus-papr-pmem
> new file mode 100644
> index ..5b10d036a8d4
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
> @@ -0,0 +1,27 @@
> +What:/sys/bus/nd/devices/nmemX/papr/flags
> +Date:Apr, 2020
> +KernelVersion:   v5.8
> +Contact: linuxppc-dev , 
> linux-nvd...@lists.01.org,
> +Description:
> + (RO) Report flags indicating various states of a
> + papr-pmem NVDIMM device. Each flag maps to a one or
> + more bits set in the dimm-health-bitmap retrieved in
> + response to H_SCM_HEALTH hcall. The details of the bit
> + flags returned in response to this hcall is available
> + at 'Documentation/powerpc/papr_hcalls.rst' . Below are
> + the flags reported in this sysfs file:
> +
> + * "not_armed"   : Indicates that NVDIMM contents will not
> +   survive a power cycle.
> + * "flush_fail"  : Indicates that NVDIMM contents
> +   couldn't be flushed during last
> +   shut-down event.
> + * "restore_fail": Indicates that NVDIMM contents
> +   couldn't be restored during NVDIMM
> +   initialization.
> + * "encrypted"   : NVDIMM contents are encrypted.
> + * "smart_notify": There is health event for the NVDIMM.
> + * "scrubbed": Indicating that contents of the
> +   NVDIMM have been scrubbed.
> +   

Re: [PATCH 0/3] KCSAN cleanups and noinstr

[Marco Elver]

On Tue, 2 Jun 2020 at 19:34, Peter Zijlstra  wrote:
>
> Hi all,
>
> Here's two KCSAN cleanups and the required noinstr change for x86.

Thank you!

Reviewed-by: Marco Elver 

As promised, here are the patches that would take care of KASAN and
UBSAN, rebased on the patches here:
https://lkml.kernel.org/r/20200602184409.22142-1-el...@google.com

Thanks,
-- Marco

Re: [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof

[Nick Desaulniers]

On Mon, Jun 1, 2020 at 5:03 PM Kaneda, Erik  wrote:
>
>
> Hi,
>
> > Will reported UBSAN warnings:
> > UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> > UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
> >
> > Looks like the emulated offsetof macro ACPI_OFFSET is causing these. We
> > can avoid this by using the compiler builtin, __builtin_offsetof.
>
> I'll take a look at this tomorrow
> >
> > The non-kernel runtime of UBSAN would print:
> > runtime error: member access within null pointer of type for this macro.
>
> actypes.h is owned by ACPICA so we typically do not allow compiler-specific
> extensions because the code is intended to be compiled using the C99 standard
> without compiler extensions. We could allow this sort of thing in a 
> Linux-specific
> header file like include/acpi/platform/aclinux.h but I'll take a look at the 
> error as well..

If I'm not allowed to touch that header, it looks like I can include
 (rather than my host's ) to get a
definition of `offsetof` thats implemented in terms of
`__builtin_offsetof`.  I should be able to use that to replace uses of
ACPI_OFFSET.  Are any of these off limits?

$ grep -rn ACPI_OFFSET
arch/arm64/include/asm/acpi.h:34:#define ACPI_MADT_GICC_MIN_LENGTH
ACPI_OFFSET(  \
arch/arm64/include/asm/acpi.h:41:#define ACPI_MADT_GICC_SPE
(ACPI_OFFSET(struct acpi_madt_generic_interrupt, \
include/acpi/actbl.h:376:#define ACPI_FADT_OFFSET(f) (u16)
ACPI_OFFSET (struct acpi_table_fadt, f)
drivers/acpi/acpica/acresrc.h:84:#define ACPI_RS_OFFSET(f)
  (u8) ACPI_OFFSET (struct acpi_resource,f)
drivers/acpi/acpica/acresrc.h:85:#define AML_OFFSET(f)
  (u8) ACPI_OFFSET (union aml_resource,f)
drivers/acpi/acpica/acinterp.h:17:#define ACPI_EXD_OFFSET(f)
(u8) ACPI_OFFSET (union acpi_operand_object,f)
drivers/acpi/acpica/acinterp.h:18:#define ACPI_EXD_NSOFFSET(f)
(u8) ACPI_OFFSET (struct acpi_namespace_node,f)
drivers/acpi/acpica/rsdumpinfo.c:16:#define ACPI_RSD_OFFSET(f)
 (u8) ACPI_OFFSET (union acpi_resource_data,f)
drivers/acpi/acpica/rsdumpinfo.c:17:#define ACPI_PRT_OFFSET(f)
 (u8) ACPI_OFFSET (struct acpi_pci_routing_table,f)

-- 
Thanks,
~Nick Desaulniers

[PATCH] staging: vc04_services: Convert get_user_pages*() --> pin_user_pages*()

[Souptick Joarder]

In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information.

[1] Documentation/core-api/pin_user_pages.rst

[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/

Signed-off-by: Souptick Joarder 
Cc: John Hubbard 
---
Hi,

I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.

 .../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c   | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 38a13e4..4616013 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -287,12 +287,8 @@ int vchiq_dump_platform_state(void *dump_context)
 pagelistinfo->num_pages, pagelistinfo->dma_dir);
}
 
-   if (pagelistinfo->pages_need_release) {
-   unsigned int i;
-
-   for (i = 0; i < pagelistinfo->num_pages; i++)
-   put_page(pagelistinfo->pages[i]);
-   }
+   if (pagelistinfo->pages_need_release)
+   unpin_user_pages(pagelistinfo->pages, pagelistinfo->num_pages);
 
dma_free_coherent(g_dev, pagelistinfo->pagelist_buffer_size,
  pagelistinfo->pagelist, pagelistinfo->dma_addr);
@@ -395,7 +391,7 @@ int vchiq_dump_platform_state(void *dump_context)
}
/* do not try and release vmalloc pages */
} else {
-   actual_pages = get_user_pages_fast(
+   actual_pages = pin_user_pages_fast(
  (unsigned long)buf & PAGE_MASK,
  num_pages,
  type == PAGELIST_READ,
@@ -407,10 +403,8 @@ int vchiq_dump_platform_state(void *dump_context)
   __func__, actual_pages, num_pages);
 
/* This is probably due to the process being killed */
-   while (actual_pages > 0) {
-   actual_pages--;
-   put_page(pages[actual_pages]);
-   }
+   if (actual_pages > 0)
+   unpin_user_pages(pages, actual_pages);
cleanup_pagelistinfo(pagelistinfo);
return NULL;
}
-- 
1.9.1

[PATCH -tip 2/2] compiler_types.h: Add __no_sanitize_{address,undefined} to noinstr

[Marco Elver]

Adds the portable definitions for __no_sanitize_address, and
__no_sanitize_undefined, and subsequently changes noinstr to use the
attributes to disable instrumentation via KASAN or UBSAN.

Link: https://lore.kernel.org/lkml/d2474c05a6c93...@google.com/
Reported-by: syzbot+dc1fa714cb070b184...@syzkaller.appspotmail.com
Signed-off-by: Marco Elver 
---

Note: __no_sanitize_coverage (for KCOV) isn't possible right now,
because neither GCC nor Clang support such an attribute. This means
going and changing the compilers again (for Clang it's fine, for GCC,
it'll take a while).

However, it looks like that KCOV_INSTRUMENT := n is currently in all the
right places. Short-term, this should be reasonable.
---
 include/linux/compiler-clang.h | 8 
 include/linux/compiler-gcc.h   | 6 ++
 include/linux/compiler_types.h | 3 ++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 2cb42d8bdedc..c0e4b193b311 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -33,6 +33,14 @@
 #define __no_sanitize_thread
 #endif
 
+#if __has_feature(undefined_behavior_sanitizer)
+/* GCC does not have __SANITIZE_UNDEFINED__ */
+#define __no_sanitize_undefined \
+   __attribute__((no_sanitize("undefined")))
+#else
+#define __no_sanitize_undefined
+#endif
+
 /*
  * Not all versions of clang implement the the type-generic versions
  * of the builtin overflow checkers. Fortunately, clang implements
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 7dd4e0349ef3..1c74464c80c6 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -150,6 +150,12 @@
 #define __no_sanitize_thread
 #endif
 
+#if __has_attribute(__no_sanitize_undefined__)
+#define __no_sanitize_undefined __attribute__((no_sanitize_undefined))
+#else
+#define __no_sanitize_undefined
+#endif
+
 #if GCC_VERSION >= 50100
 #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
 #endif
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 02becd21d456..89b8c1ae18a1 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -198,7 +198,8 @@ struct ftrace_likely_data {
 
 /* Section for code which can't be instrumented at all */
 #define noinstr
\
-   noinline notrace __attribute((__section__(".noinstr.text"))) __no_kcsan
+   noinline notrace __attribute((__section__(".noinstr.text")))\
+   __no_kcsan __no_sanitize_address __no_sanitize_undefined
 
 #endif /* __KERNEL__ */
 
-- 
2.27.0.rc2.251.g90737beb825-goog

[PATCH -tip 1/2] Kconfig: Bump required compiler version of KASAN and UBSAN

[Marco Elver]

Adds config variable CC_HAS_WORKING_NOSANITIZE, which will be true if we
have a compiler that does not fail builds due to no_sanitize functions.
This does not yet mean they work as intended, but for automated
build-tests, this is the minimum requirement.

For example, we require that __always_inline functions used from
no_sanitize functions do not generate instrumentation. On GCC <= 7 this
fails to build entirely, therefore we make the minimum version GCC 8.

For KCSAN this is a non-functional change, however, we should add it in
case this variable changes in future.

Link: 
https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
Suggested-by: Peter Zijlstra 
Signed-off-by: Marco Elver 
---
Apply after:
https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
---
 init/Kconfig  | 3 +++
 lib/Kconfig.kasan | 1 +
 lib/Kconfig.kcsan | 1 +
 lib/Kconfig.ubsan | 1 +
 4 files changed, 6 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 0f72eb4ffc87..3e8565bc8376 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -39,6 +39,9 @@ config TOOLS_SUPPORT_RELR
 config CC_HAS_ASM_INLINE
def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) 
-x c - -c -o /dev/null)
 
+config CC_HAS_WORKING_NOSANITIZE
+   def_bool !CC_IS_GCC || GCC_VERSION >= 8
+
 config CONSTRUCTORS
bool
depends on !UML
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..15e6c4b26a40 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -20,6 +20,7 @@ config KASAN
depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
   (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
+   depends on CC_HAS_WORKING_NOSANITIZE
help
  Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
  designed to find out-of-bounds accesses and use-after-free bugs.
diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
index 5ee88e5119c2..2ab4a7f511c9 100644
--- a/lib/Kconfig.kcsan
+++ b/lib/Kconfig.kcsan
@@ -5,6 +5,7 @@ config HAVE_ARCH_KCSAN
 
 config HAVE_KCSAN_COMPILER
def_bool CC_IS_CLANG && $(cc-option,-fsanitize=thread -mllvm 
-tsan-distinguish-volatile=1)
+   depends on CC_HAS_WORKING_NOSANITIZE
help
  For the list of compilers that support KCSAN, please see
  .
diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index a5ba2fd51823..f725d126af7d 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -4,6 +4,7 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL
 
 menuconfig UBSAN
bool "Undefined behaviour sanity checker"
+   depends on CC_HAS_WORKING_NOSANITIZE
help
  This option enables the Undefined Behaviour sanity checker.
  Compile-time instrumentation is used to detect various undefined
-- 
2.27.0.rc2.251.g90737beb825-goog

Re: [PATCH] iommu/vt-d: Don't apply gfx quirks to untrusted devices

[Rajat Jain]

Hi MIka,

Thanks for taking a look.

On Tue, Jun 2, 2020 at 2:50 AM Mika Westerberg
 wrote:
>
> On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devices, and thus apply iommu quirks to effectively
> > disable the IOMMU restrictions for itself.
> >
> > Thus we need to ensure that the device we are applying quirks to, is
> > indeed an internal trusted device.
> >
> > Signed-off-by: Rajat Jain 
> > ---
> >  drivers/iommu/intel-iommu.c | 28 
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index ef0a5246700e5..f2a480168a02f 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -6214,6 +6214,11 @@ const struct iommu_ops intel_iommu_ops = {
> >
> >  static void quirk_iommu_igfx(struct pci_dev *dev)
> >  {
> > + if (dev->untrusted) {
> > + pci_warn(dev, "skipping iommu quirk for untrusted gfx dev\n");
>
> I think you should be consistent with other messages. For example iommu
> should be spelled IOMMU as done below.
>
> Also this is visible to users so maybe put bit more information there:
>
>   pci_warn(dev, "Will not apply IOMMU quirk for untrusted graphics device\n");
>
> Ditto for all the other places. Also is "untrusted" good word here? If
> an ordinary user sees this will it trigger some sort of panic reaction.
> Perhaps we should call it "potentially untrusted" or something like
> that?

Fixed it, posted new patch at
https://lkml.org/lkml/2020/6/2/822

Thanks,

Rajat

>
> > + return;
> > + }
> > +
> >   pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
> >   dmar_map_gfx = 0;

[PATCH] x86/umip: Add emulation/spoofing for SLDT and STR instructions

[Brendan Shanks]

Add emulation/spoofing of SLDT and STR for both 32- and 64-bit
processes.

Wine users have found a small number of Windows apps using SLDT that
were crashing when run on UMIP-enabled systems.

Reported-by: Andreas Rammhold 
Originally-by: Ricardo Neri 
Signed-off-by: Brendan Shanks 
---
 arch/x86/kernel/umip.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index 8d5cbe1bbb3b..59dfceac5cc0 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -64,6 +64,8 @@
 #define UMIP_DUMMY_GDT_BASE 0xfffeULL
 #define UMIP_DUMMY_IDT_BASE 0xULL
 
+#define UMIP_DUMMY_TASK_REGISTER_SELECTOR 0x40
+
 /*
  * The SGDT and SIDT instructions store the contents of the global descriptor
  * table and interrupt table registers, respectively. The destination is a
@@ -244,16 +246,24 @@ static int emulate_umip_insn(struct insn *insn, int 
umip_inst,
*data_size += UMIP_GDT_IDT_LIMIT_SIZE;
memcpy(data, _limit, UMIP_GDT_IDT_LIMIT_SIZE);
 
-   } else if (umip_inst == UMIP_INST_SMSW) {
-   unsigned long dummy_value = CR0_STATE;
+   } else if (umip_inst == UMIP_INST_SMSW || umip_inst == UMIP_INST_SLDT ||
+  umip_inst == UMIP_INST_STR) {
+   unsigned long dummy_value;
+
+   if (umip_inst == UMIP_INST_SMSW)
+   dummy_value = CR0_STATE;
+   else if (umip_inst == UMIP_INST_STR)
+   dummy_value = UMIP_DUMMY_TASK_REGISTER_SELECTOR;
+   else
+   dummy_value = 0;
 
/*
-* Even though the CR0 register has 4 bytes, the number
+* For these 3 instructions, the number
 * of bytes to be copied in the result buffer is determined
 * by whether the operand is a register or a memory location.
 * If operand is a register, return as many bytes as the operand
 * size. If operand is memory, return only the two least
-* siginificant bytes of CR0.
+* siginificant bytes.
 */
if (X86_MODRM_MOD(insn->modrm.value) == 3)
*data_size = insn->opnd_bytes;
@@ -261,7 +271,6 @@ static int emulate_umip_insn(struct insn *insn, int 
umip_inst,
*data_size = 2;
 
memcpy(data, _value, *data_size);
-   /* STR and SLDT  are not emulated */
} else {
return -EINVAL;
}
@@ -383,10 +392,6 @@ bool fixup_umip_exception(struct pt_regs *regs)
umip_pr_warn(regs, "%s instruction cannot be used by applications.\n",
umip_insns[umip_inst]);
 
-   /* Do not emulate (spoof) SLDT or STR. */
-   if (umip_inst == UMIP_INST_STR || umip_inst == UMIP_INST_SLDT)
-   return false;
-
umip_pr_warn(regs, "For now, expensive software emulation returns the 
result.\n");
 
if (emulate_umip_insn(, umip_inst, dummy_data, _data_size,
-- 
2.26.2

[PATCH v2] iommu/vt-d: Don't apply gfx quirks to untrusted devices

[Rajat Jain]

Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.

Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.

Signed-off-by: Rajat Jain 
Acked-by: Lu Baolu 
---
V2: - Change the warning print strings.
- Add Lu Baolu's acknowledgement.

 drivers/iommu/intel-iommu.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..fdfbea4ff8cb3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -6214,6 +6214,13 @@ const struct iommu_ops intel_iommu_ops = {
 
 static void quirk_iommu_igfx(struct pci_dev *dev)
 {
+   if (dev->untrusted) {
+   pci_warn(dev,
+"Skipping IOMMU quirk %s() for potentially untrusted 
device\n",
+__func__);
+   return;
+   }
+
pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
dmar_map_gfx = 0;
 }
@@ -6255,6 +6262,13 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, 
quirk_iommu_igfx);
 
 static void quirk_iommu_rwbf(struct pci_dev *dev)
 {
+   if (dev->untrusted) {
+   pci_warn(dev,
+"Skipping IOMMU quirk %s() for potentially untrusted 
device\n",
+__func__);
+   return;
+   }
+
/*
 * Mobile 4 Series Chipset neglects to set RWBF capability,
 * but needs it. Same seems to hold for the desktop versions.
@@ -6285,6 +6299,13 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev 
*dev)
 {
unsigned short ggc;
 
+   if (dev->untrusted) {
+   pci_warn(dev,
+"Skipping IOMMU quirk %s() for potentially untrusted 
device\n",
+__func__);
+   return;
+   }
+
if (pci_read_config_word(dev, GGC, ))
return;
 
@@ -6318,6 +6339,15 @@ static void __init check_tylersburg_isoch(void)
pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
if (!pdev)
return;
+
+   if (pdev->untrusted) {
+   pci_warn(pdev,
+"Skipping IOMMU quirk %s() for potentially untrusted 
device\n",
+__func__);
+   pci_dev_put(pdev);
+   return;
+   }
+
pci_dev_put(pdev);
 
/* System Management Registers. Might be hidden, in which case
@@ -6327,6 +6357,14 @@ static void __init check_tylersburg_isoch(void)
if (!pdev)
return;
 
+   if (pdev->untrusted) {
+   pci_warn(pdev,
+"Skipping IOMMU quirk %s() for potentially untrusted 
device\n",
+__func__);
+   pci_dev_put(pdev);
+   return;
+   }
+
if (pci_read_config_dword(pdev, 0x188, )) {
pci_dev_put(pdev);
return;
-- 
2.27.0.rc2.251.g90737beb825-goog

[PATCH] driver core:Export the symbol device_is_bound

[Sandeep Maheswaram]

Export the symbol device_is_bound so that it can be used by the modules.
This change was suggested to solve the allmodconfig build error on adding
the patch https://lore.kernel.org/patchwork/patch/1218628/

Signed-off-by: Sandeep Maheswaram 
---
 drivers/base/dd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940..65d16ce 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -337,6 +337,7 @@ bool device_is_bound(struct device *dev)
 {
return dev->p && klist_node_attached(>p->knode_driver);
 }
+EXPORT_SYMBOL_GPL(device_is_bound);
 
 static void driver_bound(struct device *dev)
 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH -next] IB/hfi1: Use free_netdev() in hfi1_netdev_free()

[Dan Carpenter]

On Tue, Jun 02, 2020 at 11:30:13AM -0400, Dennis Dalessandro wrote:
> On 6/2/2020 2:16 AM, YueHaibing wrote:
> > dummy_netdev shold be freed by free_netdev() instead of
> > kfree(). Also remove unneeded variable 'priv'
> > 
> > Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev")
> > Signed-off-by: YueHaibing 
> > ---
> >   drivers/infiniband/hw/hfi1/netdev_rx.c | 5 +
> >   1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/infiniband/hw/hfi1/netdev_rx.c 
> > b/drivers/infiniband/hw/hfi1/netdev_rx.c
> > index 58af6a454761..63688e85e8da 100644
> > --- a/drivers/infiniband/hw/hfi1/netdev_rx.c
> > +++ b/drivers/infiniband/hw/hfi1/netdev_rx.c
> > @@ -371,12 +371,9 @@ int hfi1_netdev_alloc(struct hfi1_devdata *dd)
> >   void hfi1_netdev_free(struct hfi1_devdata *dd)
> >   {
> > -   struct hfi1_netdev_priv *priv;
> > -
> > if (dd->dummy_netdev) {
> > -   priv = hfi1_netdev_priv(dd->dummy_netdev);
> > dd_dev_info(dd, "hfi1 netdev freed\n");
> > -   kfree(dd->dummy_netdev);
> > +   free_netdev(dd->dummy_netdev);
> > dd->dummy_netdev = NULL;
> > }
> >   }
> > 
> 
> For the kfree->free_netdev, you probably want to add:
> Reported-by: kbuild test robot 
> Reported-by: Dan Carpenter 

YueHaibing wasn't on the CC list when I sent forwarded that kbuild bot
email.  Forget about it.  Let's just apply this.

regards,
dan carpenter

Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"

[Brian Norris]

On Thu, May 28, 2020 at 8:42 AM Adrian Chadd  wrote:
> On Thu, 28 May 2020 at 05:02, Julian Calaby  wrote:
> > On Thu, May 28, 2020 at 5:18 AM Brian Norris  
> > wrote:
> > >
> > > This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
> > >
> > > Users are reporting regressions in regulatory domain detection and
> > > channel availability.
> > >
> > > The problem this was trying to resolve was fixed in firmware anyway:
> >
> > Should we tell the user their firmware needs to be upgraded if it
> > reports this regulatory domain instead of completely dropping support
> > for it?

I'm not really sure how to do that properly in general, and I don't
plan to do so. I'm simply reverting a change that caused people
problems, and noting at the same time that the original problem was
resolved differently.

I don't really have a stake in this patch, because everything I care
about works correctly either way. (And AFAICT, any hardware that is
affected by this patch is somewhat broken.) I'm only posting the
revert as a community service, because Wen couldn't be bothered to do
it himself.

> Also that commit mentioned a 6174 firmware, but what about all the other 
> older chips with a regulatory domain of 0x0 ?

My understanding was that no QCA modules *should* be shipped with a
value of 0 in this field. The instance I'm aware of was more or less a
manufacturing error I think, and we got Qualcomm to patch it over in
software. I don't think people expected anybody else to have shipped
modules with a 0 value, but apparently they did. I don't know what to
do with those, other than just leave well enough alone (i.e., $subject
revert).

> As a side note, I'd /really appreciate/ if ath10k changes were tested on a 
> variety of ath10k hardware and firmware revisions, rather than just either 
> the Rome or embedded radios, rather than also including peregrine, cascade, 
> besra, etc.

Wouldn't we all love it if everybody else tested appropriately. But
Qualcomm folks can't be coordinated (trust me, I've tried), and apart
from things like KernelCI (which so far has no WiFi tests, IIUC),
there's no community testing efforts that don't involve
"${RANDOM_PERSON} boots ${PERSONAL_BOX} and see if it blows up."

This also might not be the best place to admit it, but I'll be up
front: I have no idea what peregrine, cascade, or besra are.

Brian

Re: spi: spi-ti-qspi: call pm_runtime_put on pm_runtime_get failure

[Mark Brown]

On Tue, Jun 02, 2020 at 05:05:18PM +0200, Markus Elfring wrote:
> >> I find this commit message improvable also according to Linux software
> >> development documentation.

> > Causing people to send out new versions of things for tweaks to the
> > commit log consumes time for them and everyone they're sending changes to.

> Improving patches (besides source code adjustments) is an usual software
> development activity, isn't it?

Your updates were not improvements.  The formatting was worse and to my
native speaker eyes the grammar was worse.  With this sort of stylistic
thing it's especially important that any review aligns with the needs
and practices of the subsystem, there is opinion in there and multiple
opinions just makes things harder for submitters.


signature.asc
Description: PGP signature

[PATCH v2 0/1] Document Ingenic SoCs binding.

[Zhou Yanjie]

Document the available properties for the SoC root node and the
CPU nodes of the devicetree for the Ingenic XBurst SoCs.

v1->v2:
1.Remove unnecessary "items".
2.Add "clocks" as suggested by Paul Cercueil.

周琰杰 (Zhou Yanjie) (1):
  dt-bindings: MIPS: Document Ingenic SoCs binding.

 .../bindings/mips/ingenic/ingenic,cpu.yaml | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml

-- 
2.11.0

[PATCH v2 1/1] dt-bindings: MIPS: Document Ingenic SoCs binding.

[Zhou Yanjie]

Document the available properties for the SoC root node and the
CPU nodes of the devicetree for the Ingenic XBurst SoCs.

Tested-by: H. Nikolaus Schaller 
Tested-by: Paul Boddie 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v1->v2:
1.Remove unnecessary "items".
2.Add "clocks" as suggested by Paul Cercueil.

 .../bindings/mips/ingenic/ingenic,cpu.yaml | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml

diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml 
b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
new file mode 100644
index ..171503e08505
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic XBurst family CPUs
+
+maintainers:
+  - 周琰杰 (Zhou Yanjie) 
+
+description:
+  Ingenic XBurst family CPUs shall have the following properties.
+
+properties:
+  compatible:
+oneOf:
+
+  - description: Ingenic XBurst®1 CPU Cores
+enum:
+  - ingenic,xburst-mxu1.0
+  - ingenic,xburst-fpu1.0-mxu1.1
+  - ingenic,xburst-fpu2.0-mxu2.0
+
+  - description: Ingenic XBurst®2 CPU Cores
+enum:
+  - ingenic,xburst2-fpu2.1-mxu2.1-smt
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+required:
+  - device_type
+  - compatible
+  - reg
+  - clocks
+
+examples:
+  - |
+#include 
+
+cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+   reg = <0>;
+
+   clocks = < JZ4780_CLK_CPU>;
+   clock-names = "cpu";
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+   reg = <1>;
+
+   clocks = < JZ4780_CLK_CORE1>;
+   clock-names = "cpu";
+   };
+};
+...
-- 
2.11.0

Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good

[Victor Julien]

Hi Willem,

On 02-06-2020 19:37, Willem de Bruijn wrote:
> On Tue, Jun 2, 2020 at 1:03 PM Victor Julien  wrote:
>>
>> On 02-06-2020 16:29, Willem de Bruijn wrote:
>>> On Tue, Jun 2, 2020 at 4:05 AM Victor Julien  wrote:

 Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
 that the driver has completely validated the checksums in the packet.

 The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
 in that the new flag will only be set if all the layers are valid,
 while TP_STATUS_CSUM_VALID is set as well if only the IP layer is valid.
>>>
>>> transport, not ip checksum.
>>
>> Allow me a n00b question: what does transport refer to here? Things like
>> ethernet? It isn't clear to me from the doc.
> 
> The TCP/UDP/.. transport protocol checksum.

Hmm that is what I thought originally, but then it didn't seem to work.
Hence my patch.

However I just redid my testing. I took the example tpacketv3 program
and added the status flag checks to the 'display()' func:

if (ppd->tp_status & TP_STATUS_CSUM_VALID) {
printf("TP_STATUS_CSUM_VALID, ");
}
if (ppd->tp_status & (1<<8)) {
printf("TP_STATUS_CSUM_UNNECESSARY, ");

}

Then using scapy sent some packets in 2 variants:
- default (good csums)
- deliberately bad csums
(then also added a few things like ip6 over ip)


srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(),
iface="enp1s0") // good csums

srp1(Ether()/IP(src="1.2.3.4", dst="5.6.7.8")/IPv6()/TCP(chksum=1),
iface="enp1s0") //bad tcp

1.2.3.4 -> 5.6.7.8, TP_STATUS_CSUM_VALID, TP_STATUS_CSUM_UNNECESSARY,
rxhash: 0x81ad5744
1.2.3.4 -> 5.6.7.8, rxhash: 0x81ad5744

So this suggests that what you're saying is correct, that it sets
TP_STATUS_CSUM_VALID if the TCP/UDP csum (and IPv4 csum) is valid, and
does not set it when either of them are invalid.

I'll also re-evaluate things in Suricata.


One thing I wonder if what this "at least" from the 682f048bd494 commit
message means:

"Introduce TP_STATUS_CSUM_VALID tp_status flag to tell the
 af_packet user that at least the transport header checksum
 has been already validated."

For TCP/UDP there wouldn't be a higher layer with csums, right? And
based on my testing it seems lower levels (at least IP) is also
included. Or would that perhaps refer to something like VXLAN or Geneve
over UDP? That the csums of packets on top of those layers aren't
(necessarily) considered?

Thanks,
Victor


>> (happy to follow up with a patch to clarify the doc when I understand
>> things better)
>>
>>> But as I understand it drivers set CHECKSUM_COMPLETE if they fill in
>>> skb->csum over the full length of the packet. This does not
>>> necessarily imply that any of the checksum fields in the packet are
>>> valid yet (see also skb->csum_valid). Protocol code later compares
>>> checksum fields against this using __skb_checksum_validate_complete and 
>>> friends.
>>>
>>> But packet sockets may be called before any of this, however. So I wonder
>>> how valid the checksum really is right now when setting 
>>> TP_STATUS_CSUM_VALID.
>>> I assume it's correct, but don't fully understand where the validation
>>> has taken place..
>>
>> I guess I'm more confused now about what TP_STATUS_CSUM_VALID actually
>> means. It sounds almost like the opposite of TP_STATUS_CSUMNOTREADY, but
>> I'm not sure I understand what the value would be.
>>
>> It would be great if someone could help clear this up. Everything I
>> thought I knew/understood so far has been proven wrong, so I'm not too
>> confident about my patch anymore...
> 
> Agreed that we should clear this up.
> 
>>> Similar to commit 682f048bd494 ("af_packet: pass checksum validation
>>> status to the user"), please update tpacket_rcv and packet_rcv.
>>
>> Ah yes, good catch. Will add it there as well.
>>
>>> Note also that net-next is currently closed.
>>
>> Should I hold off on sending a v3 until it reopens?
> 
> Yep, thanks. You can always check
> http://vger.kernel.org/~davem/net-next.html when unsure.
> 


-- 
-
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
-

Re: 3ba75830ce ("nfsd4: drc containerization"): [ 51.013875] WARNING: possible circular locking dependency detected

[J. Bruce Fields]

On Wed, May 27, 2020 at 01:11:59PM +0800, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit 3ba75830ce175550ef45c6524ec62faab8f62c1b

Thanks!  I looked at the code quickly and can't figure out where the
deadlock is exactly.

It seems to involve the kmem_cache_create() call in nfsd's net init
method.  Anyone know if there's a reason why creating a new slab cache
during network namespace initialization is a potential deadlock?

It was probably a dumb thing to do in this case--I can apply the below
to make the slab global again.  Kinda curious what exactly the bug is,
though.

--b.

commit 027690c75e8f
Author: J. Bruce Fields 
Date:   Mon Jun 1 17:44:45 2020 -0400

nfsd4: make drc_slab global, not per-net

I made every global per-network-namespace instead.  But perhaps doing
that to this slab was a step too far.

The kmem_cache_create call in our net init method also seems to be
responsible for this lockdep warning:

[   45.163710] Unable to find swap-space signature
[   45.375718] trinity-c1 (855): attempted to duplicate a private mapping 
with mremap.  This is not supported.
[   46.055744] futex_wake_op: trinity-c1 tries to shift op by -209; fix 
this program
[   51.011723]
[   51.013378] ==
[   51.013875] WARNING: possible circular locking dependency detected
[   51.014378] 5.2.0-rc2 #1 Not tainted
[   51.014672] --
[   51.015182] trinity-c2/886 is trying to acquire lock:
[   51.015593] 5405f099 (slab_mutex){+.+.}, at: 
slab_attr_store+0xa2/0x130
[   51.016190]
[   51.016190] but task is already holding lock:
[   51.016652] ac662005 (kn->count#43){}, at: 
kernfs_fop_write+0x286/0x500
[   51.017266]
[   51.017266] which lock already depends on the new lock.
[   51.017266]
[   51.017909]
[   51.017909] the existing dependency chain (in reverse order) is:
[   51.018497]
[   51.018497] -> #1 (kn->count#43){}:
[   51.018956]__lock_acquire+0x7cf/0x1a20
[   51.019317]lock_acquire+0x17d/0x390
[   51.019658]__kernfs_remove+0x892/0xae0
[   51.020020]kernfs_remove_by_name_ns+0x78/0x110
[   51.020435]sysfs_remove_link+0x55/0xb0
[   51.020832]sysfs_slab_add+0xc1/0x3e0
[   51.021332]__kmem_cache_create+0x155/0x200
[   51.021720]create_cache+0xf5/0x320
[   51.022054]kmem_cache_create_usercopy+0x179/0x320
[   51.022486]kmem_cache_create+0x1a/0x30
[   51.022867]nfsd_reply_cache_init+0x278/0x560
[   51.023266]nfsd_init_net+0x20f/0x5e0
[   51.023623]ops_init+0xcb/0x4b0
[   51.023928]setup_net+0x2fe/0x670
[   51.024315]copy_net_ns+0x30a/0x3f0
[   51.024653]create_new_namespaces+0x3c5/0x820
[   51.025257]unshare_nsproxy_namespaces+0xd1/0x240
[   51.025881]ksys_unshare+0x506/0x9c0
[   51.026381]__x64_sys_unshare+0x3a/0x50
[   51.026937]do_syscall_64+0x110/0x10b0
[   51.027509]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   51.028175]
[   51.028175] -> #0 (slab_mutex){+.+.}:
[   51.028817]validate_chain+0x1c51/0x2cc0
[   51.029422]__lock_acquire+0x7cf/0x1a20
[   51.029947]lock_acquire+0x17d/0x390
[   51.030438]__mutex_lock+0x100/0xfa0
[   51.030995]mutex_lock_nested+0x27/0x30
[   51.031516]slab_attr_store+0xa2/0x130
[   51.032020]sysfs_kf_write+0x11d/0x180
[   51.032529]kernfs_fop_write+0x32a/0x500
[   51.033056]do_loop_readv_writev+0x21d/0x310
[   51.033627]do_iter_write+0x2e5/0x380
[   51.034148]vfs_writev+0x170/0x310
[   51.034616]do_pwritev+0x13e/0x160
[   51.035100]__x64_sys_pwritev+0xa3/0x110
[   51.035633]do_syscall_64+0x110/0x10b0
[   51.036200]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   51.036924]
[   51.036924] other info that might help us debug this:
[   51.036924]
[   51.037876]  Possible unsafe locking scenario:
[   51.037876]
[   51.038556]CPU0CPU1
[   51.039130]
[   51.039676]   lock(kn->count#43);
[   51.040084]lock(slab_mutex);
[   51.040597]lock(kn->count#43);
[   51.041062]   lock(slab_mutex);
[   51.041320]
[   51.041320]  *** DEADLOCK ***
[   51.041320]
[   51.041793] 3 locks held by trinity-c2/886:
[   51.042128]  #0: 1f55e152 (sb_writers#5){.+.+}, at: 
vfs_writev+0x2b9/0x310
[   

Re: [GIT PULL] x86/mm changes for v5.8

[Thomas Gleixner]

Benjamin Herrenschmidt  writes:
> On Tue, 2020-06-02 at 09:33 +0200, Ingo Molnar wrote:
>> Or rather, we should ask a higher level question as well, maybe we 
>> should not do this feature at all?
>
> Well, it does solve a real issue in some circumstances and there was a
> reasonable discussion about this on the list that lead to it being
> merged with Kees and Thomas (and others) agreeing :)
>
> But yes, it is pointless with SMT and yes maybe we should make it
> explicitly do nothing on SMT, but let's not throw the baby out with the
> bath water shall we ?

It's trivial enough to fix. We have a static key already which is
telling us whether SMT scheduling is active.

Thanks,

tglx
---
 arch/x86/mm/tlb.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -457,7 +458,7 @@ static void cond_mitigation(struct task_
indirect_branch_prediction_barrier();
}
 
-   if (prev_mm & LAST_USER_MM_L1D_FLUSH) {
+   if (!sched_smt_active() && prev_mm & LAST_USER_MM_L1D_FLUSH) {
/*
 * Don't populate the TLB for the software fallback flush.
 * Populate TLB is not needed for this use case.

[GIT PULL] perf tooling changes for v5.8

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Hi Linus,

These are additional changes to the perf tools, on top of what
Ingo has already submitted and you merged, please let me know if I made
any mistake,

Available from:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
perf-tools-2020-06-02

  # HEAD: 3e9b26dc2268cfbeef85bee095f883264c18425c Remove some duplicated 
includes

A summary of what is here:

 - Further Intel PT call-trace fixes

 - Improve SELinux docs and tool warnings

 - Fix race at exit in 'perf record' using eventfd.

 - Add missing build tests to the default set of 'make -C tools/perf build-test'

 - Sync msr-index.h getting new AMD MSRs to decode and filter in 'perf trace'.

 - Fix fallback to libaudit in 'perf trace' for arches not using per-arch *.tbl 
files.

 - Fixes for 'perf ftrace'.

 - Fixes and improvements for the 'perf stat' metrics.

 - Use dummy event to get PERF_RECORD_{FORK,MMAP,etc} while synthesizing
   those metadata events for pre-existing threads.

 - Fix leaks detected using clang tooling.

 - Improvements to PMU event metric testing.

 - Report summary for 'perf stat' interval mode at the end, summing up
   all the intervals.

 - Improve pipe mode, i.e. this now works as expected, continuously
   dumping samples:

# perf record -g -e raw_syscalls:sys_enter | perf --no-pager script

 - Fixes for event grouping, detecting incompatible groups such as:

 # perf stat -e '{cycles,power/energy-cores/}' -v
 WARNING: group events cpu maps do not match, disabling group:
   anon group { power/energy-cores/, cycles }
 power/energy-cores/: 0
 cycles: 0-7

 - Fixes for 'perf probe': blacklist address checking, number of
   kretprobe instances, etc.

 - JIT processing improvements and fixes plus the addition of a 'perf
   test' entry for the java demangler.

 - Add support for synthesizing first/last level cache, TLB and remove
   access events from HW tracing in the auxtrace code, first to use is
   ARM SPE.

 - Vendor events updates and fixes, including for POWER9 and Intel.

 - Allow using ~/.perfconfig for removing the ',' separators in 'perf
   stat' output.

 - Opt-in support for libpfm4.

Best Regards,

- Arnaldo

Adrian Hunter (8):
  perf intel-pt: Use allocated branch stack for PEBS sample
  perf symbols: Fix debuginfo search for Ubuntu
  perf kcore_copy: Fix module map when there are no modules loaded
  perf evlist: Disable 'immediate' events last
  perf script: Fix --call-trace for Intel PT
  perf record: Respect --no-switch-events
  perf intel-pt: Refine kernel decoding only warning message
  perf symbols: Fix kernel maps for kcore and eBPF

Alexey Budankov (3):
  perf docs: Extend CAP_SYS_ADMIN with CAP_PERFMON where needed
  perf tool: Make perf tool aware of SELinux access control
  perf docs: Introduce security.txt file to document related issues

Anand K Mistry (1):
  perf record: Use an eventfd to wakeup when done

Andi Kleen (1):
  perf script: Don't force less for non tty output with --xed

Arnaldo Carvalho de Melo (21):
  perf evsel: Rename perf_evsel__object_config() to evsel__object_config()
  perf evsel: Rename perf_evsel__resort*() to evsel__resort*()
  perf evsel: Rename perf_evsel__fprintf() to evsel__fprintf()
  perf evsel: Rename *perf_evsel__get_config_term() & friends to evsel__env()
  perf evsel: Rename perf_evsel__new*() to evsel__new*()
  perf evsel: Rename perf_evsel__[hs]w_cache* to evsel__[hs]w_cache*
  perf counts: Rename perf_evsel__*counts() to evsel__*counts()
  perf parse-events: Fix incorrect conversion of 'if () free()' to 'zfree()'
  perf evsel: Initialize evsel->per_pkg_mask to NULL in evsel__init()
  tools feature: Rename HAVE_EVENTFD to HAVE_EVENTFD_SUPPORT
  perf build: Group the NO_SYSCALL_TABLE logic
  perf build: Allow explicitely disabling the NO_SYSCALL_TABLE variable
  perf trace: Remove union from syscalltbl, all the fields are needed
  perf trace: Use zalloc() to make sure all fields are zeroed in the syscalltbl 
constructor
  perf trace: Grow the syscall table as needed when using libaudit
  perf build: Remove libaudit from the default feature checks
  perf build: Add NO_SYSCALL_TABLE=1 to the build tests
  perf build: Add NO_LIBCRYPTO=1 to the default set of build tests
  perf build: Add NO_SDT=1 to the default set of build tests
  perf build: Add a LIBPFM4=1 build test entry
  tools arch x86: Sync the msr-index.h copy with the kernel sources

Changbin Du (2):
  perf ftrace: Trace system wide if no target is given
  perf ftrace: Detect workload failure

Ed Maste (1):
  perf tools: Correct license on jsmn JSON parser

Gustavo A. R. Silva (2):
  perf tools: Replace zero-length array with flexible-array
  perf branch: Replace zero-length array with flexible-array

Ian Rogers (38):
  perf expr: Allow for unlimited escaped characters in a symbol
  perf metrics: Fix parse errors in cascade lake metrics
  perf metrics: Fix parse errors in skylake metrics
  perf expr: 

Re: [PATCH] ARM: dts: AM33xx-l4: add gpio-ranges

[Drew Fustini]

On Tue, Jun 02, 2020 at 04:44:03PM +0300, Grygorii Strashko wrote:
> 
> 
> On 02/06/2020 16:14, Drew Fustini wrote:
> > Add gpio-ranges properties to the gpio controller nodes.
> > 
> > These gpio-ranges were created based on "Table 9-10. CONTROL_MODULE
> > REGISTERS" in the  "AM335x Technical Reference Manual" [0] and "Table
> > 4-2. Pin Attributes" in the "AM335x Sitara Processor datasheet" [1].
> > A csv file with this data is available for reference [2].
> 
> It will be good if you can explain not only "what" is changed, but
> also "why" it's needed in commit message.

That is a good point.

One reason for this patch is I think it makes sense to add gpio-ranges
properties as they describe the relationship between a gpio line and
pin control register that exists in the hardware.  For example, GPMC_A0
pin has mode 7 which is labeled gpio1_16. The conf_gpmc_a0 register is
at offset 840h which makes it pin 16.

The other reason is that I would like to patch omap_gpio_set_config()
to call gpiochip_generic_config() for PIN_CONFIG_PULL_{UP,DOWN}. It
currently fails at pinctrl_get_device_gpio_range():

  omap_gpio_set_config()  
  |- gpiochip_generic_config()
 |- pinctrl_gpio_set_config()
|- gpio_to_pin()
   |- pinctrl_get_device_gpio_range() [no gpio-ranges so fails]


Thank you,
Drew

Re: [PATCH] xfs/XXX: Add xfs/XXX

[Darrick J. Wong]

On Tue, Jun 02, 2020 at 04:51:48PM +0800, Xiao Yang wrote:
> On 2020/4/14 0:30, Darrick J. Wong wrote:
> > This might be a good time to introduce a few new helpers:
> > 
> > _require_scratch_dax ("Does $SCRATCH_DEV support DAX?")
> > _require_scratch_dax_mountopt ("Does the fs support the DAX mount options?")
> > _require_scratch_daX_iflag ("Does the fs support FS_XFLAG_DAX?")
> Hi Darrick,
> 
> Now, I am trying to introduce these new helpers and have some questions:
> 1) There are five testcases related to old dax implementation, should we
> only convert them to new dax implementation or make them compatible with old
> and new dax implementation?

What is the 'old' DAX implementation?  ext2 XIP?

> 2) I think _require_xfs_io_command "chattr" "x" is enough to check if fs
> supports FS_XFLAG_DAX.  Is it necessary to add _require_scratch_dax_iflag()?
> like this:
> _require_scratch_dax_iflag()
> {
>   _require_xfs_io_command "chattr" "x"
> }

I suggested that list based on the major control knobs that will be
visible to userspace programs.  Even if this is just a one-line helper,
its name is useful for recognizing which of those knobs we're looking
for.

Yes, you could probably save a trivial amount of time by skipping one
iteration of bash function calling, but now everyone has to remember
that the xfs_io chattr "x" flag means the dax inode flag, and not
confuse it for chmod +x or something else.

--D

> Best Regards,
> Xiao Yang
> 
> 

[PATCH 4.9 00/55] 4.9.226-rc3 review

[Greg Kroah-Hartman]

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

Responses should be made by Thu, 04 Jun 2020 18:12:28 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.226-rc3.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.9.226-rc3

Benjamin Block 
scsi: zfcp: fix request object use-after-free in send path causing wrong 
traces

Salil Mehta 
net: hns: Fixes the missing put_device in positive leg for roce reset

Guoqing Jiang 
sc16is7xx: move label 'err_spi' to correct section

Liviu Dudau 
mm/vmalloc.c: don't dereference possible NULL pointer in __vunmap()

Roopa Prabhu 
net: rtnl_configure_link: fix dev flags changes arg to __dev_notify_flags

Thomas Gleixner 
genirq/generic_pending: Do not lose pending affinity update

Pablo Neira Ayuso 
netfilter: nf_conntrack_pptp: fix compilation warning with W=1 build

Qiushi Wu 
bonding: Fix reference count leak in bond_sysfs_slave_add.

Qiushi Wu 
qlcnic: fix missing release in qlcnic_83xx_interrupt_test.

Pablo Neira Ayuso 
netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code

Phil Sutter 
netfilter: ipset: Fix subcounter update skip

Michael Braun 
netfilter: nft_reject_bridge: enable reject with bridge vlan

Xin Long 
ip_vti: receive ipip packet by calling ip_tunnel_rcv

Jeremy Sowden 
vti4: eliminated some duplicate code.

Xin Long 
xfrm: fix a NULL-ptr deref in xfrm_local_error

Xin Long 
xfrm: fix a warning in xfrm_policy_insert_list

Xin Long 
xfrm: allow to accept packets with ipv6 NEXTHDR_HOP in xfrm_input

Alexander Dahl 
x86/dma: Fix max PFN arithmetic overflow on 32 bit systems

Linus Lüssing 
mac80211: mesh: fix discovery timer re-arming issue / crash

Helge Deller 
parisc: Fix kernel panic in mem_init()

Qiushi Wu 
iommu: Fix reference count leak in iommu_group_alloc.

Arnd Bergmann 
include/asm-generic/topology.h: guard cpumask_of_node() macro argument

Alexander Potapenko 
fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

Konstantin Khlebnikov 
mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()

Jerry Lee 
libceph: ignore pool overlay and cache logic on redirects

Eric W. Biederman 
exec: Always set cap_ambient in cap_bprm_set_creds

Chris Chiu 
ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC

Changming Liu 
ALSA: hwdep: fix a left shifting 1 by 31 UB bug

Robert Beckett 
ARM: dts/imx6q-bx50v3: Set display interface clock parents

Sebastian Reichel 
ARM: dts: imx6q-bx50v3: Add internal switch

Martyn Welch 
ARM: dts: imx: Correct B850v3 clock assignment

Kaike Wan 
IB/qib: Call kobject_put() when kobject_init_and_add() fails

Wei Yongjun 
Input: synaptics-rmi4 - fix error return code in rmi_driver_probe()

Kevin Locke 
Input: i8042 - add ThinkPad S230u to i8042 reset list

Łukasz Patron 
Input: xpad - add custom init packet for Xbox One S controllers

Brendan Shanks 
Input: evdev - call input_flush_device() on release(), not flush()

James Hilliard 
Input: usbtouchscreen - add support for BonXeon TP

Steve French 
cifs: Fix null pointer check in cifs_read

Masahiro Yamada 
usb: gadget: legacy: fix redundant initialization warnings

Lei Xue 
cachefiles: Fix race between read_waiter and read_copier involving op->to_do

Bob Peterson 
gfs2: move privileged user check to gfs2_quota_lock_check

Chuhong Yuan 
net: microchip: encx24j600: add missed kthread_stop

Stephen Warren 
gpio: tegra: mask GPIO IRQs during IRQ shutdown

Kalderon, Michal 
IB/cma: Fix reference count leak when no ipv4 addresses are set

Dmitry V. Levin 
uapi: fix linux/if_pppol2tp.h userspace compilation errors

Qiushi Wu 
net/mlx4_core: fix a memory leak bug.

Qiushi Wu 
net: sun: fix missing release regions in cas_init_one().

Moshe Shemesh 
net/mlx5: Add command entry handling completion

Manivannan Sadhasivam 
net: qrtr: Fix passing invalid reference to qrtr_local_enqueue()

Moshe Shemesh 
net/mlx5e: Update netdev txq on completions during closure

Jere Leppänen 
sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and 
socket is closed

Roman Mashak 
net sched: fix reporting the first-time use timestamp

Yuqi Jin 
net: revert "net: get rid of an signed integer overflow in 
ip_idents_reserve()"

Vadim Fedorenko 
net: ipip: fix wrong address family in init error path

Eric Dumazet 

Re: [PATCHv2 00/13] perf tests: Add metrics tests

[Ian Rogers]

On Tue, Jun 2, 2020 at 4:51 AM Jiri Olsa  wrote:
>
> hi,
> changes for using metric result in another metric seem
> to change lot of core metric code, so it's better we
> have some more tests before we do that.
>
> v2 changes:
>   - some of the patches got accepted
>   - add missing free to patch 1 [Ian]
>   - factor pmu-events test functions and reuse it in the new test [Ian]
>   - add fake_pmu bool to parse_events interface [Ian]
>   - simplify metric tests
>   - use proper cover letter subject ;-)
>
> I actually reworked the 2 patches Ian acked so far,
> so I did not add them.
>
> Also available in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/metric_test
>
> thanks,
> jirka
>
>
> ---
> Jiri Olsa (13):
>   perf tools: Add fake pmu support
>   perf tools: Add fake_pmu bool to parse_events interface
>   perf tests: Factor check_parse_id function
>   perf tests: Add another metric parsing test
>   perf tools: Factor out parse_groups function
>   perf tools: Add fake_pmu to parse_events function
>   perf tools: Add map to parse_events function
>   perf tools: Add metricgroup__parse_groups_test function
>   perf tools: Factor out prepare_metric function
>   perf tools: Release metric_events rblist
>   perf tools: Add test_generic_metric function
>   perf tests: Add parse metric test for ipc metric
>   perf tests: Add parse metric test for frontend metric
>
>  tools/perf/arch/arm/util/cs-etm.c|   2 +-
>  tools/perf/arch/arm64/util/arm-spe.c |   2 +-
>  tools/perf/arch/powerpc/util/kvm-stat.c  |   2 +-
>  tools/perf/arch/x86/tests/intel-cqm.c|   2 +-
>  tools/perf/arch/x86/tests/perf-time-to-tsc.c |   2 +-
>  tools/perf/arch/x86/util/intel-bts.c |   2 +-
>  tools/perf/arch/x86/util/intel-pt.c  |   6 ++--
>  tools/perf/builtin-stat.c|   9 +++---
>  tools/perf/builtin-trace.c   |   4 +--
>  tools/perf/tests/Build   |   1 +
>  tools/perf/tests/backward-ring-buffer.c  |   3 +-
>  tools/perf/tests/builtin-test.c  |   4 +++
>  tools/perf/tests/code-reading.c  |   2 +-
>  tools/perf/tests/event-times.c   |   2 +-
>  tools/perf/tests/evsel-roundtrip-name.c  |   4 +--
>  tools/perf/tests/hists_cumulate.c|   2 +-
>  tools/perf/tests/hists_filter.c  |   4 +--
>  tools/perf/tests/hists_link.c|   4 +--
>  tools/perf/tests/hists_output.c  |   2 +-
>  tools/perf/tests/keep-tracking.c |   4 +--
>  tools/perf/tests/parse-events.c  |   2 +-
>  tools/perf/tests/parse-metric.c  | 170 
> ++
>  tools/perf/tests/pmu-events.c| 132 
> ++
>  tools/perf/tests/switch-tracking.c   |   8 ++---
>  tools/perf/tests/tests.h |   1 +
>  tools/perf/util/bpf-loader.c |   2 +-
>  tools/perf/util/metricgroup.c|  74 
> --
>  tools/perf/util/metricgroup.h|  10 +++
>  tools/perf/util/parse-events.c   |  29 +++---
>  tools/perf/util/parse-events.h   |   5 ++--
>  tools/perf/util/parse-events.l   |   8 +++--
>  tools/perf/util/parse-events.y   |  41 --
>  tools/perf/util/perf_api_probe.c |   2 +-
>  tools/perf/util/record.c |   2 +-
>  tools/perf/util/stat-shadow.c|  67 
> ++
>  tools/perf/util/stat.h   |   3 ++
>  36 files changed, 527 insertions(+), 92 deletions(-)
>  create mode 100644 tools/perf/tests/parse-metric.c
>

Acked-by: Ian Rogers 

Re: [PATCH v3 0/4] Add support for SCD30 sensor

[Tomasz Duszynski]

On Tue, Jun 02, 2020 at 07:55:55PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
>  wrote:
> >
> > Following series adds support for Sensirion SCD30 sensor module capable of
> > measuring carbon dioxide, temperature and relative humidity. CO2 
> > measurements
> > base on NDIR principle while temperature and relative humidity are measured 
> > by
> > the on board SHT31. As for sensor communication, both I2C and serial 
> > interfaces
> > are supported.
>
> Btw, since we have relaxed 80 limit to 100, I recommend to reconsider
> some lines to be joined.
>

Heh, that particular change is becoming more viral that corona itself these 
days.

> --
> With Best Regards,
> Andy Shevchenko

Re: Subject: [PATCH v2] ASoC: soc-pcm: fix BE dai not hw_free and shutdown during mixer update

[Pierre-Louis Bossart]

On 5/29/20 5:12 AM, 朱灿灿 wrote:

FE state is SND_SOC_DPCM_STATE_PREPARE now, BE1 is
used by FE.

Later when new BE2 is added to FE by mixer update,
it will call dpcm_run_update_startup() to update
BE2's state, but unfortunately BE2 .prepare() meets
error, it will disconnect all non started BE.

This make BE1 dai skip .hw_free() and .shutdown(),
and the BE1 users will never decrease to zero.

Signed-off-by: zhucancan 
---
re-format patch content v2
---
  sound/soc/soc-pcm.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index 1f302de44052..df34422bd0dd 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2730,12 +2730,12 @@ static int dpcm_run_update_startup(struct 
snd_soc_pcm_runtime *fe, int stream)
  close:
dpcm_be_dai_shutdown(fe, stream);
  disconnect:
-   /* disconnect any non started BEs */
+   /* disconnect any closed BEs */
spin_lock_irqsave(>card->dpcm_lock, flags);
for_each_dpcm_be(fe, stream, dpcm) {
struct snd_soc_pcm_runtime *be = dpcm->be;
-   if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
-   dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
+   if (be->dpcm[stream].state == SND_SOC_DPCM_STATE_CLOSE)
+   dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
}
spin_unlock_irqrestore(>card->dpcm_lock, flags);


This change is quite hard to review, this error handling can be called 
from multiple places.


I *think* it's correct because in all cases where the 
disconnect/close/hw_free labels are reached, the non-shared BEs either 
remain or are put in the DPCM_STATE_CLOSE state before doing this test.


Reviewed-by: Pierre-Louis Bossart 

It really wouldn't hurt though if others double-checked this change...

Re: [PATCH 2/2] lib/Kconfig.debug: Fix typo in the help text of CONFIG_PANIC_TIMEOUT

[Kees Cook]

On Tue, Jun 02, 2020 at 09:09:18PM +0800, Tiezhu Yang wrote:
> There exists duplicated "the" in the help text of CONFIG_PANIC_TIMEOUT,
> remove it.
> 
> Signed-off-by: Tiezhu Yang 

Thanks for catching that!

Reviewed-by: Kees Cook 

-- 
Kees Cook

[PATCH] s390: fix syscall_get_error for compat processes

[Dmitry V. Levin]

If both the tracer and the tracee are compat processes, and gprs[2]
is assigned a value by __poke_user_compat, then the higher 32 bits
of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and
syscall_get_error() always returns 0.

Fix the implementation by sign-extending the value for compat processes
the same way as x86 implementation does.

The bug was exposed to user space by commit 201766a20e30f ("ptrace: add
PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite.

This change fixes strace syscall tampering on s390.

Fixes: 753c4dd6a2fa2 ("[S390] ptrace changes")
Cc: Elvira Khabirova 
Cc: sta...@vger.kernel.org # v2.6.28+
Signed-off-by: Dmitry V. Levin 
---
 arch/s390/include/asm/syscall.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/syscall.h b/arch/s390/include/asm/syscall.h
index f073292e9fdb..c07633824715 100644
--- a/arch/s390/include/asm/syscall.h
+++ b/arch/s390/include/asm/syscall.h
@@ -33,7 +33,17 @@ static inline void syscall_rollback(struct task_struct *task,
 static inline long syscall_get_error(struct task_struct *task,
 struct pt_regs *regs)
 {
-   return IS_ERR_VALUE(regs->gprs[2]) ? regs->gprs[2] : 0;
+   unsigned long error = regs->gprs[2];
+#ifdef CONFIG_COMPAT
+   if (test_tsk_thread_flag(task, TIF_31BIT)) {
+   /*
+* Sign-extend the value so (int)-EFOO becomes (long)-EFOO
+* and will match correctly in comparisons.
+*/
+   error = (long) (int) error;
+   }
+#endif
+   return IS_ERR_VALUE(error) ? error : 0;
 }
 
 static inline long syscall_get_return_value(struct task_struct *task,
-- 
ldv

Re: [PATCH 1/2] kernel/panic.c: Make oops_may_print() return bool

[Kees Cook]

On Tue, Jun 02, 2020 at 09:09:17PM +0800, Tiezhu Yang wrote:
> The return value of oops_may_print() is true or false, so change its type
> to reflect that.
> 
> Signed-off-by: Tiezhu Yang 

Sure, that looks fine. :)

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH] net: genetlink: Fix memleak in genl_family_rcv_msg_dumpit()

[Cong Wang]

On Mon, Jun 1, 2020 at 11:47 PM YueHaibing  wrote:
> @@ -630,6 +625,9 @@ static int genl_family_rcv_msg_dumpit(const struct 
> genl_family *family,
> err = __netlink_dump_start(net->genl_sock, skb, nlh, );
> }
>
> +   genl_family_rcv_msg_attrs_free(info->family, info->attrs, true);
> +   genl_dumpit_info_free(info);
> +
> return err;
>  }

I do not think you can just move it after __netlink_dump_start(),
because cb->done() can be called, for example, in netlink_sock_destruct()
too.

[PATCH 1/6] arm64/vdso: use the fault callback to map vvar pages

[Andrei Vagin]

This is required to support time namespaces where a time namespace data
page is different for each namespace.

Reviewed-by: Vincenzo Frascino 
Signed-off-by: Andrei Vagin 
---
 arch/arm64/kernel/vdso.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 033a48f30dbb..031ee1a8d4a8 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -114,28 +114,32 @@ static int __vdso_init(enum arch_vdso_type arch_index)
PAGE_SHIFT;
 
/* Allocate the vDSO pagelist, plus a page for the data. */
-   vdso_pagelist = kcalloc(vdso_lookup[arch_index].vdso_pages + 1,
+   vdso_pagelist = kcalloc(vdso_lookup[arch_index].vdso_pages,
sizeof(struct page *),
GFP_KERNEL);
if (vdso_pagelist == NULL)
return -ENOMEM;
 
-   /* Grab the vDSO data page. */
-   vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
-
-
/* Grab the vDSO code pages. */
pfn = sym_to_pfn(vdso_lookup[arch_index].vdso_code_start);
 
for (i = 0; i < vdso_lookup[arch_index].vdso_pages; i++)
-   vdso_pagelist[i + 1] = pfn_to_page(pfn + i);
+   vdso_pagelist[i] = pfn_to_page(pfn + i);
 
-   vdso_lookup[arch_index].dm->pages = _pagelist[0];
-   vdso_lookup[arch_index].cm->pages = _pagelist[1];
+   vdso_lookup[arch_index].cm->pages = vdso_pagelist;
 
return 0;
 }
 
+static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
+struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+   if (vmf->pgoff == 0)
+   return vmf_insert_pfn(vma, vmf->address,
+   sym_to_pfn(vdso_data));
+   return VM_FAULT_SIGBUS;
+}
+
 static int __setup_additional_pages(enum arch_vdso_type arch_index,
struct mm_struct *mm,
struct linux_binprm *bprm,
@@ -155,7 +159,7 @@ static int __setup_additional_pages(enum arch_vdso_type 
arch_index,
}
 
ret = _install_special_mapping(mm, vdso_base, PAGE_SIZE,
-  VM_READ|VM_MAYREAD,
+  VM_READ|VM_MAYREAD|VM_PFNMAP,
   vdso_lookup[arch_index].dm);
if (IS_ERR(ret))
goto up_fail;
@@ -215,6 +219,7 @@ static struct vm_special_mapping aarch32_vdso_spec[C_PAGES] 
= {
 #ifdef CONFIG_COMPAT_VDSO
{
.name = "[vvar]",
+   .fault = vvar_fault,
},
{
.name = "[vdso]",
@@ -385,6 +390,7 @@ static int vdso_mremap(const struct vm_special_mapping *sm,
 static struct vm_special_mapping vdso_spec[A_PAGES] __ro_after_init = {
{
.name   = "[vvar]",
+   .fault = vvar_fault,
},
{
.name   = "[vdso]",
-- 
2.24.1

Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)

[Kees Cook]

On Mon, Jun 01, 2020 at 07:48:04PM -0700, Matt Turner wrote:
> I bisected a regression on alpha to f2f84b05e02b (bug: consolidate
> warn_slowpath_fmt() usage) which looks totally innocuous.
> 
> Reverting it on master confirms that it somehow is the trigger. At or a
> little after starting userspace, I'll see an oops like this:
> 
> Unable to handle kernel paging request at virtual address 
> CPU 0
> kworker/u2:5(98): Oops -1
> pc = [<>]  ra = [<>]  ps = Not tainted
> pc is at 0x0

 so, the instruction pointer is NULL. The only way I can imagine
that happening would be from this line:

worker->current_func(work);

> ra is at 0x0
> v0 = 0007  t0 = 0001  t1 = 0001
> t2 =   t3 = fc00bfe68780  t4 = 0001
> t5 = fc00bf8cc780  t6 = 026f8000  t7 = fc00bfe7
> s0 = fc000250d310  s1 = fc000250d310  s2 = fc000250d310
> s3 = fc000250ca40  s4 = fc000250caa0  s5 = 
> s6 = fc000250ca40
> a0 = fc00024f0488  a1 = fc00bfe73d98  a2 = fc00bfe68800
> a3 = fc00bf881400  a4 = 0001  a5 = 0002
> t8 =   t9 =   t10= 01321800
> t11= ba4e  pv = fc000189ca00  at = 
> gp = fc000253e430  sp = 43a83c2e
> Disabling lock debugging due to kernel taint
> Trace:
> [] process_one_work+0x25c/0x5a0

Can you verify where this ^^   is?

> [] worker_thread+0x5c/0x7d0
> [] kthread+0x188/0x1f0
> [] ret_from_kernel_thread+0x18/0x20
> [] kthread+0x0/0x1f0
> [] worker_thread+0x0/0x7d0
> 
> Code:
>  
>  
>  00063301
>  12e2
>  
>  0005ffde
> 
> It seems to cause a hard lock on an SMP system, but not on a system with
> a single CPU. Similarly, if I boot the SMP system (2 CPUs) with
> maxcpus=1 the oops doesn't happen. Until I tested on a non-SMP system
> today I suspected that it was unaffected, but I saw the oops there too.
> With the revert applied, I don't see a warning or an oops.
> 
> Any clues how this patch could have triggered the oops?

I cannot begin to imagine. :P Compared to other things I've seen like
this in the past maybe it's some kind of effect from the code size
changing the location/alignment or timing of something else?

Various questions ranging in degrees of sanity:

Does alpha use work queues for WARN?

Which work queue is getting a NULL function? (And then things like "if
WARN was much slower or much faster, is there a race to something
setting itself to NULL?")

Was there a WARN before the above Oops?

Does WARN have side-effects on alpha?

Does __WARN_printf() do something bad that warn_slowpath_null() doesn't?

Does making incremental changes narrow anything down? (e.g. instead of
this revert, remove the __warn() call in warn_slowpath_fmt() that was
added? (I mean, that'll be quite broken for WARN, but will it not oops?)

Does alpha have hardware breakpoints? When I had to track down a
corruption in the io scheduler, I ended up setting breakpoints on the
thing that went crazy (in this case, I assume the work queue function
pointer) to figure out what touched it.

... I can't think of anything else.

-Kees

> 
> Here's the revert, with a trivial conflict resolved, that I've used in
> testing:
> 
> From fdbdd0f606f0f412ee06c1152e33a22ca17102bc Mon Sep 17 00:00:00 2001
> From: Matt Turner 
> Date: Sun, 24 May 2020 20:46:00 -0700
> Subject: [PATCH] Revert "bug: consolidate warn_slowpath_fmt() usage"
> 
> This reverts commit f2f84b05e02b7710a201f0017b3272ad7ef703d1.
> ---
>  include/asm-generic/bug.h |  3 ++-
>  kernel/panic.c| 15 +++
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 384b5c835ced..a4a311d4b4b0 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -82,7 +82,8 @@ struct bug_entry {
>  extern __printf(4, 5)
>  void warn_slowpath_fmt(const char *file, const int line, unsigned taint,
>  const char *fmt, ...);
> -#define __WARN() __WARN_printf(TAINT_WARN, NULL)
> +extern void warn_slowpath_null(const char *file, const int line);
> +#define __WARN() warn_slowpath_null(__FILE__, __LINE__)
>  #define __WARN_printf(taint, arg...) \
>   warn_slowpath_fmt(__FILE__, __LINE__, taint, arg)
>  #else
> diff --git a/kernel/panic.c b/kernel/panic.c
> index b69ee9e76cb2..c8ed8046b484 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -603,20 +603,19 @@ void warn_slowpath_fmt(const char *file, int line, 
> unsigned taint,
>  {
>   struct warn_args args;
> - pr_warn(CUT_HERE);
> -
> - if (!fmt) {
> - __warn(file, line, __builtin_return_address(0), taint,
> -NULL, NULL);
> - return;
> - }
> -
>   args.fmt 

[PATCH RESEND v3 0/6] arm64: add the time namespace support

[Andrei Vagin]

Allocate the time namespace page among VVAR pages and add the logic
to handle faults on VVAR properly.

If a task belongs to a time namespace then the VVAR page which contains
the system wide VDSO data is replaced with a namespace specific page
which has the same layout as the VVAR page. That page has vdso_data->seq
set to 1 to enforce the slow path and vdso_data->clock_mode set to
VCLOCK_TIMENS to enforce the time namespace handling path.

The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
update of the VDSO data is in progress, is not really affecting regular
tasks which are not part of a time namespace as the task is spin waiting
for the update to finish and vdso_data->seq to become even again.

If a time namespace task hits that code path, it invokes the corresponding
time getter function which retrieves the real VVAR page, reads host time
and then adds the offset for the requested clock which is stored in the
special VVAR page.

v2: Code cleanups suggested by Vincenzo.
v3: add a comment in __arch_get_timens_vdso_data.

Reviewed-by: Vincenzo Frascino 
Cc: Thomas Gleixner 
Cc: Dmitry Safonov 

v3 on github (if someone prefers `git pull` to `git am`):
https://github.com/avagin/linux-task-diag/tree/arm64/timens-v3

Andrei Vagin (6):
  arm64/vdso: use the fault callback to map vvar pages
  arm64/vdso: Zap vvar pages when switching to a time namespace
  arm64/vdso: Add time napespace page
  arm64/vdso: Handle faults on timens page
  arm64/vdso: Restrict splitting VVAR VMA
  arm64: enable time namespace support

 arch/arm64/Kconfig|   1 +
 .../include/asm/vdso/compat_gettimeofday.h|  11 ++
 arch/arm64/include/asm/vdso/gettimeofday.h|   8 ++
 arch/arm64/kernel/vdso.c  | 134 --
 arch/arm64/kernel/vdso/vdso.lds.S |   3 +-
 arch/arm64/kernel/vdso32/vdso.lds.S   |   3 +-
 include/vdso/datapage.h   |   1 +
 7 files changed, 147 insertions(+), 14 deletions(-)

-- 
2.24.1

[PATCH 6/6] arm64: enable time namespace support

[Andrei Vagin]

CONFIG_TIME_NS is dependes on GENERIC_VDSO_TIME_NS.

Reviewed-by: Vincenzo Frascino 
Signed-off-by: Andrei Vagin 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5d513f461957..27d7e4ed1c93 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -111,6 +111,7 @@ config ARM64
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
select GENERIC_GETTIMEOFDAY
+   select GENERIC_VDSO_TIME_NS
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_PCI
-- 
2.24.1

[PATCH 4/6] arm64/vdso: Handle faults on timens page

[Andrei Vagin]

If a task belongs to a time namespace then the VVAR page which contains
the system wide VDSO data is replaced with a namespace specific page
which has the same layout as the VVAR page.

Reviewed-by: Vincenzo Frascino 
Signed-off-by: Andrei Vagin 
---
 arch/arm64/kernel/vdso.c | 57 +---
 1 file changed, 53 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 1fa6f9362e56..f3baecd8edfb 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -175,15 +176,63 @@ int vdso_join_timens(struct task_struct *task, struct 
time_namespace *ns)
up_write(>mmap_sem);
return 0;
 }
+
+static struct page *find_timens_vvar_page(struct vm_area_struct *vma)
+{
+   if (likely(vma->vm_mm == current->mm))
+   return current->nsproxy->time_ns->vvar_page;
+
+   /*
+* VM_PFNMAP | VM_IO protect .fault() handler from being called
+* through interfaces like /proc/$pid/mem or
+* process_vm_{readv,writev}() as long as there's no .access()
+* in special_mapping_vmops().
+* For more details check_vma_flags() and __access_remote_vm()
+*/
+
+   WARN(1, "vvar_page accessed remotely");
+
+   return NULL;
+}
+#else
+static inline struct page *find_timens_vvar_page(struct vm_area_struct *vma)
+{
+   return NULL;
+}
 #endif
 
 static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
 struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-   if (vmf->pgoff == 0)
-   return vmf_insert_pfn(vma, vmf->address,
-   sym_to_pfn(vdso_data));
-   return VM_FAULT_SIGBUS;
+   struct page *timens_page = find_timens_vvar_page(vma);
+   unsigned long pfn;
+
+   switch (vmf->pgoff) {
+   case VVAR_DATA_PAGE_OFFSET:
+   if (timens_page)
+   pfn = page_to_pfn(timens_page);
+   else
+   pfn = sym_to_pfn(vdso_data);
+   break;
+#ifdef CONFIG_TIME_NS
+   case VVAR_TIMENS_PAGE_OFFSET:
+   /*
+* If a task belongs to a time namespace then a namespace
+* specific VVAR is mapped with the VVAR_DATA_PAGE_OFFSET and
+* the real VVAR page is mapped with the VVAR_TIMENS_PAGE_OFFSET
+* offset.
+* See also the comment near timens_setup_vdso_data().
+*/
+   if (!timens_page)
+   return VM_FAULT_SIGBUS;
+   pfn = sym_to_pfn(vdso_data);
+   break;
+#endif /* CONFIG_TIME_NS */
+   default:
+   return VM_FAULT_SIGBUS;
+   }
+
+   return vmf_insert_pfn(vma, vmf->address, pfn);
 }
 
 static int __setup_additional_pages(enum arch_vdso_type arch_index,
-- 
2.24.1