Re: [tip:x86/boot] ACPI/NUMA: Add warning message if the padding size for KASLR is not enough

[Masayoshi Mizuma]

On Wed, Oct 03, 2018 at 02:48:14PM +0200, Borislav Petkov wrote:
> On Wed, Oct 03, 2018 at 02:34:02PM +0200, Peter Zijlstra wrote:
> > 
> > Subject: ACPI/NUMA: Fix KASLR build error
> > 
> > There is no point in trying to compile KASLR specific code when there is
> > no KASLR.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > ---
> 
> Yeah, Peter and I were just talking on IRC and he gave me a much better
> idea how to fix this, see below. I'll run this through the *config builder and
> commit it if no complaints.

Hi Boris and Peter,

Thank you for the fix. It is great!

- Masa

> 
> ---
> From: "Peter Zijlstra (Intel)" 
> Date: Wed, 3 Oct 2018 14:41:27 +0200
> Subject: [PATCH] ACPI/NUMA: Fix KASLR build error
> 
> There is no point in trying to compile KASLR specific code when there is
> no KASLR.
> 
>  [ bp: Move the whole crap into kaslr.c and make
>rand_mem_physical_padding static. ]
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Signed-off-by: Borislav Petkov 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Link: 
> http://lkml.kernel.org/r/20181003123402.ga15...@hirez.programming.kicks-ass.net
> ---
>  arch/x86/include/asm/kaslr.h |  2 ++
>  arch/x86/include/asm/setup.h |  2 --
>  arch/x86/mm/kaslr.c  | 18 +-
>  drivers/acpi/numa.c  | 15 +++
>  4 files changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
> index db7ba2feb947..95ef3fc01d12 100644
> --- a/arch/x86/include/asm/kaslr.h
> +++ b/arch/x86/include/asm/kaslr.h
> @@ -6,8 +6,10 @@ unsigned long kaslr_get_random_long(const char *purpose);
>  
>  #ifdef CONFIG_RANDOMIZE_MEMORY
>  void kernel_randomize_memory(void);
> +void kaslr_check_padding(void);
>  #else
>  static inline void kernel_randomize_memory(void) { }
> +static inline void kaslr_check_padding(void) { }
>  #endif /* CONFIG_RANDOMIZE_MEMORY */
>  
>  #endif
> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
> index 65a5bf8f6aba..ae13bc974416 100644
> --- a/arch/x86/include/asm/setup.h
> +++ b/arch/x86/include/asm/setup.h
> @@ -80,8 +80,6 @@ static inline unsigned long kaslr_offset(void)
>   return (unsigned long)&_text - __START_KERNEL;
>  }
>  
> -extern int rand_mem_physical_padding;
> -
>  /*
>   * Do NOT EVER look at the BIOS memory size location.
>   * It does not work on many machines.
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 00cf4cae38f5..d58b7da0d55c 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -40,7 +40,7 @@
>   */
>  static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
>  
> -int __initdata rand_mem_physical_padding = 
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> +static int __initdata rand_mem_physical_padding = 
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
>  /*
>   * Memory regions randomized by KASLR (except modules that use a separate 
> logic
>   * earlier during boot). The list is ordered based on virtual addresses. This
> @@ -70,6 +70,22 @@ static inline bool kaslr_memory_enabled(void)
>   return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
>  }
>  
> +/*
> + * Check the padding size for KASLR is enough.
> + */
> +void kaslr_check_padding(void)
> +{
> + u64 max_possible_phys, max_actual_phys, threshold;
> +
> + max_actual_phys = roundup(PFN_PHYS(max_pfn), 1ULL << 40);
> + max_possible_phys = roundup(PFN_PHYS(max_possible_pfn), 1ULL << 40);
> + threshold = max_actual_phys + ((u64)rand_mem_physical_padding << 40);
> +
> + if (max_possible_phys > threshold)
> + pr_warn("Set 'rand_mem_physical_padding=%llu' to avoid memory 
> hotadd failure.\n",
> + (max_possible_phys - max_actual_phys) >> 40);
> +}
> +
>  static int __init rand_mem_physical_padding_setup(char *str)
>  {
>   int max_padding = (1 << (MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index 3d69834c692f..4408e37600ef 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -32,7 +32,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  static nodemask_t nodes_found_map = NODE_MASK_NONE;
>  
> @@ -436,7 +436,6 @@ acpi_table_parse_srat(enum acpi_srat_type id,
>  int __init acpi_numa_init(void)
>  {
>   int cnt = 0;
> - u64 max_possible_phys, max_actual_phys, threshold;
>  
>   if (acpi_disabled)
>   return -EINVAL;
> @@ -466,17 +465,9 @@ int __init acpi_numa_init(void)
>   cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
>   acpi_parse_memory_affinity, 0);
>  
> - /* check the padding size for KASLR is enough. */
> - if (parsed_numa_memblks && kaslr_enabled()) {
> - max_actual_phys = roundup(PFN_PHYS(max_pfn), 1ULL << 
> 40);
> - max_possible_phys = roundup(PFN_PHYS(max_possible_pfn), 
> 1ULL << 40);
> - threshold 

Re: [PATCH v5 04/21] dt-bindings: Add doc for the Ingenic TCU drivers

[Daniel Lezcano]

On 03/10/2018 14:51, Paul Cercueil wrote:
> 
> Le 3 oct. 2018 2:47 PM, Daniel Lezcano  a
> écrit :
>> 
>> On 03/10/2018 12:32, Paul Cercueil wrote:
>>> 
>>> Le 1 oct. 2018 10:48, Daniel Lezcano 
>>> a écrit :
 
 On 31/07/2018 00:01, Paul Cercueil wrote:
 
 [ ... ]
 
>>> +- ingenic,timer-channel: Specifies the TCU channel that
>>>  should be used as +  system timer. If not provided, the
>>> TCU channel 0 is used for the system timer. + +- 
>>> ingenic,clocksource-channel: Specifies the TCU channel
>>> that should be used +  as clocksource and sched_clock. It
>>> must be a different channel than the one +  used as
>>> system timer. If not provided, neither a clocksource nor
>>> a +  sched_clock is instantiated.
>> 
>> clocksource and sched_clock are Linux specific and don't
>> belong in DT. You should define properties of the hardware
>> or use existing properties like interrupts or clocks to
>> figure out which channel to use. For example, if some
>> channels don't have an interrupt, then use them for
>> clocksource and not a clockevent. Or you could have timers
>> that run in low-power modes or not. If all the channels are
>> identical, then it shouldn't matter which ones the OS
>> picks.
 
 It can't work in this case because the pmw and the timer driver
 are not communicating and the first one can stole a channel to
 the last one.
>>> 
>>> In that particular case the timer driver will always request its
>>>  channels first; with no timer set the system hangs before 
>>> subsys_initcall, and the PWM driver is a subnode of the timer
>>> node, so is probed only after the timer probed.
>>> 
> We already talked about that. All the TCU channels can be
> used for PWM. The problem is I cannot know from the driver's
> scope which channels will be free and which channels will be
> requested for PWM. You suggested that I parse the devicetree
> for clients, and I did that in the V3/V4 patchset. But it
> only works for clients requesting through devicetree, not
> from platform code or even sysfs.
> 
> One thing I can try is to dynamically change the channels the
>  system timer and clocksource are using when the current ones
> are requested for PWM. But that sounds hardcore...
 
 Yes, it is :/
 
 Sorry for letting you wasting time and effort to write an
 overkill code not suitable for upstream.
 
 A very gross thought, wouldn't be possible to "register" a
 channel from the timer driver code in a shared data area (but
 well self-encapsulated) and the pwm code will check such
 channel isn't in use ?
>>> 
>>> Probably, but it's the contrary I need to do. The timer driver
>>> code can use any channel, and probes first. The PWM driver code
>>> must use specific channels, and probes last. So either the timer
>>> driver knows what channels it can't use, thanks to a device
>>> property, or it adapts itself when a channel in use is requested
>>> for PWM, which is what I tried in v7.
>> 
>> When you say "must use specific channels", where is coming this 
>> information ?
> 
> If the backlight for the LCD is connected to the pin that corresponds
> to PWM1, then you must use the TCU channel 1. It's that simple.

Is it a runtime detection or is it hardcoded somewhere ?

(just trying to understand the whole picture)

>>> I think we could find a way to use a devicetree property that
>>> doesn't trigger Rob. That would still be the easiest and cleanest
>>> solution.
>>> 
>>> Maybe "ingenic,reserved-channels-mask", which would contain a
>>> mask of channels that can only be used by the timer driver. And
>>> what the timer driver does with these channels, would be specific
>>> to the implementation and would not appear in the bindings. I
>>> hope Rob can work with that.
>>> 
>>> -Paul


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] lib/seq_buf: auto-correct some typos

[Sergey Senozhatsky]

Correct vnprintf() typo + several aspell corrections.

Signed-off-by: Sergey Senozhatsky 
---
 lib/seq_buf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 11f2ae0f9099..738b4e92780c 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
@@ -50,7 +50,7 @@ int seq_buf_print_seq(struct seq_file *m, struct seq_buf *s)
  * @fmt: printf format string
  * @args: va_list of arguments from a printf() type function
  *
- * Writes a vnprintf() format into the sequencce buffer.
+ * Writes a vsprintf() format into the sequence buffer.
  *
  * Returns zero on success, -1 on overflow.
  */
@@ -175,7 +175,7 @@ int seq_buf_putc(struct seq_buf *s, unsigned char c)
 }
 
 /**
- * seq_buf_putmem - write raw data into the sequenc buffer
+ * seq_buf_putmem - write raw data into the sequence buffer
  * @s: seq_buf descriptor
  * @mem: The raw memory to copy into the buffer
  * @len: The length of the raw memory to copy (in bytes)
@@ -280,7 +280,7 @@ int seq_buf_path(struct seq_buf *s, const struct path 
*path, const char *esc)
 }
 
 /**
- * seq_buf_to_user - copy the squence buffer to user space
+ * seq_buf_to_user - copy the sequence buffer to user space
  * @s: seq_buf descriptor
  * @ubuf: The userspace memory location to copy to
  * @cnt: The amount to copy
-- 
2.19.0

Re: [PATCH v2] perf record: encode -k clockid frequency into Perf trace

[Jiri Olsa]

On Wed, Oct 03, 2018 at 10:01:56AM +0300, Alexey Budankov wrote:
> 
> Store -k clockid frequency into Perf trace to enable timestamps 
> derived metrics conversion into wall clock time on reporting stage.
> 
> Below is the example of perf report output:
> 
> tools/perf/perf record -k raw -- ../../matrix/linux/matrix.gcc
> ...
> [ perf record: Captured and wrote 31.222 MB perf.data (818054 samples) ]
> 
> tools/perf/perf report --header
> # 
> ...
> # event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 
> 4000, sample_type = IP|TID|TIME|PERIOD, disabled = 1, inherit = 1, mmap = 1, 
> comm = 1, freq = 1, enable_on_exec = 1, task = 1, precise_ip = 3, 
> sample_id_all = 1, exclude_guest = 1, mmap2 = 1, comm_exec = 1, use_clockid = 
> 1, clockid = 4
> ...
> # clockid frequency: 1000 MHz
> ...
> # 
> 
> Signed-off-by: Alexey Budankov 
> ---
> Changes in v2:
>  - renamed clockid_freq to clockid_res_ns and get_clockid_freq() to 
> get_clockid_res()
>  - avoided redundant define of NSEC_IN_SEC, reused linux/time64.h:NSEC_PER_SEC
>  - moved MHz conversion into print_clockid() and shortened write_clockid()
> ---
>  tools/perf/builtin-record.c | 21 +++--
>  tools/perf/perf.h   |  1 +
>  tools/perf/util/env.h   |  1 +
>  tools/perf/util/header.c| 27 +++
>  tools/perf/util/header.h|  1 +
>  5 files changed, 49 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 0980dfe3396b..127dc7432394 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -592,6 +592,11 @@ static void record__init_features(struct record *rec)
>   if (!rec->opts.full_auxtrace)
>   perf_header__clear_feat(>header, HEADER_AUXTRACE);
>  
> + if (rec->opts.use_clockid && rec->opts.clockid_res_ns)
> + session->header.env.clockid_res_ns = rec->opts.clockid_res_ns;
> + else
> + perf_header__clear_feat(>header, HEADER_CLOCKID);
> +

could you please keep only bits setting in record__init_features
and move the header.env.clockid_res_ns assignment out of it?

sry for not catching this in the first version

>   perf_header__clear_feat(>header, HEADER_STAT);
>  }
>  
> @@ -1337,6 +1342,17 @@ static const struct clockid_map clockids[] = {
>   CLOCKID_END,
>  };
>  
> +static int get_clockid_res(clockid_t clk_id, size_t *res_ns)
> +{
> + struct timespec res;
> +
> + *res_ns = 0;
> + if (!clock_getres(clk_id, ))
> + *res_ns = res.tv_nsec + res.tv_sec * NSEC_PER_SEC;

hum, if this one fails (which I guess is unlikely) we should tell
and probably even quit

thanks,
jirka

Re: [PATCH 2/2] mm, numa: Migrate pages to local nodes quicker early in the lifetime of a task

[Srikar Dronamraju]

* Mel Gorman  [2018-10-03 14:21:55]:

> On Wed, Oct 03, 2018 at 06:37:41PM +0530, Srikar Dronamraju wrote:
> > * Srikar Dronamraju  [2018-10-02 23:00:05]:
> > 
> 

> That's unfortunate.
> 
> How much does this workload normally vary between runs? If you monitor
> migrations over time, is there an increase spike in migration early in
> the lifetime of the workload?
> 

The run to run variation has always been less than 1%.
I haven't monitored migrations over time. Will try to include it my next
run. Its a shared setup so I may not get the box immediately.


-- 
Thanks and Regards
Srikar Dronamraju

Re: [PATCH] perf tools: Allocate id array in perf_event__synthesize_event_update_cpus

[John Garry]

On 03/10/2018 12:36, Jiri Olsa wrote:

On Tue, Oct 02, 2018 at 01:16:21PM +0200, Jiri Olsa wrote:

On Tue, Oct 02, 2018 at 11:41:36AM +0100, John Garry wrote:

SNIP




---
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 1ec1d9bc2d63..fb2a0dab3978 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -29,6 +29,7 @@
 #include "symbol.h"
 #include "debug.h"
 #include "cpumap.h"
+#include "thread_map.h"
 #include "pmu.h"
 #include "vdso.h"
 #include "strbuf.h"
@@ -3579,6 +3580,11 @@ perf_event__synthesize_event_update_cpus(struct 
perf_tool *tool,
if (!evsel->own_cpus)
return 0;

+   if (!evsel->id ||


for my test, evsel->id is NULL


+   perf_evsel__alloc_id(evsel, cpu_map__nr(evsel->cpus),
+thread_map__nr(evsel->threads)))


and then this function is not called as we return immediately. So did you
really want this:

if (!evsel->id && perf_evsel__alloc_id(...))
return -ENOMEM;


ugh.. yes ;-) thanks for the fix.. I'll double
check the logic and post the patch this week


actualy, we also need to populate those ids ;-)
so calling perf_evsel__store_ids instead..
attaching the full patch

thanks,
jirka



Hi Jirka,

Can you please double-check your new patch, as I'm getting this now:
root@localhost:~# ./perf_debug record -e armv8_pmuv3_0/br_mis_pred/ sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (6 samples) ]
root@localhost:~# ./perf_debug report
0xe8 [0]: failed to process type: 461
Error:
failed to process sample
# To display the perf.data header info, please use 
--header/--header-only option

#
root@localhost:~#

Thanks,
John



---
John reported crash when recording on an event under
pmu with cpumask defined:

  root@localhost:~# ./perf_debug_ record -e armv8_pmuv3_0/br_mis_pred/ sleep 1
  perf: Segmentation fault
  Obtained 9 stack frames.
  ./perf_debug_() [0x4c5ef8]
  [0x82ba267c]
  ./perf_debug_() [0x4bc5a8]
  ./perf_debug_() [0x419550]
  ./perf_debug_() [0x41a928]
  ./perf_debug_() [0x472f58]
  ./perf_debug_() [0x473210]
  ./perf_debug_() [0x4070f4]
  /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe0) [0x8294c8a0]
  Segmentation fault (core dumped)

We synthesize an update event that needs to touch the evsel
id array, which is not defined at that time. Fixing this
by allocating the array and getting IDs before it's used.

Reported-by: John Garry 
Link: http://lkml.kernel.org/n/tip-8x4n7o34yheigoxm1jibf...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/header.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 1ec1d9bc2d63..14ca27f79d4a 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -29,6 +29,7 @@
 #include "symbol.h"
 #include "debug.h"
 #include "cpumap.h"
+#include "thread_map.h"
 #include "pmu.h"
 #include "vdso.h"
 #include "strbuf.h"
@@ -3579,6 +3580,9 @@ perf_event__synthesize_event_update_cpus(struct perf_tool 
*tool,
if (!evsel->own_cpus)
return 0;

+   if (!evsel->id && perf_evsel__store_ids(evsel, evsel->evlist))
+   return -ENOMEM;
+
ev = cpu_map_data__alloc(evsel->own_cpus, , , );
if (!ev)
return -ENOMEM;

Re: [PATCH] perf/x86/intel: Add counter freezing quirk for Goldmont

[Andi Kleen]

> There is another variant of model/stepping micro code verification code in
> intel_snb_pebs_broken(). Can we please make this table based and use a
> common function? That's certainly not the last quirk we're going to have.

I have a patch to add a table driven microcode matcher for another fix.
Will post shortly.

-Andi

Re: [GIT PULL] parisc fixes for kernel v4.19

[Helge Deller]

On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
>> Hi Greg,
>>
>> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
>>> On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
 please pull a last set of fixes for the parisc architecture for kernel 
 4.19 from:

   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
 parisc-4.19-3

 The major change is for parisc64 to use a 64-bit suseconds_t type to
 match what glibc expects for 64-bit userspace. It's an ABI change, but
 since we don't have a 64-bit userspace on parisc yet, it won't introduce
 a breakage.
>>>
>>> Isn't it a bit "late" in the release cycle for such a change?  Why not
>>> do this on the -rc1 release?
>>
>> I've tagged it for stable release.
>> So, it can go in now, or just wait until -rc1 and go in later.
> 
> Why is a major API change a viable stable change?

Of course it's not.
Esp. not if an API has been used already.
IMHO, this case is really different though... 

> What bugfix does it provide?

It fixes that code in stable kernels which would return wrong
time values *if* someone would create a libc for 64-bit parisc
and would run it with those "stable" kernels.
Fixing it now has no side-effects, the change is a trivial
2-line-removal patch, would bring the code in sync with
newer kernel source code, and it really fixes existing code. 

I still believe that this justifies for a backport.

Nevertheless, if you really disagree, I'm fine dropping the 
backport to stable and will only push it in the next
merge window for v4.20.
 
 Other than that we simply drop unused code and outdated gcc version
 checks.
>>>
>>> Why are those needed now?
>>
>> The patch in there which is by me changes one line simply cleans up a patch 
>> which
>> went in during the 4.19 merge cycle. So it would be nice to have it
>> added now before v4.19 gets released.
>> The other two patches are trivial and just remove dead code.
>> I rate them all as non-critical, but nice-to-have-in-v4.19. 
>>
>> If you disagree I'm absolutely fine to wait with all of them 
>> for the next merge window.
> 
> Normally I only let "bugfixes" into my trees at this point in time.
> cleanups always wait for the next -rc1 merge window as that's what it is
> there for.  So I'd recommend waiting as well.

Ok.

Helge

[PATCH] zsmalloc: fix fall-through annotation

[Gustavo A. R. Silva]

Replace "fallthru" with a proper "fall through" annotation.

This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough

Signed-off-by: Gustavo A. R. Silva 
---
 mm/zsmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 58886d4..fd4b3a9 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -418,7 +418,7 @@ static void *zs_zpool_map(void *pool, unsigned long handle,
case ZPOOL_MM_WO:
zs_mm = ZS_MM_WO;
break;
-   case ZPOOL_MM_RW: /* fallthru */
+   case ZPOOL_MM_RW: /* fall through */
default:
zs_mm = ZS_MM_RW;
break;
-- 
2.7.4

Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/03/2018 03:52 PM, Suzuki K Poulose wrote:
> 
> 
> On 02/10/18 13:56, Anshuman Khandual wrote:
>>
>>
>> On 10/02/2018 06:08 PM, Suzuki K Poulose wrote:
>>> Hi Anshuman
>>>
>>> On 02/10/18 13:15, Anshuman Khandual wrote:
 Architectures like arm64 have PUD level HugeTLB pages for certain configs
 (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
 enabled for migration. It can be achieved through checking for PUD_SHIFT
 order based HugeTLB pages during migration.

 Signed-off-by: Anshuman Khandual 
 ---
    include/linux/hugetlb.h | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
 index 6b68e34..9c1b77f 100644
 --- a/include/linux/hugetlb.h
 +++ b/include/linux/hugetlb.h
 @@ -483,7 +483,8 @@ static inline bool hugepage_migration_supported(struct 
 hstate *h)
    {
    #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
    if ((huge_page_shift(h) == PMD_SHIFT) ||
 -    (huge_page_shift(h) == PGDIR_SHIFT))
 +    (huge_page_shift(h) == PUD_SHIFT) ||
>>>
>>>
 +    (huge_page_shift(h) == PGDIR_SHIFT))
>>>
>>> nit: Extra Tab ^^.
>>
>> The tab is in there when you apply this patch and all three checks are tab 
>> separated
>> in a newline.
> 
> Well, with the patch applied, at least I can see 2 tabs for the
> PUD_SHIFT check and 3 tabs for PGDIR_SHIFT check. Which seems
> inconsistent. Is it just me (my mail client) ?

I am sorry, you are right. Did not understand your point earlier. Yeah there is
increasing number of tabs for each new line with a conditional check. Is there
a problem with this style of indentation ? Though I will be happy to change.

linux-next: Tree for Oct 3

[Stephen Rothwell]

Hi all,

Changes since 20181002:

The vfs tree gained conflicts against the f2fs tree.

The net-next tree gained a conflict against the net tree.

The bpf-next tree gained a build failure so I used the version from
next-20181002.

The devicetree tree gained a conflict against the c6x tree.

The xarray tree gained a conflict against the f2fs tree.

Non-merge commits (relative to Linus' tree): 7748
 7535 files changed, 353115 insertions(+), 159195 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 290 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1d2ba7fee28b Merge tag 'fbdev-v4.19-rc7' of 
https://github.com/bzolnier/linux)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain 
not in Clang search path)
Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE 
in arch's Makefile)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (2a3f93459d68 arm64: KVM: Sanitize PSTATE.M 
when being set from userspace)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (7e0cf1c983b5 selftests/powerpc: Fix Makefiles for 
headers_install change)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (ff58e2df62ce nfp: avoid soft lockups under control message 
storm)
Merging bpf/master (b0584ea66d73 bpf: don't accept cgroup local storage with 
zero value size)
Merging ipsec/master (92d7c74b6f72 Merge branch 'for-upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging netfilter/master (1ad98e9d1bdf tcp/dccp: fix lockdep issue when SYN is 
backlogged)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue 
size)
Merging mac80211/master (848e616e66d4 cfg80211: fix wext-compat memory leak)
Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before 
releasing reference)
Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the 
audio-component completion timeout)
Merging sound-asoc-fixes/for-linus (6f450574b28f Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (17b57b1883c1 Linux 4.19-rc6)
Merging spi-fixes/for-linus (17b57b1883c1 Linux 4.19-rc6)
Merging pci-current/for-linus (95375f2ab296 PCI: mvebu: Fix PCI I/O mapping 
creation sequence)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (17b57b1883c1 Linux 4.19-rc6)
Merging usb.current/usb-linus (555df5820e73 usb: xhci-mtk: resume USB3 roothub 
first)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add 
Motorola Tetra MTP6550 id)
Merging 

Re: [RFC PATCH v2 1/9] leds: add TI LMU backlight driver

[Dan Murphy]

Hello

On 10/02/2018 05:07 PM, Pavel Machek wrote:
> Hi!
> 
>>> We have debated this over and over and now we have 3 different 
>>> implementations
>>> available we need to collude on which one we want to support.
>>>
>>> Jacek I defer to you and Pavel since you are both LED maintainers.
>>>
>>> I can support the dedicated LED drivers but I cannot support the TI LMU 
>>> only implementation.
>>
>> I uphold my previous opinion - please go ahead with moving the support
>> for non-MFD devices from MFD subsystem to the LED subsystem. And yes -
>> along with the bindings. This is semantically correct, and yet we don't
>> have mainline users.
>>
>> Pavel - you will have to engage more people for your crusade to prevail.
>> For now, to speed up the things, I am forced to ignore your NAK.
>> So NAK to your NAK. Sorry.
> 
> No need to be sorry :-).
> 
> Lets ignore the code for now, as code can be changed easily.
> 
> Bindings are not something you or I maintain, so we don't have final
> word there, and I have feeling this is not going to go past device
> tree maintainers. [AFAICT: you can move binding in Documentation/ to
> different place, that's not a problem; but creating a new binding when
> old one exists is.]
> 
> If you and Dan feel that is okay, you are welcome to try to get the
> patches past Rob, just please retain the NAK so that he remembers the
> discussion, and so that it is clear that I don't like the changes.
> 
> I believe smart thing to do is to try to do that before working
> further on the code, but of course, its all up to you :-).

I was looking for the review for the ti-lmu.txt binding on patchworks to see 
what
the comments were on the review or any explanation from reviewers to
why this implementation was done in the MFD.

Maybe there is some historical context that needs to be learned from here from
1.5 years ago.

I cannot seem to find any review posted in the patchworks archive.
I see reviews posted for the ti-lmu-backlight binding but none from
the ti-lmu.txt base binding.

Does anyone have a reference to the review?

If there is no review then I am wondering how this binding was accepted.
If there is no review and no current users then I would think that binding
 modification should be allowed.  But thats just my opinion.

Dan


> 
> Friends,
>   Pavel
> 


-- 
--
Dan Murphy

[PATCH] TC: Set DMA masks for devices

[Maciej W. Rozycki]

Fix a TURBOchannel support regression with commit 205e1b7f51e4 
("dma-mapping: warn when there is no coherent_dma_mask") that caused 
coherent DMA allocations to produce a warning such as:

defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
tc1: DEFTA at MMIO addr = 0x1e90, IRQ = 20, Hardware addr = 
08-00-2b-a3-a3-29
[ cut here ]
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 
dfx_dev_register+0x670/0x678
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
Stack : 8009ffc0 fec0  80647650
  806f5f80 
  0001 8065d4e8
9800031b6300 80563478 805685b0 
 805d6720 0204 80388df8
 0009 8053efd0 806657d0
 803177f8  806d
980003078000 98000307b9e0 1e90 80067940
 805d6720 0204 80388df8
805176c0 8004dc78  80067940
...
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---

This is because the TURBOchannel bus driver fails to set the coherent 
DMA mask for devices enumerated.

Set the regular and coherent DMA masks for TURBOchannel devices then, 
observing that the bus protocol supports a 34-bit (16GiB) DMA address 
space, by interpreting the value presented in the address cycle across 
the 32 `ad' lines as a 32-bit word rather than byte address[1].  The 
architectural size of the TURBOchannel DMA address space exceeds the 
maximum amount of RAM any actual TURBOchannel system in existence may 
have, hence both masks are the same.

This removes the warning shown above.

References:

[1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital 
Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17

Signed-off-by: Maciej W. Rozycki 
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Cc: sta...@vger.kernel.org # 4.16+
---
 drivers/tc/tc.c|8 +++-
 include/linux/tc.h |1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

linux-tc-dma-mask.patch
Index: linux-20180930-4maxp64/drivers/tc/tc.c
===
--- linux-20180930-4maxp64.orig/drivers/tc/tc.c
+++ linux-20180930-4maxp64/drivers/tc/tc.c
@@ -2,7 +2,7 @@
  * TURBOchannel bus services.
  *
  * Copyright (c) Harald Koerfgen, 1998
- * Copyright (c) 2001, 2003, 2005, 2006  Maciej W. Rozycki
+ * Copyright (c) 2001, 2003, 2005, 2006, 2018  Maciej W. Rozycki
  * Copyright (c) 2005  James Simmons
  *
  * This file is subject to the terms and conditions of the GNU
@@ -10,6 +10,7 @@
  * directory of this archive for more details.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -92,6 +93,11 @@ static void __init tc_bus_add_devices(st
tdev->dev.bus = _bus_type;
tdev->slot = slot;
 
+   /* TURBOchannel has 34-bit DMA addressing (16GiB space). */
+   tdev->dma_mask = DMA_BIT_MASK(34);
+   tdev->dev.dma_mask = >dma_mask;
+   tdev->dev.coherent_dma_mask = DMA_BIT_MASK(34);
+
for (i = 0; i < 8; i++) {
tdev->firmware[i] =
readb(module + offset + TC_FIRM_VER + 4 * i);
Index: linux-20180930-4maxp64/include/linux/tc.h
===
--- linux-20180930-4maxp64.orig/include/linux/tc.h
+++ linux-20180930-4maxp64/include/linux/tc.h
@@ -84,6 +84,7 @@ struct tc_dev {
   device. */
struct device   dev;/* Generic device interface. */
struct resource resource;   /* Address space of this device. */
+   u64 dma_mask;   /* DMA addressable range. */
charvendor[9];
charname[9];
charfirmware[9];

Re: [PATCH 4.18 000/228] 4.18.12-stable review

[Guenter Roeck]

On 10/02/2018 06:21 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.18.12 release.
There are 228 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 Oct  4 13:24:08 UTC 2018.
Anything received after that time might be too late.





Build results:
total: 137 pass: 137 fail: 0
Qemu test results:
total: 321 pass: 320 fail: 1
Failed tests:
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs

Details are available at https://kerneltests.org/builders/.

Guenter

Re: [QUEUED v20180920 05/16] stm class: Add a helper for writing data packets

[Alexander Shishkin]

Mathieu Poirier  writes:

>> +static ssize_t notrace stm_write(struct stm_data *data, unsigned int master,
>> +  unsigned int channel, const char *buf, size_t count)
>> +{
>> +ssize_t sz;
>> +
>> +sz = stm_data_write(data, master, channel, true, buf, count);
>> +if (sz > 0)
>> +data->packet(data, master, channel, STP_PACKET_FLAG, 0, 0,
>> + buf);
>
> The original code the payload of a flag packet was '0' while in this patch
> changes it to be anything.  Some external tooling could be very confused.

I think the original intention was so: the 'size' field of ->packet()
refers to how many bytes from the given 'payload' the callback should
use. IOW, with size 0, buf may point to anything (still a valid pointer
though). But that should have been documented better from the beginning,
so you're completely right. I'll make a note to myself to go over the
API bits and sort out stuff like that.

Thanks,
--
Alex

Re: [PATCH] mfd: cros-ec: copy the whole event in get_next_event_xfer

[Neil Armstrong]

Hi Enric,

On 03/10/2018 13:01, Enric Balletbo i Serra wrote:
> Hi Emil,
> 
> Many thanks to catch this and fix. Some comments below.
> 
> You missed to add the v2, please send the next patch with v3 prefix.
> 
> On 28/9/18 19:08, Emil Karlson wrote:
>> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard 
>> events
>> be truncated on many chromebooks so that Left and Right keys on Column 12 
>> were
>> always 0. Use ret as memcpy len to fix this.
>>

[...]

> 
> Neil, can you give us your Tested-by to have the make sure this doesn't break
> with protocol v1, I don't have such hardware.

I'd like to, but I'm unable to get developer mode and legacy boot back on my 
TEEMO device...

Neil

> 
> Benson, will be really good have this merged in this rc. Are you fine with 
> this
> solution?
> 
> BTW, you can add my in next version.
> 
> Acked-by: Enric Balletbo i Serra 
> 

Re: [RFC PATCH] mtd: rawnand: ams-delta: use ->exec_op()

[Boris Brezillon]

On Wed, 03 Oct 2018 15:55:25 +0200
Janusz Krzysztofik  wrote:
  
> > > 
> > > Implementation of NAND_OP_WAITRDY_INSTR has been based on legacy
> > > nand_wait_ready(),  
> > 
> > I don't remember what the ams-delta ->dev_ready()/->waitfunc() hooks
> > are doing, but is shouldn't be too hard to replace them by an
> > ams_delta_wait_ready() func.  
> 
> Default nand_wait() is used as ->waitfunc(), and ->dev_ready() returns R/B 
> GPIO pin status.

Okay. Then it might make sense to provide a generic helper to poll a
gpio.

void nand_gpio_waitrdy(struct nand_chip *chip, struct gpio_desc *gpiod)
{
...
}

> 
> > > otherwise that function would probabaly have to be  
> > 
> > ^ probably  
> 
> Do you think other drivers which now provide ->dev_ready() won't require 
> reimplementation of nand_wait_ready()?

It depends. I mean, most controllers support native R/B sensing, and in
case they do actually require you to poll the RB pin status, duplicating
the wait_ready() logic shouldn't be a problem. On the other hand, I
really want to get rid of ->dev_ready().

Re: [PATCH] perf/x86/intel: Add counter freezing quirk for Goldmont

[Thomas Gleixner]

On Wed, 3 Oct 2018, Liang, Kan wrote:
> On 10/3/2018 9:55 AM, Thomas Gleixner wrote:
> > On Wed, 3 Oct 2018, Liang, Kan wrote:
> > > On 10/3/2018 2:10 AM, Thomas Gleixner wrote:
> > > > There is another variant of model/stepping micro code verification code
> > > > in
> > > > intel_snb_pebs_broken(). Can we please make this table based and use a
> > > > common function? That's certainly not the last quirk we're going to
> > > > have.
> > > > 
> > > > We already have a table based variant of ucode checking in
> > > > bad_spectre_microcode(). It's trivial enough to generalize that.
> > > > 
> > > 
> > > Sure, I will generalize the bad_spectre_microcode(), rename it to
> > > is_bad_intel_microcode(), and move it to
> > > arch\x86\kernel\cpu\microcode\intel.c.
> > 
> > I suggest: is_bad_microcode() and have it in cpu/microcode/core.c unless
> > you are claiming that bad microcode() is an intel only feature.
> > 
> 
> Yes, other platforms also have microcode issues.
> To make it more generic, I think we also need to extend the struct
> sku_microcode to check vendor and family.
> The "model" in struct x86_cpu_id is u16. I will also change "model" and
> "stepping" to u16.
> 
> struct sku_microcode {
>   u16 vendor;
>   u16 family;
>   u16 model;
>   u16 stepping;
>   u32 microcode;
> };

Makes sense.

Thanks,

tglx

Re: [PATCH] spi: slave: Fix missing break in switch

[Geert Uytterhoeven]

Hi Gustavo,

On Wed, Oct 3, 2018 at 2:57 PM Gustavo A. R. Silva
 wrote:
> Apparently, this code does not actually fall through to the next case
> because the machine restarts before it has a chance. However, for the
> sake of maintenance and readability, we better add the missing break
> statement.
>
> Addresses-Coverity-ID: 1437892 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/spi/spi-slave-system-control.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-slave-system-control.c 
> b/drivers/spi/spi-slave-system-control.c
> index c0257e9..169f3d5 100644
> --- a/drivers/spi/spi-slave-system-control.c
> +++ b/drivers/spi/spi-slave-system-control.c
> @@ -60,6 +60,7 @@ static void spi_slave_system_control_complete(void *arg)
> case CMD_REBOOT:
> dev_info(>spi->dev, "Rebooting system...\n");
> kernel_restart(NULL);
> +   break;
>
> case CMD_POWEROFF:
> dev_info(>spi->dev, "Powering off system...\n");

Alternatively, kernel_restart() and friends could be marked __noreturn.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] ALSA: intel8x0: Fix fall-through annotations

[Gustavo A. R. Silva]

Replace "fallthru" with a proper "fall through" annotation.

This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough

Signed-off-by: Gustavo A. R. Silva 
---
 sound/pci/intel8x0.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
index 9517f9b..ffddcdf 100644
--- a/sound/pci/intel8x0.c
+++ b/sound/pci/intel8x0.c
@@ -825,7 +825,7 @@ static int snd_intel8x0_pcm_trigger(struct 
snd_pcm_substream *substream, int cmd
switch (cmd) {
case SNDRV_PCM_TRIGGER_RESUME:
ichdev->suspended = 0;
-   /* fallthru */
+   /* fall through */
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
val = ICH_IOCE | ICH_STARTBM;
@@ -833,7 +833,7 @@ static int snd_intel8x0_pcm_trigger(struct 
snd_pcm_substream *substream, int cmd
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
ichdev->suspended = 1;
-   /* fallthru */
+   /* fall through */
case SNDRV_PCM_TRIGGER_STOP:
val = 0;
break;
@@ -867,7 +867,7 @@ static int snd_intel8x0_ali_trigger(struct 
snd_pcm_substream *substream, int cmd
switch (cmd) {
case SNDRV_PCM_TRIGGER_RESUME:
ichdev->suspended = 0;
-   /* fallthru */
+   /* fall through */
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
@@ -884,7 +884,7 @@ static int snd_intel8x0_ali_trigger(struct 
snd_pcm_substream *substream, int cmd
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
ichdev->suspended = 1;
-   /* fallthru */
+   /* fall through */
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
/* pause */
-- 
2.7.4

Re: [PATCH] firmware: dcdbas: include linux/io.h

[Andy Shevchenko]

On Wed, Oct 3, 2018 at 12:17 AM Arnd Bergmann  wrote:
>
> memremap() is declared in linux/io.h, not in asm/io.h, so we should
> include that header to avoid build errors:
>
> drivers/platform/x86/dcdbas.c: In function 'dcdbas_check_wsmt':
> drivers/platform/x86/dcdbas.c:572:15: error: implicit declaration of function 
> 'memremap'; did you mean 'ioremap'? [-Werror=implicit-function-declaration]
>   eps_buffer = memremap(eps->smm_comm_buff_addr, remap_size, MEMREMAP_WB);
>^~~~
>ioremap
> drivers/platform/x86/dcdbas.c:572:61: error: 'MEMREMAP_WB' undeclared (first 
> use in this function)
>   eps_buffer = memremap(eps->smm_comm_buff_addr, remap_size, MEMREMAP_WB);
>  ^~~
> drivers/platform/x86/dcdbas.c:572:61: note: each undeclared identifier is 
> reported only once for each function it appears in
> drivers/platform/x86/dcdbas.c: In function 'dcdbas_exit':
> drivers/platform/x86/dcdbas.c:748:3: error: implicit declaration of function 
> 'memunmap'; did you mean 'vm_munmap'? [-Werror=implicit-function-declaration]
>

Pushed to for-next, sorry for inconveniences and thanks for the quick fix!

> Fixes: 12c956c4f32e ("firmware: dcdbas: Add support for WSMT ACPI table")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/platform/x86/dcdbas.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/dcdbas.c b/drivers/platform/x86/dcdbas.c
> index ae28e48ff7dc..daa7e3574568 100644
> --- a/drivers/platform/x86/dcdbas.c
> +++ b/drivers/platform/x86/dcdbas.c
> @@ -37,7 +37,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "dcdbas.h"
>
> --
> 2.18.0
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 06/21] tpm: move tpm1_pcr_extend to tpm1-cmd.c

[Jarkko Sakkinen]

On Tue, Oct 02, 2018 at 02:58:00PM +0530, Nayna Jain wrote:
> 
> 
> On 10/02/2018 06:12 AM, Jarkko Sakkinen wrote:
> > On Sat, Sep 29, 2018 at 01:30:20AM +0300, Tomas Winkler wrote:
> > > Move tpm1_pcr_extend to tpm1-cmd.c and remove
> > > unused pcrextend_header structure and
> > > EXTEND_PCR_RESULT_SIZE and EXTEND_PCR_RESULT_BODY_SIZE
> > > defines.
> > > 
> > > Fixes warning:
> > > drivers/char/tpm/tpm-interface.c:609:38: warning: ‘pcrextend_header’ 
> > > defined but not used [-Wunused-const-variable=]
> > >   static const struct tpm_input_header pcrextend_header = {
> > >^~~~
> > > 
> > > Signed-off-by: Tomas Winkler 
> > > Reviewed-by: Jarkko Sakkinen 
> > Would need help with this from someone with a working IMA setup
> > on testing.
> 
> 
> My test system is down for now.. I think it will be up later in this week. I
> can test it then.

Thank you.

/Jarkko

Re: [RFC PATCH v2 1/9] leds: add TI LMU backlight driver

[Dan Murphy]

Hello

On 10/03/2018 07:00 AM, Dan Murphy wrote:
> Hello
> 
> On 10/02/2018 05:07 PM, Pavel Machek wrote:
>> Hi!
>>
 We have debated this over and over and now we have 3 different 
 implementations
 available we need to collude on which one we want to support.

 Jacek I defer to you and Pavel since you are both LED maintainers.

 I can support the dedicated LED drivers but I cannot support the TI LMU 
 only implementation.
>>>
>>> I uphold my previous opinion - please go ahead with moving the support
>>> for non-MFD devices from MFD subsystem to the LED subsystem. And yes -
>>> along with the bindings. This is semantically correct, and yet we don't
>>> have mainline users.
>>>
>>> Pavel - you will have to engage more people for your crusade to prevail.
>>> For now, to speed up the things, I am forced to ignore your NAK.
>>> So NAK to your NAK. Sorry.
>>
>> No need to be sorry :-).
>>
>> Lets ignore the code for now, as code can be changed easily.
>>
>> Bindings are not something you or I maintain, so we don't have final
>> word there, and I have feeling this is not going to go past device
>> tree maintainers. [AFAICT: you can move binding in Documentation/ to
>> different place, that's not a problem; but creating a new binding when
>> old one exists is.]
>>
>> If you and Dan feel that is okay, you are welcome to try to get the
>> patches past Rob, just please retain the NAK so that he remembers the
>> discussion, and so that it is clear that I don't like the changes.
>>
>> I believe smart thing to do is to try to do that before working
>> further on the code, but of course, its all up to you :-).
> 
> I was looking for the review for the ti-lmu.txt binding on patchworks to see 
> what
> the comments were on the review or any explanation from reviewers to
> why this implementation was done in the MFD.
> 
> Maybe there is some historical context that needs to be learned from here from
> 1.5 years ago.
> 
> I cannot seem to find any review posted in the patchworks archive.
> I see reviews posted for the ti-lmu-backlight binding but none from
> the ti-lmu.txt base binding.
> 
> Does anyone have a reference to the review?

I found the review or at least the reference for the ti-lmu.txt binding.

https://lore.kernel.org/patchwork/patch/764180/

Does not appear that the binding was sent to the device tree mail list.
(Maybe that email list did not exist in Feb 2017).
Especially with the amount of change that is being submitted in the
newer patchsets.

Dan

> 
> If there is no review then I am wondering how this binding was accepted.
> If there is no review and no current users then I would think that binding
>  modification should be allowed.  But thats just my opinion.
> 
> Dan
> 
> 
>>
>> Friends,
>>  Pavel
>>
> 
> 


-- 
--
Dan Murphy

[BUG] sound: pci: trident: a possible data race

[Jia-Ju Bai]

CPU0:
snd_trident_hw_free
snd_trident_free_voice
line 3870: spin_lock_irqsave()
line 3881: voice->substream = NULL; [WRITE]
CPU1:
snd_trident_interrupt
line 3798: snd_pcm_period_elapsed(voice->substream);  [READ]

As for voice->substream, the WRITE operation in CPU0 is performed
with holding a spinlock, but the READ operation in CPU1 is performed
without holding this spinlock, so there may exist a data race.


Best wishes,
Jia-Ju Bai

Re: [PATCH V2 3/5] usb: xhci: tegra: Add genpd support

[Jon Hunter]

On 03/10/18 10:52, Ulf Hansson wrote:
> [...]
> 
>>  static int tegra_xusb_probe(struct platform_device *pdev)
>>  {
>> struct tegra_xusb_mbox_msg msg;
>> @@ -1038,7 +1095,7 @@ static int tegra_xusb_probe(struct platform_device 
>> *pdev)
>> goto put_padctl;
>> }
>>
>> -   if (!pdev->dev.pm_domain) {
>> +   if (!of_property_read_bool(pdev->dev.of_node, "power-domains")) {
> 
> I am assuming the original check was because allowing the two
> power-domains to be (wrongly) modeled as one (or as a
> master+subdomain)?

Actually, the original check was added to prepare for supporting
multiple power-domains and that once we had proper support in place the
'pdev->dev.domain' would then be populated. However, given that this is
not used in the case of multiple power-domains, I simply changed the test.

> I was thinking that, perhaps we should add a new OF helper function,
> where one can get the number of specifiers being listed in the
> power-domains property. Would that help to easier distinguish what to
> do when dealing with backwards compatibility?

We could do, but it is not necessary here, because we never had any form
of genpd support for the Tegra xHCI driver.

Cheers
Jon

-- 
nvpublic

Re: [RFC PATCH] mtd: rawnand: ams-delta: use ->exec_op()

[Janusz Krzysztofik]

On Wednesday, October 3, 2018 2:30:54 PM CEST Boris Brezillon wrote:
> Hi Janusz,
> 
> On Wed,  3 Oct 2018 14:00:28 +0200
> Janusz Krzysztofik  wrote:
> 
> > Replace legacy callbacks with ->select_chip() and ->exec_op().
> 
> Thanks for working on that, that's really appreciated.
> 
> > 
> > Implementation of NAND_OP_WAITRDY_INSTR has been based on legacy
> > nand_wait_ready(),
> 
> I don't remember what the ams-delta ->dev_ready()/->waitfunc() hooks
> are doing, but is shouldn't be too hard to replace them by an
> ams_delta_wait_ready() func.

Default nand_wait() is used as ->waitfunc(), and ->dev_ready() returns R/B 
GPIO pin status.

> > otherwise that function would probabaly have to be
> 
>   ^ probably

Do you think other drivers which now provide ->dev_ready() won't require 
reimplementation of nand_wait_ready()?

> > reimplemented inside the driver.  Hence, legacy callback ->dev_ready()
> > is still used.
> > 
> > Use of IO_ADDR_R and IO_ADDR_W legacy structure members will be dropped
> > later, as soon as the driver is converted to use GPIO API for data I/O.
> 
> In the meantime, can you move the iomem pointer to the ams_delta
> private struct so that this driver no longer uses the ->IO_ADDR_R/W
> fields?

OK

> > 
> > Suggested-by: Boris Brezillon 
> > Signed-off-by: Janusz Krzysztofik 
> > ---
> > Hi,
> > 
> > I've not tested the change on hardware yet as I'm not sure if:
> > - handling of NCE limited to that inside ->select_chip() is
> >   sufficient,
> 
> I think it is.
> 
> > - releasing ALE / CLE immediately after ams_delta_write_buf() is
> >   correct.
> 
> Well, you should probably consider waiting for instr->ctx.delay_ns
> nanoseconds after each instruction, but, if it was working before the
> conversion to ->exec_op(), it should work just fine now.

OK, I'll give it a try.

Thanks,
Janusz

Re: [PATCH] kvm: nVMX: fix entry with pending interrupt if APICv is enabled

[Nikita Leshenko]

On Wed, 2018-10-03 at 13:47 +0200, Paolo Bonzini wrote:
> Commit b5861e5cf2fcf83031ea3e26b0a69d887adf7d21 introduced a check on
> the interrupt-window and NMI-window CPU execution controls in order to
> inject an external interrupt vmexit before the first guest instruction
> executes.  However, when APIC virtualization is enabled the host does not
> need a vmexit in order to inject an interrupt at the next interrupt window;
> instead, it just places the interrupt vector in RVI and the processor will
> inject it as soon as possible.  Therefore, on machines with APICv it is
> not enough to check the CPU execution controls: the same scenario can also
> happen if RVI>0.
> 
> Fixes: b5861e5cf2fcf83031ea3e26b0a69d887adf7d21
> Cc: Nikita Leshchenko 
> Cc: Sean Christopherson 
> Cc: Liran Alon 
> Cc: Radim Krčmář 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/vmx.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 6ef2d5b139b9..c0c7689f0049 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -10280,6 +10280,11 @@ static void vmx_hwapic_isr_update(struct kvm_vcpu 
> *vcpu, int max_isr)
>   }
>  }
>  
> +static u8 vmx_get_rvi(void)
> +{
> + return vmcs_read16(GUEST_INTR_STATUS) & 0xff;
> +}
> +
>  static void vmx_set_rvi(int vector)
>  {
>   u16 status;
> @@ -12593,10 +12598,13 @@ static int enter_vmx_non_root_mode(struct kvm_vcpu 
> *vcpu, u32 *exit_qual)
>   struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
>   bool from_vmentry = !!exit_qual;
>   u32 dummy_exit_qual;
> - u32 vmcs01_cpu_exec_ctrl;
> + bool evaluate_pending_interrupts;
>   int r = 0;
>  
> - vmcs01_cpu_exec_ctrl = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
> + evaluate_pending_interrupts = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
> + (CPU_BASED_VIRTUAL_INTR_PENDING | 
> CPU_BASED_VIRTUAL_NMI_PENDING);
> + if (enable_apicv && kvm_vcpu_apicv_active(vcpu))
> + evaluate_pending_interrupts |= vmx_get_rvi() > 0;

You should check for RVI > VPPR, similarly to how it is done in
vmx_guest_apic_has_interrupt().

Also, now that you introduced vmx_get_rvi(), it could be nice to use it
in vmx_guest_apic_has_interrupt() as well.

Apart from that, looks good.

Reviewed-by: Nikita Leshenko 

Thanks,
Nikita

>  
>   enter_guest_mode(vcpu);
>  
> @@ -12650,10 +12658,8 @@ static int enter_vmx_non_root_mode(struct kvm_vcpu 
> *vcpu, u32 *exit_qual)
>* instead. Thus, we force L0 to perform pending event
>* evaluation by requesting a KVM_REQ_EVENT.
>*/
> - if (vmcs01_cpu_exec_ctrl &
> - (CPU_BASED_VIRTUAL_INTR_PENDING | 
> CPU_BASED_VIRTUAL_NMI_PENDING)) {
> + if (evaluate_pending_interrupts)
>   kvm_make_request(KVM_REQ_EVENT, vcpu);
> - }
>  
>   /*
>* Note no nested_vmx_succeed or nested_vmx_fail here. At this point

[GIT PULL] kselftest fixes update for Linux-4.19-rc7

[Shuah Khan]

Hi Greg,

Please pull the following kselftest for 4.19-rc7.

linux-kselftest-4.19-rc7

This fixes update for 4.19-rc7 consists one fix to rseq test to prevent
it from seg-faulting when compiled with -fpie.

diff is attached.

thanks,
-- Shuah



The following changes since commit 7876320f88802b22d4e2daf7eb027dd14175a0f8:

  Linux 4.19-rc4 (2018-09-16 11:52:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest 
tags/linux-kselftest-4.19-rc7

for you to fetch changes up to ce01a1575f45bf319e374592656441021a7f5823:

  rseq/selftests: fix parametrized test with -fpie (2018-09-27 12:59:19 -0600)


linux-kselftest-4.19-rc7

This fixes update for 4.19-rc7 consists one fix to rseq test to prevent
it from seg-faulting when compiled with -fpie.


Mathieu Desnoyers (1):
  rseq/selftests: fix parametrized test with -fpie

 tools/testing/selftests/rseq/param_test.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)


diff --git a/tools/testing/selftests/rseq/param_test.c b/tools/testing/selftests/rseq/param_test.c
index 642d4e12abea..eec2663261f2 100644
--- a/tools/testing/selftests/rseq/param_test.c
+++ b/tools/testing/selftests/rseq/param_test.c
@@ -56,15 +56,13 @@ unsigned int yield_mod_cnt, nr_abort;
 			printf(fmt, ## __VA_ARGS__);	\
 	} while (0)
 
-#if defined(__x86_64__) || defined(__i386__)
+#ifdef __i386__
 
 #define INJECT_ASM_REG	"eax"
 
 #define RSEQ_INJECT_CLOBBER \
 	, INJECT_ASM_REG
 
-#ifdef __i386__
-
 #define RSEQ_INJECT_ASM(n) \
 	"mov asm_loop_cnt_" #n ", %%" INJECT_ASM_REG "\n\t" \
 	"test %%" INJECT_ASM_REG ",%%" INJECT_ASM_REG "\n\t" \
@@ -76,9 +74,16 @@ unsigned int yield_mod_cnt, nr_abort;
 
 #elif defined(__x86_64__)
 
+#define INJECT_ASM_REG_P	"rax"
+#define INJECT_ASM_REG		"eax"
+
+#define RSEQ_INJECT_CLOBBER \
+	, INJECT_ASM_REG_P \
+	, INJECT_ASM_REG
+
 #define RSEQ_INJECT_ASM(n) \
-	"lea asm_loop_cnt_" #n "(%%rip), %%" INJECT_ASM_REG "\n\t" \
-	"mov (%%" INJECT_ASM_REG "), %%" INJECT_ASM_REG "\n\t" \
+	"lea asm_loop_cnt_" #n "(%%rip), %%" INJECT_ASM_REG_P "\n\t" \
+	"mov (%%" INJECT_ASM_REG_P "), %%" INJECT_ASM_REG "\n\t" \
 	"test %%" INJECT_ASM_REG ",%%" INJECT_ASM_REG "\n\t" \
 	"jz 333f\n\t" \
 	"222:\n\t" \
@@ -86,10 +91,6 @@ unsigned int yield_mod_cnt, nr_abort;
 	"jnz 222b\n\t" \
 	"333:\n\t"
 
-#else
-#error "Unsupported architecture"
-#endif
-
 #elif defined(__s390__)
 
 #define RSEQ_INJECT_INPUT \

Re: [PATCH] stm class: fix a missing-check bug

[Wenwen Wang]

On Wed, Oct 3, 2018 at 2:57 AM Alexander Shishkin
 wrote:
>
> Wenwen Wang  writes:
>
> > In stm_char_policy_set_ioctl(), the 'size' field of the struct
> > 'stp_polic_id' is firstly copied from the user space and then checked,
> > because the length of the 'id' field in this struct, which represents an
> > identification string, is not fixed. If the 'size' field cannot pass the
> > check, an error code EINVAL will be returned. However, after the check, the
> > whole struct is copied again from the user space. Given that the user data
> > resides in the user space, a malicious user-space process can race to
> > change the size between the two copies. By doing so, the attacker can
> > bypass the check on the 'size' field and inject malicious data.
>
> How? The id->size is not used for anything.
>
> And even if there was a problem, this:
>
> > - if (copy_from_user(id, arg, size)) {
> > + if (copy_from_user(>master, (char __user *)arg + sizeof(size),
> > + size - sizeof(size))) {
>
> is completely pointless.

Given that id->size is not used, it should not be copied from the user
space. This code is used to remove such redundant copy.

>
> >   ret = -EFAULT;
> >   goto err_free;
> >   }
> >
> > + id->size = size;
>
> So, if we did use id->size after the copying, we'd indeed have this line
> in the code. But since we don't, it's also pointless, so it's not there.
>
> Thanks,
> --
> Alex

Re: [PATCH] kvm: nVMX: fix entry with pending interrupt if APICv is enabled

[Paolo Bonzini]

On 03/10/2018 16:53, Sean Christopherson wrote:
> Isn't enable_apicv redundant with kvm_vcpu_apicv_active()?  And since
> getting RVI requires a VMREAD, I think it would make sense to only
> fall into this code if !evaluate_pending_interrupts, e.g.:
> 
>   if (!evaluate_pending_interrupts && kvm_vcpu_apicv_active(vcpu))
>   evaluate_pending_interrupts |= vmx_get_rvi() > 0;

Yes, both suggestions make sense.  I'll make it
likely(!evaluate_pending_interrupts).

Thanks to both you and Nikita for the quick review!

Paolo

Re: [PATCH] spi: slave: Fix missing break in switch

[Mark Brown]

On Wed, Oct 03, 2018 at 04:46:45PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 3, 2018 at 2:57 PM Gustavo A. R. Silva

> > case CMD_REBOOT:
> > dev_info(>spi->dev, "Rebooting system...\n");
> > kernel_restart(NULL);
> > +   break;

> Alternatively, kernel_restart() and friends could be marked __noreturn.

Yes, that seems more sensible though there's no harm in this patch even
with that.  It'd definitely avoid other issues in future.


signature.asc
Description: PGP signature

Re: [PATCH v5 04/27] arm64: daifflags: Use irqflags functions for daifflags

[Catalin Marinas]

On Tue, Aug 28, 2018 at 04:51:14PM +0100, Julien Thierry wrote:
> Some of the work done in daifflags save/restore is already provided
> by irqflags functions. Daifflags should always be a superset of irqflags
> (it handles irq status + status of other flags). Modifying behaviour of
> irqflags should alter the behaviour of daifflags.
> 
> Use irqflags_save/restore functions for the corresponding daifflags
> operation.
> 
> Signed-off-by: Julien Thierry 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: James Morse 

Queued for 4.20. Thanks.

-- 
Catalin

Re: [PATCH 6/6] lib/scatterlist: Fix overflow check in sgl_alloc_order

[Bart Van Assche]

On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> It is necessary to ensure types on both sides of the comparison are of the
> same width. Otherwise the check overflows sooner than expect due left hand
> side being an unsigned long length, and the right hand side unsigned int
> number of elements multiplied by element size.

Reviewed-by: Bart Van Assche 

Re: [PATCH] perf/x86/intel: Add counter freezing quirk for Goldmont

[Peter Zijlstra]

On Wed, Oct 03, 2018 at 08:10:31AM +0200, Thomas Gleixner wrote:
> On Tue, 2 Oct 2018, kan.li...@linux.intel.com wrote:
> 
> There is another variant of model/stepping micro code verification code in
> intel_snb_pebs_broken(). Can we please make this table based and use a
> common function? That's certainly not the last quirk we're going to have.
> 
> We already have a table based variant of ucode checking in
> bad_spectre_microcode(). It's trivial enough to generalize that.

apic_check_deadline_errata() is another one. That one already uses the
x86_cpu_id thing, but still plays silly games for steppings. So if we're
going to build a new microcode table matcher...

Re: [PATCH] perf/x86/intel: Add counter freezing quirk for Goldmont

[Borislav Petkov]

On Wed, Oct 03, 2018 at 05:41:32PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 03, 2018 at 08:10:31AM +0200, Thomas Gleixner wrote:
> > On Tue, 2 Oct 2018, kan.li...@linux.intel.com wrote:
> > 
> > There is another variant of model/stepping micro code verification code in
> > intel_snb_pebs_broken(). Can we please make this table based and use a
> > common function? That's certainly not the last quirk we're going to have.
> > 
> > We already have a table based variant of ucode checking in
> > bad_spectre_microcode(). It's trivial enough to generalize that.
> 
> apic_check_deadline_errata() is another one. That one already uses the
> x86_cpu_id thing, but still plays silly games for steppings. So if we're
> going to build a new microcode table matcher...

intel_snb_pebs_broken() looks like a potential candidate too...

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 6/8] mtd: maps: gpio-addr-flash: Convert to gpiod

[Ricardo Ribalda Delgado]

Hi Boris
On Wed, Oct 3, 2018 at 5:17 PM Boris Brezillon
 wrote:
>
> On Wed, 3 Oct 2018 17:11:14 +0200
> Boris Brezillon  wrote:
>
> > Hi Ricardo,
> >
> > On Mon,  1 Oct 2018 14:43:49 +0200
> > Ricardo Ribalda Delgado  wrote:
> >
> > > @@ -248,14 +252,19 @@ static int gpio_flash_probe(struct platform_device 
> > > *pdev)
> > >
> > > i = 0;
> > > do {
> > > -   if (devm_gpio_request(>dev, state->gpio_addrs[i],
> > > - DRIVER_NAME)) {
> > > +   unsigned int *gpio_id = (unsigned int *)gpios->start;
> > > +
> > > +   if (devm_gpio_request_one(>dev, gpio_id[i], 
> > > GPIOD_OUT_LOW,
> > > +   DRIVER_NAME)) {
> > > dev_err(>dev, "failed to request gpio %d\n",
> > > -   state->gpio_addrs[i]);
> > > +   gpio_id[i]);
> > > return -EBUSY;
> > > }
> > > -   gpio_direction_output(state->gpio_addrs[i], 0);
> > > -   } while (++i < state->gpio_count);
> > > +
> > > +   state->gpios->desc[i] = gpio_to_desc(gpio_id[i]);
> > > +   if (!state->gpios->desc[i])
> > > +   return -EINVAL;
> > > +   } while (++i < state->gpios->ndescs);
> >
> > Actually, I was thinking about using devm_gpiod_get_array() here and
> > defining a gpio lookup table in the board file registering the device.
> > This way, adding support for DT based parsing is transparent.
>
> It's actually easier than I thought since no one is registering such a
> device, so all you have to do is call devm_gpiod_get_array() and have a
> struct gpio_descs pointer in struct async_state.

That is what I do in patch 8/8 for DT based parsing.

I am am doing the gpio_to_desc and other to maintain compatibility
with old platform board files (in and out tree).

I think is important to maintain that compatibility, but you decide ;)

Cheers

-- 
Ricardo Ribalda

Re: [RFC PATCH 10/10] arch/x86: Introduce QOS feature for AMD

[Moger, Babu]

On 10/02/2018 01:27 PM, Fenghua Yu wrote:
> On Mon, Sep 24, 2018 at 07:19:16PM +, Moger, Babu wrote:
>>  int parse_bw(void *_buf, struct rdt_resource *r,  struct rdt_domain *d);
>> +int parse_bw_amd(void *_buf, struct rdt_resource *r,  struct rdt_domain *d);
> 
> Please note the type of _buf in parse_bw() is changed in latest kernel
> to fix some issues. Please follow the same definition of parse_bw() in
> parse_bw_amd().

Yes, I noticed it. Saw the same issue(mba data parsing) and found it fixed
in 4-19-rc5. Will re-base to the latest kernel.
> 
> Thanks.
> 
> -Fenghua
> 

Re: [PATCH 0/6] lib/scatterlist: sgl API fixes and cleanups

[Bart Van Assche]

On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Mostly same fixes and cleanups I've sent earlier in the year, but with some
> patches dropped and some split into smaller ones as per request.

I think in order for a patch series to get noticed that the maintainer the
series is sent to should appear in the "To" field of the e-mail. If you
resend this patch series, please Cc the linux-block mailing list and please
also use my current e-mail address. I only noticed this patch series today
because my old e-mail address occurs in the Cc list of this patch series.

Thanks,

Bart.

[PATCH v9 3/3]: perf record: extend trace writing to multi AIO

[Alexey Budankov]

Multi AIO trace writing allows caching more kernel data into userspace 
memory postponing trace writing for the sake of overall profiling data 
thruput increase. It could be seen as kernel data buffer extension into
userspace memory.

With aio-cblocks option value different from 0, current default value, 
tool has capability to cache more and more data into user space
along with delegating spill to AIO.

That allows avoiding suspend at record__aio_sync() between calls of 
record__mmap_read_evlist() and increase profiling data thruput for 
the cost of userspace memory.

Signed-off-by: Alexey Budankov 
---
 tools/perf/builtin-record.c | 59 +++--
 tools/perf/util/evlist.c|  7 ++--
 tools/perf/util/evlist.h|  3 +-
 tools/perf/util/mmap.c  | 79 -
 tools/perf/util/mmap.h  |  7 ++--
 5 files changed, 115 insertions(+), 40 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c63fe8c021a2..7b67574be5b7 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -196,16 +196,35 @@ static int record__aio_complete(struct perf_mmap *md, 
struct aiocb *cblock)
return rc;
 }
 
-static void record__aio_sync(struct perf_mmap *md)
+static int record__aio_sync(struct perf_mmap *md, bool sync_all)
 {
-   struct aiocb *cblock = >cblock;
+   struct aiocb **aiocb = md->aiocb;
+   struct aiocb *cblocks = md->cblocks;
struct timespec timeout = { 0, 1000 * 1000  * 1 }; // 1ms
+   int i, do_suspend;
 
do {
-   if (cblock->aio_fildes == -1 || record__aio_complete(md, 
cblock))
-   return;
+   do_suspend = 0;
+   for (i = 0; i < md->nr_cblocks; ++i) {
+   if (cblocks[i].aio_fildes == -1 || 
record__aio_complete(md, [i])) {
+   if (sync_all)
+   aiocb[i] = NULL;
+   else
+   return i;
+   } else {
+   /*
+* Started aio write is not complete yet
+* so it has to be waited before the
+* next allocation.
+*/
+   aiocb[i] = [i];
+   do_suspend = 1;
+   }
+   }
+   if (!do_suspend)
+   return -1;
 
-   while (aio_suspend((const struct aiocb**), 1, )) 
{
+   while (aio_suspend((const struct aiocb **)aiocb, 
md->nr_cblocks, )) {
if (!(errno == EAGAIN || errno == EINTR))
pr_err("failed to sync perf data, error: %m\n");
}
@@ -436,11 +455,15 @@ static int record__mmap_evlist(struct record *rec,
   struct perf_evlist *evlist)
 {
struct record_opts *opts = >opts;
+   int nr_cblocks = 0;
char msg[512];
-
+#ifdef HAVE_AIO_SUPPORT
+   nr_cblocks = opts->nr_cblocks;
+#endif
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
 opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode) < 0) {
+opts->auxtrace_snapshot_mode,
+nr_cblocks) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
   "Consider increasing "
@@ -637,7 +660,7 @@ static void record__mmap_read_sync(struct record *rec 
__maybe_unused)
for (i = 0; i < evlist->nr_mmaps; i++) {
struct perf_mmap *map = [i];
if (map->base)
-   record__aio_sync(map);
+   record__aio_sync(map, true);
}
 #endif
 }
@@ -676,12 +699,13 @@ static int record__mmap_read_evlist(struct record *rec, 
struct perf_evlist *evli
goto out;
}
} else {
+   int idx;
/*
 * Call record__aio_sync() to wait till 
map->data buffer
 * becomes available after previous aio write 
request.
 */
-   record__aio_sync(map);
-   if (perf_mmap__aio_push(map, rec, 
record__aio_pushfn) != 0) {
+   idx = record__aio_sync(map, false);
+   if (perf_mmap__aio_push(map, rec, idx, 
record__aio_pushfn) != 0) {
rc = -1;
goto out;
}
@@ -1442,6 +1466,10 @@ static 

Re: [PATCH v7 08/14] sched/topology: Disable EAS on inappropriate platforms

[Peter Zijlstra]

On Wed, Sep 12, 2018 at 10:13:03AM +0100, Quentin Perret wrote:
> @@ -288,6 +321,21 @@ static void build_perf_domains(const struct cpumask 
> *cpu_map)
>   goto free;
>   tmp->next = pd;
>   pd = tmp;
> +
> + /*
> +  * Count performance domains and capacity states for the
> +  * complexity check.
> +  */
> + nr_pd++;
> + nr_cs += em_pd_nr_cap_states(pd->obj);
> + }
> +
> + /* Bail out if the Energy Model complexity is too high. */
> + if (nr_pd * (nr_cs + nr_cpus) > EM_MAX_COMPLEXITY) {
> + if (sched_debug())
> + pr_info("rd %*pbl: EM complexity is too high\n ",
> + cpumask_pr_args(cpu_map));
> + goto free;
>   }

I would make than an unconditional WARN, we do not really expect that to
trigger, but then it does, we really don't want to hide it.

Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

[Jann Horn]

On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
 wrote:
> On 01.10.2018 19:11, Thomas Gleixner wrote:
> > Peter and I discussed that and we came up with the idea that the file
> > descriptor is not even required, i.e. you could make it backward
> > compatible.
> >
> > perf_event_open() knows which PMU is associated with the event the caller
> > tries to open. So perf_event_open() can try to access/open the special per
> > PMU file on behalf of the caller. That should get the same security
> > treatment like a regular open() from user space. If that succeeds, access
> > is granted.
> >
> > The magic file could still be writeable for root to give general
> > restrictions aside of the file based ones similar to what you are
> > proposing.
>
> Let me wrap up all the requirements and ideas that have been captured so far.
>
> 1. A file [1] is added so that it can belong to a group of users allowed to 
> use ${PMU},
>something like this:
>
> ls -alh /sys/bus/event_source/devices/${PMU}/caps/
> total 0
> drwxr-xr-x 2 root root0 Oct  1 20:36 .
> drwxr-xr-x 6 root root0 Oct  1 20:36 ..
> -r--r--r-- 1 root root 4.0K Oct  1 20:36 branches
> -r--r--r-- 1 root root 4.0K Oct  1 20:36 max_precise
> -r--r--r-- 1 root root 4.0K Oct  1 20:36 pmu_name
> -rw-r--r--   root ${PMU}_users   paranoid<===
>
>Modifications of file content are allowed to those who can
>modify /proc/sys/kernel/perf_event_paranoid setting.
>
> 2. Semantics and content of the introduced paranoid file is
>similar to /proc/sys/kernel/perf_even_paranoid [2]:
>
>The perf_event_paranoid file can be set to restrict access
>to the performance counters.
>
>2   allow only user-space measurements (default since Linux 4.6).
>1   allow both kernel and user measurements (default before Linux 4.6).
>0   allow access to CPU-specific data but not raw trace‐point samples.
>   -1  no restrictions.
>
>The existence of the perf_event_paranoid file is the official method
>for determining if a kernel supports perf_event_open().
>
> 3. Every time an event for ${PMU} is created over perf_event_open():
>a) the calling thread's euid is checked to belong to ${PMU}_users group
>   and if it does then the event's fd is allocated;
>b) then traditional checks against perf_event_pranoid content are applied;
>c) if the file doesn't exist the access is governed by global setting
>   at /proc/sys/kernel/perf_even_paranoid;

You'll also have to make sure that this thing in kernel/events/core.c
doesn't have any bad effect:

/*
* Special case software events and allow them to be part of
* any hardware group.
*/

As in, make sure that you can't smuggle in arbitrary software events
by attaching them to a whitelisted hardware event.

> 4. Documentation/admin-guide/perf-security.rst file is introduced that:
>a) contains general explanation for fine grained access control;
>b) contains a section with guidance about scope and risk for each PMU
>   which is enabled for fine grained access control;
>c) file is extended when more PMUs are enabled for fine grain control;
>
> >
> > The analysis and documentation requirements still remain of course.
>
> Security analysis for uncore IMC, QPI/UPI, PCIe PMUs is still required
> to be enabled for fine grain control.

And you can't whitelist anything that permits using sampling events
with arbitrary sample_type.

[PATCH 0/3] HID: debug: fix the ring buffer implementation

[Vladis Dronov]

This patchset is fixing some aspects of the ring buffer implementation in
drivers/hid/hid-debug.c. This implementation has certain problem points:

- it may stuck in an infinite loop
- it may return corrupted data
- a reader and a writer are not protected by spinlocks, which can lead to
  the corrupted data

The suggested patchset is a new ring buffer implementation which overwrites
the oldest data in case of an overflow. One can verify the suggested ring
buffer implementation by fuzzing it with modified kernel and fuzzer-reader
at: https://gist.github.com/nefigtut/33d56e3870b67493cc867344aed2a062

Vladis Dronov (3):
  HID: debug: avoid infinite loop and corrupting data
  HID: debug: provide reader-writer locking for the ring buffer
  HID: debug: fix ring buffer implementation

 drivers/hid/hid-debug.c   | 201 ++
 include/linux/hid-debug.h |   1 +
 2 files changed, 142 insertions(+), 60 deletions(-)

-- 
2.19.0

[PATCH 1/3] HID: debug: avoid infinite loop and corrupting data

[Vladis Dronov]

hid_debug_events_read() does not properly handle the case when tail < head
and count < HID_DEBUG_BUFSIZE - head and returns corrupted data. Also,
after commit 717adfdaf147 ("HID: debug: check length before
copy_to_user()") it can enter an infinite loop if called with count == 0.
Fix this by properly handling this case and adding a check.

Also, the function has "while (ret == 0)" loop which is not needed, remove
it.

Signed-off-by: Vladis Dronov 
---
 drivers/hid/hid-debug.c | 109 
 1 file changed, 65 insertions(+), 44 deletions(-)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index b48100236df8..20580871b0ec 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -722,7 +722,7 @@ void hid_dump_input(struct hid_device *hdev, struct 
hid_usage *usage, __s32 valu
hid_debug_event(hdev, buf);
 
kfree(buf);
-wake_up_interruptible(>debug_wait);
+   wake_up_interruptible(>debug_wait);
 
 }
 EXPORT_SYMBOL_GPL(hid_dump_input);
@@ -1112,73 +1112,95 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
int ret = 0, len;
DECLARE_WAITQUEUE(wait, current);
 
-   mutex_lock(>read_mutex);
-   while (ret == 0) {
-   if (list->head == list->tail) {
-   add_wait_queue(>hdev->debug_wait, );
-   set_current_state(TASK_INTERRUPTIBLE);
+   if (!count)
+   return 0;
 
-   while (list->head == list->tail) {
-   if (file->f_flags & O_NONBLOCK) {
-   ret = -EAGAIN;
-   break;
-   }
-   if (signal_pending(current)) {
-   ret = -ERESTARTSYS;
-   break;
-   }
+   mutex_lock(>read_mutex);
+   if (list->head == list->tail) {
+   add_wait_queue(>hdev->debug_wait, );
+   set_current_state(TASK_INTERRUPTIBLE);
+
+   while (list->head == list->tail) {
+   if (file->f_flags & O_NONBLOCK) {
+   ret = -EAGAIN;
+   break;
+   }
 
-   if (!list->hdev || !list->hdev->debug) {
-   ret = -EIO;
-   set_current_state(TASK_RUNNING);
-   goto out;
-   }
+   if (signal_pending(current)) {
+   ret = -ERESTARTSYS;
+   break;
+   }
 
-   /* allow O_NONBLOCK from other threads */
-   mutex_unlock(>read_mutex);
-   schedule();
-   mutex_lock(>read_mutex);
-   set_current_state(TASK_INTERRUPTIBLE);
+   if (!list->hdev || !list->hdev->debug) {
+   ret = -EIO;
+   set_current_state(TASK_RUNNING);
+   goto out;
}
 
-   set_current_state(TASK_RUNNING);
-   remove_wait_queue(>hdev->debug_wait, );
+   /* allow O_NONBLOCK from other threads */
+   mutex_unlock(>read_mutex);
+   schedule();
+   mutex_lock(>read_mutex);
+   set_current_state(TASK_INTERRUPTIBLE);
}
 
-   if (ret)
-   goto out;
+   set_current_state(TASK_RUNNING);
+   remove_wait_queue(>hdev->debug_wait, );
+   }
+
+   if (ret)
+   goto out;
 
-   /* pass the ringbuffer contents to userspace */
+   /* pass the ringbuffer content to userspace */
 copy_rest:
-   if (list->tail == list->head)
-   goto out;
-   if (list->tail > list->head) {
-   len = list->tail - list->head;
-   if (len > count)
-   len = count;
+   if (list->tail == list->head)
+   goto out;
+
+   /* the data from the head to the tail in the buffer is linear */
+   if (list->tail > list->head) {
+   len = list->tail - list->head;
+   if (len > count)
+   len = count;
 
-   if (copy_to_user(buffer + ret, 
>hid_debug_buf[list->head], len)) {
+   if (copy_to_user(buffer + ret,
+ >hid_debug_buf[list->head], len)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   ret += len;

[PATCH v3 13/15] platform: goldfish: pipe: Add a dedicated constant for the device name

[rkir]

From: Roman Kiryanov 

Create a constant to refer to the device name instead if several copies
of a string.

Signed-off-by: Roman Kiryanov 
---
Changes in v3:
 - No change.
Changes in v2:
 - No change.

 drivers/platform/goldfish/goldfish_pipe.h| 2 ++
 drivers/platform/goldfish/goldfish_pipe_v2.c | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.h 
b/drivers/platform/goldfish/goldfish_pipe.h
index ee0b54bcb165..0fa6ecb32c6d 100644
--- a/drivers/platform/goldfish/goldfish_pipe.h
+++ b/drivers/platform/goldfish/goldfish_pipe.h
@@ -2,6 +2,8 @@
 #ifndef GOLDFISH_PIPE_H
 #define GOLDFISH_PIPE_H
 
+#define DEVICE_NAME "goldfish_pipe"
+
 struct goldfish_pipe_dev_base {
/* the destructor, the pointer is set in init */
int (*deinit)(void *pipe_dev, struct platform_device *pdev);
diff --git a/drivers/platform/goldfish/goldfish_pipe_v2.c 
b/drivers/platform/goldfish/goldfish_pipe_v2.c
index 9857ce07d0e6..0e2a62322477 100644
--- a/drivers/platform/goldfish/goldfish_pipe_v2.c
+++ b/drivers/platform/goldfish/goldfish_pipe_v2.c
@@ -775,7 +775,7 @@ static void init_miscdevice(struct miscdevice *miscdev)
memset(miscdev, 0, sizeof(*miscdev));
 
miscdev->minor = MISC_DYNAMIC_MINOR;
-   miscdev->name = "goldfish_pipe";
+   miscdev->name = DEVICE_NAME;
miscdev->fops = _pipe_fops;
 }
 
@@ -806,7 +806,7 @@ int goldfish_pipe_device_v2_init(struct platform_device 
*pdev,
 
err = devm_request_irq(>dev, irq,
   goldfish_pipe_interrupt,
-  IRQF_SHARED, "goldfish_pipe", dev);
+  IRQF_SHARED, DEVICE_NAME, dev);
if (err) {
dev_err(>dev, "unable to allocate IRQ for v2\n");
return err;
-- 
2.19.0.605.g01d371f741-goog

[PATCH v3 12/15] platform: goldfish: pipe: Rename the init function (add "v2")

[rkir]

From: Roman Kiryanov 

This is the v2 driver. v1 will be added later.

Signed-off-by: Roman Kiryanov 
---
Changes in v3:
 - No change.
Changes in v2:
 - No change.

 drivers/platform/goldfish/goldfish_pipe.c| 2 +-
 drivers/platform/goldfish/goldfish_pipe_v2.c | 6 +++---
 drivers/platform/goldfish/goldfish_pipe_v2.h | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index 792b20bdf76c..7b0920e962eb 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -87,7 +87,7 @@ static int goldfish_pipe_probe(struct platform_device *pdev)
if (WARN_ON(version < PIPE_CURRENT_DEVICE_VERSION))
return -EINVAL;
 
-   return goldfish_pipe_device_init(pdev, base, irq);
+   return goldfish_pipe_device_v2_init(pdev, base, irq);
 }
 
 static int goldfish_pipe_remove(struct platform_device *pdev)
diff --git a/drivers/platform/goldfish/goldfish_pipe_v2.c 
b/drivers/platform/goldfish/goldfish_pipe_v2.c
index 641dfdcc3ffd..9857ce07d0e6 100644
--- a/drivers/platform/goldfish/goldfish_pipe_v2.c
+++ b/drivers/platform/goldfish/goldfish_pipe_v2.c
@@ -787,9 +787,9 @@ static void write_pa_addr(void *addr, void __iomem *portl, 
void __iomem *porth)
writel(lower_32_bits(paddr), portl);
 }
 
-int goldfish_pipe_device_init(struct platform_device *pdev,
- char __iomem *base,
- int irq)
+int goldfish_pipe_device_v2_init(struct platform_device *pdev,
+char __iomem *base,
+int irq)
 {
struct goldfish_pipe_dev *dev;
int err;
diff --git a/drivers/platform/goldfish/goldfish_pipe_v2.h 
b/drivers/platform/goldfish/goldfish_pipe_v2.h
index 03b476fb9978..70bf4ec1fd66 100644
--- a/drivers/platform/goldfish/goldfish_pipe_v2.h
+++ b/drivers/platform/goldfish/goldfish_pipe_v2.h
@@ -3,8 +3,8 @@
 #define GOLDFISH_PIPE_V2_H
 
 /* The entry point to the pipe v2 driver */
-int goldfish_pipe_device_init(struct platform_device *pdev,
- char __iomem *base,
- int irq);
+int goldfish_pipe_device_v2_init(struct platform_device *pdev,
+char __iomem *base,
+int irq);
 
 #endif /* #define GOLDFISH_PIPE_V2_H */
-- 
2.19.0.605.g01d371f741-goog

Re: [PATCH] soc: qcom: Add irq clear handling during SE init

[Doug Anderson]

Hi,

On Wed, Oct 3, 2018 at 5:24 AM Alok Chauhan  wrote:
>
> when the kernel inits a SE, its quite possible we have pending interrupts
> from bootloaders which did not handle/clear them. So do this in kernel at
> the SE init, to avoid some of it causing bad behavior, while at it also
> club all the register writes needed to clear the se irqs into a function
> to avoid repeating it over.
>
> Signed-off-by: Alok Chauhan 
> ---
>  drivers/soc/qcom/qcom-geni-se.c | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)

This looks fine to me.  To clarify this doesn't fix any known issues
and it just fixes the theoretical case where somehow a IRQ was sitting
around (maybe left by the firmware) so we want to make really certain
that we start with a clean state at init time.

Reviewed-by: Douglas Anderson 

[PATCH] nvmem: Convert to using %pOFn instead of device_node.name

[Srinivas Kandagatla]

From: Rob Herring 

In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Cc: Srinivas Kandagatla 
Signed-off-by: Rob Herring 
[srinivas: rebased on top of next]
Signed-off-by: Srinivas Kandagatla 
---
 drivers/nvmem/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index cc815bb2eebd..b4c09bc20b67 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -298,6 +298,7 @@ static void nvmem_cell_drop(struct nvmem_cell *cell)
mutex_lock(_mutex);
list_del(>node);
mutex_unlock(_mutex);
+   kfree(cell->name);
kfree(cell);
 }
 
@@ -547,7 +548,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device 
*nvmem)
cell->nvmem = nvmem;
cell->offset = be32_to_cpup(addr++);
cell->bytes = be32_to_cpup(addr);
-   cell->name = child->name;
+   cell->name = kasprintf(GFP_KERNEL, "%pOFn", child);
 
addr = of_get_property(child, "bits", );
if (addr && len == (2 * sizeof(u32))) {
@@ -564,6 +565,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device 
*nvmem)
dev_err(dev, "cell %s unaligned to nvmem stride %d\n",
cell->name, nvmem->stride);
/* Cells already added will be freed later. */
+   kfree(cell->name);
kfree(cell);
return -EINVAL;
}
-- 
2.19.0

Re: [PATCH 2/3] x86/intel_rdt: CBM overlap should also check for overlap with CDP peer

[Reinette Chatre]

Hi Thomas,

On 10/3/2018 12:02 AM, Thomas Gleixner wrote:
> On Wed, 26 Sep 2018, Reinette Chatre wrote:
>>  /**
>> - * rdtgroup_cbm_overlaps - Does CBM for intended closid overlap with other
>> + * _rdtgroup_cbm_overlaps - Does CBM for intended closid overlap with other
>>   * @r: Resource to which domain instance @d belongs.
>>   * @d: The domain instance for which @closid is being tested.
>>   * @cbm: Capacity bitmask being tested.
>> @@ -1049,8 +1048,8 @@ static int __attribute__((unused)) 
>> rdt_cdp_peer_get(struct rdt_resource *r,
>>   *
>>   * Return: false if CBM does not overlap, true if it does.
>>   */
>> -bool rdtgroup_cbm_overlaps(struct rdt_resource *r, struct rdt_domain *d,
>> -   u32 _cbm, int closid, bool exclusive)
>> +static bool _rdtgroup_cbm_overlaps(struct rdt_resource *r, struct 
>> rdt_domain *d,
>> +   u32 _cbm, int closid, bool exclusive)
> 
> Existing issue. The documentation uses @cbm, but the argument is _cbm.

Thanks for spotting this.

> 
> Also please make this __rdtgroup_cbm_overlaps(). Double underscores are
> standing more out.

Will do.

> 
>>  {
>>  unsigned long *cbm = (unsigned long *)&_cbm;
>>  unsigned long *ctrl_b;
>> @@ -1087,6 +1086,44 @@ bool rdtgroup_cbm_overlaps(struct rdt_resource *r, 
>> struct rdt_domain *d,
>>  return false;
>>  }
>>  
>> +/**
>> + * rdtgroup_cbm_overlaps - Does CBM overlap with other use of hardware
>> + * @r: Resource to which domain instance @d belongs.
>> + * @d: The domain instance for which @closid is being tested.
>> + * @cbm: Capacity bitmask being tested.
>> + * @closid: Intended closid for @cbm.
>> + * @exclusive: Only check if overlaps with exclusive resource groups
>> + *
>> + * Resources that can be allocated using a CBM can use the CBM to control
>> + * the overlap of these allocations. rdtgroup_cmb_overlaps() is the test
>> + * for overlap. Overlap test is not limited to the specific resource for
>> + * which the CBM is intended though - when dealing with CDP resources that
>> + * share the underlying hardware the overlap check should be performed on
>> + * the CDP resource sharing the hardware also.
>> + *
>> + * Refer to description of _rdtgroup_cbm_overlaps() for the details of the
>> + * overlap test.
>> + *
>> + * Return: true if CBM overlap detected, false if there is no overlap
>> + */
>> +bool rdtgroup_cbm_overlaps(struct rdt_resource *r, struct rdt_domain *d,
>> +   u32 _cbm, int closid, bool exclusive)
> 
> Ditto. And here is no reason for using _cbm.

Thanks for spotting this also, will do.

> 
>> +{
>> +struct rdt_resource *r_cdp;
>> +struct rdt_domain *d_cdp;
>> +bool ret;
>> +
>> +ret = _rdtgroup_cbm_overlaps(r, d, _cbm, closid, exclusive);
>> +if (ret)
>> +return ret;
> 
>   if (__rdtgroup_cbm_overlaps(r, d, _cbm, closid, exclusive))
>   return true;
> 
>> +
>> +if (rdt_cdp_peer_get(r, d, _cdp, _cdp) == 0)
>> +return _rdtgroup_cbm_overlaps(r_cdp, d_cdp, _cbm,
>> +  closid, exclusive);
> 
>   if (rdt_cdp_peer_get(r, d, _cdp, _cdp) < 0)
>   return false;
> 
>   return __rdtgroup_cbm_overlaps(r_cpd, d_cdp, _cbm, closid, exclusive);
> 
> Makes the whole thing more obvious.

I think a different change is needed to support the request from your
review of the first patch to propagate that unthinkable error where only
one of the CDP peers could have an rdt_domain associated with it.

In the above that error in question from rdt_cdp_peer_get() will be lost.

I could do the following in support of propagating that error (note that
in support of the code below __rdtgroup_cbm_overlaps() also changes to
return int instead of bool):

int rdtgroup_cbm_overlaps(struct rdt_resource *r, struct rdt_domain *d,
  u32 cbm, int closid, bool exclusive)
{
struct rdt_resource *r_cdp;
struct rdt_domain *d_cdp;
int ret;

if (__rdtgroup_cbm_overlaps(r, d, cbm, closid, exclusive))
return 1;

ret = rdt_cdp_peer_get(r, d, _cdp, _cdp);
if (ret == -ENOENT) {
return 0;
} else if (ret == -EINVAL) {
rdt_last_cmd_puts("Error finding CDP peer\n");
return ret;
} else {
return  __rdtgroup_cbm_overlaps(r_cdp, d_cdp, cbm,
closid, exclusive);
}

return -EINVAL;
}

With the above change in rdtgroup_cbm_overlaps() the call sites then
change to for example:

ret = rdtgroup_cbm_overlaps(r, d, cbm_val, rdtgrp->closid, true);
if (ret < 0) {
/* last_cmd_status already populated with error */
return -EINVAL;
} else if (ret == 1) {
rdt_last_cmd_puts("overlaps with exclusive group\n");
return -EINVAL;
}
/* fall through when no 

Re: [PATCH v4 6/8] mtd: maps: gpio-addr-flash: Convert to gpiod

[Boris Brezillon]

On Wed, 3 Oct 2018 17:11:14 +0200
Boris Brezillon  wrote:

> Hi Ricardo,
> 
> On Mon,  1 Oct 2018 14:43:49 +0200
> Ricardo Ribalda Delgado  wrote:
> 
> > @@ -248,14 +252,19 @@ static int gpio_flash_probe(struct platform_device 
> > *pdev)
> >  
> > i = 0;
> > do {
> > -   if (devm_gpio_request(>dev, state->gpio_addrs[i],
> > - DRIVER_NAME)) {
> > +   unsigned int *gpio_id = (unsigned int *)gpios->start;
> > +
> > +   if (devm_gpio_request_one(>dev, gpio_id[i], GPIOD_OUT_LOW,
> > +   DRIVER_NAME)) {
> > dev_err(>dev, "failed to request gpio %d\n",
> > -   state->gpio_addrs[i]);
> > +   gpio_id[i]);
> > return -EBUSY;
> > }
> > -   gpio_direction_output(state->gpio_addrs[i], 0);
> > -   } while (++i < state->gpio_count);
> > +
> > +   state->gpios->desc[i] = gpio_to_desc(gpio_id[i]);
> > +   if (!state->gpios->desc[i])
> > +   return -EINVAL;
> > +   } while (++i < state->gpios->ndescs);  
> 
> Actually, I was thinking about using devm_gpiod_get_array() here and
> defining a gpio lookup table in the board file registering the device.
> This way, adding support for DT based parsing is transparent.

It's actually easier than I thought since no one is registering such a
device, so all you have to do is call devm_gpiod_get_array() and have a
struct gpio_descs pointer in struct async_state.

[PATCH v2 2/3] i2c: mux: ltc4306: simplify code to reach the adapter

[Luca Ceresoli]

From: Luca Ceresoli 

struct i2c_client has a direct pointer to the adapter, no need to dig
it out of the struct device tree.

Suggested-by: Peter Rosin 
Signed-off-by: Luca Ceresoli 
---
 drivers/i2c/muxes/i2c-mux-ltc4306.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c 
b/drivers/i2c/muxes/i2c-mux-ltc4306.c
index a9af93259b19..83a714605cd6 100644
--- a/drivers/i2c/muxes/i2c-mux-ltc4306.c
+++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
@@ -208,7 +208,7 @@ MODULE_DEVICE_TABLE(of, ltc4306_of_match);
 
 static int ltc4306_probe(struct i2c_client *client)
 {
-   struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+   struct i2c_adapter *adap = client->adapter;
const struct chip_desc *chip;
struct i2c_mux_core *muxc;
struct ltc4306 *data;
-- 
2.17.1

[PATCH v2 1/3] i2c: mux: pca954x: simplify code to reach the adapter

[Luca Ceresoli]

From: Luca Ceresoli 

struct i2c_client has a direct pointer to the adapter, no need to dig
it out of the struct device tree.

Signed-off-by: Luca Ceresoli 
---
 drivers/i2c/muxes/i2c-mux-pca954x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c 
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 24bd9275fde5..bfabf985e830 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -347,7 +347,7 @@ static void pca954x_cleanup(struct i2c_mux_core *muxc)
 static int pca954x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+   struct i2c_adapter *adap = client->adapter;
struct pca954x_platform_data *pdata = dev_get_platdata(>dev);
struct device *dev = >dev;
struct device_node *np = dev->of_node;
-- 
2.17.1

[PATCH v2 3/3] i2c: mux: mlxcpld: simplify code to reach the adapter

[Luca Ceresoli]

From: Luca Ceresoli 

struct i2c_client has a direct pointer to the adapter, no need to dig
it out of the struct device tree.

Suggested-by: Peter Rosin 
Signed-off-by: Luca Ceresoli 
---
 drivers/i2c/muxes/i2c-mux-mlxcpld.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/muxes/i2c-mux-mlxcpld.c 
b/drivers/i2c/muxes/i2c-mux-mlxcpld.c
index f2bf3e57ed67..5ed55ca4fe93 100644
--- a/drivers/i2c/muxes/i2c-mux-mlxcpld.c
+++ b/drivers/i2c/muxes/i2c-mux-mlxcpld.c
@@ -132,7 +132,7 @@ static int mlxcpld_mux_deselect(struct i2c_mux_core *muxc, 
u32 chan)
 static int mlxcpld_mux_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
-   struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+   struct i2c_adapter *adap = client->adapter;
struct mlxcpld_mux_plat_data *pdata = dev_get_platdata(>dev);
struct i2c_mux_core *muxc;
int num, force;
-- 
2.17.1

Re: [PATCH] spi: pxa2xx: Mark expected switch fall-through

[Gustavo A. R. Silva]

On 10/3/18 5:22 PM, Mark Brown wrote:
> On Wed, Oct 03, 2018 at 02:12:11PM +0200, Gustavo A. R. Silva wrote:
> 
>>  switch (drv_data->n_bytes) {
>>  case 4:
>>  bytes_left >>= 1;
>> +/* Fall through */
>>  case 2:
>>  bytes_left >>= 1;
>>  }
> 
> I think this code is just being too cute and it'd be better to just
> rewrite it to directly do the expected number of shifts directly in each
> case and have break statements; your fix is good but still not ideal for
> readability I think.
> 

Okay. I agree. I'll rewrite and send v2.

Thanks
--
Gustavo

Re: [PATCH 2/4] mm: introduce put_user_page(), placeholder version

[Jan Kara]

On Thu 27-09-18 22:39:48, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> Introduces put_user_page(), which simply calls put_page().
> This provides a way to update all get_user_pages*() callers,
> so that they call put_user_page(), instead of put_page().
> 
> Also adds release_user_pages(), a drop-in replacement for
> release_pages(). This is intended to be easily grep-able,
> for later performance improvements, since release_user_pages
> is not batched like release_pages() is, and is significantly
> slower.

A small nit but can we maybe call this put_user_pages() for symmetry with
put_user_page()? I don't really care too much but it would look natural to
me.

Honza

-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v5 1/3] staging: mt7621-mmc: Remove #if 0 blocks

[Nishad Kamdar]

On Tue, Oct 02, 2018 at 03:16:36PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Oct 01, 2018 at 08:13:40PM +0530, Nishad Kamdar wrote:
> > This patch removes #if 0 code blocks and usages of
> > functions defined in the #if 0 blocks.
> > 
> > Signed-off-by: Nishad Kamdar 
> > ---
> >  drivers/staging/mt7621-mmc/dbg.c |  21 +--
> >  drivers/staging/mt7621-mmc/dbg.h |  14 --
> >  drivers/staging/mt7621-mmc/sd.c  | 269 ---
> >  3 files changed, 1 insertion(+), 303 deletions(-)
> 
> This patch did not apply :(

Oh, do you mean it gave conflicts while applying?
I'll check and resubmit it in that case.

Thanks for the review.

regards,
Nishad

[PATCH 2/2] pwm: Kconfig: Enable TI ECAP driver for ARCH_K3

[Vignesh R]

K3 devices have the same ECAP IP as OMAP SoC. Enable driver to be built
for K3 devices.

Signed-off-by: Vignesh R 
Signed-off-by: Sekhar Nori 
---
 drivers/pwm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 504d252716f2..0c7bc6f554cf 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -447,7 +447,7 @@ config PWM_TEGRA
 
 config  PWM_TIECAP
tristate "ECAP PWM support"
-   depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE
+   depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE || 
ARCH_K3
help
  PWM driver support for the ECAP APWM controller found on AM33XX
  TI SOC
-- 
2.19.0

Re: [PATCH v2 4/5] locking/lockdep: Make class->ops a percpu counter

[Waiman Long]

On 10/03/2018 09:57 AM, Waiman Long wrote:
> On 10/03/2018 03:48 AM, Peter Zijlstra wrote:
>> On Tue, Oct 02, 2018 at 04:19:19PM -0400, Waiman Long wrote:
>>> +DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops);
>>> @@ -179,9 +181,30 @@ DECLARE_PER_CPU(struct lockdep_stats, lockdep_stats);
>>> }   \
>>> __total;\
>>>  })
>>> +
>>> +static inline void debug_class_ops_inc(struct lock_class *class)
>>> +{
>>> +   int idx;
>>> +
>>> +   idx = class - lock_classes;
>>> +   __this_cpu_inc(lock_class_ops[idx]);
>>> +}
>>> +
>>> +static inline unsigned long debug_class_ops_read(struct lock_class *class)
>>> +{
>>> +   int idx, cpu;
>>> +   unsigned long ops = 0;
>>> +
>>> +   idx = class - lock_classes;
>>> +   for_each_possible_cpu(cpu)
>>> +   ops += per_cpu(lock_class_ops[idx], cpu);
>>> +   return ops;
>>> +}
>> Would it make sense to stick that in struct lockdep_stats ?
>>
>> A little something like:
>>
>> struct lockdep_stats {
>>  /* ... */
>>  int lock_class_ops[MAX_LOCKDEP_KEYS];
>> };
>>
>> and then use:
>>
>>  debug_atomic_inc(lock_class_ops[idx]);
>>
> Yes, I can certainly do that. Thanks for pointing this out. Will post an
> updated patch just for this one.
>
> Cheers,
> Longman
>
Attached is the updated patch 4. Please let me know if you guys are OK
with that.

Cheers,
Longman

>From e615f62dfa155cbf9c04318f146570047f2c0c0c Mon Sep 17 00:00:00 2001
From: Waiman Long 
Date: Wed, 3 Oct 2018 11:36:24 -0400
Subject: [PATCH v3 4/5] locking/lockdep: Make class->ops a percpu counter

A sizable portion of the CPU cycles spent on the __lock_acquire() is used
up by the atomic increment of class->ops stat counter. By taking it out
from the lock_class structure and changing it to a per-cpu per-lock-class
counter, we can reduce the amount of cacheline contention on the class
structure when multiple CPUs are trying to acquire locks of the same
class simultaneously.

To limit the increase in memory consumption because of the percpu nature
of that counter, it is now put back under the CONFIG_DEBUG_LOCKDEP
config option. So the memory consumption increase will only occur if
CONFIG_DEBUG_LOCKDEP is defined. The lock_class structure, however,
is reduced in size by 16 bytes on 64-bit archs after ops removal and
a minor restructuring of the fields.

This patch also fixes a bug in the increment code as the counter is of
the unsigned long type, but atomic_inc() was used to increment it.

 v3: Move lock_class_ops[] into lockdep_stats structure.

Signed-off-by: Waiman Long 
---
 include/linux/lockdep.h|  7 +--
 kernel/locking/lockdep.c   | 11 ---
 kernel/locking/lockdep_internals.h | 27 +++
 kernel/locking/lockdep_proc.c  |  2 +-
 4 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index b0d0b51c4d85..1fd82ff99c65 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -99,13 +99,8 @@ struct lock_class {
 	 */
 	unsigned int			version;
 
-	/*
-	 * Statistics counter:
-	 */
-	unsigned long			ops;
-
-	const char			*name;
 	intname_version;
+	const char			*name;
 
 #ifdef CONFIG_LOCK_STAT
 	unsigned long			contention_point[LOCKSTAT_POINTS];
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index b7774ff2516f..57e3f153474f 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -138,7 +138,7 @@ static struct lock_list list_entries[MAX_LOCKDEP_ENTRIES];
  * get freed - this significantly simplifies the debugging code.
  */
 unsigned long nr_lock_classes;
-static struct lock_class lock_classes[MAX_LOCKDEP_KEYS];
+struct lock_class lock_classes[MAX_LOCKDEP_KEYS];
 
 static inline struct lock_class *hlock_class(struct held_lock *hlock)
 {
@@ -435,6 +435,7 @@ unsigned int max_lockdep_depth;
  * Various lockdep statistics:
  */
 DEFINE_PER_CPU(struct lockdep_stats, lockdep_stats);
+DEFINE_PER_CPU(unsigned long [MAX_LOCKDEP_KEYS], lock_class_ops);
 #endif
 
 /*
@@ -1391,7 +1392,9 @@ static void print_lock_class_header(struct lock_class *class, int depth)
 
 	printk("%*s->", depth, "");
 	print_lock_name(class);
-	printk(KERN_CONT " ops: %lu", class->ops);
+#ifdef CONFIG_DEBUG_LOCKDEP
+	printk(KERN_CONT " ops: %lu", debug_class_ops_read(class));
+#endif
 	printk(KERN_CONT " {\n");
 
 	for (bit = 0; bit < LOCK_USAGE_STATES; bit++) {
@@ -3226,7 +3229,9 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
 		if (!class)
 			return 0;
 	}
-	atomic_inc((atomic_t *)>ops);
+
+	debug_class_ops_inc(class);
+
 	if (very_verbose(class)) {
 		printk("\nacquire class [%px] %s", class->key, class->name);
 		if (class->name_version > 1)
diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index d459d624ba2a..88c847a41c8a 100644
--- 

[PATCH 1/2] dt-bindings: pwm: tiecap: Add TI AM654 SoC specific compatible

[Vignesh R]

Add a new compatible string "ti,am654-ecap" to support PWM ECAP IP of
TI AM654 SoC.

Signed-off-by: Vignesh R 
Signed-off-by: Sekhar Nori 
---
 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 06a363d9ccef..b9a1d7402128 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -7,6 +7,7 @@ Required properties:
   for da850  - compatible = "ti,da850-ecap", "ti,am3352-ecap", 
"ti,am33xx-ecap";
   for dra746 - compatible = "ti,dra746-ecap", "ti,am3352-ecap";
   for 66ak2g - compatible = "ti,k2g-ecap", "ti,am3352-ecap";
+  for am654  - compatible = "ti,am654-ecap", "ti,am3352-ecap";
 - #pwm-cells: should be 3. See pwm.txt in this directory for a description of
   the cells format. The PWM channel index ranges from 0 to 4. The only third
   cell flag supported by this binding is PWM_POLARITY_INVERTED.
-- 
2.19.0

[PATCH 3/3] HID: debug: fix the ring buffer writer implementation

[Vladis Dronov]

ring buffer implementation hid_debug_event() is strange allowing a lost
of data. it does not move head pointer on append and uses per-byte for()
loop. fix this by introducing a new ring buffer implementation, which
overwrites the oldest data in case of the ring buffer overflow. it uses
some calculations for the buffer pointers but only 2 or less memcpy()
calls.

Signed-off-by: Vladis Dronov 
---
 drivers/hid/hid-debug.c | 66 -
 1 file changed, 58 insertions(+), 8 deletions(-)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index de640e4132c7..63247ac4a9ce 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -661,20 +661,70 @@ EXPORT_SYMBOL_GPL(hid_dump_device);
 /* enqueue string to 'events' ring buffer */
 void hid_debug_event(struct hid_device *hdev, char *buf)
 {
-   unsigned i;
struct hid_debug_list *list;
-   unsigned long flags, flags2;
+   unsigned long flags1, flags2;
+   unsigned int part1, part2;
+   size_t len;
 
-   spin_lock_irqsave(>debug_list_lock, flags);
+   if (!buf || !buf[0])
+   return;
+
+   len = strlen(buf);
+
+   spin_lock_irqsave(>debug_list_lock, flags1);
list_for_each_entry(list, >debug_list, node) {
spin_lock_irqsave(>list_lock, flags2);
-   for (i = 0; buf[i]; i++)
-   list->hid_debug_buf[(list->tail + i) % 
HID_DEBUG_BUFSIZE] =
-   buf[i];
-   list->tail = (list->tail + i) % HID_DEBUG_BUFSIZE;
+
+   /* len >= BUFSIZE, copy the last HID_DEBUG_BUFSIZE-1 bytes */
+   if (len > HID_DEBUG_BUFSIZE - 1) {
+   memcpy(list->hid_debug_buf,
+   buf + len - (HID_DEBUG_BUFSIZE - 1),
+   HID_DEBUG_BUFSIZE - 1);
+
+   list->head = 0;
+   list->tail = HID_DEBUG_BUFSIZE - 1;
+   } else {
+   /* append data to the ring buffer */
+   part1 = min_t(size_t, HID_DEBUG_BUFSIZE - list->tail,
+   len);
+   part2 = len - part1;
+
+   memcpy(list->hid_debug_buf + list->tail, buf, part1);
+
+   /* check if head must be moved as the ring is full */
+   if ((list->tail < list->head) &&
+   (list->tail + part1 >= list->head)) {
+   list->head = list->tail + part1 + 1;
+
+   if (list->head >= HID_DEBUG_BUFSIZE)
+   list->head -= HID_DEBUG_BUFSIZE;
+   }
+
+   /* set tail after the end of appended data */
+   list->tail = list->tail + part1;
+   if (list->tail == HID_DEBUG_BUFSIZE) {
+   list->tail = 0;
+   if (list->head == 0)
+   list->head = 1;
+   }
+
+   /* append the 2nd part of data to the ring */
+   if (part2 > 0) {
+   memcpy(list->hid_debug_buf, buf + part1, part2);
+
+   /* check if head must be moved again as
+* the ring is full
+*/
+   if (list->tail + part2 >= list->head)
+   list->head = list->tail + part2 + 1;
+
+   list->tail = list->tail + part2;
+   }
+   }
+
spin_unlock_irqrestore(>list_lock, flags2);
}
-   spin_unlock_irqrestore(>debug_list_lock, flags);
+   spin_unlock_irqrestore(>debug_list_lock, flags1);
 
wake_up_interruptible(>debug_wait);
 }
-- 
2.19.0

[PATCH 2/3] HID: debug: provide reader-writer locking for the ring buffer

[Vladis Dronov]

hdev->debug_list->hid_debug_buf is not protected from concurrent updates
from the writer, hid_debug_event() and reads by the reader,
hid_debug_events_read(). Fix this by adding per-list-element spinlock.
Also introduce a temporary buffer tempbuf so copy_to_user() is not called
from under a spinlock.

Signed-off-by: Vladis Dronov 
---
 drivers/hid/hid-debug.c   | 47 +++
 include/linux/hid-debug.h |  1 +
 2 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 20580871b0ec..e827784baf1a 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -663,15 +663,17 @@ void hid_debug_event(struct hid_device *hdev, char *buf)
 {
unsigned i;
struct hid_debug_list *list;
-   unsigned long flags;
+   unsigned long flags, flags2;
 
spin_lock_irqsave(>debug_list_lock, flags);
list_for_each_entry(list, >debug_list, node) {
+   spin_lock_irqsave(>list_lock, flags2);
for (i = 0; buf[i]; i++)
list->hid_debug_buf[(list->tail + i) % 
HID_DEBUG_BUFSIZE] =
buf[i];
list->tail = (list->tail + i) % HID_DEBUG_BUFSIZE;
-}
+   spin_unlock_irqrestore(>list_lock, flags2);
+   }
spin_unlock_irqrestore(>debug_list_lock, flags);
 
wake_up_interruptible(>debug_wait);
@@ -1095,6 +1097,7 @@ static int hid_debug_events_open(struct inode *inode, 
struct file *file)
}
list->hdev = (struct hid_device *) inode->i_private;
file->private_data = list;
+   spin_lock_init(>list_lock);
mutex_init(>read_mutex);
 
spin_lock_irqsave(>hdev->debug_list_lock, flags);
@@ -1109,6 +1112,8 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
size_t count, loff_t *ppos)
 {
struct hid_debug_list *list = file->private_data;
+   char *tmpbuf;
+   unsigned long flags;
int ret = 0, len;
DECLARE_WAITQUEUE(wait, current);
 
@@ -1151,10 +1156,18 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
if (ret)
goto out;
 
-   /* pass the ringbuffer content to userspace */
+   tmpbuf = kmalloc(min_t(size_t, count, HID_DEBUG_BUFSIZE),
+GFP_KERNEL|__GFP_NOWARN);
+   if (!tmpbuf) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   /* lock and copy the ringbuffer content to tmpbuf */
+   spin_lock_irqsave(>list_lock, flags);
 copy_rest:
if (list->tail == list->head)
-   goto out;
+   goto out_unlock;
 
/* the data from the head to the tail in the buffer is linear */
if (list->tail > list->head) {
@@ -1162,11 +1174,7 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
if (len > count)
len = count;
 
-   if (copy_to_user(buffer + ret,
- >hid_debug_buf[list->head], len)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   memcpy(tmpbuf + ret, >hid_debug_buf[list->head], len);
ret += len;
list->head += len;
} else {
@@ -1180,19 +1188,11 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
if (len > count) {
len = count;
 
-   if (copy_to_user(buffer,
- >hid_debug_buf[list->head], len)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   memcpy(tmpbuf, >hid_debug_buf[list->head], len);
ret += len;
list->head += len;
} else {
-   if (copy_to_user(buffer,
- >hid_debug_buf[list->head], len)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   memcpy(tmpbuf, >hid_debug_buf[list->head], len);
list->head = 0;
ret += len;
count -= len;
@@ -1202,6 +1202,15 @@ static ssize_t hid_debug_events_read(struct file *file, 
char __user *buffer,
goto copy_rest;
}
}
+
+out_unlock:
+   spin_unlock_irqrestore(>list_lock, flags);
+
+   /* copy out tmpbuf content to userspace */
+   if (ret && copy_to_user(buffer, tmpbuf, ret))
+   ret = -EFAULT;
+   kfree(tmpbuf);
+
 out:
mutex_unlock(>read_mutex);
return ret;
diff --git a/include/linux/hid-debug.h b/include/linux/hid-debug.h
index 8663f216c563..f58665651cb5 100644
--- a/include/linux/hid-debug.h
+++ 

Re: X86-64 uses generic string functions (strlen, strchr, memcmp, ...)

[Ingo Molnar]

* Jann Horn  wrote:

> Hi!
> 
> I noticed that X86-64 is using the generic string functions from
> lib/string.c for things like strlen(), strchr(), memcmp() and so on.
> Is that an intentional omission, because they're not considered worth
> optimizing, or is this an oversight? The kernel doesn't use string
> functions much, but if you e.g. run readlinkat() in a loop on a
> symlink with a 1000-byte target, something around 25%-50% of time are
> spent on strlen(). But that's a microbenchmark that people probably
> don't care about a lot?
> 
> One notable in-kernel user of memcmp() is BPF, which uses it for its
> hash table implementations when walking the linked list of a hash
> bucket. But I don't know whether anyone uses BPF hash tables with keys
> that are sufficiently large to make this noticeable?

One reason we've been resisting this is how hard it is to determine whether a 
micro-optimization truly helps application workloads.

But there's a way:

 - Write a 'perf bench vfs ...' kind of scalability microbenchmark that
   runs in less than 60 seconds, provides stable numeric output, can
   meaningfully measured via 'perf', etc., which does multi-threaded
   or multi-tasked, CPU-bound VFS operations intentionally designed
   to hit these string ops.

 - Use this benchmark to demonstrate that the performance of any of the
   string ops matters.

 - Implement nice assembly speedups.

 - If the functions are out of line then add a kernel patching based method
   to run either the generic string function or the assembly version -
   a static-key based approach would be fine I think. This makes the two
   versions runtime switchable.

 - Use the benchmark again to prove that it indeed helped this particular
   workload. It can be a small speedup but has to be a larger signal than the
   "perf stat --null --repeat 10 ..." stddev.

Then that offers a maintainable way to implement such speedups:

 - The 'perf bench vfs ...' testcase and the kernel-patching debug knobs allows 
other to 
   replicate and check out other hardware.  Does the assembly function written 
on contemporary 
   Intel hardware work equally well on AMD hardware? People can help out by 
running those 
   tests.

 - We can go back and check the difference anytime in the future, once new CPUs 
arrive,
   or a new variant of the benchmark is written, or a workload is hurting.

If you do it systematically like that then I'd be *very* interested in merging 
both the tooling 
(benchmarking) and any eventual assembly speedups.

But it's quite some work - much harder than just writing a random assembly 
variant and using it 
instead of the generic version.

Thanks,

Ingo

Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc

[Mike Rapoport]

On Tue, Oct 02, 2018 at 01:29:42PM -0700, David Rientjes wrote:
> On Tue, 2 Oct 2018, Michal Hocko wrote:
> 
> > On Wed 26-09-18 08:06:24, Michal Hocko wrote:
> > > On Tue 25-09-18 15:04:06, Andrew Morton wrote:
> > > > On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes 
> > > >  wrote:
> > > > 
> > > > > > > It is also used in 
> > > > > > > automated testing to ensure that vmas get disabled for thp 
> > > > > > > appropriately 
> > > > > > > and we used "nh" since that is how PR_SET_THP_DISABLE previously 
> > > > > > > enforced 
> > > > > > > this, and those tests now break.
> > > > > > 
> > > > > > This sounds like a bit of an abuse to me. It shows how an internal
> > > > > > implementation detail leaks out to the userspace which is something 
> > > > > > we
> > > > > > should try to avoid.
> > > > > > 
> > > > > 
> > > > > Well, it's already how this has worked for years before commit 
> > > > > 1860033237d4 broke it.  Changing the implementation in the kernel is 
> > > > > fine 
> > > > > as long as you don't break userspace who relies on what is exported 
> > > > > to it 
> > > > > and is the only way to determine if MADV_NOHUGEPAGE is preventing it 
> > > > > from 
> > > > > being backed by hugepages.
> > > > 
> > > > 1860033237d4 was over a year ago so perhaps we don't need to be
> > > > too worried about restoring the old interface.  In which case
> > > > we have an opportunity to make improvements such as that suggested
> > > > by Michal?
> > > 
> > > Yeah, can we add a way to export PR_SET_THP_DISABLE to userspace
> > > somehow? E.g. /proc//status. It is a process wide thing so
> > > reporting it per VMA sounds strange at best.
> > 
> > So how about this? (not tested yet but it should be pretty
> > straightforward)
> 
> Umm, prctl(PR_GET_THP_DISABLE)?
> 

~/git/linux$ git grep PR_GET_THP_DISABLE
include/uapi/linux/prctl.h:#define PR_GET_THP_DISABLE   42
kernel/sys.c:   case PR_GET_THP_DISABLE:
tools/include/uapi/linux/prctl.h:#define PR_GET_THP_DISABLE 42

-- 
Sincerely yours,
Mike.

Re: [PATCH 4.18 000/228] 4.18.12-stable review

[Guenter Roeck]

On Wed, Oct 03, 2018 at 12:53:11PM -0500, Rob Herring wrote:
> On Wed, Oct 3, 2018 at 12:24 PM Guenter Roeck  wrote:
> >
> > On Wed, Oct 03, 2018 at 09:25:39AM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Oct 03, 2018 at 05:59:09AM -0700, Guenter Roeck wrote:
> > > > On 10/02/2018 06:21 AM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.18.12 release.
> > > > > There are 228 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 Oct  4 13:24:08 UTC 2018.
> > > > > Anything received after that time might be too late.
> > > > >
> > > >
> > > >
> > > >
> > > > Build results:
> > > > total: 137 pass: 137 fail: 0
> > > > Qemu test results:
> > > > total: 321 pass: 320 fail: 1
> > > > Failed tests:
> > > > powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
> > >
> > > What is the status of that powerpc failure fix?  What's the odds it can
> > > get into mainline soon?
> > >
> >
> > The fix has been -next for about a week.
> >
> > da08d8cb8cfc of: unittest: Disable interrupt node tests for old world MAC 
> > systems
> >
> > You'll have to ask Rob (copied) if he plans to send a pull request before
> > the next commit window opens.
> 
> I wasn't planning to as it's just for the unittest and has been that
> way for how long? Why's the unittest enabled for a defconfig anyways?
> 

I enabled it to improve test coverage for stable releases. This is how
I found the problem in the first place. Are you suggesting that I should
not run DT unit tests for stable release candidates ?

> There was another g3beige fix (e54192b48da7 of: fix phandle cache
> creation for DTs with no phandles) which is tagged for stable. Not
> sure if qemu would hit the issue though.
> 

Depends if there is a test that can be enabled which hits the problem.

Thanks,
Guenter

Re: [PATCH] regulator: fixed: Default enable high on DT regulators

[Leonard Crestez]

On Wed, 2018-10-03 at 13:10 +0100, Mark Brown wrote:
> On Tue, Oct 02, 2018 at 01:42:38PM +, Leonard Crestez wrote:
> 
> > This turns the phy off and on again instead of leaving it up from uboot
> > and it doesn't work for some reason. However looking at
> > reg_fixed_voltage_probe introducing an edge seems to be intentional for
> > regulators which are not marked with "enabled-at-boot". Right?
> 
> No, that's definitely not desired.  We don't want to change the state of
> the regulator at all if we can avoid it unless the user explicitly asked
> for it.

That also makes sense, for a top level perspective. But
reg_fixed_voltage_probe contains the following snippet:

if (config->enabled_at_boot) {
if (config->enable_high)
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
else
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
} else {
if (config->enable_high)
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
else
cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
}

Unless config->enabled_at_boot the GPIO is initialized with the
opposite polarity of enabled. This means that fixed regulators which
are not marked with "enabled-at-boot" but happen to be "on" anyway are
always power cycled.

This is from before recent changes by Linus, code dates from 2012
commit 25a53dfbfbfd ("regulator: fixed: Use core GPIO enable support").
Even before that the logic was similar:

drvdata->is_enabled = config->enabled_at_boot;
ret = drvdata->is_enabled ?
config->enable_high : !config->enable_high;
gpio_flag = ret ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;

Looking further back it seems that this behavior has always been
present in fixed-regulator code.

In theory it might be possible to request the GPIO while asking to keep
the value from the bootloader? Maybe I'm confused but I don't see an
easy way to do this through the GPIO api; functions for requesting in
output mode all seem to also ask for the initial value.

GPIOD_ASIS looks close but it doesn't even adjust the direction.

> > It's possible that you exposed an imx board-specific bug: maybe power
> > cycling the phy after uboot needs some missing fixup?
> 
> It'd probably also be good to sort this out though.

Yes, handled separately: https://lore.kernel.org/patchwork/patch/994871/

Re: [GIT PULL] kselftest fixes update for Linux-4.19-rc7

[Greg Kroah-Hartman]

On Wed, Oct 03, 2018 at 08:42:13AM -0600, Shuah Khan wrote:
> Hi Greg,
> 
> Please pull the following kselftest for 4.19-rc7.
> 
> linux-kselftest-4.19-rc7
> 
> This fixes update for 4.19-rc7 consists one fix to rseq test to prevent
> it from seg-faulting when compiled with -fpie.

Now merged, thanks.

greg k-h

[PATCH] Fix compat_sys_preadv64v2/compat_sys_pwritev64v2

[H.J. Lu]

Update compat_sys_preadv64v2 and compat_sys_pwritev64v2 to handle the
offset argument == -1, which should use and update the the current file
offset.

Signed-off-by: H.J. Lu 
---
 fs/read_write.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fs/read_write.c b/fs/read_write.c
index 153f8f690490..c1d183862c13 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1241,6 +1241,9 @@ COMPAT_SYSCALL_DEFINE5(preadv64v2, unsigned long, fd,
const struct compat_iovec __user *,vec,
unsigned long, vlen, loff_t, pos, rwf_t, flags)
 {
+   if (pos == -1)
+   return do_compat_readv(fd, vec, vlen, flags);
+
return do_compat_preadv64(fd, vec, vlen, pos, flags);
 }
 #endif
@@ -1347,6 +1350,9 @@ COMPAT_SYSCALL_DEFINE5(pwritev64v2, unsigned long, fd,
const struct compat_iovec __user *,vec,
unsigned long, vlen, loff_t, pos, rwf_t, flags)
 {
+   if (pos == -1)
+   return do_compat_writev(fd, vec, vlen, flags);
+
return do_compat_pwritev64(fd, vec, vlen, pos, flags);
 }
 #endif
-- 
2.17.1

X86-64 uses generic string functions (strlen, strchr, memcmp, ...)

[Jann Horn]

Hi!

I noticed that X86-64 is using the generic string functions from
lib/string.c for things like strlen(), strchr(), memcmp() and so on.
Is that an intentional omission, because they're not considered worth
optimizing, or is this an oversight? The kernel doesn't use string
functions much, but if you e.g. run readlinkat() in a loop on a
symlink with a 1000-byte target, something around 25%-50% of time are
spent on strlen(). But that's a microbenchmark that people probably
don't care about a lot?

One notable in-kernel user of memcmp() is BPF, which uses it for its
hash table implementations when walking the linked list of a hash
bucket. But I don't know whether anyone uses BPF hash tables with keys
that are sufficiently large to make this noticeable?

Re: [PATCH] spi: slave: Fix missing break in switch

[Geert Uytterhoeven]

Hi Gustavo,

On Wed, Oct 3, 2018 at 5:05 PM Gustavo A. R. Silva
 wrote:
> On 10/3/18 5:01 PM, Mark Brown wrote:
> > On Wed, Oct 03, 2018 at 04:46:45PM +0200, Geert Uytterhoeven wrote:
> >> On Wed, Oct 3, 2018 at 2:57 PM Gustavo A. R. Silva
> >
> >>> case CMD_REBOOT:
> >>> dev_info(>spi->dev, "Rebooting system...\n");
> >>> kernel_restart(NULL);
> >>> +   break;
> >
> >> Alternatively, kernel_restart() and friends could be marked __noreturn.
> >
> > Yes, that seems more sensible though there's no harm in this patch even
> > with that.  It'd definitely avoid other issues in future.
>
> I'll include the __noreturn in addition to the break statement.
> I'll send v2 shortly.

Please note that adding __noreturn is not a trivial task, due to the complex
call chains, and the different implementations on the various architectures
and platforms.  So that will be a big patch series.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 6/8] mtd: maps: gpio-addr-flash: Convert to gpiod

[Boris Brezillon]

Hi Ricardo,

On Mon,  1 Oct 2018 14:43:49 +0200
Ricardo Ribalda Delgado  wrote:

> @@ -248,14 +252,19 @@ static int gpio_flash_probe(struct platform_device 
> *pdev)
>  
>   i = 0;
>   do {
> - if (devm_gpio_request(>dev, state->gpio_addrs[i],
> -   DRIVER_NAME)) {
> + unsigned int *gpio_id = (unsigned int *)gpios->start;
> +
> + if (devm_gpio_request_one(>dev, gpio_id[i], GPIOD_OUT_LOW,
> + DRIVER_NAME)) {
>   dev_err(>dev, "failed to request gpio %d\n",
> - state->gpio_addrs[i]);
> + gpio_id[i]);
>   return -EBUSY;
>   }
> - gpio_direction_output(state->gpio_addrs[i], 0);
> - } while (++i < state->gpio_count);
> +
> + state->gpios->desc[i] = gpio_to_desc(gpio_id[i]);
> + if (!state->gpios->desc[i])
> + return -EINVAL;
> + } while (++i < state->gpios->ndescs);

Actually, I was thinking about using devm_gpiod_get_array() here and
defining a gpio lookup table in the board file registering the device.
This way, adding support for DT based parsing is transparent.

Regards,

Boris

Re: [PATCH] spi: slave: Fix missing break in switch

[Mark Brown]

On Wed, Oct 03, 2018 at 05:05:04PM +0200, Gustavo A. R. Silva wrote:

> I'll include the __noreturn in addition to the break statement.
> I'll send v2 shortly.

No need for a v2, I already applied this - adding __noreturn seems like
a separate (although desirable) effort.


signature.asc
Description: PGP signature

Re: [RFC PATCH 07/10] arch/x86: Bring few more functions into the resource structure

[Moger, Babu]

On 10/02/2018 05:07 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/24/2018 12:19 PM, Moger, Babu wrote:
>> Bring all resource functions that are different between the vendors
>> into resource structure and initialize them dynamically.
>>
>> Implement these functions separately for each vendors.
>> update_mba_bw : Feedback loop bandwidth update functionality is not
>> needed for AMD.
>> cbm_validate  : Cache bitmask validate function. AMD allows
>> non-contiguous masks. So, use separate functions for
>> Intel and AMD.
>>
>> Signed-off-by: Babu Moger 
>> ---
>>  arch/x86/kernel/cpu/rdt.c | 17 +
>>  arch/x86/kernel/cpu/rdt.h | 19 +--
>>  arch/x86/kernel/cpu/rdt_ctrlmondata.c |  4 ++--
>>  arch/x86/kernel/cpu/rdt_monitor.c | 10 +++---
>>  4 files changed, 35 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/rdt.c b/arch/x86/kernel/cpu/rdt.c
>> index 6dec45bf81d6..ae26b9b3fafa 100644
>> --- a/arch/x86/kernel/cpu/rdt.c
>> +++ b/arch/x86/kernel/cpu/rdt.c
>> @@ -867,10 +867,19 @@ static __init void rdt_init_res_defs_intel(void)
>>  struct rdt_resource *r;
>>  
>>  for_each_rdt_resource(r) {
>> -if (r->rid == RDT_RESOURCE_MBA) {
>> -r->msr_base = IA32_MBA_THRTL_BASE;
>> -r->msr_update = mba_wrmsr;
>> -r->parse_ctrlval = parse_bw;
>> +if ((r->rid == RDT_RESOURCE_L3) ||
>> +(r->rid == RDT_RESOURCE_L3DATA) ||
>> +(r->rid == RDT_RESOURCE_L3CODE) ||
>> +(r->rid == RDT_RESOURCE_L2) ||
>> +(r->rid == RDT_RESOURCE_L2DATA) ||
>> +(r->rid == RDT_RESOURCE_L2CODE))
>> +r->cbm_validate = cbm_validate;
> 
> Same comment here about naming as in patch 6. Later cbm_validate_amd
> would appear while this remains - to help reduce confusion it may help
> to rename this function to cbm_validate_intel at this time.

Sure.  Will make this change.

> 
>> +
>> +else if (r->rid == RDT_RESOURCE_MBA) {
>> + r->msr_base = IA32_MBA_THRTL_BASE;
>> + r->msr_update = mba_wrmsr;
>> + r->parse_ctrlval = parse_bw;
>> + r->update_mba_bw = update_mba_bw;
> 
> Same comment about naming.

Yes.  Will add _intel to these functions.

> 
>>  }
>>  }
>>  }
>> diff --git a/arch/x86/kernel/cpu/rdt.h b/arch/x86/kernel/cpu/rdt.h
>> index 2569c10c37f4..7205157d359b 100644
>> --- a/arch/x86/kernel/cpu/rdt.h
>> +++ b/arch/x86/kernel/cpu/rdt.h
>> @@ -386,9 +386,9 @@ static inline bool is_mbm_event(int e)
>>   * struct rdt_resource - attributes of an RDT resource
>>   * @rid:The index of the resource
>>   * @alloc_enabled:  Is allocation enabled on this machine
>> - * @mon_enabled:Is monitoring enabled for this feature
>> + * @mon_enabled:Is monitoring enabled for this feature
>>   * @alloc_capable:  Is allocation available on this machine
>> - * @mon_capable:Is monitor feature available on this machine
>> + * @mon_capable:Is monitor feature available on this machine
>>   * @name:   Name to use in "schemata" file
>>   * @num_closid: Number of CLOSIDs available
>>   * @cache_level:Which cache level defines scope of this resource
>> @@ -400,10 +400,12 @@ static inline bool is_mbm_event(int e)
>>   * @cache:  Cache allocation related data
>>   * @format_str: Per resource format string to show domain value
>>   * @parse_ctrlval:  Per resource function pointer to parse control values
>> - * @evt_list:   List of monitoring events
>> - * @num_rmid:   Number of RMIDs available
>> - * @mon_scale:  cqm counter * mon_scale = occupancy in 
>> bytes
>> - * @fflags: flags to choose base and info files
>> + * @update_mba_bw:  Feedback loop for MBA software controllerer function
> 
> controllerer -> controller ?

Yes. Will fix it.

> 
>> + * @cbm_validateCache bitmask validate function
>> + * @evt_list:   List of monitoring events
>> + * @num_rmid:   Number of RMIDs available
>> + * @mon_scale:  cqm counter * mon_scale = occupancy in bytes
>> + * @fflags: flags to choose base and info files
>>   */
>>  struct rdt_resource {
>>  int rid;
>> @@ -425,6 +427,9 @@ struct rdt_resource {
>>  const char  *format_str;
>>  int (*parse_ctrlval)(void *data, struct rdt_resource *r,
>>   struct rdt_domain *d);
>> +void (*update_mba_bw)   (struct rdtgroup *rgrp,
>> + struct rdt_domain *dom_mbm);
>> +bool (*cbm_validate)(char *buf, u32 *data, struct rdt_resource *r);
>>  struct list_headevt_list;
>>  int num_rmid;

Re: [PATCH 5/6] lib/scatterlist: Use appropriate type for elem_len in sgl_alloc_order

[Bart Van Assche]

On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We should not use an explicit width u32 for elem_len but unsinged int to
> match the underlying type in struct scatterlist.

Reviewed-by: Bart Van Assche 

[PATCH v9 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads

[Alexey Budankov]

Currently in record mode the tool implements trace writing serially. 
The algorithm loops over mapped per-cpu data buffers and stores 
ready data chunks into a trace file using write() system call.

At some circumstances the kernel may lack free space in a buffer 
because the other buffer's half is not yet written to disk due to 
some other buffer's data writing by the tool at the moment.

Thus serial trace writing implementation may cause the kernel 
to loose profiling data and that is what observed when profiling 
highly parallel CPU bound workloads on machines with big number 
of cores.

Experiment with profiling matrix multiplication code executing 128 
threads on Intel Xeon Phi (KNM) with 272 cores, like below,
demonstrates data loss metrics value of 98%:

/usr/bin/time perf record -o /tmp/perf-ser.data -a -N -B -T -R -g \
--call-graph dwarf,1024 --user-regs=IP,SP,BP --switch-events \
-e cycles,instructions,ref-cycles,software/period=1,name=cs,config=0x3/Duk 
-- \
matrix.gcc

Data loss metrics is the ratio lost_time/elapsed_time where 
lost_time is the sum of time intervals containing PERF_RECORD_LOST 
records and elapsed_time is the elapsed application run time 
under profiling.

Applying asynchronous trace streaming thru Posix AIO API [1] lowers 
data loss metrics value providing 2x improvement (from 98% to ~1%)

Asynchronous trace streaming currently limited to glibc linkage
because there may be other libc libraries linked by Perf tool 
that currently lack Posix AIO API support [2], [3], [4]. 
NO_AIO define may be used to limit Perf tool binary to 
serial streaming only.

---
 Alexey Budankov (3):
perf util: map data buffer for preserving collected data
perf record: enable asynchronous trace writing
perf record: extend trace writing to multi AIO

 tools/perf/Makefile.config  |   5 ++
 tools/perf/Makefile.perf|   7 +-
 tools/perf/builtin-record.c | 197 +++-
 tools/perf/perf.h   |   3 +
 tools/perf/util/evlist.c|   9 +-
 tools/perf/util/evlist.h|   3 +-
 tools/perf/util/mmap.c  | 137 ++
 tools/perf/util/mmap.h  |  16 
 8 files changed, 369 insertions(+), 8 deletions(-)

---
 Changes in v9:
 - enable AIO streaming only when --aio-cblocks option is specified explicitly
 - enable AIO based implementation when linking with glibc only
 - define NO_AIO to limit Perf binary to serial implementation
 Changes in v8:
 - run the whole thing thru checkpatch.pl and corrected found issues except
   lines longer than 80 symbols
 - corrected comments alignment and formatting
 - moved multi AIO implementation into 3rd patch in the series
 - implemented explicit cblocks array allocation
 - split AIO completion check into separate record__aio_complete()
 - set nr_cblocks default to 1 and max allowed value to 4
 Changes in v7:
 - implemented handling record.aio setting from perfconfig file
 Changes in v6:
 - adjusted setting of priorities for cblocks;
 - handled errno == EAGAIN case from aio_write() return;
 Changes in v5:
 - resolved livelock on perf record -e intel_pt// -- dd if=/dev/zero 
of=/dev/null count=10
 - data loss metrics decreased from 25% to 2x in trialed configuration;
 - reshaped layout of data structures;
 - implemented --aio option;
 - avoided nanosleep() prior calling aio_suspend();
 - switched to per-cpu aio multi buffer record__aio_sync();
 - record_mmap_read_sync() now does global sync just before 
   switching trace file or collection stop;
 Changes in v4:
 - converted mmap()/munmap() to malloc()/free() for mmap->data buffer management
 - converted void *bf to struct perf_mmap *md in signatures
 - written comment in perf_mmap__push() just before perf_mmap__get();
 - written comment in record__mmap_read_sync() on possible restarting 
   of aio_write() operation and releasing perf_mmap object after all;
 - added perf_mmap__put() for the cases of failed aio_write();
 Changes in v3:
 - written comments about nanosleep(0.5ms) call prior aio_suspend()
   to cope with intrusiveness of its implementation in glibc;
 - written comments about rationale behind coping profiling data 
   into mmap->data buffer;
 Changes in v2:
 - converted zalloc() to calloc() for allocation of mmap_aio array,
 - cleared typo and adjusted fallback branch code;

---

[1] http://man7.org/linux/man-pages/man7/aio.7.html
[2] https://android.googlesource.com/platform/bionic/+/master/docs/status.md
[3] https://www.uclibc.org/
[4] https://uclibc-ng.org/

Re: [BUG] sound: pci: trident: a possible data race

[Takashi Iwai]

On Wed, 03 Oct 2018 14:50:25 +0200,
Jia-Ju Bai wrote:
> 
> CPU0:
> snd_trident_hw_free
> snd_trident_free_voice
> line 3870: spin_lock_irqsave()
> line 3881: voice->substream = NULL; [WRITE]
> CPU1:
> snd_trident_interrupt
> line 3798: snd_pcm_period_elapsed(voice->substream);  [READ]
> 
> As for voice->substream, the WRITE operation in CPU0 is performed
> with holding a spinlock, but the READ operation in CPU1 is performed
> without holding this spinlock, so there may exist a data race.

Thanks for the report.

The actual crash must be very unlikely, almost 0%, though.
snd_trident_hw_free() is called always after the PCM stream gets
stopped via trigger callback, i.e. at the moment, there is no
corresponding interrupt is generated for that voice entry.

And the hardware is very old, I bet only a handful people still using
in the whole world :)

If we really want to be 100% sure, we may call synchronize_irq()
before the NULL-clearing.  But there is no way to test the bug nor
the fix, so it's fairly moot, IMO.


thanks,

Takashi

Re: [PATCH] spi: pxa2xx: Mark expected switch fall-through

[Gustavo A. R. Silva]

On 10/3/18 5:27 PM, Gustavo A. R. Silva wrote:
> 
> 
> On 10/3/18 5:22 PM, Mark Brown wrote:
>> On Wed, Oct 03, 2018 at 02:12:11PM +0200, Gustavo A. R. Silva wrote:
>>
>>> switch (drv_data->n_bytes) {
>>> case 4:
>>> bytes_left >>= 1;
>>> +   /* Fall through */
>>> case 2:
>>> bytes_left >>= 1;
>>> }
>>
>> I think this code is just being too cute and it'd be better to just
>> rewrite it to directly do the expected number of shifts directly in each
>> case and have break statements; your fix is good but still not ideal for
>> readability I think.
>>
> 
> Okay. I agree. I'll rewrite and send v2.
> 

I'll actually send a completely new patch for this.

Thanks
--
Gustavo

[PATCH 1/2] dt-bindings: phy: Document cadence Sierra PHY bindings

[Alan Douglas]

Add DT binding documentation for Sierra PHY.  The PHY supports
a number of different protocols, including PCIe and USB.

The PHY lanes may be configured as single or multi-lane links.
Each link is treated as a separate sub-node.  For example, if
there are 4 lanes in total the first 2 might be configured as
a multi-lane PCIe link while the other two are single lane
USB links, and in this case there would be 3 sub-nodes.

There are two resets for the PHY block (one for APB register
access, one for the PHY link) and separate resets for each
link.  For multi-lane links, the reset corresponds to the
reset line on the master lane, the resets on other lanes
have no effect.

Signed-off-by: Alan Douglas 
---
 .../devicetree/bindings/phy/cdns-sierra-phy.txt| 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/cdns-sierra-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/cdns-sierra-phy.txt 
b/Documentation/devicetree/bindings/phy/cdns-sierra-phy.txt
new file mode 100644
index 000..0e2f3e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns-sierra-phy.txt
@@ -0,0 +1,68 @@
+Cadence Sierra PHY
+---
+
+Required properties:
+- compatible:  cdns,sierra-phy-t0
+- clocks:  Must contain an entry in clock-names.
+   See ../clocks/clock-bindings.txt for details.
+- clock-names: Must be "phy_clk"
+- resets:  Must contain an entry for each in reset-names.
+   See ../reset/reset.txt for details.
+- reset-names: Must include "sierra_reset" and "sierra_apb" and one for each
+   sub-node.
+   "sierra_reset" must control the reset line to the PHY.
+   "sierra_apb" must control the reset line to the APB PHY
+   interface.
+   The name of the reset for each sub-node should match the full
+   name of the sub-node.  The sub-node resets must control the
+   reset line for the master lane of the sub-node.
+- reg: register range for the PHY.
+- #address-cells: Must be 1
+- #size-cells: Must be 0
+
+Optional properties:
+- cdns,autoconf:   A boolean property whose presence indicates that the
+   PHY registers will be configured by hardware. If not
+   present, all sub-node optional properties must be
+   provided.
+
+Sub-nodes:
+  Each group of PHY lanes with a single master lane should be represented as
+  a sub-node. Note that the actual configuration of each lane is determined by
+  hardware strapping, and must match the configuration specified here.
+
+Sub-node required properties:
+- #phy-cells:  Generic PHY binding; must be 0.
+
+Sub-node optional properties:
+- reg: The master lane number.  This is the lowest numbered
+   lane in the lane group.
+- cdns,num-lanes:  Number of lanes in this group.  From 1 to 4.  The
+   group is made up of consecutive lanes.
+- cdns,phy-type:   Can be PHY_TYPE_PCIE or PHY_TYPE_USB3, depending on
+   configuration of lanes.
+
+Example:
+   pcie_phy4: pcie-phy@fd24 {
+   compatible = "cdns,sierra-phy-t0";
+   reg = <0x0 0xfd24 0x0 0x4>;
+   resets = < 0>, < 1>, < 2>, < 4>;
+   reset-names = "sierra_reset", "sierra_apb",
+   "pcie_phy@0", "pcie_phy@2";
+   clocks = <>;
+   clock-names = "phy_clk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pcie0_phy0: pcie-phy@0 {
+   reg = <0>;
+   cdns,num-lanes = <2>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   };
+   pcie0_phy1: pcie-phy@2 {
+   reg = <2>;
+   cdns,num-lanes = <1>;
+   #phy-cells = <0>;
+   cdns,phy-type = ;
+   };
+
-- 
1.9.0

[PATCH 0/2] phy: cadence: Add driver and dt-bindings for Sierra PHY

[Alan Douglas]

The Cadence Sierra PHY supports a number of different protocols.  This
series adds a driver with support for USB3 and PCIe modes.

Only one clock frequency is currently supported, so the value of clock
provided in device tree is ignored.

Changes since RFC v2:
* Devicetree bindings modified as suggested by Rob Herring.
* Tidy up and correction of return paths in probe function.

Changes since RFC v1:
* Each group of lanes is now treated as a subnode, and a generic PHY
  device is created for each group.
* General cleanup based on comments
* A reset is now required for each subnode.  The complete PHY block
  is taken out of reset at initial probe, and remains out of reset.
* Added a binding to allow for hardware configuration of PHY registers


Alan Douglas (2):
  dt-bindings: phy: Document cadence Sierra PHY bindings
  phy: cadence: Add driver for Sierra PHY

 .../devicetree/bindings/phy/cdns-sierra-phy.txt|  68 
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/cadence/Kconfig|   9 +
 drivers/phy/cadence/Makefile   |   2 +
 drivers/phy/cadence/cdns-sierra.c  | 380 +
 6 files changed, 461 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/cdns-sierra-phy.txt
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/cdns-sierra.c

-- 
1.9.0

Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps

[Jan Kara]

On Tue 02-10-18 11:14:47, Dave Chinner wrote:
> On Mon, Oct 01, 2018 at 05:47:57AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 01, 2018 at 04:11:27PM +1000, Dave Chinner wrote:
> > > This reminds me so much of Linux mmap() in the mid-2000s - mmap()
> > > worked for ext3 without being aware of page faults,
> > 
> > And "worked" still is a bit of a stretch, as soon as you'd get
> > ENOSPC it would still blow up badly.  Which probably makes it an
> > even better analogy to the current case.
> > 
> > > RDMA does not call ->page_mkwrite on clean file backed pages before it
> > > writes to them and calls set_page_dirty(), and hence RDMA to file
> > > backed pages is completely unreliable. I'm not sure this can be
> > > solved without having page fault capable RDMA hardware
> > 
> > We can always software prefault at gup time.
> 
> I'm not sure that's sufficient - we've got a series of panics from
> machines running ext4+RDMA where there are no bufferheads on dirty
> pages at writeback time. This was also reproducable on versions of
> XFS that used bufferheads.
> 
> We suspect that memory reclaim has tripped the bufferhead stripping
> threshold (yeah, that old ext3 hack to avoid writeback deadlocks
> under memory pressure), hence removed the bufferheads from clean
> mapped pages while RDMA has them pinned. And then some time later
> after set_page_dirty() was called on them the filesystem's page
> writeback code crashes and burns
> 
> i.e. just because the page was in a known state at when it was
> pinned, it doesn't mean it will remain in that state until it is
> unpinned

Exactly. The problem really is GUP user can call set_page_dirty() after the
page has been unmapped from all page tables and thus filesystem is totaly
unprepared to handle that.

> > And also remember that
> > while RDMA might be the case at least some people care about here it
> > really isn't different from any of the other gup + I/O cases, including
> > doing direct I/O to a mmap area.  The only difference in the various
> > cases is how long the area should be pinned down - some users like RDMA
> > want a long term mapping, while others like direct I/O just need a short
> > transient one.
> 
> Yup, now that I'm aware of all those little intricacies with gup I
> always try to consider what impact they have...
> 
> > > We could address these use-after-free situations via forcing RDMA to
> > > use file layout leases and revoke the lease when we need to modify
> > > the backing store on leased files. However, this doesn't solve the
> > > need for filesystems to receive write fault notifications via
> > > ->page_mkwrite.
> > 
> > Exactly.   We need three things here:
> > 
> >  - notification to the filesystem that a page is (possibly) beeing
> >written to
> >  - a way to to block fs operations while the pages are pinned
> >  - a way to distinguish between short and long term mappings,
> >and only allow long terms mappings if they can be broken
> >using something like leases

Actually when using page cache, we should be fine with just knowing the
page it pinned by GUP. Writeback can then use bounce buffers to handle
data integrity writeout requests, skip periodic writeback, and keep page
dirty all the time it is pinned. That should deal with all the problems we
are currently aware of.

With DAX more is needed as truncate cannot proceed with pending GUP
references. So there we really need all you mention above. But for DAX we
have much more wiggle room how to define behavior and what we declare as
unsupported as DAX is new and it was never really used with RDMA and stuff.

> > I'm also pretty sure we already explained this a long time ago when the
> > issue came up last year, so I'm not sure why this is even still
> > contentious.
> 
> I suspect that it's simply because these discussions have been
> spread across different groups and not everyone is aware of what the
> other groups are discussing...

Yes, I have the same feeling.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] cdrom: fix improper type cast, which can leat to information leak.

[Jens Axboe]

On 10/3/18 6:54 AM, Yang Xiao wrote:
> From: Young_X 
> 
> There is another cast from unsigned long to int which causes
> a bounds check to fail with specially crafted input. The value is
> then used as an index in the slot array in cdrom_slot_status().
> 
> This issue is similar to CVE-2018-16658 and CVE-2018-10940.

Applied, thanks.

-- 
Jens Axboe

[PATCH 0/3] ARM: dts: stm32: add dmas to stm32mp157c timers

[Fabrice Gasnier]

This series adds dmas description to stm32mp157c device tree file.
But dmas are kept disabled by default on all boards. They are only
necessary for PWM capture. So, spare them for other usage by default.

Fabrice Gasnier (3):
  ARM: dts: stm32: Add dmas to timer on stm32mp157c
  ARM: dts: stm32: don't use timers dmas on stm32mp157c-ed1
  ARM: dts: stm32: don't use timers dmas on stm32mp157c-ev1

 arch/arm/boot/dts/stm32mp157c-ed1.dts |  3 ++
 arch/arm/boot/dts/stm32mp157c-ev1.dts |  7 +
 arch/arm/boot/dts/stm32mp157c.dtsi| 58 +++
 3 files changed, 68 insertions(+)

-- 
1.9.1

[PATCH 3/3] ARM: dts: stm32: don't use timers dmas on stm32mp157c-ev1

[Fabrice Gasnier]

Spare dmas when using timers on stm32mp157c-ev1.

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/boot/dts/stm32mp157c-ev1.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts 
b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 372bc2e..89bb35d 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -100,6 +100,9 @@
 };
 
  {
+   /* spare dmas for other usage (un-delete to enable pwm capture) */
+   /delete-property/dmas;
+   /delete-property/dma-names;
status = "disabled";
pwm {
pinctrl-0 = <_pins_a>;
@@ -112,6 +115,8 @@
 };
 
  {
+   /delete-property/dmas;
+   /delete-property/dma-names;
status = "disabled";
pwm {
pinctrl-0 = <_pins_a>;
@@ -124,6 +129,8 @@
 };
 
  {
+   /delete-property/dmas;
+   /delete-property/dma-names;
status = "disabled";
pwm {
pinctrl-0 = <_pins_a>;
-- 
1.9.1

[PATCH v2] Bluetooth: hci_qca: Add support for controller debug logs.

[Balakrishna Godavarthi]

This patch will prevent error messages splashing on console.

[   78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet for 
unknown connection handle 3804
[   78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet for 
unknown connection handle 3804
[   78.446639] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet for 
unknown connection handle 3804
[   78.456596] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet for 
unknown connection handle 3804

QCA wcn3990 will send the debug logs in the form of ACL packets.
While decoding packet in qca_recv(), marking the received debug log
packet as diagnostic packet.

Signed-off-by: Harish Bandi 
Signed-off-by: Balakrishna Godavarthi 
---
v2: 
  * Addressed reviewer comments.
v1: 
  * initial patch
---
 drivers/bluetooth/hci_qca.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index d98ed0442201..63ac3c6b4149 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -63,6 +63,10 @@
 /* susclk rate */
 #define SUSCLK_RATE_32KHZ  32768
 
+/* Controller debug log header */
+#define QCA_DEBUG_HDR_MSB  0xDC
+#define QCA_DEBUG_HDR_LSB  0x2E
+
 /* HCI_IBS transmit side sleep protocol states */
 enum tx_ibs_states {
HCI_IBS_TX_ASLEEP,
@@ -849,6 +853,20 @@ static int qca_ibs_wake_ack(struct hci_dev *hdev, struct 
sk_buff *skb)
return 0;
 }
 
+static int qca_recv_acl_data(struct hci_dev *hdev, struct sk_buff *skb)
+{
+   /* We receive debug logs from chip as an ACL packets.
+* Instead of sending the data to ACL to decode the
+* received data, we are pushing them to the above layers
+* as a diagnostic packet.
+*/
+   if ((skb->len > 2) && (skb->data[0] == QCA_DEBUG_HDR_MSB) &&
+   (skb->data[1] == QCA_DEBUG_HDR_LSB))
+   return hci_recv_diag(hdev, skb);
+
+   return hci_recv_frame(hdev, skb);
+}
+
 #define QCA_IBS_SLEEP_IND_EVENT \
.type = HCI_IBS_SLEEP_IND, \
.hlen = 0, \
@@ -871,7 +889,7 @@ static int qca_ibs_wake_ack(struct hci_dev *hdev, struct 
sk_buff *skb)
.maxlen = HCI_MAX_IBS_SIZE
 
 static const struct h4_recv_pkt qca_recv_pkts[] = {
-   { H4_RECV_ACL, .recv = hci_recv_frame},
+   { H4_RECV_ACL, .recv = qca_recv_acl_data },
{ H4_RECV_SCO, .recv = hci_recv_frame},
{ H4_RECV_EVENT,   .recv = hci_recv_frame},
{ QCA_IBS_WAKE_IND_EVENT,  .recv = qca_ibs_wake_ind  },
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] kvm: nVMX: fix entry with pending interrupt if APICv is enabled

[Paolo Bonzini]

Commit b5861e5cf2fcf83031ea3e26b0a69d887adf7d21 introduced a check on
the interrupt-window and NMI-window CPU execution controls in order to
inject an external interrupt vmexit before the first guest instruction
executes.  However, when APIC virtualization is enabled the host does not
need a vmexit in order to inject an interrupt at the next interrupt window;
instead, it just places the interrupt vector in RVI and the processor will
inject it as soon as possible.  Therefore, on machines with APICv it is
not enough to check the CPU execution controls: the same scenario can also
happen if RVI>0.

Fixes: b5861e5cf2fcf83031ea3e26b0a69d887adf7d21
Cc: Nikita Leshchenko 
Cc: Sean Christopherson 
Cc: Liran Alon 
Cc: Radim Krčmář 
Signed-off-by: Paolo Bonzini 
---
 arch/x86/kvm/vmx.c | 38 ++
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6ef2d5b139b9..c7ae8ea87bc4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6162,6 +6162,11 @@ static void vmx_complete_nested_posted_interrupt(struct 
kvm_vcpu *vcpu)
nested_mark_vmcs12_pages_dirty(vcpu);
 }
 
+static u8 vmx_get_rvi(void)
+{
+   return vmcs_read16(GUEST_INTR_STATUS) & 0xff;
+}
+
 static bool vmx_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -6174,7 +6179,7 @@ static bool vmx_guest_apic_has_interrupt(struct kvm_vcpu 
*vcpu)
WARN_ON_ONCE(!vmx->nested.virtual_apic_page))
return false;
 
-   rvi = vmcs_read16(GUEST_INTR_STATUS) & 0xff;
+   rvi = vmx_get_rvi();
 
vapic_page = kmap(vmx->nested.virtual_apic_page);
vppr = *((u32 *)(vapic_page + APIC_PROCPRI));
@@ -10349,6 +10354,14 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu)
return max_irr;
 }
 
+static u8 vmx_has_apicv_interrupt(struct kvm_vcpu *vcpu)
+{
+   u8 rvi = vmx_get_rvi();
+   u8 vppr = kvm_lapic_get_reg(vcpu->arch.apic, APIC_PROCPRI);
+
+   return ((rvi & 0xf0) > (vppr & 0xf0));
+}
+
 static void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
 {
if (!kvm_vcpu_apicv_active(vcpu))
@@ -12593,10 +12606,13 @@ static int enter_vmx_non_root_mode(struct kvm_vcpu 
*vcpu, u32 *exit_qual)
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
bool from_vmentry = !!exit_qual;
u32 dummy_exit_qual;
-   u32 vmcs01_cpu_exec_ctrl;
+   bool evaluate_pending_interrupts;
int r = 0;
 
-   vmcs01_cpu_exec_ctrl = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
+   evaluate_pending_interrupts = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
+   (CPU_BASED_VIRTUAL_INTR_PENDING | 
CPU_BASED_VIRTUAL_NMI_PENDING);
+   if (likely(!evaluate_pending_interrupts) && kvm_vcpu_apicv_active(vcpu))
+   evaluate_pending_interrupts |= vmx_has_apicv_interrupt(vcpu);
 
enter_guest_mode(vcpu);
 
@@ -12644,16 +12660,14 @@ static int enter_vmx_non_root_mode(struct kvm_vcpu 
*vcpu, u32 *exit_qual)
 * to L1 or delivered directly to L2 (e.g. In case L1 don't
 * intercept EXTERNAL_INTERRUPT).
 *
-* Usually this would be handled by L0 requesting a
-* IRQ/NMI window by setting VMCS accordingly. However,
-* this setting was done on VMCS01 and now VMCS02 is active
-* instead. Thus, we force L0 to perform pending event
-* evaluation by requesting a KVM_REQ_EVENT.
-*/
-   if (vmcs01_cpu_exec_ctrl &
-   (CPU_BASED_VIRTUAL_INTR_PENDING | 
CPU_BASED_VIRTUAL_NMI_PENDING)) {
+* Usually this would be handled by the processor noticing an
+* IRQ/NMI window request, or checking RVI during evaluation of
+* pending virtual interrupts.  However, this setting was done
+* on VMCS01 and now VMCS02 is active instead. Thus, we force L0
+* to perform pending event evaluation by requesting a KVM_REQ_EVENT.
+*/
+   if (unlikely(evaluate_pending_interrupts))
kvm_make_request(KVM_REQ_EVENT, vcpu);
-   }
 
/*
 * Note no nested_vmx_succeed or nested_vmx_fail here. At this point
-- 
1.8.3.1

Re: [RFC PATCH 06/10] arch/x86: Initialize the resource functions that are different

[Moger, Babu]

On 10/02/2018 05:06 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/24/2018 12:19 PM, Moger, Babu wrote:
>> Initialize the resource functions that are different between the
>> vendors. Some features are initialized differently between the vendors.
>>
>> For example, MBA feature varies significantly between Intel and AMD.
>> Separate the initialization of these resource functions. That way we
>> can easily add AMD's functions later.
>>
>> Signed-off-by: Babu Moger 
>> ---
>>  arch/x86/kernel/cpu/rdt.c | 28 +---
>>  arch/x86/kernel/cpu/rdt.h |  4 
>>  2 files changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/rdt.c b/arch/x86/kernel/cpu/rdt.c
>> index 736715b81fd8..6dec45bf81d6 100644
>> --- a/arch/x86/kernel/cpu/rdt.c
>> +++ b/arch/x86/kernel/cpu/rdt.c
>> @@ -174,10 +174,7 @@ struct rdt_resource rdt_resources_all[] = {
>>  .rid= RDT_RESOURCE_MBA,
>>  .name   = "MB",
>>  .domains= domain_init(RDT_RESOURCE_MBA),
>> -.msr_base   = IA32_MBA_THRTL_BASE,
>> -.msr_update = mba_wrmsr,
>>  .cache_level= 3,
>> -.parse_ctrlval  = parse_bw,
>>  .format_str = "%d=%*u",
>>  .fflags = RFTYPE_RES_MB,
>>  },
>> @@ -865,6 +862,25 @@ static __init void rdt_check_mba(void)
>>  rdt_get_mem_config(_resources_all[RDT_RESOURCE_MBA]);
>>  }
>>  
>> +static __init void rdt_init_res_defs_intel(void)
>> +{
>> +struct rdt_resource *r;
>> +
>> +for_each_rdt_resource(r) {
>> +if (r->rid == RDT_RESOURCE_MBA) {
>> +r->msr_base = IA32_MBA_THRTL_BASE;
>> +r->msr_update = mba_wrmsr;
>> +r->parse_ctrlval = parse_bw;
>> +}
>> +}
>> +}
> 
> Patch 10 introduces parse_bw_amd and mba_wrmsr_amd as you prepare us for
> in the commit message. I think it would reduce confusion if these
> functions, mba_wrmsr and parse_bw, also follow this pattern to contain
> the vendor name. So, mba_wrmsr -> mba_wrmsr_intel, parse_bw ->
> parse_bw_intel.

Yes. Sure. Will make this change.

> 
>> +
>> +static __init void rdt_init_res_defs(void)
>> +{
>> +if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>> +rdt_init_res_defs_intel();
>> +}
>> +
>>  static enum cpuhp_state rdt_online;
>>  
>>  static int __init rdt_late_init(void)
>> @@ -875,6 +891,12 @@ static int __init rdt_late_init(void)
>>  /* Run quirks first */
>>  rdt_quirks();
>>  
>> +/*
>> + * Initialize functions(or definitions) that are different
>> + * between vendors here.
>> + */
>> +rdt_init_res_defs();
>> +
> 
> While it does seem as though currently rdt_quirks() is not using any of
> the settings made in rdt_init_res_defs() it (rdt_quirks()) does use the
> partially initialized resources structure and this may in the future
> include using parameters that have not been initialized yet.
> 
> I thus think it would be safer to do this initialization before
> rdt_quirks().

Yes.  Makes sense.

> 
> Reinette
> 

Re: [PATCH 1/6] lib/scatterlist: Use natural long for sgl_alloc(_order) length parameter

[Bart Van Assche]

On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> None of the callers need unsinged long long (they either pass in an int,
   
   unsigned?
> u32, or size_t) so it is not required to burden the 32-bit builds with an
> overspecified length parameter.

Otherwise,

Reviewed-by: Bart Van Assche 

[PATCH v2] regulator: bd718x7: Remove struct bd718xx_pmic

[Axel Lin]

All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.

Signed-off-by: Axel Lin 
---
v2:
Sorry, just update the subject line.

 drivers/regulator/bd718x7-regulator.c | 59 +--
 1 file changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/regulator/bd718x7-regulator.c 
b/drivers/regulator/bd718x7-regulator.c
index d2522d4e1505..3a47e0372e77 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -15,13 +15,6 @@
 #include 
 #include 
 
-struct bd718xx_pmic {
-   struct bd718xx_regulator_data *rdata;
-   struct bd718xx *mfd;
-   struct platform_device *pdev;
-   struct regulator_dev *rdev[BD718XX_REGULATOR_AMOUNT];
-};
-
 /*
  * BUCK1/2/3/4
  * BUCK1RAMPRATE[1:0] BUCK1 DVS ramp rate setting
@@ -33,12 +26,10 @@ struct bd718xx_pmic {
 static int bd718xx_buck1234_set_ramp_delay(struct regulator_dev *rdev,
   int ramp_delay)
 {
-   struct bd718xx_pmic *pmic = rdev_get_drvdata(rdev);
-   struct bd718xx *mfd = pmic->mfd;
int id = rdev->desc->id;
unsigned int ramp_value = BUCK_RAMPRATE_10P00MV;
 
-   dev_dbg(>pdev->dev, "Buck[%d] Set Ramp = %d\n", id + 1,
+   dev_dbg(>dev, "Buck[%d] Set Ramp = %d\n", id + 1,
ramp_delay);
switch (ramp_delay) {
case 1 ... 1250:
@@ -55,12 +46,12 @@ static int bd718xx_buck1234_set_ramp_delay(struct 
regulator_dev *rdev,
break;
default:
ramp_value = BUCK_RAMPRATE_10P00MV;
-   dev_err(>pdev->dev,
+   dev_err(>dev,
"%s: ramp_delay: %d not supported, setting 
1mV//us\n",
rdev->desc->name, ramp_delay);
}
 
-   return regmap_update_bits(mfd->regmap, BD718XX_REG_BUCK1_CTRL + id,
+   return regmap_update_bits(rdev->regmap, BD718XX_REG_BUCK1_CTRL + id,
  BUCK_RAMPRATE_MASK, ramp_value << 6);
 }
 
@@ -1022,7 +1013,7 @@ struct bd718xx_pmic_inits {
 
 static int bd718xx_probe(struct platform_device *pdev)
 {
-   struct bd718xx_pmic *pmic;
+   struct bd718xx *mfd;
struct regulator_config config = { 0 };
struct bd718xx_pmic_inits pmic_regulators[] = {
[BD718XX_TYPE_BD71837] = {
@@ -1037,54 +1028,46 @@ static int bd718xx_probe(struct platform_device *pdev)
 
int i, j, err;
 
-   pmic = devm_kzalloc(>dev, sizeof(*pmic), GFP_KERNEL);
-   if (!pmic)
-   return -ENOMEM;
-
-   pmic->pdev = pdev;
-   pmic->mfd = dev_get_drvdata(pdev->dev.parent);
-
-   if (!pmic->mfd) {
+   mfd = dev_get_drvdata(pdev->dev.parent);
+   if (!mfd) {
dev_err(>dev, "No MFD driver data\n");
err = -EINVAL;
goto err;
}
-   if (pmic->mfd->chip_type >= BD718XX_TYPE_AMOUNT ||
-   !pmic_regulators[pmic->mfd->chip_type].r_datas) {
+
+   if (mfd->chip_type >= BD718XX_TYPE_AMOUNT ||
+   !pmic_regulators[mfd->chip_type].r_datas) {
dev_err(>dev, "Unsupported chip type\n");
err = -EINVAL;
goto err;
}
 
-   platform_set_drvdata(pdev, pmic);
-
/* Register LOCK release */
-   err = regmap_update_bits(pmic->mfd->regmap, BD718XX_REG_REGLOCK,
+   err = regmap_update_bits(mfd->regmap, BD718XX_REG_REGLOCK,
 (REGLOCK_PWRSEQ | REGLOCK_VREG), 0);
if (err) {
-   dev_err(>pdev->dev, "Failed to unlock PMIC (%d)\n", err);
+   dev_err(>dev, "Failed to unlock PMIC (%d)\n", err);
goto err;
} else {
-   dev_dbg(>pdev->dev, "Unlocked lock register 0x%x\n",
+   dev_dbg(>dev, "Unlocked lock register 0x%x\n",
BD718XX_REG_REGLOCK);
}
 
-   for (i = 0; i < pmic_regulators[pmic->mfd->chip_type].r_amount; i++) {
+   for (i = 0; i < pmic_regulators[mfd->chip_type].r_amount; i++) {
 
const struct regulator_desc *desc;
struct regulator_dev *rdev;
const struct bd718xx_regulator_data *r;
 
-   r = &(*pmic_regulators[pmic->mfd->chip_type].r_datas)[i];
+   r = &(*pmic_regulators[mfd->chip_type].r_datas)[i];
desc = >desc;
 
config.dev = pdev->dev.parent;
-   config.driver_data = pmic;
-   config.regmap = pmic->mfd->regmap;
+   config.regmap = mfd->regmap;
 
rdev = devm_regulator_register(>dev, desc, );
if (IS_ERR(rdev)) {
-   dev_err(pmic->mfd->dev,
+   dev_err(>dev,
"failed to register %s regulator\n",
desc->name);
err = PTR_ERR(rdev);
@@ -1096,28 +1079,26 @@ static int 

Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME

[Leonardo Bras]

On Mon, Oct 1, 2018 at 4:56 AM Robert Richter  wrote:
>
> On 27.09.18 23:08:09, Leonardo Brás wrote:
> > This Patchset changes some driver's Makefile to allow them building
> > using the command 'make drivers/DRIVERNAME', if compatible.
> >
> > The changed drivers would return error if the above command was run
> > on them, after an x86 allyesconfig.
>
> I don't see what you are trying to achieve here. Why shouldn't the
> command fail if it is not the intended way to call it? There are a
> couple of use cases where drivers/ is used to share common code over
> different archs and it is not always the intention to build them in
> drivers/ directly.


Sorry, I was not very clear at my reasons why this change is important,
I will try to briefly explain the whole story.

Some weeks ago I was trying to solve a task that needed to change some
compiling options, build the whole kernel (allyesconfig) and look for errors.
The problem was: It would take a long time to build everything in my computer.
And many friends with slimmer laptops would take much longer.

So, I was looking for a service that could do that for me, in the cloud.
I found out Gitlab.com offers free 50k minutes of CI for open source projects,
and allows anyone get this CI time by only forking my project, adding their
changes and pushing to Gitlab.

But Gitlab don't allow 'jobs' to take longer than 3 hours, after that the 'job'
is killed.

The kernel could not be built in 3h, not with allyesconfig. So, I created a
'job' for each directory in Linux kernel, and tried to build them separately.
All went fine, except for drivers/, which took over 3 hours.

Most logical thing was to continue the division and create five 'jobs' that
could divide the building time of drivers. To do that, each job took care of a
range of starting letters, as you can see in this link:
https://gitlab.com/LeoBras/linux-next/blob/build-ci/.gitlab-ci.yml

But then I found out some drivers were failing to build. Even if they were not
enabled in my .config. After some work I found out some drivers selection is
done in drivers/Makefile, and incompatible drivers would break my build if
tried to call them directly on drivers/DRIVERNAME.

This patchset intents to let the .config selection happen also in
drivers/DRIVERNAME/Makefile, avoiding accidentally building drivers
that are not in .config.

This would allow the kernel to be build on Gitlab CI, and would benefit many
people who wants to help in the kernel development, but have not much
processing power in their machines.

I understand my changes may have mistakes, and I am trying to fix them all.
I thank you any suggestion to make the code better.

Also, I would be happy to know of any other solution to remote build my changes
and look for warnkings / errors.


Thank you for reading,
Leonardo Bras

[PATCH 2/2] phy: cadence: Add driver for Sierra PHY

[Alan Douglas]

Add a Sierra PHY driver with PCIe and USB support.

The PHY has multiple lanes, which can be configured into
groups, and a generic PHY device is created for each group.

There are two resets controlling the overall PHY block, one
to enable the APB interface for programming registers, and
another to enable the PHY itself.  Additionally there are
resets for each PHY lane.

The PHY can be configured in hardware to read register
settings from ROM, or they can be written by the driver.

The sequence of operation on startup is to enable the APB
bus, write the PHY registers (if required)  for each lane
group, and then enable the PHY.  Each group of lanes
can then be individually controlled using the power_on()/
power_off() function for that generic PHY

Signed-off-by: Alan Douglas 
---
 drivers/phy/Kconfig   |   1 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/cadence/Kconfig   |   9 +
 drivers/phy/cadence/Makefile  |   2 +
 drivers/phy/cadence/cdns-sierra.c | 380 ++
 5 files changed, 393 insertions(+)
 create mode 100644 drivers/phy/cadence/Kconfig
 create mode 100644 drivers/phy/cadence/Makefile
 create mode 100644 drivers/phy/cadence/cdns-sierra.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c8d452..cc47f85 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -43,6 +43,7 @@ config PHY_XGENE
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
+source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/lantiq/Kconfig"
 source "drivers/phy/marvell/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 84e3bd9..ba48acd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_RENESAS)+= renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
 obj-y  += broadcom/\
+  cadence/ \
   hisilicon/   \
   marvell/ \
   motorola/\
diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig
new file mode 100644
index 000..098df0f
--- /dev/null
+++ b/drivers/phy/cadence/Kconfig
@@ -0,0 +1,9 @@
+#
+# Phy drivers for Cadence PHYs
+#
+config CDNS_SIERRA_PHY
+   tristate "Cadence Sierra PHY Driver"
+   depends on OF && HAS_IOMEM && RESET_CONTROLLER
+   select GENERIC_PHY
+   help
+ Enable this to support the Cadence Sierra PHY driver
diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile
new file mode 100644
index 000..c396c69
--- /dev/null
+++ b/drivers/phy/cadence/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CDNS_SIERRA_PHY)  += cdns-sierra.o
diff --git a/drivers/phy/cadence/cdns-sierra.c 
b/drivers/phy/cadence/cdns-sierra.c
new file mode 100644
index 000..598e512
--- /dev/null
+++ b/drivers/phy/cadence/cdns-sierra.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence Sierra PHY Driver
+ *
+ * Copyright (c) 2018 Cadence Design Systems
+ * Author: Alan Douglas 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PHY register offsets */
+#define SIERRA_PHY_PLL_CFG (0xc00e << 2)
+#define SIERRA_DET_STANDEC_A   (0x4000 << 2)
+#define SIERRA_DET_STANDEC_B   (0x4001 << 2)
+#define SIERRA_DET_STANDEC_C   (0x4002 << 2)
+#define SIERRA_DET_STANDEC_D   (0x4003 << 2)
+#define SIERRA_DET_STANDEC_E   (0x4004 << 2)
+#define SIERRA_PSM_LANECAL (0x4008 << 2)
+#define SIERRA_PSM_DIAG(0x4015 << 2)
+#define SIERRA_PSC_TX_A0   (0x4028 << 2)
+#define SIERRA_PSC_TX_A1   (0x4029 << 2)
+#define SIERRA_PSC_TX_A2   (0x402A << 2)
+#define SIERRA_PSC_TX_A3   (0x402B << 2)
+#define SIERRA_PSC_RX_A0   (0x4030 << 2)
+#define SIERRA_PSC_RX_A1   (0x4031 << 2)
+#define SIERRA_PSC_RX_A2   (0x4032 << 2)
+#define SIERRA_PSC_RX_A3   (0x4033 << 2)
+#define SIERRA_PLLCTRL_SUBRATE (0x403A << 2)
+#define SIERRA_PLLCTRL_GEN_D   (0x403E << 2)
+#define SIERRA_DRVCTRL_ATTEN   (0x406A << 2)
+#define SIERRA_CLKPATHCTRL_TMR (0x4081 << 2)
+#define SIERRA_RX_CREQ_FLTR_A_MODE1(0x4087 << 2)
+#define SIERRA_RX_CREQ_FLTR_A_MODE0(0x4088 << 2)
+#define SIERRA_CREQ_CCLKDET_MODE01 (0x408E << 2)
+#define SIERRA_RX_CTLE_MAINTENANCE (0x4091 << 2)
+#define SIERRA_CREQ_FSMCLK_SEL (0x4092 << 2)
+#define SIERRA_CTLELUT_CTRL(0x4098 << 2)
+#define SIERRA_DFE_ECMP_RATESEL

SoCFPGA Turn on ARM errata for L2 cache ?

[Clément Péron]

Hi,

Saw this patch on the Altera OpenSource GitHub.

But it's not mainlained can I propose it?

How do you do when the patch is from someone else ? Do you keep the
sign-off of the original author or do you just mention it? in the
commit log ?

Thanks,
Clement

>From 6f7559407c1fcdb9b31c9493f0da79d614290e91 Mon Sep 17 00:00:00 2001
From: Dinh Nguyen 
Date: Wed, 27 Feb 2013 18:29:14 -0600
Subject: [PATCH] ARM: socfpga: Turn on ARM errata for L2 cache

Turn on these ARM and PL310 errata for SoCFPGA:

ARM_ERRATA_754322
ARM_ERRATA_764369
ARM_ERRATA_775420

PL310_ERRATA_588369
PL310_ERRATA_727915
PL310_ERRATA_753970
PL310_ERRATA_769419

Signed-off-by: Dinh Nguyen 
---
 arch/arm/mach-socfpga/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 4adb901dd5eb..a04660918d71 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -11,6 +11,13 @@ menuconfig ARCH_SOCFPGA
  select HAVE_ARM_TWD if SMP
  select MFD_SYSCON
  select PCI_DOMAINS if PCI
+ select ARM_ERRATA_754322
+ select ARM_ERRATA_764369 if SMP
+ select ARM_ERRATA_775420
+ select PL310_ERRATA_588369
+ select PL310_ERRATA_727915
+ select PL310_ERRATA_753970 if PL310
+ select PL310_ERRATA_769419

 if ARCH_SOCFPGA
 config SOCFPGA_SUSPEND

Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps

[Jan Kara]

On Sat 29-09-18 04:46:09, Jerome Glisse wrote:
> On Fri, Sep 28, 2018 at 07:28:16PM -0700, John Hubbard wrote:
> > Actually, the latest direction on that discussion was toward periodically
> > writing back, even while under RDMA, via bounce buffers:
> > 
> >   https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz
> > 
> > I still think that's viable. Of course, there are other things besides 
> > writeback (see below) that might also lead to waiting.
> 
> Write back under bounce buffer is fine, when looking back at links you
> provided the solution that was discuss was blocking in page_mkclean()
> which is horrible in my point of view.

Yeah, after looking into it for some time, we figured that waiting for page
pins in page_mkclean() isn't really going to fly due to deadlocks. So we
came up with the bounce buffers idea which should solve that nicely.

> > > With the solution put forward here you can potentialy wait _forever_ for
> > > the driver that holds a pin to drop it. This was the point i was trying to
> > > get accross during LSF/MM. 
> > 
> > I agree that just blocking indefinitely is generally unacceptable for kernel
> > code, but we can probably avoid it for many cases (bounce buffers), and
> > if we think it is really appropriate (file system unmounting, maybe?) then
> > maybe tolerate it in some rare cases.  
> > 
> > >You can not fix broken hardware that decided to
> > > use GUP to do a feature they can't reliably do because their hardware is
> > > not capable to behave.
> > > 
> > > Because code is easier here is what i was meaning:
> > > 
> > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=a5dbc0fe7e71d347067579f13579df372ec48389
> > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=01677bc039c791a16d5f82b3ef84917d62fac826
> > > 
> > 
> > While that may work sometimes, I don't think it is reliable enough to trust 
> > for
> > identifying pages that have been gup-pinned. There's just too much 
> > overloading of
> > other mechanisms going on there, and if we pile on top with this constraint 
> > of "if you
> > have +3 refcounts, and this particular combination of page counts and 
> > mapcounts, then
> > you're definitely a long-term pinned page", I think users will find a lot 
> > of corner
> > cases for us that break that assumption. 
> 
> So the mapcount == refcount (modulo extra reference for mapping and
> private) should holds, here are the case when it does not:
> - page being migrated
> - page being isolated from LRU
> - mempolicy changes against the page
> - page cache lookup
> - some file system activities
> - i likely miss couples here i am doing that from memory
> 
> What matter is that all of the above are transitory, the extra reference
> only last for as long as it takes for the action to finish (migration,
> mempolicy change, ...).
> 
> So skipping those false positive page while reclaiming likely make sense,
> the blocking free buffer maybe not.

Well, as John wrote, these page refcount are fragile (and actually
filesystem dependent as some filesystems hold page reference from their
page->private data and some don't). So I think we really need a new
reliable mechanism for tracking page references from GUP. And John works
towards that.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] ALSA: intel8x0: Fix fall-through annotations

[Takashi Iwai]

On Wed, 03 Oct 2018 12:38:36 +0200,
 Gustavo A. R. Silva  wrote:
> 
> Replace "fallthru" with a proper "fall through" annotation.
> 
> This fix is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough
> 
> Signed-off-by: Gustavo A. R. Silva 

Thanks, applied.


Takashi

[PATCH v9 2/3]: perf record: enable asynchronous trace writing

[Alexey Budankov]

Trace file offset is calculated and updated linearly prior
enqueuing aio write at record__pushfn().

record__aio_sync() blocks till completion of started AIO operation 
and then proceeds.

record__mmap_read_sync() implements a barrier for all incomplete
aio write requests.

Signed-off-by: Alexey Budankov 
---
 Changes in v9:
 - enable AIO streaming only when --aio-cblocks option is specified explicitly
 Changes in v8:
 - split AIO completion check into separate record__aio_complete()
 Changes in v6:
 - handled errno == EAGAIN case from aio_write();
 Changes in v5:
 - data loss metrics decreased from 25% to 2x in trialed configuration;
 - avoided nanosleep() prior calling aio_suspend();
 - switched to per cpu multi record__aio_sync() aio
 - record_mmap_read_sync() now does global barrier just before 
   switching trace file or collection stop;
 - resolved livelock on perf record -e intel_pt// -- dd if=/dev/zero 
of=/dev/null count=10
 Changes in v4:
 - converted void *bf to struct perf_mmap *md in signatures
 - written comment in perf_mmap__push() just before perf_mmap__get();
 - written comment in record__mmap_read_sync() on possible restarting 
   of aio_write() operation and releasing perf_mmap object after all;
 - added perf_mmap__put() for the cases of failed aio_write();
 Changes in v3:
 - written comments about nanosleep(0.5ms) call prior aio_suspend()
   to cope with intrusiveness of its implementation in glibc;
 - written comments about rationale behind coping profiling data 
   into mmap->data buffer;
---
 tools/perf/builtin-record.c | 154 +++-
 tools/perf/perf.h   |   3 +
 tools/perf/util/mmap.c  |  73 +
 tools/perf/util/mmap.h  |   4 ++
 4 files changed, 233 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 0980dfe3396b..c63fe8c021a2 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -124,6 +124,118 @@ static int record__write(struct record *rec, struct 
perf_mmap *map __maybe_unuse
return 0;
 }
 
+#ifdef HAVE_AIO_SUPPORT
+static int record__aio_write(struct aiocb *cblock, int trace_fd,
+   void *buf, size_t size, off_t off)
+{
+   int rc;
+
+   cblock->aio_fildes = trace_fd;
+   cblock->aio_buf= buf;
+   cblock->aio_nbytes = size;
+   cblock->aio_offset = off;
+   cblock->aio_sigevent.sigev_notify = SIGEV_NONE;
+
+   do {
+   rc = aio_write(cblock);
+   if (rc == 0) {
+   break;
+   } else if (errno != EAGAIN) {
+   cblock->aio_fildes = -1;
+   pr_err("failed to queue perf data, error: %m\n");
+   break;
+   }
+   } while (1);
+
+   return rc;
+}
+
+static int record__aio_complete(struct perf_mmap *md, struct aiocb *cblock)
+{
+   void *rem_buf;
+   off_t rem_off;
+   size_t rem_size;
+   int rc, aio_errno;
+   ssize_t aio_ret, written;
+
+   aio_errno = aio_error(cblock);
+   if (aio_errno == EINPROGRESS)
+   return 0;
+
+   written = aio_ret = aio_return(cblock);
+   if (aio_ret < 0) {
+   if (aio_errno != EINTR)
+   pr_err("failed to write perf data, error: %m\n");
+   written = 0;
+   }
+
+   rem_size = cblock->aio_nbytes - written;
+
+   if (rem_size == 0) {
+   cblock->aio_fildes = -1;
+   /*
+* md->refcount is incremented in perf_mmap__push() for
+* every enqueued aio write request so decrement it because
+* the request is now complete.
+*/
+   perf_mmap__put(md);
+   rc = 1;
+   } else {
+   /*
+* aio write request may require restart with the
+* reminder if the kernel didn't write whole
+* chunk at once.
+*/
+   rem_off = cblock->aio_offset + written;
+   rem_buf = (void *)(cblock->aio_buf + written);
+   record__aio_write(cblock, cblock->aio_fildes,
+   rem_buf, rem_size, rem_off);
+   rc = 0;
+   }
+
+   return rc;
+}
+
+static void record__aio_sync(struct perf_mmap *md)
+{
+   struct aiocb *cblock = >cblock;
+   struct timespec timeout = { 0, 1000 * 1000  * 1 }; // 1ms
+
+   do {
+   if (cblock->aio_fildes == -1 || record__aio_complete(md, 
cblock))
+   return;
+
+   while (aio_suspend((const struct aiocb**), 1, )) 
{
+   if (!(errno == EAGAIN || errno == EINTR))
+   pr_err("failed to sync perf data, error: %m\n");
+   }
+   } while (1);
+}
+
+static int record__aio_pushfn(void *to, struct aiocb *cblock, void *bf, size_t 
size)
+{
+   off_t 

Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call

[Jan Kara]

On Fri 28-09-18 20:12:33, John Hubbard wrote:
>  static inline void release_user_pages(struct page **pages,
> - unsigned long npages)
> + unsigned long npages,
> + bool set_dirty)
>  {
> -   while (npages)
> -   put_user_page(pages[--npages]);
> +   if (set_dirty)
> +   release_user_pages_dirty(pages, npages);
> +   else
> +   release_user_pages_basic(pages, npages);
> +}

Is there a good reason to have this with set_dirty argument? Generally bool
arguments are not great for readability (or greppability for that matter).
Also in this case callers can just as easily do:
if (set_dirty)
release_user_pages_dirty(...);
else
release_user_pages(...);

And furthermore it makes the code author think more whether he needs
set_page_dirty() or set_page_dirty_lock(), rather than just passing 'true'
and hoping the function magically does the right thing for him.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v2] Bluetooth: hci_qca: Add support for controller debug logs.

[Marcel Holtmann]

Hi Balakrishna,

> This patch will prevent error messages splashing on console.
> 
> [   78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet 
> for unknown connection handle 3804
> [   78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet 
> for unknown connection handle 3804
> [   78.446639] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet 
> for unknown connection handle 3804
> [   78.456596] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet 
> for unknown connection handle 3804
> 
> QCA wcn3990 will send the debug logs in the form of ACL packets.
> While decoding packet in qca_recv(), marking the received debug log
> packet as diagnostic packet.
> 
> Signed-off-by: Harish Bandi 
> Signed-off-by: Balakrishna Godavarthi 
> ---
> v2: 
>  * Addressed reviewer comments.
> v1: 
>  * initial patch
> ---
> drivers/bluetooth/hci_qca.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index d98ed0442201..63ac3c6b4149 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -63,6 +63,10 @@
> /* susclk rate */
> #define SUSCLK_RATE_32KHZ 32768
> 
> +/* Controller debug log header */
> +#define QCA_DEBUG_HDR_MSB0xDC
> +#define QCA_DEBUG_HDR_LSB0x2E
> +

since this is actually the ACL handle, why not call it QCA_DEBUG_HANDLE.

> /* HCI_IBS transmit side sleep protocol states */
> enum tx_ibs_states {
>   HCI_IBS_TX_ASLEEP,
> @@ -849,6 +853,20 @@ static int qca_ibs_wake_ack(struct hci_dev *hdev, struct 
> sk_buff *skb)
>   return 0;
> }
> 
> +static int qca_recv_acl_data(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + /* We receive debug logs from chip as an ACL packets.
> +  * Instead of sending the data to ACL to decode the
> +  * received data, we are pushing them to the above layers
> +  * as a diagnostic packet.
> +  */
> + if ((skb->len > 2) && (skb->data[0] == QCA_DEBUG_HDR_MSB) &&
> + (skb->data[1] == QCA_DEBUG_HDR_LSB))

Skip the individual () since they are not needed. Also the skb->len check is 
not needed since the H4_RECV_ACL already ensures the proper length of the 
header.

And just use get_unaligned_le16(skb->data) here (or be16 if that is the byte 
order).

> + return hci_recv_diag(hdev, skb);

Is there any reason to keep the 4 octets hci_acl_hdr with this SKB? Or would it 
be better to be stripped off. Mainly asking are they any other magic handles 
that we might want to feed through the diag channel?

> +
> + return hci_recv_frame(hdev, skb);
> +}
> +

Regards

Marcel

[PATCH v3] perf record: encode -k clockid frequency into Perf trace

[Alexey Budankov]

Store -k clockid frequency into Perf trace to enable timestamps 
derived metrics conversion into wall clock time on reporting stage.

Below is the example of perf report output:

tools/perf/perf record -k raw -- ../../matrix/linux/matrix.gcc
...
[ perf record: Captured and wrote 31.222 MB perf.data (818054 samples) ]

tools/perf/perf report --header
# 
...
# event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 
4000, sample_type = IP|TID|TIME|PERIOD, disabled = 1, inherit = 1, mmap = 1, 
comm = 1, freq = 1, enable_on_exec = 1, task = 1, precise_ip = 3, sample_id_all 
= 1, exclude_guest = 1, mmap2 = 1, comm_exec = 1, use_clockid = 1, clockid = 4
...
# clockid frequency: 1000 MHz
...
# 

Signed-off-by: Alexey Budankov 
---
Changes in v3:
 - moved header's clockid_res_ns initialization out of record__init_features()
 - added explicit warning for case of failed clock_getres() call
Changes in v2:
 - renamed clockid_freq to clockid_res_ns and get_clockid_freq() to 
get_clockid_res()
 - avoided redundant define of NSEC_IN_SEC, reused linux/time64.h:NSEC_PER_SEC
 - moved MHz conversion into print_clockid() and shortened write_clockid()
---
 tools/perf/builtin-record.c | 24 ++--
 tools/perf/perf.h   |  1 +
 tools/perf/util/env.h   |  1 +
 tools/perf/util/header.c| 27 +++
 tools/perf/util/header.h|  1 +
 5 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 0980dfe3396b..d803d3264465 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -592,6 +592,9 @@ static void record__init_features(struct record *rec)
if (!rec->opts.full_auxtrace)
perf_header__clear_feat(>header, HEADER_AUXTRACE);
 
+   if (!(rec->opts.use_clockid && rec->opts.clockid_res_ns))
+   perf_header__clear_feat(>header, HEADER_CLOCKID);
+
perf_header__clear_feat(>header, HEADER_STAT);
 }
 
@@ -897,6 +900,9 @@ static int __cmd_record(struct record *rec, int argc, const 
char **argv)
 
record__init_features(rec);
 
+   if (rec->opts.use_clockid && rec->opts.clockid_res_ns)
+   session->header.env.clockid_res_ns = rec->opts.clockid_res_ns;
+
if (forks) {
err = perf_evlist__prepare_workload(rec->evlist, >target,
argv, data->is_pipe,
@@ -1337,6 +1343,19 @@ static const struct clockid_map clockids[] = {
CLOCKID_END,
 };
 
+static int get_clockid_res(clockid_t clk_id, size_t *res_ns)
+{
+   struct timespec res;
+
+   *res_ns = 0;
+   if (!clock_getres(clk_id, ))
+   *res_ns = res.tv_nsec + res.tv_sec * NSEC_PER_SEC;
+   else
+   pr_warning("WARNING: Failed to determine specified clock 
resolution.\n");
+
+   return 0;
+}
+
 static int parse_clockid(const struct option *opt, const char *str, int unset)
 {
struct record_opts *opts = (struct record_opts *)opt->value;
@@ -1360,7 +1379,7 @@ static int parse_clockid(const struct option *opt, const 
char *str, int unset)
 
/* if its a number, we're done */
if (sscanf(str, "%d", >clockid) == 1)
-   return 0;
+   return get_clockid_res(opts->clockid, >clockid_res_ns);
 
/* allow a "CLOCK_" prefix to the name */
if (!strncasecmp(str, "CLOCK_", 6))
@@ -1369,7 +1388,8 @@ static int parse_clockid(const struct option *opt, const 
char *str, int unset)
for (cm = clockids; cm->name; cm++) {
if (!strcasecmp(str, cm->name)) {
opts->clockid = cm->clockid;
-   return 0;
+   return get_clockid_res(opts->clockid,
+  >clockid_res_ns);
}
}
 
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 21bf7f5a3cf5..981db3c2ed60 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -81,6 +81,7 @@ struct record_opts {
unsigned initial_delay;
bool use_clockid;
clockid_tclockid;
+   size_t   clockid_res_ns;
unsigned int proc_map_timeout;
 };
 
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index 1f3ccc368530..b167a54d635f 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -63,6 +63,7 @@ struct perf_env {
struct numa_node*numa_nodes;
struct memory_node  *memory_nodes;
unsigned long long   memory_bsize;
+   size_t   clockid_res_ns;
 };
 
 extern struct perf_env perf_env;
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 1ec1d9bc2d63..4ce5339158f7 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1034,6 +1034,13 @@ static int write_auxtrace(struct feat_fd *ff,
return err;
 }
 
+static int write_clockid(struct feat_fd *ff,
+   

[PATCH 0/3] spi-nor: Add Octal SPI support

[Vignesh R]

This series adds support for octal mode of mt35x flash. Also, adds
support for OSPI version of Cadence QSPI controller.

Based on top of patches adding basic support for mt35xu512aba here:
https://patchwork.ozlabs.org/cover/971437/

Vignesh R (3):
  mtd: spi-nor: Add Octal mode support for mt35xu512aba
  dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
  mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller

 .../devicetree/bindings/mtd/cadence-quadspi.txt   |  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c |  9 +
 drivers/mtd/spi-nor/spi-nor.c | 11 ++-
 include/linux/mtd/spi-nor.h   |  2 ++
 4 files changed, 22 insertions(+), 1 deletion(-)

-- 
2.19.0

[PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller

[Vignesh R]

Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index e24db817154e..48b00e75a879 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -101,6 +101,7 @@ struct cqspi_st {
 #define CQSPI_INST_TYPE_SINGLE 0
 #define CQSPI_INST_TYPE_DUAL   1
 #define CQSPI_INST_TYPE_QUAD   2
+#define CQSPI_INST_TYPE_OCTAL  3
 
 #define CQSPI_DUMMY_CLKS_PER_BYTE  8
 #define CQSPI_DUMMY_BYTES_MAX  4
@@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const 
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+   case SNOR_PROTO_1_1_8:
+   f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+   break;
default:
return -EINVAL;
}
@@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, 
struct device_node *np)
SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_READ_1_1_4 |
+   SNOR_HWCAPS_READ_1_1_8 |
SNOR_HWCAPS_PP,
};
struct platform_device *pdev = cqspi->pdev;
@@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,k2g-qspi",
.data = (void *)CQSPI_NEEDS_WR_DELAY,
},
+   {
+   .compatible = "ti,am654-ospi",
+   .data = (void *)CQSPI_NEEDS_WR_DELAY,
+   },
{ /* end of table */ }
 };
 
-- 
2.19.0

Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"

[Daniel Wang]

On Wed, Oct 3, 2018 at 2:14 AM Petr Mladek  wrote:
>
> On Tue 2018-10-02 21:23:27, Steven Rostedt wrote:
> > I don't see the big deal of backporting this. The biggest complaints
> > about backports are from fixes that were added to late -rc releases
> > where the fixes didn't get much testing. This commit was added in 4.16,
> > and hasn't had any issues due to the design. Although a fix has been
> > added:
> >
> > c14376de3a1 ("printk: Wake klogd when passing console_lock owner")
>
> As I said, I am fine with backporting the console_lock owner stuff
> into the stable release.
>
> I just wonder (like Sergey) what the real problem is. The console_lock
> owner handshake is not fully reliable. It is might be good enough
> to prevent softlockup. But we should not relay on it to prevent
> a deadlock.

Yes. I myself was curious too. :)

>
> My new theory ;-)
>
> printk_safe_flush() is called in nmi_trigger_cpumask_backtrace().
> => watchdog_timer_fn() is blocked until all backtraces are printed.
>
> Now, the original report complained that the system rebooted before
> all backtraces were printed. It means that panic() was called
> on another CPU. My guess is that it is from the hardlockup detector.
> And the panic() was not able to flush the console because it was
> not able to take console_lock.
>
> IMHO, there was not a real deadlock. The console_lock owner
> handshake jsut helped to get console_lock in panic() and
> flush all messages before reboot => it is reasonable
> and acceptable fix.

I had the same speculation. Tried to capture a lockdep snippet with
CONFIG_PROVE_LOCKING turned on but didn't get anything. But
maybe I was doing it wrong.

>
> Just to be sure. Daniel, could you please send a log with
> the console_lock owner stuff backported? There we would see
> who called the panic() and why it rebooted early.

Sure. Here is one. It's a bit long but complete. I attached another log
snippet below it which is what I got when `softlockup_panic` was turned
off. The log was from the IRQ task that was flushing the printk buffer. I
will be taking a closer look at it too but in case you'll find it helpful.

lockup-test-16-2 login: [   89.277372] LoadPin: kernel-module
pinning-ignored obj="/tmp/release/hog.ko" pid=1992 cmdline="insmod
hog.ko"
[   89.280029] hog: loading out-of-tree module taints kernel.
[   89.294559] Hogging a CPU now
[   92.619688] watchdog: BUG: soft lockup - CPU#6 stuck for 3s! [hog:1993]
[   92.626490] Modules linked in: hog(O) ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 xt_addrtype nf_nat
br_netfilter ip6table_filter ip6_tables aesni_intel aes_x86_64
crypto_simd cryptd glue_helper
[   92.645567] CPU: 6 PID: 1993 Comm: hog Tainted: G   O 4.15.0+ #12
[   92.652899] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[   92.662245] RIP: 0010:hog_thread+0x13/0x1000 [hog]
[   92.667164] RSP: 0018:b489c741ff10 EFLAGS: 0282 ORIG_RAX:
ff11
[   92.675139] RAX: 0011 RBX: 9f5c75a88900 RCX: 
[   92.682474] RDX: 9f5c8339d840 RSI: 9f5c833954b8 RDI: 9f5c833954b8
[   92.689727] RBP: b489c741ff48 R08: 0030 R09: 
[   92.696985] R10: 03a8 R11:  R12: 9f5c7959e080
[   92.704251] R13: b489c7f2bc70 R14:  R15: 9f5c75a88948
[   92.711498] FS:  () GS:9f5c8338()
knlGS:
[   92.719699] CS:  0010 DS:  ES:  CR0: 80050033
[   92.725556] CR2: 558184c9b89c CR3: 000499e12006 CR4: 003606a0
[   92.732976] DR0:  DR1:  DR2: 
[   92.740231] DR3:  DR6: fffe0ff0 DR7: 0400
[   92.747487] Call Trace:
[   92.750054]  kthread+0x120/0x160
[   92.753419]  ? 0xc030d000
[   92.756859]  ? kthread_stop+0x120/0x120
[   92.760819]  ret_from_fork+0x35/0x40
[   92.764594] Code:  fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[   92.772656] Sending NMI from CPU 6 to CPUs 0-5,7-15:
[   92.43] NMI backtrace for cpu 0
[   92.46] CPU: 0 PID: 1844 Comm: dd Tainted: G   O 4.15.0+ #12
[   92.47] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[   92.55] RIP: 0010:native_queued_spin_lock_slowpath+0x18/0x1b0
[   92.56] RSP: 0018:b489c7dcbdb0 EFLAGS: 0002
[   92.57] RAX: 0001 RBX: 9f5c82ca5a68 RCX: 
[   92.58] RDX: 0001 RSI: 0001 RDI: 9f5c82ca5a68
[   92.59] RBP: b489c7dcbde0 R08: f9f8f56c R09: 4c55ba96
[   92.60] R10: 84f6cd57 R11: 41f66b45 R12: 9f5c82ca5a68
[   92.61] R13: b489c7dcbe38 R14: b489c7dcbe38 R15: 0040
[   92.62] FS:  7f1e21116700() GS:9f5c8320()
knlGS:
[   92.63] CS:  0010 DS: 

Re: [PATCH v1] ras: Use consistent types for UUIDs

[Andy Shevchenko]

On Fri, Jul 13, 2018 at 04:10:27PM +0300, Andy Shevchenko wrote:
> The commit
> 
>   297b64c74385 ("ras: acpi / apei: generate trace event for unrecognized CPER 
> section")
> 
> brought inconsistency in UUID types which are used across the RAS subsystem.
> 
> Fix this by moving to use guid_t everywhere.

Any comments on this?

> 
> Cc: Tyler Baicar 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/ras/ras.c   | 2 +-
>  include/ras/ras_event.h | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
> index 3f38907320dc..95540ea8dd9d 100644
> --- a/drivers/ras/ras.c
> +++ b/drivers/ras/ras.c
> @@ -14,7 +14,7 @@
>  #define TRACE_INCLUDE_PATH ../../include/ras
>  #include 
>  
> -void log_non_standard_event(const uuid_le *sec_type, const uuid_le *fru_id,
> +void log_non_standard_event(const guid_t *sec_type, const guid_t *fru_id,
>   const char *fru_text, const u8 sev, const u8 *err,
>   const u32 len)
>  {
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index a0794632fd01..36c5c5e38c1d 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -27,7 +27,7 @@
>  TRACE_EVENT(extlog_mem_event,
>   TP_PROTO(struct cper_sec_mem_err *mem,
>u32 err_seq,
> -  const uuid_le *fru_id,
> +  const guid_t *fru_id,
>const char *fru_text,
>u8 sev),
>  
> @@ -39,7 +39,7 @@ TRACE_EVENT(extlog_mem_event,
>   __field(u8, sev)
>   __field(u64, pa)
>   __field(u8, pa_mask_lsb)
> - __field_struct(uuid_le, fru_id)
> + __field_struct(guid_t, fru_id)
>   __string(fru_text, fru_text)
>   __field_struct(struct cper_mem_err_compact, data)
>   ),
> @@ -218,8 +218,8 @@ TRACE_EVENT(arm_event,
>   */
>  TRACE_EVENT(non_standard_event,
>  
> - TP_PROTO(const uuid_le *sec_type,
> -  const uuid_le *fru_id,
> + TP_PROTO(const guid_t *sec_type,
> +  const guid_t *fru_id,
>const char *fru_text,
>const u8 sev,
>const u8 *err,
> -- 
> 2.18.0
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH V5 3/3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Doug Anderson]

Hi,

On Wed, Oct 3, 2018 at 6:45 AM Alok Chauhan  wrote:
> +static irqreturn_t geni_spi_isr(int irq, void *data)
> +{
> +   struct spi_master *spi = data;
> +   struct spi_geni_master *mas = spi_master_get_devdata(spi);
> +   struct geni_se *se = >se;
> +   u32 m_irq;
> +   unsigned long flags;
> +   irqreturn_t ret = IRQ_HANDLED;
> +
> +   if (mas->cur_mcmd == CMD_NONE)
> +   return IRQ_NONE;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   m_irq = readl(se->base + SE_GENI_M_IRQ_STATUS);
> +
> +   if ((m_irq & M_RX_FIFO_WATERMARK_EN) || (m_irq & M_RX_FIFO_LAST_EN))
> +   geni_spi_handle_rx(mas);
> +
> +   if (m_irq & M_TX_FIFO_WATERMARK_EN)
> +   geni_spi_handle_tx(mas);
> +
> +   if (m_irq & M_CMD_DONE_EN) {
> +   if (mas->cur_mcmd == CMD_XFER)
> +   spi_finalize_current_transfer(spi);
> +   else if (mas->cur_mcmd == CMD_CS)
> +   complete(>xfer_done);
> +   mas->cur_mcmd = CMD_NONE;
> +   /*
> +* If this happens, then a CMD_DONE came before all the Tx
> +* buffer bytes were sent out. This is unusual, log this
> +* condition and disable the WM interrupt to prevent the
> +* system from stalling due an interrupt storm.
> +* If this happens when all Rx bytes haven't been received, 
> log
> +* the condition.
> +* The only known time this can happen is if bits_per_word != 
> 8
> +* and some registers that expect xfer lengths in num 
> spi_words
> +* weren't written correctly.
> +*/
> +   if (mas->tx_rem_bytes) {
> +   writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
> +   dev_err(mas->dev, "Premature done. tx_rem = %d 
> bpw%d\n",
> +   mas->tx_rem_bytes, mas->cur_bits_per_word);
> +   }
> +   if (mas->rx_rem_bytes)
> +   dev_err(mas->dev, "Premature done. rx_rem = %d 
> bpw%d\n",
> +   mas->rx_rem_bytes, mas->cur_bits_per_word);
> +   }
> +
> +   if ((m_irq & M_CMD_CANCEL_EN) || (m_irq & M_CMD_ABORT_EN)) {
> +   mas->cur_mcmd = CMD_NONE;
> +   complete(>xfer_done);
> +   }
> +
> +   writel(m_irq, se->base + SE_GENI_M_IRQ_CLEAR);
> +   spin_unlock_irqrestore(>lock, flags);
> +   return ret;

nit: you no longer need the "ret" variable.  Just return IRQ_HANDLED
here and remove the "ret" local variable from this function.  It'd be
nice if you put a blank line before the return too.


I'm not convinced it's worth spinning the patch to fix that one nit,
but if you spin it for some other reason please fix it.  I believe
this fixes all outstanding feedback that I'm aware of.  Thus:

Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 

-Doug