[PATCH] mm/mmap: fix the adjusted length error

2019-05-17 Thread jianhong chen
In linux version 4.4, a 32-bit process may fail to allocate 64M hugepage
memory by function shmat even though there is a 64M memory gap in
the process.

It is the adjusted length that causes the problem, introduced from
commit db4fbfb9523c935 ("mm: vm_unmapped_area() lookup function").
Accounting for the worst case alignment overhead, function unmapped_area
and unmapped_area_topdown adjust the search length before searching
for available vma gap. This is an estimated length, sum of the desired
length and the longest alignment offset, which can cause misjudgement
if the system has very few virtual memory left. For example, if the
longest memory gap available is 64M, we can’t get it from the system
by allocating 64M hugepage memory via shmat function. The reason is
that it requires a longger length, the sum of the desired length(64M)
and the longest alignment offset.

To fix this error ,we can calculate the alignment offset of
gap_start or gap_end to get a desired gap_start or gap_end value,
before searching for the available gap. In this way, we don't
need to adjust the search length.

Problem reproduces procedure:
1. allocate a lot of virtual memory segments via shmat and malloc
2. release one of the biggest memory segment via shmdt
3. attach the biggest memory segment via shmat

e.g.
process maps:
8000-9000 r-xp  00:12 3385/tmp/memory_mmap
00011000-00012000 rw-p 1000 00:12 3385/tmp/memory_mmap
27536000-f756a000 rw-p  00:00 0
f756a000-f7691000 r-xp  01:00 560 /lib/libc-2.11.1.so
f7691000-f7699000 ---p 00127000 01:00 560 /lib/libc-2.11.1.so
f7699000-f769b000 r--p 00127000 01:00 560 /lib/libc-2.11.1.so
f769b000-f769c000 rw-p 00129000 01:00 560 /lib/libc-2.11.1.so
f769c000-f769f000 rw-p  00:00 0
f769f000-f76c r-xp  01:00 583 /lib/libgcc_s.so.1
f76c-f76c7000 ---p 00021000 01:00 583 /lib/libgcc_s.so.1
f76c7000-f76c8000 rw-p 0002 01:00 583 /lib/libgcc_s.so.1
f76c8000-f76e5000 r-xp  01:00 543 /lib/ld-2.11.1.so
f76e9000-f76ea000 rw-p  00:00 0
f76ea000-f76ec000 rw-p  00:00 0
f76ec000-f76ed000 r--p 0001c000 01:00 543 /lib/ld-2.11.1.so
f76ed000-f76ee000 rw-p 0001d000 01:00 543 /lib/ld-2.11.1.so
f780-f7a0 rw-s  00:0e 0   /SYSV00ea (deleted)
fba0-fca0 rw-s  00:0e 65538   /SYSV00ec (deleted)
fca0-fce0 rw-s  00:0e 98307   /SYSV00ed (deleted)
fce0-fd80 rw-s  00:0e 131076  /SYSV00ee (deleted)
ff913000-ff934000 rw-p  00:00 0   [stack]
-1000 r-xp  00:00 0   [vectors]

from 0xf7a0 to fba0, it has 64M memory gap, but we can't get
it from kernel.

Signed-off-by: jianhong chen 
Cc: sta...@vger.kernel.org
---
 mm/mmap.c | 43 +--
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index bd7b9f2..c5a5782 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1865,6 +1865,22 @@ unsigned long mmap_region(struct file *file, unsigned 
long addr,
return error;
 }
 
+static inline unsigned long gap_start_offset(struct vm_unmapped_area_info 
*info,
+   unsigned long addr)
+{
+   /* get gap_start offset to adjust gap address to the
+* desired alignment
+*/
+   return (info->align_offset - addr) & info->align_mask;
+}
+
+static inline unsigned long gap_end_offset(struct vm_unmapped_area_info *info,
+   unsigned long addr)
+{
+   /* get gap_end offset to adjust gap address to the desired alignment */
+   return (addr - info->align_offset) & info->align_mask;
+}
+
 unsigned long unmapped_area(struct vm_unmapped_area_info *info)
 {
/*
@@ -1879,10 +1895,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info 
*info)
struct vm_area_struct *vma;
unsigned long length, low_limit, high_limit, gap_start, gap_end;
 
-   /* Adjust search length to account for worst case alignment overhead */
-   length = info->length + info->align_mask;
-   if (length < info->length)
-   return -ENOMEM;
+   length = info->length;
 
/* Adjust search limits by the desired length */
if (info->high_limit < length)
@@ -1914,6 +1927,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info 
*info)
}
 
gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+   gap_start += gap_start_offset(info, gap_start);
 check_current:
/* Check if current node has a suitable gap */
if (gap_start > high_limit)
@@ -1942,6 +1956,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info 
*info)
   struct vm_area_struct, vm_rb);
if (prev == vma->vm_rb.rb_left) {
gap_start = vm_end_gap(vma->vm_prev);
+   

[PATCH 1/1] LZ4: Port LZ4 1.9.x FAST_DEC_LOOP and enable it on x86 and ARM64

2019-05-17 Thread Chenxi Mao
FAST_DEC_LOOP was introduced from LZ4 1.9.0[1]
This change would be introduce 10% on decompress operation
according to LZ4 benchmark result on X86 devices.
Meanwhile, LZ4 with FAST_DEC_LOOP could get improvements on ARM64,
however clang compiler has downgrade if FAST_DEC_LOOP enabled.

So FAST_DEC_LOOP only enabled on X86/X86-64 or ARM64 with GCC build.

LZ4 FAST_DEC_LOOP bug fixes include as well.
1. fixed read-after input in LZ4_decompress_safe() (issue 681)
2. Fix out-of-bound read in LZ4_decompress_fast() (issue 676)

PS2:
1. Move common API to lz4defs.h
2. Add PPC related inline Macro defination.
3. Force inline new static apis.

Here is the test result on ARM64(cortex-A53)
Benchmark via ZRAM:

Test case:
taskset 03 /data/fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers \
--buffer_compress_percentage=75  --size=700M \
--scramble_buffers=1 --direct=1 --loops=100 --numjobs=1 \
--filename=/data/test/test --name=seq-read --rw=read --stonewall

Patched:
READ: bw=150MiB/s (157MB/s)
Vanilla:
READ: bw=135MiB/s (142MB/s)

[1] https://github.com/lz4/lz4/releases/tag/v1.9.0

Signed-off-by: chenxi.mao 
---
 lib/lz4/lz4_compress.c   |   4 +-
 lib/lz4/lz4_decompress.c | 397 ---
 lib/lz4/lz4defs.h|  60 +-
 lib/lz4/lz4hc_compress.c |   2 +-
 4 files changed, 392 insertions(+), 71 deletions(-)

diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
index cc7b6d4cc7c7..b703ed1ca57d 100644
--- a/lib/lz4/lz4_compress.c
+++ b/lib/lz4/lz4_compress.c
@@ -322,7 +322,7 @@ static FORCE_INLINE int LZ4_compress_generic(
*token = (BYTE)(litLength << ML_BITS);
 
/* Copy Literals */
-   LZ4_wildCopy(op, anchor, op + litLength);
+   LZ4_wildCopy8(op, anchor, op + litLength);
op += litLength;
}
 
@@ -628,7 +628,7 @@ static int LZ4_compress_destSize_generic(
*token = (BYTE)(litLength << ML_BITS);
 
/* Copy Literals */
-   LZ4_wildCopy(op, anchor, op + litLength);
+   LZ4_wildCopy8(op, anchor, op + litLength);
op += litLength;
}
 
diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
index 0c9d3ad17e0f..8622922304c3 100644
--- a/lib/lz4/lz4_decompress.c
+++ b/lib/lz4/lz4_decompress.c
@@ -50,6 +50,96 @@
 #define assert(condition) ((void)0)
 #endif
 
+#ifndef LZ4_FAST_DEC_LOOP
+#if defined(__i386__) || defined(__x86_64__)
+#define LZ4_FAST_DEC_LOOP 1
+#elif defined(__aarch64__) && !defined(__clang__)
+ /* On aarch64, we disable this optimization for clang because on certain
+  * mobile chipsets and clang, it reduces performance. For more information
+  * refer to https://github.com/lz4/lz4/pull/707. */
+#define LZ4_FAST_DEC_LOOP 1
+#else
+#define LZ4_FAST_DEC_LOOP 0
+#endif
+#endif
+
+#if LZ4_FAST_DEC_LOOP
+#define FASTLOOP_SAFE_DISTANCE 64
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_memcpy_using_offset_base(BYTE * dstPtr, const BYTE * srcPtr, BYTE * dstEnd,
+const size_t offset)
+{
+   if (offset < 8) {
+   dstPtr[0] = srcPtr[0];
+
+   dstPtr[1] = srcPtr[1];
+   dstPtr[2] = srcPtr[2];
+   dstPtr[3] = srcPtr[3];
+   srcPtr += inc32table[offset];
+   memcpy(dstPtr + 4, srcPtr, 4);
+   srcPtr -= dec64table[offset];
+   dstPtr += 8;
+   } else {
+   memcpy(dstPtr, srcPtr, 8);
+   dstPtr += 8;
+   srcPtr += 8;
+   }
+
+   LZ4_wildCopy8(dstPtr, srcPtr, dstEnd);
+}
+
+/* customized variant of memcpy, which can overwrite up to 32 bytes beyond 
dstEnd
+ * this version copies two times 16 bytes (instead of one time 32 bytes)
+ * because it must be compatible with offsets >= 16. */
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_wildCopy32(void *dstPtr, const void *srcPtr, void *dstEnd)
+{
+   BYTE *d = (BYTE *) dstPtr;
+   const BYTE *s = (const BYTE *)srcPtr;
+   BYTE *const e = (BYTE *) dstEnd;
+
+   do {
+   memcpy(d, s, 16);
+   memcpy(d + 16, s + 16, 16);
+   d += 32;
+   s += 32;
+   } while (d < e);
+}
+
+FORCE_O2_INLINE_GCC_PPC64LE void
+LZ4_memcpy_using_offset(BYTE *dstPtr, const BYTE *srcPtr, BYTE *dstEnd,
+   const size_t offset)
+{
+   BYTE v[8];
+   switch (offset) {
+
+   case 1:
+   memset(v, *srcPtr, 8);
+   goto copy_loop;
+   case 2:
+   memcpy(v, srcPtr, 2);
+   memcpy([2], srcPtr, 2);
+   memcpy([4], [0], 4);
+   goto copy_loop;
+   case 4:
+   memcpy(v, srcPtr, 4);
+   memcpy([4], srcPtr, 4);
+   goto copy_loop;
+   default:
+   LZ4_memcpy_using_offset_base(dstPtr, srcPtr, 

RE: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node

2019-05-17 Thread Chuanhua Han


> -Original Message-
> From: Shawn Guo 
> Sent: 2019年5月17日 10:38
> To: Chuanhua Han 
> Cc: Leo Li ; mark.rutl...@arm.com;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Ying Zhang 
> Subject: [EXT] Re: [PATCH] arm64: dts: ls1028a: fix watchdog device node
> 
> Caution: EXT Email
> 
> On Thu, May 09, 2019 at 03:06:57PM +0800, Chuanhua Han wrote:
> > ls1028a platform uses sp805 watchdog, and use 1/16 platform clock as
> > timer clock, this patch fix device tree node.
> >
> > Signed-off-by: Zhang Ying-22455 
> > Signed-off-by: Chuanhua Han 
> > ---
> >  .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 19
> > ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index b04581249f0b..1510b1858246 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -285,13 +285,18 @@
> >   #interrupt-cells = <2>;
> >   };
> >
> > - wdog0: watchdog@23c {
> > - compatible = "fsl,ls1028a-wdt", "fsl,imx21-wdt";
> > - reg = <0x0 0x23c 0x0 0x1>;
> > - interrupts = ;
> > - clocks = < 4 1>;
> > - big-endian;
> > - status = "disabled";
> > + cluster1_core0_watchdog: wdt@c00 {
> 
> Keep 'watchdog' as the node name,
Thanks for your replay
Do you mean replace the ‘wdt’ with ‘watchdog’?
and keep nodes sort in unit-address.
What does this mean?
> 
> Shawn
> 
> > + compatible = "arm,sp805", "arm,primecell";
> > + reg = <0x0 0xc00 0x0 0x1000>;
> > + clocks = < 4 15>, < 4 15>;
> > + clock-names = "apb_pclk", "wdog_clk";
> > + };
> > +
> > + cluster1_core1_watchdog: wdt@c01 {
> > + compatible = "arm,sp805", "arm,primecell";
> > + reg = <0x0 0xc01 0x0 0x1000>;
> > + clocks = < 4 15>, < 4 15>;
> > + clock-names = "apb_pclk", "wdog_clk";
> >   };
> >
> >   sata: sata@320 {
> > --
> > 2.17.1
> >


[PATCH] jbd2: fix some print format mistakes

2019-05-17 Thread Gaowei Pu
There are some print format mistakes in debug messages. Fix them.

Signed-off-by: Gaowei Pu 
---
 fs/jbd2/journal.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 37e16d969925..565e99b67b30 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -203,7 +203,7 @@ static int kjournald2(void *arg)
if (journal->j_flags & JBD2_UNMOUNT)
goto end_loop;
 
-   jbd_debug(1, "commit_sequence=%d, commit_request=%d\n",
+   jbd_debug(1, "commit_sequence=%u, commit_request=%u\n",
journal->j_commit_sequence, journal->j_commit_request);
 
if (journal->j_commit_sequence != journal->j_commit_request) {
@@ -324,7 +324,7 @@ static void journal_kill_thread(journal_t *journal)
  * IO is in progress. do_get_write_access() handles this.
  *
  * The function returns a pointer to the buffer_head to be used for IO.
- * 
+ *
  *
  * Return value:
  *  <0: Error
@@ -500,7 +500,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
target)
 */
 
journal->j_commit_request = target;
-   jbd_debug(1, "JBD2: requesting commit %d/%d\n",
+   jbd_debug(1, "JBD2: requesting commit %u/%u\n",
  journal->j_commit_request,
  journal->j_commit_sequence);
journal->j_running_transaction->t_requested = jiffies;
@@ -513,7 +513,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
target)
WARN_ONCE(1, "JBD2: bad log_start_commit: %u %u %u %u\n",
  journal->j_commit_request,
  journal->j_commit_sequence,
- target, journal->j_running_transaction ? 
+ target, journal->j_running_transaction ?
  journal->j_running_transaction->t_tid : 0);
return 0;
 }
@@ -698,12 +698,12 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid)
 #ifdef CONFIG_JBD2_DEBUG
if (!tid_geq(journal->j_commit_request, tid)) {
printk(KERN_ERR
-  "%s: error: j_commit_request=%d, tid=%d\n",
+  "%s: error: j_commit_request=%u, tid=%u\n",
   __func__, journal->j_commit_request, tid);
}
 #endif
while (tid_gt(tid, journal->j_commit_sequence)) {
-   jbd_debug(1, "JBD2: want %d, j_commit_sequence=%d\n",
+   jbd_debug(1, "JBD2: want %u, j_commit_sequence=%u\n",
  tid, journal->j_commit_sequence);
read_unlock(>j_state_lock);
wake_up(>j_wait_commit);
@@ -944,7 +944,7 @@ int __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
 
trace_jbd2_update_log_tail(journal, tid, block, freed);
jbd_debug(1,
- "Cleaning journal tail from %d to %d (offset %lu), "
+ "Cleaning journal tail from %u to %u (offset %lu), "
  "freeing %lu\n",
  journal->j_tail_sequence, tid, block, freed);
 
@@ -1318,7 +1318,7 @@ static int journal_reset(journal_t *journal)
 */
if (sb->s_start == 0) {
jbd_debug(1, "JBD2: Skipping superblock update on recovered sb "
-   "(start %ld, seq %d, errno %d)\n",
+   "(start %ld, seq %u, errno %d)\n",
journal->j_tail, journal->j_tail_sequence,
journal->j_errno);
journal->j_flags |= JBD2_FLUSHED;
@@ -1453,7 +1453,7 @@ static void jbd2_mark_journal_empty(journal_t *journal, 
int write_op)
return;
}
 
-   jbd_debug(1, "JBD2: Marking journal as empty (seq %d)\n",
+   jbd_debug(1, "JBD2: Marking journal as empty (seq %u)\n",
  journal->j_tail_sequence);
 
sb->s_sequence = cpu_to_be32(journal->j_tail_sequence);
-- 
2.21.0



Re: [GIT PULL] KVM changes for 5.2 merge window

2019-05-17 Thread Nathan Chancellor
On Fri, May 17, 2019 at 05:59:36AM +0200, Paolo Bonzini wrote:
> Linus,
> 
> The following changes since commit 7a223e06b1a411cef6c4cd7a9b9a33c8d225b10e:
> 
>   KVM: x86: avoid misreporting level-triggered irqs as edge-triggered in 
> tracing (2019-04-16 15:38:08 +0200)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
> 
> for you to fetch changes up to dd53f6102c30a774e0db8e55d49017a38060f6f6:
> 
>   Merge tag 'kvmarm-for-v5.2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD 
> (2019-05-15 23:41:43 +0200)
> 
> 
> 
> * ARM: support for SVE and Pointer Authentication in guests, PMU improvements
> 
> * POWER: support for direct access to the POWER9 XIVE interrupt controller,
> memory and performance optimizations.
> 
> * x86: support for accessing memory not backed by struct page, fixes and 
> refactoring
> 
> * Generic: dirty page tracking improvements
> 
> 
> Aaron Lewis (5):
>   tests: kvm: Add tests to .gitignore
>   tests: kvm: Add tests for KVM_CAP_MAX_VCPUS and KVM_CAP_MAX_CPU_ID
>   KVM: nVMX: KVM_SET_NESTED_STATE - Tear down old EVMCS state before 
> setting new state
>   tests: kvm: Add tests for KVM_SET_NESTED_STATE
>   kvm: nVMX: Set nested_run_pending in vmx_set_nested_state after checks 
> complete
> 
> Alexey Kardashevskiy (3):
>   KVM: PPC: Book3S HV: Fix lockdep warning when entering the guest
>   KVM: PPC: Book3S HV: Avoid lockdep debugging in TCE realmode handlers
>   KVM: PPC: Book3S: Allocate guest TCEs on demand too
> 
> Amit Daniel Kachhap (3):
>   KVM: arm64: Add a vcpu flag to control ptrauth for guest
>   KVM: arm64: Add userspace flag to enable pointer authentication
>   KVM: arm64: Add capability to advertise ptrauth for guest
> 
> Andrew Murray (9):
>   arm64: arm_pmu: Remove unnecessary isb instruction
>   arm64: KVM: Encapsulate kvm_cpu_context in kvm_host_data
>   arm64: KVM: Add accessors to track guest/host only counters
>   arm64: arm_pmu: Add !VHE support for exclude_host/exclude_guest 
> attributes
>   arm64: KVM: Enable !VHE support for :G/:H perf event modifiers
>   arm64: KVM: Enable VHE support for :G/:H perf event modifiers
>   arm64: KVM: Avoid isb's by using direct pmxevtyper sysreg
>   arm64: docs: Document perf event attributes
>   arm64: KVM: Fix perf cycle counter support for VHE
> 
> Borislav Petkov (1):
>   x86/kvm: Implement HWCR support
> 
> Christian Borntraeger (9):
>   KVM: s390: add vector enhancements facility 2 to cpumodel
>   KVM: s390: add vector BCD enhancements facility to cpumodel
>   KVM: s390: add MSA9 to cpumodel
>   KVM: s390: provide query function for instructions returning 32 byte
>   KVM: s390: add enhanced sort facilty to cpu model
>   KVM: s390: add deflate conversion facilty to cpu model
>   KVM: s390: enable MSA9 keywrapping functions depending on cpu model
>   KVM: polling: add architecture backend to disable polling
>   KVM: s390: provide kvm_arch_no_poll function
> 
> Colin Ian King (1):
>   KVM: PPC: Book3S HV: XIVE: Fix spelling mistake "acessing" -> 
> "accessing"
> 
> Cédric Le Goater (18):
>   powerpc/xive: add OPAL extensions for the XIVE native exploitation 
> support
>   KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native 
> exploitation mode
>   KVM: PPC: Book3S HV: XIVE: Introduce a new capability 
> KVM_CAP_PPC_IRQ_XIVE
>   KVM: PPC: Book3S HV: XIVE: add a control to initialize a source
>   KVM: PPC: Book3S HV: XIVE: Add a control to configure a source
>   KVM: PPC: Book3S HV: XIVE: Add controls for the EQ configuration
>   KVM: PPC: Book3S HV: XIVE: Add a global reset control
>   KVM: PPC: Book3S HV: XIVE: Add a control to sync the sources
>   KVM: PPC: Book3S HV: XIVE: Add a control to dirty the XIVE EQ pages
>   KVM: PPC: Book3S HV: XIVE: Add get/set accessors for the VP XIVE state
>   KVM: Introduce a 'mmap' method for KVM devices
>   KVM: PPC: Book3S HV: XIVE: Add a TIMA mapping
>   KVM: PPC: Book3S HV: XIVE: Add a mapping for the source ESB pages
>   KVM: PPC: Book3S HV: XIVE: Add passthrough support
>   KVM: PPC: Book3S HV: XIVE: Activate XIVE exploitation mode
>   KVM: Introduce a 'release' method for KVM devices
>   KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method by a 'release' 
> method
>   KVM: PPC: Book3S: Remove useless checks in 'release' method of KVM 
> device
> 
> Dan Carpenter (1):
>   KVM: vmx: clean up some debug output
> 
> Dave Martin (41):
>   KVM: Documentation: Document arm64 core registers in detail
>   arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush
>   KVM: arm64: Delete orphaned declaration for __fpsimd_enabled()
>   KVM: 

Re: [PATCH 1/2] ledtrig-gpio: Request user input pin as GPIO

2019-05-17 Thread Uwe Kleine-König
Cc: += linux-g...@vger.kernel.org

On Thu, May 16, 2019 at 02:42:08PM -0700, Kun Yi wrote:
> The ledtrig-gpio logic assumes the input pin can be directly converted
> to IRQ using gpio_to_irq. This is problematic since there is no
> guarantee on the pinmux function nor the direction of the pin. Request
> the pin as an input GPIO before requesting it as an IRQ.

When reading this I thought the driver requested the gpio only after
converting to an irq. But in fact it didn't request and set the
direction at all.

> Tested: a free pin can be correctly requested as GPIO

This doesn't belong into the signed-off-area.

> Signed-off-by: Kun Yi 
> Change-Id: I657e3e108552612506775cc348a8b4b35d40cac5

This doesn't belong into the linux history either.

> ---
>  drivers/leds/trigger/ledtrig-gpio.c | 31 +++--
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/leds/trigger/ledtrig-gpio.c 
> b/drivers/leds/trigger/ledtrig-gpio.c
> index ed0db8ed825f..f6d50e031492 100644
> --- a/drivers/leds/trigger/ledtrig-gpio.c
> +++ b/drivers/leds/trigger/ledtrig-gpio.c
> @@ -117,6 +117,16 @@ static ssize_t gpio_trig_gpio_show(struct device *dev,
>   return sprintf(buf, "%u\n", gpio_data->gpio);
>  }
>  
> +static inline void free_used_gpio_if_valid(unsigned int gpio,
> +struct led_classdev *led)

Please stick to the function prefix used in this driver. I'd call this
function gpio_trig_free_gpio and not put "if_valid" into the name.

> +{
> + if (gpio == 0)
> + return;
> +
> + free_irq(gpio_to_irq(gpio), led);
> + gpio_free(gpio);
> +}
> +
>  static ssize_t gpio_trig_gpio_store(struct device *dev,
>   struct device_attribute *attr, const char *buf, size_t n)
>  {
> @@ -135,20 +145,30 @@ static ssize_t gpio_trig_gpio_store(struct device *dev,
>   return n;
>  
>   if (!gpio) {
> - if (gpio_data->gpio != 0)
> - free_irq(gpio_to_irq(gpio_data->gpio), led);
> + free_used_gpio_if_valid(gpio_data->gpio, led);
>   gpio_data->gpio = 0;
>   return n;
>   }
>  
> + ret = gpio_request(gpio, "ledtrig-gpio");
> + if (ret) {
> + dev_err(dev, "gpio_request failed with error %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpio_direction_input(gpio);
> + if (ret) {
> + dev_err(dev, "gpio_direction_input failed with err %d\n", ret);
> + return ret;
> + }

Please use gpio_request_one which implements both gpio_request() and
gpio_direction_*(). This also fixes the missing gpio_free() in the error
path of gpio_direction_input().

> +
>   ret = request_threaded_irq(gpio_to_irq(gpio), NULL, gpio_trig_irq,
>   IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_RISING
>   | IRQF_TRIGGER_FALLING, "ledtrig-gpio", led);
>   if (ret) {
>   dev_err(dev, "request_irq failed with error %d\n", ret);
>   } else {
> - if (gpio_data->gpio != 0)
> - free_irq(gpio_to_irq(gpio_data->gpio), led);
> + free_used_gpio_if_valid(gpio_data->gpio, led);
>   gpio_data->gpio = gpio;
>   /* After changing the GPIO, we need to update the LED. */
>   gpio_trig_irq(0, led);
> @@ -184,8 +204,7 @@ static void gpio_trig_deactivate(struct led_classdev *led)
>  {
>   struct gpio_trig_data *gpio_data = led_get_trigger_data(led);
>  
> - if (gpio_data->gpio != 0)
> - free_irq(gpio_to_irq(gpio_data->gpio), led);
> + free_used_gpio_if_valid(gpio_data->gpio, led);
>   kfree(gpio_data);
>  }
>  

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH 2/2] ledtrig-gpio: 0 is a valid GPIO number

2019-05-17 Thread Uwe Kleine-König
On Thu, May 16, 2019 at 02:42:09PM -0700, Kun Yi wrote:
> GPIO number 0 is a valid case to handle. Use -1 as initial value
> and use gpio_is_valid() to determine validity of the GPIO
> number.

I think it's more sensible to convert to gpiod instead.

Best regards
Uwe

> Signed-off-by: Kun Yi 
> Change-Id: I4a29f98b237fd0d8ba4dd2a28219d4429f2ccfff
> ---
>  drivers/leds/trigger/ledtrig-gpio.c | 16 +---
>  1 file changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/leds/trigger/ledtrig-gpio.c 
> b/drivers/leds/trigger/ledtrig-gpio.c
> index f6d50e031492..48d8ef8538bd 100644
> --- a/drivers/leds/trigger/ledtrig-gpio.c
> +++ b/drivers/leds/trigger/ledtrig-gpio.c
> @@ -22,7 +22,7 @@ struct gpio_trig_data {
>  
>   unsigned desired_brightness;/* desired brightness when led is on */
>   unsigned inverted;  /* true when gpio is inverted */
> - unsigned gpio;  /* gpio that triggers the leds */
> + int gpio;   /* gpio that triggers the leds */
>  };
>  
>  static irqreturn_t gpio_trig_irq(int irq, void *_led)
> @@ -114,13 +114,12 @@ static ssize_t gpio_trig_gpio_show(struct device *dev,
>  {
>   struct gpio_trig_data *gpio_data = led_trigger_get_drvdata(dev);
>  
> - return sprintf(buf, "%u\n", gpio_data->gpio);
> + return sprintf(buf, "%d\n", gpio_data->gpio);
>  }
>  
> -static inline void free_used_gpio_if_valid(unsigned int gpio,
> -struct led_classdev *led)
> +static inline void free_used_gpio_if_valid(int gpio, struct led_classdev 
> *led)
>  {
> - if (gpio == 0)
> + if (!gpio_is_valid(gpio))
>   return;
>  
>   free_irq(gpio_to_irq(gpio), led);
> @@ -144,12 +143,6 @@ static ssize_t gpio_trig_gpio_store(struct device *dev,
>   if (gpio_data->gpio == gpio)
>   return n;
>  
> - if (!gpio) {
> - free_used_gpio_if_valid(gpio_data->gpio, led);
> - gpio_data->gpio = 0;
> - return n;
> - }
> -
>   ret = gpio_request(gpio, "ledtrig-gpio");
>   if (ret) {
>   dev_err(dev, "gpio_request failed with error %d\n", ret);
> @@ -195,6 +188,7 @@ static int gpio_trig_activate(struct led_classdev *led)
>   return -ENOMEM;
>  
>   gpio_data->led = led;
> + gpio_data->gpio = -1;
>   led_set_trigger_data(led, gpio_data);
>  
>   return 0;
> -- 
> 2.21.0.1020.gf2820cf01a-goog
> 
> 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |


Re: [PATCH 5.0 000/137] 5.0.17-stable review

2019-05-17 Thread Kelsey Skunberg
On Wed, May 15, 2019 at 12:54:41PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.0.17 release.
> There are 137 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 Fri 17 May 2019 09:04:31 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.17-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.0.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no dmesg regressions on my system.

Cheers,
Kelsey


[PATCH v2] mtd: rawnand: Add Macronix NAND read retry support

2019-05-17 Thread Mason Yang
Add support for Macronix NAND read retry.

Macronix NANDs support specific read operation for data recovery,
which can be enabled/disabled with a SET/GET_FEATURE.
Driver checks byte 167 of Vendor Blocks in ONFI parameter page table
to see if this high-reliability function is supported.

Signed-off-by: Mason Yang 
---
 drivers/mtd/nand/raw/nand_macronix.c | 57 
 1 file changed, 57 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
b/drivers/mtd/nand/raw/nand_macronix.c
index e287e71..1a4dc92 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -17,6 +17,62 @@
 
 #include "internals.h"
 
+#define MACRONIX_READ_RETRY_BIT BIT(0)
+#define MACRONIX_READ_RETRY_MODE 6
+
+struct nand_onfi_vendor_macronix {
+   u8 reserved[1];
+   u8 reliability_func;
+} __packed;
+
+/*
+ * Macronix NANDs support using SET/GET_FEATURES to enter/exit read retry mode
+ */
+static int macronix_nand_setup_read_retry(struct nand_chip *chip, int mode)
+{
+   u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
+   int ret, feature_addr = ONFI_FEATURE_ADDR_READ_RETRY;
+
+   if (chip->parameters.supports_set_get_features &&
+   test_bit(feature_addr, chip->parameters.set_feature_list) &&
+   test_bit(feature_addr, chip->parameters.get_feature_list)) {
+   feature[0] = mode;
+   ret =  nand_set_features(chip, feature_addr, feature);
+   if (ret)
+   pr_err("Failed to set read retry moded:%d\n", mode);
+
+   ret =  nand_get_features(chip, feature_addr, feature);
+   if (ret || feature[0] != mode)
+   pr_err("Failed to verify read retry moded:%d(%d)\n",
+  mode, feature[0]);
+   }
+
+   return ret;
+}
+
+static void macronix_nand_onfi_init(struct nand_chip *chip)
+{
+   struct nand_parameters *p = >parameters;
+   struct nand_onfi_vendor_macronix *mxic;
+
+   if (!p->onfi)
+   return;
+
+   mxic = (struct nand_onfi_vendor_macronix *)p->onfi->vendor;
+   if ((mxic->reliability_func & MACRONIX_READ_RETRY_BIT) == 0)
+   return;
+
+   chip->read_retries = MACRONIX_READ_RETRY_MODE;
+   chip->setup_read_retry = macronix_nand_setup_read_retry;
+
+   if (p->supports_set_get_features) {
+   bitmap_set(p->set_feature_list,
+  ONFI_FEATURE_ADDR_READ_RETRY, 1);
+   bitmap_set(p->get_feature_list,
+  ONFI_FEATURE_ADDR_READ_RETRY, 1);
+   }
+}
+
 /*
  * Macronix AC series does not support using SET/GET_FEATURES to change
  * the timings unlike what is declared in the parameter page. Unflag
@@ -65,6 +121,7 @@ static int macronix_nand_init(struct nand_chip *chip)
chip->options |= NAND_BBM_FIRSTPAGE | NAND_BBM_SECONDPAGE;
 
macronix_nand_fix_broken_get_timings(chip);
+   macronix_nand_onfi_init(chip);
 
return 0;
 }
-- 
1.9.1



Re: [PATCH 4.9 00/51] 4.9.177-stable review

2019-05-17 Thread Kelsey Skunberg
On Wed, May 15, 2019 at 12:55:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.177 release.
> There are 51 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 Fri 17 May 2019 09:04:42 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.177-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no dmesg regressions on my system.

Cheers,
Kelsey



[PATCH] sound: open brace should be on the previous line

2019-05-17 Thread parna . naveenkumar
From: Naveen Kumar Parna 

Resolved open brace { should be on the previous line checkpatch.pl
error. While addressing this error, also corrected the affected code
for below mentioned checkpatch errors.

ERROR: spaces required around that '<' (ctx:VxV)
ERROR: spaces required around that '==' (ctx:VxV)
ERROR: space required before the open parenthesis '('

Signed-off-by: Naveen Kumar Parna 
---
 sound/sound_core.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/sound/sound_core.c b/sound/sound_core.c
index 40ad000c2e3c..ce794a2afc6b 100644
--- a/sound/sound_core.c
+++ b/sound/sound_core.c
@@ -111,8 +111,7 @@ module_exit(cleanup_soundcore);
 
 #define SOUND_STEP 16
 
-struct sound_unit
-{
+struct sound_unit {
int unit_minor;
const struct file_operations *unit_fops;
struct sound_unit *next;
@@ -151,8 +150,7 @@ module_param(preclaim_oss, int, 0444);
 
 static int soundcore_open(struct inode *, struct file *);
 
-static const struct file_operations soundcore_fops =
-{
+static const struct file_operations soundcore_fops = {
/* We must have an owner or the module locking fails */
.owner  = THIS_MODULE,
.open   = soundcore_open,
@@ -173,8 +171,7 @@ static int __sound_insert_unit(struct sound_unit * s, 
struct sound_unit **list,
while (*list && (*list)->unit_minornext);
 
-   while(nunit_minor>n)
break;
@@ -219,11 +216,9 @@ static int __sound_insert_unit(struct sound_unit * s, 
struct sound_unit **list,
  
 static struct sound_unit *__sound_remove_unit(struct sound_unit **list, int 
unit)
 {
-   while(*list)
-   {
+   while (*list) {
struct sound_unit *p=*list;
-   if(p->unit_minor==unit)
-   {
+   if (p->unit_minor == unit) {
*list=p->next;
return p;
}
@@ -528,8 +523,7 @@ static struct sound_unit *__look_for_unit(int chain, int 
unit)
struct sound_unit *s;

s=chains[chain];
-   while(s && s->unit_minor <= unit)
-   {
+   while (s && s->unit_minor <= unit) {
if(s->unit_minor==unit)
return s;
s=s->next;
@@ -545,8 +539,7 @@ static int soundcore_open(struct inode *inode, struct file 
*file)
const struct file_operations *new_fops = NULL;
 
chain=unit&0x0F;
-   if(chain==4 || chain==5)/* dsp/audio/dsp16 */
-   {
+   if (chain == 4 || chain == 5) { /* dsp/audio/dsp16 */
unit&=0xF0;
unit|=3;
chain=3;
-- 
2.17.1



Re: [PATCH 5.1 00/46] 5.1.3-stable review

2019-05-17 Thread Kelsey Skunberg
On Wed, May 15, 2019 at 12:56:24PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.3 release.
> There are 46 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 Fri 17 May 2019 09:04:22 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.3-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.1.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no dmesg regressions on my system.

Cheers,
Kelsey



Re: [PATCH 1/1] LZ4: Port LZ4 1.9.x FAST_DEC_LOOP and enable it on x86 and ARM64

2019-05-17 Thread Gao Xiang
Hi Chenxi,

Some words about the patch format.. not important tho.

One suggestion is that the subject line should be better written
as "[PATCH v2/v3/...] title" since it's more clear to know
which patch is the latest patch among these emails.

On 2019/5/17 13:56, Chenxi Mao wrote:
> FAST_DEC_LOOP was introduced from LZ4 1.9.0[1]
> This change would be introduce 10% on decompress operation
> according to LZ4 benchmark result on X86 devices.
> Meanwhile, LZ4 with FAST_DEC_LOOP could get improvements on ARM64,
> however clang compiler has downgrade if FAST_DEC_LOOP enabled.
> 
> So FAST_DEC_LOOP only enabled on X86/X86-64 or ARM64 with GCC build.
> 
> LZ4 FAST_DEC_LOOP bug fixes include as well.
> 1. fixed read-after input in LZ4_decompress_safe() (issue 681)
> 2. Fix out-of-bound read in LZ4_decompress_fast() (issue 676)
> 
> PS2:
> 1. Move common API to lz4defs.h
> 2. Add PPC related inline Macro defination.
> 3. Force inline new static apis.
> 
> Here is the test result on ARM64(cortex-A53)
> Benchmark via ZRAM:
> 
> Test case:
> taskset 03 /data/fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers \
> --buffer_compress_percentage=75  --size=700M \
> --scramble_buffers=1 --direct=1 --loops=100 --numjobs=1 \
> --filename=/data/test/test --name=seq-read --rw=read --stonewall
> 
> Patched:
> READ: bw=150MiB/s (157MB/s)
> Vanilla:
> READ: bw=135MiB/s (142MB/s)
> 
> [1] https://github.com/lz4/lz4/releases/tag/v1.9.0
> 
> Signed-off-by: chenxi.mao 
> ---

It's perferred to move all changelogs here if you don't want these changelog
as a part of commit and there are some patches which can be referenced:
https://lore.kernel.org/lkml/

Thanks,
Gao Xiang

>  lib/lz4/lz4_compress.c   |   4 +-
>  lib/lz4/lz4_decompress.c | 397 ---
>  lib/lz4/lz4defs.h|  60 +-
>  lib/lz4/lz4hc_compress.c |   2 +-
>  4 files changed, 392 insertions(+), 71 deletions(-)
> 
> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
> index cc7b6d4cc7c7..b703ed1ca57d 100644
> --- a/lib/lz4/lz4_compress.c
> +++ b/lib/lz4/lz4_compress.c
> @@ -322,7 +322,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>   *token = (BYTE)(litLength << ML_BITS);
>  
>   /* Copy Literals */
> - LZ4_wildCopy(op, anchor, op + litLength);
> + LZ4_wildCopy8(op, anchor, op + litLength);
>   op += litLength;
>   }
>  
> @@ -628,7 +628,7 @@ static int LZ4_compress_destSize_generic(
>   *token = (BYTE)(litLength << ML_BITS);
>  
>   /* Copy Literals */
> - LZ4_wildCopy(op, anchor, op + litLength);
> + LZ4_wildCopy8(op, anchor, op + litLength);
>   op += litLength;
>   }
>  
> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
> index 0c9d3ad17e0f..8622922304c3 100644
> --- a/lib/lz4/lz4_decompress.c
> +++ b/lib/lz4/lz4_decompress.c
> @@ -50,6 +50,96 @@
>  #define assert(condition) ((void)0)
>  #endif
>  
> +#ifndef LZ4_FAST_DEC_LOOP
> +#if defined(__i386__) || defined(__x86_64__)
> +#define LZ4_FAST_DEC_LOOP 1
> +#elif defined(__aarch64__) && !defined(__clang__)
> + /* On aarch64, we disable this optimization for clang because on certain
> +  * mobile chipsets and clang, it reduces performance. For more 
> information
> +  * refer to https://github.com/lz4/lz4/pull/707. */
> +#define LZ4_FAST_DEC_LOOP 1
> +#else
> +#define LZ4_FAST_DEC_LOOP 0
> +#endif
> +#endif
> +
> +#if LZ4_FAST_DEC_LOOP
> +#define FASTLOOP_SAFE_DISTANCE 64
> +FORCE_O2_INLINE_GCC_PPC64LE void
> +LZ4_memcpy_using_offset_base(BYTE * dstPtr, const BYTE * srcPtr, BYTE * 
> dstEnd,
> +  const size_t offset)
> +{
> + if (offset < 8) {
> + dstPtr[0] = srcPtr[0];
> +
> + dstPtr[1] = srcPtr[1];
> + dstPtr[2] = srcPtr[2];
> + dstPtr[3] = srcPtr[3];
> + srcPtr += inc32table[offset];
> + memcpy(dstPtr + 4, srcPtr, 4);
> + srcPtr -= dec64table[offset];
> + dstPtr += 8;
> + } else {
> + memcpy(dstPtr, srcPtr, 8);
> + dstPtr += 8;
> + srcPtr += 8;
> + }
> +
> + LZ4_wildCopy8(dstPtr, srcPtr, dstEnd);
> +}
> +
> +/* customized variant of memcpy, which can overwrite up to 32 bytes beyond 
> dstEnd
> + * this version copies two times 16 bytes (instead of one time 32 bytes)
> + * because it must be compatible with offsets >= 16. */
> +FORCE_O2_INLINE_GCC_PPC64LE void
> +LZ4_wildCopy32(void *dstPtr, const void *srcPtr, void *dstEnd)
> +{
> + BYTE *d = (BYTE *) dstPtr;
> + const BYTE *s = (const BYTE *)srcPtr;
> + BYTE *const e = (BYTE *) dstEnd;
> +
> + do {
> + memcpy(d, s, 16);
> + memcpy(d + 16, s + 16, 16);
> + d += 32;
> + s += 32;
> + } while (d < 

RE: [PATCH V12 2/5] thermal: of-thermal: add API for getting sensor ID from DT

2019-05-17 Thread Anson Huang


> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Thursday, May 16, 2019 5:39 PM
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com;
> will.dea...@arm.com; rui.zh...@intel.com; edubez...@gmail.com;
> Aisheng Dong ; ulf.hans...@linaro.org; Daniel
> Baluta ; Peng Fan ;
> he...@sntech.de; horms+rene...@verge.net.au; agr...@kernel.org;
> o...@lixom.net; bjorn.anders...@linaro.org; ja...@amarulasolutions.com;
> enric.balle...@collabora.com; marc.w.gonza...@free.fr;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: Re: [PATCH V12 2/5] thermal: of-thermal: add API for getting sensor
> ID from DT
> 
> On 16/04/2019 05:22, Anson Huang wrote:
> > On some platforms like i.MX8QXP, the thermal driver needs a real HW
> > sensor ID from DT thermal zone, the HW sensor ID is used to get
> > temperature from SCU firmware, and the virtual sensor ID starting from
> > 0 to N is NOT used at all, this patch adds new API
> > thermal_zone_of_get_sensor_id() to provide the feature of getting
> > sensor ID from DT thermal zone's node.
> >
> > Signed-off-by: Anson Huang 
> 
> Eduardo?
> 
> What do you think about this patch?

I would like to hear Eduardo's opinion about this patch before sending out a 
new version
for review, thanks.

Anson.

> 
> > ---
> > New patch.
> > ---
> >  drivers/thermal/of-thermal.c | 53
> ++--
> >  include/linux/thermal.h  | 10 +
> >  2 files changed, 51 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/of-thermal.c
> > b/drivers/thermal/of-thermal.c index 2df059c..2e4320c 100644
> > --- a/drivers/thermal/of-thermal.c
> > +++ b/drivers/thermal/of-thermal.c
> > @@ -446,6 +446,46 @@ thermal_zone_of_add_sensor(struct device_node
> > *zone,  }
> >
> >  /**
> > + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal
> > + zone
> > + * @tz_np: a valid thermal zone device node.
> > + * @sensor_specs: pointer to output arguments structure will be passed
> back.
> > + * @id: a sensor ID pointer will be passed back.
> > + *
> > + * This function will get sensor ID from a given thermal zone node,
> > + use
> > + * "thermal-sensors" as list name, and get sensor ID from first
> > + phandle's
> > + * argument.
> > + *
> > + * Return: 0 on success, proper error code otherwise.
> > + */
> > +
> > +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > + struct of_phandle_args *sensor_specs,
> > + u32 *id)
> > +{
> > +   int ret;
> > +
> > +   ret = of_parse_phandle_with_args(tz_np,
> > +"thermal-sensors",
> > +"#thermal-sensor-cells",
> > +0,
> > +sensor_specs);
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (sensor_specs->args_count >= 1) {
> > +   *id = sensor_specs->args[0];
> > +   WARN(sensor_specs->args_count > 1,
> > +"%pOFn: too many cells in sensor specifier %d\n",
> > +sensor_specs->np, sensor_specs->args_count);
> > +   } else {
> > +   *id = 0;
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(thermal_zone_of_get_sensor_id);
> > +
> > +/**
> >   * thermal_zone_of_sensor_register - registers a sensor to a DT thermal
> zone
> >   * @dev: a valid struct device pointer of a sensor device. Must contain
> >   *   a valid .of_node, for the sensor node.
> > @@ -500,21 +540,10 @@ thermal_zone_of_sensor_register(struct device
> *dev, int sensor_id, void *data,
> > int ret, id;
> >
> > /* For now, thermal framework supports only 1 sensor per
> zone */
> > -   ret = of_parse_phandle_with_args(child, "thermal-sensors",
> > -"#thermal-sensor-cells",
> > -0, _specs);
> > +   ret = thermal_zone_of_get_sensor_id(child, _specs,
> );
> > if (ret)
> > continue;
> >
> > -   if (sensor_specs.args_count >= 1) {
> > -   id = sensor_specs.args[0];
> > -   WARN(sensor_specs.args_count > 1,
> > -"%pOFn: too many cells in sensor specifier %d\n",
> > -sensor_specs.np, sensor_specs.args_count);
> > -   } else {
> > -   id = 0;
> > -   }
> > -
> > if (sensor_specs.np == sensor_np && id == sensor_id) {
> > tzd = thermal_zone_of_add_sensor(child, sensor_np,
> >  data, ops);
> > diff --git a/include/linux/thermal.h 

Re: [PATCH 4.4 000/266] 4.4.180-stable review

2019-05-17 Thread Greg Kroah-Hartman
On Thu, May 16, 2019 at 03:47:25PM -0700, Kevin Hilman wrote:
> Greg Kroah-Hartman  writes:
> 
> > On Wed, May 15, 2019 at 07:47:45AM -0700, kernelci.org bot wrote:
> >> stable-rc/linux-4.4.y boot: 98 boots: 1 failed, 92 passed with 3 offline, 
> >> 1 untried/unknown, 1 conflict (v4.4.179-267-gbe756dada5b7)
> >> 
> >> Full Boot Summary: 
> >> https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.179-267-gbe756dada5b7/
> >> Full Build Summary: 
> >> https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.179-267-gbe756dada5b7/
> >> 
> >> Tree: stable-rc
> >> Branch: linux-4.4.y
> >> Git Describe: v4.4.179-267-gbe756dada5b7
> >> Git Commit: be756dada5b771fe51be37a77ad0bdfba543fdae
> >> Git URL: 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> Tested: 44 unique boards, 21 SoC families, 14 builds out of 190
> >> 
> >> Boot Regressions Detected:
> >> 
> >> arm:
> >> 
> >> omap2plus_defconfig:
> >> gcc-8:
> >>   omap4-panda:
> >>   lab-baylibre: new failure (last pass: 
> >> v4.4.179-254-gce69be0d452a)
> >
> > Odd, is this specific to this release?
> 
> No, looks like a lab-specific hiccup.
> 
> A little bit further down in the original report (I know, not a useful
> place for it) was this:
> 
> > Conflicting Boot Failure Detected: (These likely are not failures as other 
> > labs are reporting PASS. Needs review.)
> >  
> > arm:
> > omap2plus_defconfig:
> > omap4-panda:
> > lab-baylibre: FAIL (gcc-8)
> > lab-baylibre-seattle: PASS (gcc-8)
> 
> which means the same board passed in one lab, but not the other,
> suggesting something.
> 
> This is a bug in our email reports.  Regressions should not be reported
> whene there are conflicting results from labs.

Ah, thanks for the explaination, that makes more sense.

greg k-h


RE: my test code and result///[PATCH] mm/mmap: fix the adjusted length error

2019-05-17 Thread chenjianhong (A)
[test code] The following is my test code.
/*
 * first, we allocat large virtual memory;
 * second, we allocate hugepage memory by shmat, and release one
 * of the hugepage memory block;
 * third, we allocate hugepage memory by shmat again, this will fail.
 */
#include 
#include 
#include 
#include 

int size = 0x400;
int shmid[5];
void *shm[5];
int key[5] = {234, 235, 236, 237, 238};
unsigned long seg_size[5] = {0x20, 0x400, 0x100,
0x40, 0xa0};

int init_memory(void)
{
int i,j;
for (i = 0; i < 5; i++) {
shmid[i] = shmget((key_t)key[i], seg_size[i], 0666
| IPC_CREAT | SHM_HUGETLB);
if (shmid[i] == -1) {
fprintf(stderr, "shmget[%d] error(%d)\n",
i, errno);
goto failed;
}
}
return 0;
failed:
for (j = 0; j < i; j++) {
shmctl(shmid[j], IPC_RMID, 0);
}
return -1;
}

int del_segmem(void)
{
int i = 0;
for (i = 0; i < 5; i++) {
shmdt(shm[i]);
shmctl(shmid[i], IPC_RMID, 0);
}
return 0;
}

int fun_C(void)
{
int i = 0;
printf("---fun_C shmat---\n");
for (i = 0; i < 5; i+=1) {
shm[i] = shmat(shmid[i], 0, 0);
if (shm[i] == (void *)-1) {
fprintf(stderr, "shmat[%d] failed %d\n", i, errno);
return -1;
}
}
sleep(2);
system("pid=`ps -e | grep memory | awk '{print $1}'`;cat 
/proc/$pid/maps");
shmdt(shm[1]);
printf("---after fun_C 
shmdt---\n");
system("pid=`ps -e | grep memory | awk '{print $1}'`;cat 
/proc/$pid/maps");
printf("---fun_C ok---\n");
return 0;
}

int fun_A(void)
{
int i = 1;
shm[i] = shmat(shmid[1], 0, 0);
printf("---fun_A shmat---\n");
if (shm[i] == (void *)-1) {
fprintf(stderr, "funa shmat[%d] size(0x%08x)failed %d\n",
i, seg_size[i], errno);
return -1;
}
system("pid=`ps -e | grep memory | awk '{print $1}'`;cat 
/proc/$pid/maps");
sleep(2);
shmdt(shm[1]);
printf("---fun_A shmdt---\n");
system("pid=`ps -e | grep memory | awk '{print $1}'`;cat 
/proc/$pid/maps");
printf("---fun_A ok---\n");
return 0;
}

/*
 * first, we allocat large virtual memory;
 * second, we allocate hugepage memory by shmat, and release one
 * of the hugepage memory block;
 * third, we allocate hugepage memory by shmat again, this will fail.
 */

int main(int argc,char * argv[])
{
int i;
int ret = 0;
for (i == 0; i < 52; i++) {
malloc(size);//first
}
if (init_memory() != 0) {
ret = -1;
goto failed_memory;
}
fun_C();//second
sleep(5);
ret = fun_A();//third
if (ret != 0) {
goto failed_memory;
}
sleep(3);
failed_memory:
del_segmem();
return ret;
}

[Test result]
---fun_C shmat-
8000-9000 r-xp  00:12 290   /tmp/memory_mmap
00011000-00012000 rw-p 1000 00:12 290   /tmp/memory_mmap
27589000-f75bd000 rw-p  00:00 0
f75bd000-f76e4000 r-xp  01:00 560   /lib/libc-2.11.1.so
f76e4000-f76ec000 ---p 00127000 01:00 560   /lib/libc-2.11.1.so
f76ec000-f76ee000 r--p 00127000 01:00 560   /lib/libc-2.11.1.so
f76ee000-f76ef000 rw-p 00129000 01:00 560   /lib/libc-2.11.1.so
f76ef000-f76f2000 rw-p  00:00 0
f76f2000-f7713000 r-xp  01:00 583   /lib/libgcc_s.so.1
f7713000-f771a000 ---p 00021000 01:00 583   /lib/libgcc_s.so.1
f771a000-f771b000 rw-p 0002 01:00 583   /lib/libgcc_s.so.1
f771b000-f7738000 r-xp  01:00 543   /lib/ld-2.11.1.so
f773c000-f773d000 rw-p  00:00 0
f773d000-f773f000 rw-p  00:00 0
f773f000-f774 r--p 0001c000 01:00 543   /lib/ld-2.11.1.so
f774-f7741000 rw-p 0001d000 01:00 543   /lib/ld-2.11.1.so
f780-f7a0 rw-s  00:0e 327680/SYSV00ea (deleted)
f7a0-fba0 rw-s  00:0e 360449/SYSV00eb (deleted)
fba0-fca0 rw-s  00:0e 393218/SYSV00ec (deleted)
fca0-fce0 rw-s  00:0e 425987/SYSV00ed (deleted)
fce0-fd80 rw-s  00:0e 458756/SYSV00ee (deleted)
ff9df000-ffa0 rw-p  00:00 0 [stack]
-1000 r-xp  

[PATCH] s390: add unreachable() to dump_fault_info() to fix -Wmaybe-uninitialized

2019-05-17 Thread Masahiro Yamada
When CONFIG_OPTIMIZE_INLINING is enabled for s390, I see this warning:

arch/s390/mm/fault.c:127:15: warning: 'asce' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  switch (asce & _ASCE_TYPE_MASK) {
arch/s390/mm/fault.c:177:16: note: 'asce' was declared here
  unsigned long asce;
^~~~

If get_fault_type() is not inlined, the compiler cannot deduce that
all the possible paths in the 'switch' statement are covered.

Of course, we could mark get_fault_type() as __always_inline to get
back the original behavior, but I do not think it sensible to force
inlining just for the purpose of suppressing the warning. Since this
is just a matter of warning, I want to keep as much room for compiler
optimization as possible.

I added unreachable() to teach the compiler that the 'default' label
is unreachable.

I got rid of the 'inline' marker. Even without the 'inline' hint,
the compiler inlines functions based on its inlining heuristic.

Fixes: 9012d011660e ("compiler: allow all arches to enable 
CONFIG_OPTIMIZE_INLINING")
Signed-off-by: Masahiro Yamada 
---

 arch/s390/mm/fault.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index c220399ae196..91ce03fd0c84 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -85,7 +85,7 @@ static inline int notify_page_fault(struct pt_regs *regs)
  * Find out which address space caused the exception.
  * Access register mode is impossible, ignore space == 3.
  */
-static inline enum fault_type get_fault_type(struct pt_regs *regs)
+static enum fault_type get_fault_type(struct pt_regs *regs)
 {
unsigned long trans_exc_code;
 
@@ -211,6 +211,8 @@ static void dump_fault_info(struct pt_regs *regs)
asce = S390_lowcore.kernel_asce;
pr_cont("kernel ");
break;
+   default:
+   unreachable();
}
pr_cont("ASCE.\n");
dump_pagetable(asce, regs->int_parm_long & __FAIL_ADDR_MASK);
-- 
2.17.1



[PATCH] s390: mark __cpacf_check_opcode() and cpacf_query_func() as __always_inline

2019-05-17 Thread Masahiro Yamada
Commit e60fb8bf68d4 ("s390/cpacf: mark scpacf_query() as __always_inline")
was not enough to make sure to meet the 'i' (immediate) constraint for the
asm operands.

With CONFIG_OPTIMIZE_INLINING enabled, Laura Abbott reported error
with gcc 9.1.1:

  In file included from arch/s390/crypto/prng.c:29:
  ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func':
  ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably 
doesn't match constraints
170 |  asm volatile(
|  ^~~
  ./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm'

Add more __always_inline to force inlining.

Fixes: 9012d011660e ("compiler: allow all arches to enable 
CONFIG_OPTIMIZE_INLINING")
Reported-by: Laura Abbott 
Signed-off-by: Masahiro Yamada 
---

 arch/s390/include/asm/cpacf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
index f316de40e51b..19459dfb4295 100644
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -177,7 +177,7 @@ static inline void __cpacf_query(unsigned int opcode, 
cpacf_mask_t *mask)
: "cc");
 }
 
-static inline int __cpacf_check_opcode(unsigned int opcode)
+static __always_inline int __cpacf_check_opcode(unsigned int opcode)
 {
switch (opcode) {
case CPACF_KMAC:
@@ -217,7 +217,7 @@ static inline int cpacf_test_func(cpacf_mask_t *mask, 
unsigned int func)
return (mask->bytes[func >> 3] & (0x80 >> (func & 7))) != 0;
 }
 
-static inline int cpacf_query_func(unsigned int opcode, unsigned int func)
+static __always_inline int cpacf_query_func(unsigned int opcode, unsigned int 
func)
 {
cpacf_mask_t mask;
 
-- 
2.17.1



Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

2019-05-17 Thread Christian Brauner
On May 16, 2019 10:23:31 PM GMT+02:00, "Dmitry V. Levin"  
wrote:
>[looks like linux-abi is a typo, Cc'ed linux-api instead]
>
>On Thu, May 16, 2019 at 05:50:22PM +0100, Al Viro wrote:
>> [linux-abi cc'd]
>> 
>> On Thu, May 16, 2019 at 06:31:52PM +0200, Christian Brauner wrote:
>> > On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote:
>> > > On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote:
>> > > > 
>> > > > Hi Linus, Al,
>> > > > 
>> > > > Here are some patches that make changes to the mount API UAPI
>and two of
>> > > > them really need applying, before -rc1 - if they're going to be
>applied at
>> > > > all.
>> > > 
>> > > I'm fine with 2--4, but I'm not convinced that cloexec-by-default
>crusade
>> > > makes any sense.  Could somebody give coherent arguments in
>favour of
>> > > abandoning the existing conventions?
>> > 
>> > So as I said in the commit message. From a userspace perspective
>it's
>> > more of an issue if one accidently leaks an fd to a task during
>exec.
>> > 
>> > Also, most of the time one does not want to inherit an fd during an
>> > exec. It is a hazzle to always have to specify an extra flag.
>> > 
>> > As Al pointed out to me open() semantics are not going anywhere.
>Sure,
>> > no argument there at all.
>> > But the idea of making fds cloexec by default is only targeted at
>fds
>> > that come from separate syscalls. fsopen(), open_tree_clone(), etc.
>they
>> > all return fds independent of open() so it's really easy to have
>them
>> > cloexec by default without regressing anyone and we also remove the
>need
>> > for a bunch of separate flags for each syscall to turn them into
>> > cloexec-fds. I mean, those for syscalls came with 4 separate flags
>to be
>> > able to specify that the returned fd should be made cloexec. The
>other
>> > way around, cloexec by default, fcntl() to remove the cloexec bit
>is way
>> > saner imho.
>> 
>> Re separate flags - it is, in principle, a valid argument.  OTOH, I'm
>not
>> sure if they need to be separate - they all have the same value and
>> I don't see any reason for that to change...
>> 
>> Only tangentially related, but I wonder if something like
>close_range(from, to)
>> would be a more useful approach...  That kind of open-coded loops is
>not
>> rare in userland and kernel-side code can do them much cheaper. 
>Something
>> like
>>  /* that exec is sensitive */
>>  unshare(CLONE_FILES);
>>  /* we don't want anything past stderr here */
>>  close_range(3, ~0U);
>>  execve();
>> on the userland side of thing.  Comments?
>
>glibc people need a syscall to implement closefrom properly, see
>https://sourceware.org/bugzilla/show_bug.cgi?id=10353#c14

I have a prototype for close_range().
I'll send it out after rc1.

Christian



Re: [PATCH] s390: add unreachable() to dump_fault_info() to fix -Wmaybe-uninitialized

2019-05-17 Thread Sergey Senozhatsky
On (05/17/19 15:49), Masahiro Yamada wrote:
[..]
> @@ -211,6 +211,8 @@ static void dump_fault_info(struct pt_regs *regs)
>   asce = S390_lowcore.kernel_asce;
>   pr_cont("kernel ");
>   break;
> + default:
> + unreachable();
>   }
>   pr_cont("ASCE.\n");
>   dump_pagetable(asce, regs->int_parm_long & __FAIL_ADDR_MASK);

Or have default fault type and asce?

Just an idea.

---

diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index c220399ae196..876d71c31894 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -174,7 +174,8 @@ static void dump_pagetable(unsigned long asce, unsigned 
long address)
 
 static void dump_fault_info(struct pt_regs *regs)
 {
-   unsigned long asce;
+   unsigned long asce = S390_lowcore.kernel_asce;
+   char *type = "kernel ";
 
pr_alert("Failing address: %016lx TEID: %016lx\n",
 regs->int_parm_long & __FAIL_ADDR_MASK, regs->int_parm_long);
@@ -197,22 +198,18 @@ static void dump_fault_info(struct pt_regs *regs)
switch (get_fault_type(regs)) {
case USER_FAULT:
asce = S390_lowcore.user_asce;
-   pr_cont("user ");
+   type = "user ";
break;
case VDSO_FAULT:
asce = S390_lowcore.vdso_asce;
-   pr_cont("vdso ");
+   type = "vdso ";
break;
case GMAP_FAULT:
asce = ((struct gmap *) S390_lowcore.gmap)->asce;
-   pr_cont("gmap ");
-   break;
-   case KERNEL_FAULT:
-   asce = S390_lowcore.kernel_asce;
-   pr_cont("kernel ");
+   type = "gmap ";
break;
}
-   pr_cont("ASCE.\n");
+   pr_cont("%s ASCE.\n", type);
dump_pagetable(asce, regs->int_parm_long & __FAIL_ADDR_MASK);
 }
 


[GIT PULL] s390 patches for the 5.2 merge window #2

2019-05-17 Thread Martin Schwidefsky
The following changes since commit 71ae5fc87c34ecbdca293c2a5c563d6be2576558:

  Merge tag 'linux-kselftest-5.2-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest (2019-05-06 
20:29:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux tags/s390-5.2-2

for you to fetch changes up to f3e20ad67b4c8365df9818fd3c8026e105d6b53a:

  s390: move arch/s390/defconfig to arch/s390/configs/defconfig (2019-05-14 
17:54:48 +0200)


s390 updates for the 5.2 merge window #2

 - Enhancements for the QDIO layer

 - Remove the RCP trace event

 - Avoid three build issues

 - Move the defconfig to the configs directory


Farhan Ali (1):
  s390/cio: Remove tracing for rchp instruction

Julian Wiedmann (3):
  s390/qdio: allow to scan all Output SBALs in one go
  s390/qdio: use get_buf_state() in debug_get_buf_state()
  s390/qdio: optimize state inspection of HW-owned SBALs

Martin Schwidefsky (1):
  s390/boot: fix compiler error due to missing awk strtonum

Masahiro Yamada (1):
  s390: move arch/s390/defconfig to arch/s390/configs/defconfig

Vasily Gorbik (2):
  latent_entropy: avoid build error when plugin cflags are not set
  s390/kasan: adapt disabled_wait usage to avoid build error

 arch/s390/Makefile  |  2 ++
 arch/s390/boot/Makefile |  1 -
 arch/s390/boot/compressed/vmlinux.lds.S |  2 ++
 arch/s390/{ => configs}/defconfig   |  0
 arch/s390/mm/kasan_init.c   |  2 +-
 drivers/s390/cio/qdio_main.c| 19 +++
 drivers/s390/cio/trace.c|  1 -
 drivers/s390/cio/trace.h| 23 ---
 include/linux/random.h  |  2 +-
 9 files changed, 17 insertions(+), 35 deletions(-)
 rename arch/s390/{ => configs}/defconfig (100%)

diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index df1d6a1..de8521f 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -10,6 +10,8 @@
 # Copyright (C) 1994 by Linus Torvalds
 #
 
+KBUILD_DEFCONFIG := defconfig
+
 LD_BFD := elf64-s390
 KBUILD_LDFLAGS := -m elf64_s390
 KBUILD_AFLAGS_MODULE += -fPIC
diff --git a/arch/s390/boot/Makefile b/arch/s390/boot/Makefile
index c51496b..7cba96e 100644
--- a/arch/s390/boot/Makefile
+++ b/arch/s390/boot/Makefile
@@ -58,7 +58,6 @@ define cmd_section_cmp
touch $@
 endef
 
-OBJCOPYFLAGS_bzImage := --pad-to $$(readelf -s $(obj)/compressed/vmlinux | awk 
'/\<_end\>/ {print or(strtonum("0x"$$2),4095)+1}')
 $(obj)/bzImage: $(obj)/compressed/vmlinux $(obj)/section_cmp.boot.data 
$(obj)/section_cmp.boot.preserved.data FORCE
$(call if_changed,objcopy)
 
diff --git a/arch/s390/boot/compressed/vmlinux.lds.S 
b/arch/s390/boot/compressed/vmlinux.lds.S
index 112b8d9..635217e 100644
--- a/arch/s390/boot/compressed/vmlinux.lds.S
+++ b/arch/s390/boot/compressed/vmlinux.lds.S
@@ -77,6 +77,8 @@ SECTIONS
_compressed_start = .;
*(.vmlinux.bin.compressed)
_compressed_end = .;
+   FILL(0xff);
+   . = ALIGN(4096);
}
. = ALIGN(256);
.bss : {
diff --git a/arch/s390/defconfig b/arch/s390/configs/defconfig
similarity index 100%
rename from arch/s390/defconfig
rename to arch/s390/configs/defconfig
diff --git a/arch/s390/mm/kasan_init.c b/arch/s390/mm/kasan_init.c
index 01892dc..0c1f257 100644
--- a/arch/s390/mm/kasan_init.c
+++ b/arch/s390/mm/kasan_init.c
@@ -28,7 +28,7 @@ static void __init kasan_early_panic(const char *reason)
 {
sclp_early_printk("The Linux kernel failed to boot with the 
KernelAddressSanitizer:\n");
sclp_early_printk(reason);
-   disabled_wait(0);
+   disabled_wait();
 }
 
 static void * __init kasan_early_alloc_segment(void)
diff --git a/drivers/s390/cio/qdio_main.c b/drivers/s390/cio/qdio_main.c
index cfce255..7b7620d 100644
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@ -205,17 +205,22 @@ static inline int get_buf_states(struct qdio_q *q, 
unsigned int bufnr,
 int auto_ack, int merge_pending)
 {
unsigned char __state = 0;
-   int i;
+   int i = 1;
 
if (is_qebsm(q))
return qdio_do_eqbs(q, state, bufnr, count, auto_ack);
 
/* get initial state: */
__state = q->slsb.val[bufnr];
+
+   /* Bail out early if there is no work on the queue: */
+   if (__state & SLSB_OWNER_CU)
+   goto out;
+
if (merge_pending && __state == SLSB_P_OUTPUT_PENDING)
__state = SLSB_P_OUTPUT_EMPTY;
 
-   for (i = 1; i < count; i++) {
+   for (; i < count; i++) {
bufnr = next_buf(bufnr);
 
/* merge PENDING into EMPTY: */
@@ -228,6 +233,8 @@ static inline int get_buf_states(struct qdio_q *q, 

Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

2019-05-17 Thread Christian Brauner
On May 16, 2019 6:50:22 PM GMT+02:00, Al Viro  wrote:
>[linux-abi cc'd]
>
>On Thu, May 16, 2019 at 06:31:52PM +0200, Christian Brauner wrote:
>> On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote:
>> > On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote:
>> > > 
>> > > Hi Linus, Al,
>> > > 
>> > > Here are some patches that make changes to the mount API UAPI and
>two of
>> > > them really need applying, before -rc1 - if they're going to be
>applied at
>> > > all.
>> > 
>> > I'm fine with 2--4, but I'm not convinced that cloexec-by-default
>crusade
>> > makes any sense.  Could somebody give coherent arguments in favour
>of
>> > abandoning the existing conventions?
>> 
>> So as I said in the commit message. From a userspace perspective it's
>> more of an issue if one accidently leaks an fd to a task during exec.
>> 
>> Also, most of the time one does not want to inherit an fd during an
>> exec. It is a hazzle to always have to specify an extra flag.
>> 
>> As Al pointed out to me open() semantics are not going anywhere.
>Sure,
>> no argument there at all.
>> But the idea of making fds cloexec by default is only targeted at fds
>> that come from separate syscalls. fsopen(), open_tree_clone(), etc.
>they
>> all return fds independent of open() so it's really easy to have them
>> cloexec by default without regressing anyone and we also remove the
>need
>> for a bunch of separate flags for each syscall to turn them into
>> cloexec-fds. I mean, those for syscalls came with 4 separate flags to
>be
>> able to specify that the returned fd should be made cloexec. The
>other
>> way around, cloexec by default, fcntl() to remove the cloexec bit is
>way
>> saner imho.
>
>Re separate flags - it is, in principle, a valid argument.  OTOH, I'm
>not
>sure if they need to be separate - they all have the same value and
>I don't see any reason for that to change...

One last thing I'd like to point out is that
we already have syscalls and ioctls that
return cloexec fds. So the consistency
argument is kinda dead.

If you still prefer to have cloexec flags
for the 4 new syscalls then yes,
if they could at least all have the same name
(FSMOUNT_CLOEXEC?) that would be good.

>
>Only tangentially related, but I wonder if something like
>close_range(from, to)
>would be a more useful approach...  That kind of open-coded loops is
>not
>rare in userland and kernel-side code can do them much cheaper. 
>Something
>like
>   /* that exec is sensitive */
>   unshare(CLONE_FILES);
>   /* we don't want anything past stderr here */
>   close_range(3, ~0U);
>   execve();
>on the userland side of thing.  Comments?

Said it before but, the list was mistyped so again:
I think that's a great idea.
I have a prototype for close_range(start, end, flags).
I'll wait after rc1 and then send it out.

Christian


RE: [PATCH v3] selftests/x86: Support Atom for syscall_arg_fault test

2019-05-17 Thread Tong, Bo
Is this patch going to be merged? Or still any blocking issue there?

Thanks,
Bo

-Original Message-
From: shuah [mailto:sh...@kernel.org] 
Sent: Friday, April 19, 2019 10:05 PM
To: Tong, Bo ; l...@kernel.org; x...@kernel.org
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; 
sk...@linuxfoundation.org; sh...@kernel.org
Subject: Re: [PATCH v3] selftests/x86: Support Atom for syscall_arg_fault test

On 4/19/19 1:10 AM, Tong Bo wrote:
> Atom-based CPUs trigger stack fault when invoke 32-bit SYSENTER 
> instruction with invalid register values. So we also need SIGBUS handling in 
> this case.
> 
> Following is assembly when the fault exception happens.
> 
> (gdb) disassemble $eip
> Dump of assembler code for function __kernel_vsyscall:
> 0xf7fd8fe0 <+0>: push   %ecx
> 0xf7fd8fe1 <+1>: push   %edx
> 0xf7fd8fe2 <+2>: push   %ebp
> 0xf7fd8fe3 <+3>: mov%esp,%ebp
> 0xf7fd8fe5 <+5>: sysenter
> 0xf7fd8fe7 <+7>: int$0x80
> => 0xf7fd8fe9 <+9>: pop%ebp
> 0xf7fd8fea <+10>:pop%edx
> 0xf7fd8feb <+11>:pop%ecx
> 0xf7fd8fec <+12>:ret
> End of assembler dump.
> 
> According to Intel SDM, this could also be a Stack Segment Fault(#SS, 
> 12), except a normal Page Fault(#PF, 14). Especially, in section 6.9 
> of Vol.3A, both stack and page faults are within the 10th(lowest 
> priority) class, and as it said, "exceptions within each class are 
> implementation-dependent and may vary from processor to processor". 
> It's expected for processors like Intel Atom to trigger stack 
> fault(SIGBUS), while we get page fault(SIGSEGV) from common Core processors.
> 
> Signed-off-by: Tong Bo 
> Acked-by: Andy Lutomirski 
> ---
>   tools/testing/selftests/x86/syscall_arg_fault.c | 10 --
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/x86/syscall_arg_fault.c 
> b/tools/testing/selftests/x86/syscall_arg_fault.c
> index 7db4fc9..d2548401 100644
> --- a/tools/testing/selftests/x86/syscall_arg_fault.c
> +++ b/tools/testing/selftests/x86/syscall_arg_fault.c
> @@ -43,7 +43,7 @@ static sigjmp_buf jmpbuf;
>   
>   static volatile sig_atomic_t n_errs;
>   
> -static void sigsegv(int sig, siginfo_t *info, void *ctx_void)
> +static void sigsegv_or_sigbus(int sig, siginfo_t *info, void 
> +*ctx_void)
>   {
>   ucontext_t *ctx = (ucontext_t*)ctx_void;
>   
> @@ -73,7 +73,13 @@ int main()
>   if (sigaltstack(, NULL) != 0)
>   err(1, "sigaltstack");
>   
> - sethandler(SIGSEGV, sigsegv, SA_ONSTACK);
> + sethandler(SIGSEGV, sigsegv_or_sigbus, SA_ONSTACK);
> + /*
> +  * The actual exception can vary.  On Atom CPUs, we get #SS
> +  * instead of #PF when the vDSO fails to access the stack when
> +  * ESP is too close to 2^32, and #SS causes SIGBUS.
> +  */
> + sethandler(SIGBUS, sigsegv_or_sigbus, SA_ONSTACK);
>   sethandler(SIGILL, sigill, SA_ONSTACK);
>   
>   /*
> 

In case there is a dependency on x86 tree, here is my Ack

Acked-by: Shuah Khan 

thanks,
-- Shuah


[PATCH] nvme: target: use struct_size() in kmalloc()

2019-05-17 Thread xiaolinkui
Use struct_size() to keep code sample.
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

instance = kmalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);

Signed-off-by: xiaolinkui 
---
 drivers/nvme/target/admin-cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c
index 9f72d51..6f9f830 100644
--- a/drivers/nvme/target/admin-cmd.c
+++ b/drivers/nvme/target/admin-cmd.c
@@ -248,8 +248,8 @@ static void nvmet_execute_get_log_page_ana(struct nvmet_req 
*req)
u16 status;
 
status = NVME_SC_INTERNAL;
-   desc = kmalloc(sizeof(struct nvme_ana_group_desc) +
-   NVMET_MAX_NAMESPACES * sizeof(__le32), GFP_KERNEL);
+   desc = kmalloc(struct_size(desc, nsids, NVMET_MAX_NAMESPACES),
+   GFP_KERNEL);
if (!desc)
goto out;
 
-- 
2.7.4





Re: [PATCH 1/1] LZ4: Port LZ4 1.9.x FAST_DEC_LOOP and enable it on x86 and ARM64

2019-05-17 Thread Mao, Chenxi
Hi Xiang:

Got it and thanks.
Will follow the rules in next PS.

Chenxi

On 5/17/19 2:35 PM, Gao Xiang wrote:
> Hi Chenxi,
> 
> Some words about the patch format.. not important tho.
> 
> One suggestion is that the subject line should be better written
> as "[PATCH v2/v3/...] title" since it's more clear to know
> which patch is the latest patch among these emails.
> 
> On 2019/5/17 13:56, Chenxi Mao wrote:
>> FAST_DEC_LOOP was introduced from LZ4 1.9.0[1]
>> This change would be introduce 10% on decompress operation
>> according to LZ4 benchmark result on X86 devices.
>> Meanwhile, LZ4 with FAST_DEC_LOOP could get improvements on ARM64,
>> however clang compiler has downgrade if FAST_DEC_LOOP enabled.
>>
>> So FAST_DEC_LOOP only enabled on X86/X86-64 or ARM64 with GCC build.
>>
>> LZ4 FAST_DEC_LOOP bug fixes include as well.
>> 1. fixed read-after input in LZ4_decompress_safe() (issue 681)
>> 2. Fix out-of-bound read in LZ4_decompress_fast() (issue 676)
>>
>> PS2:
>> 1. Move common API to lz4defs.h
>> 2. Add PPC related inline Macro defination.
>> 3. Force inline new static apis.
>>
>> Here is the test result on ARM64(cortex-A53)
>> Benchmark via ZRAM:
>>
>> Test case:
>> taskset 03 /data/fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers 
>> \
>> --buffer_compress_percentage=75  --size=700M \
>> --scramble_buffers=1 --direct=1 --loops=100 --numjobs=1 \
>> --filename=/data/test/test --name=seq-read --rw=read --stonewall
>>
>> Patched:
>> READ: bw=150MiB/s (157MB/s)
>> Vanilla:
>> READ: bw=135MiB/s (142MB/s)
>>
>> [1] https://github.com/lz4/lz4/releases/tag/v1.9.0
>>
>> Signed-off-by: chenxi.mao 
>> ---
> 
> It's perferred to move all changelogs here if you don't want these changelog
> as a part of commit and there are some patches which can be referenced:
> https://lore.kernel.org/lkml/
> 
> Thanks,
> Gao Xiang
> 
>>  lib/lz4/lz4_compress.c   |   4 +-
>>  lib/lz4/lz4_decompress.c | 397 ---
>>  lib/lz4/lz4defs.h|  60 +-
>>  lib/lz4/lz4hc_compress.c |   2 +-
>>  4 files changed, 392 insertions(+), 71 deletions(-)
>>
>> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
>> index cc7b6d4cc7c7..b703ed1ca57d 100644
>> --- a/lib/lz4/lz4_compress.c
>> +++ b/lib/lz4/lz4_compress.c
>> @@ -322,7 +322,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>>  *token = (BYTE)(litLength << ML_BITS);
>>  
>>  /* Copy Literals */
>> -LZ4_wildCopy(op, anchor, op + litLength);
>> +LZ4_wildCopy8(op, anchor, op + litLength);
>>  op += litLength;
>>  }
>>  
>> @@ -628,7 +628,7 @@ static int LZ4_compress_destSize_generic(
>>  *token = (BYTE)(litLength << ML_BITS);
>>  
>>  /* Copy Literals */
>> -LZ4_wildCopy(op, anchor, op + litLength);
>> +LZ4_wildCopy8(op, anchor, op + litLength);
>>  op += litLength;
>>  }
>>  
>> diff --git a/lib/lz4/lz4_decompress.c b/lib/lz4/lz4_decompress.c
>> index 0c9d3ad17e0f..8622922304c3 100644
>> --- a/lib/lz4/lz4_decompress.c
>> +++ b/lib/lz4/lz4_decompress.c
>> @@ -50,6 +50,96 @@
>>  #define assert(condition) ((void)0)
>>  #endif
>>  
>> +#ifndef LZ4_FAST_DEC_LOOP
>> +#if defined(__i386__) || defined(__x86_64__)
>> +#define LZ4_FAST_DEC_LOOP 1
>> +#elif defined(__aarch64__) && !defined(__clang__)
>> + /* On aarch64, we disable this optimization for clang because on 
>> certain
>> +  * mobile chipsets and clang, it reduces performance. For more 
>> information
>> +  * refer to https://github.com/lz4/lz4/pull/707. */
>> +#define LZ4_FAST_DEC_LOOP 1
>> +#else
>> +#define LZ4_FAST_DEC_LOOP 0
>> +#endif
>> +#endif
>> +
>> +#if LZ4_FAST_DEC_LOOP
>> +#define FASTLOOP_SAFE_DISTANCE 64
>> +FORCE_O2_INLINE_GCC_PPC64LE void
>> +LZ4_memcpy_using_offset_base(BYTE * dstPtr, const BYTE * srcPtr, BYTE * 
>> dstEnd,
>> + const size_t offset)
>> +{
>> +if (offset < 8) {
>> +dstPtr[0] = srcPtr[0];
>> +
>> +dstPtr[1] = srcPtr[1];
>> +dstPtr[2] = srcPtr[2];
>> +dstPtr[3] = srcPtr[3];
>> +srcPtr += inc32table[offset];
>> +memcpy(dstPtr + 4, srcPtr, 4);
>> +srcPtr -= dec64table[offset];
>> +dstPtr += 8;
>> +} else {
>> +memcpy(dstPtr, srcPtr, 8);
>> +dstPtr += 8;
>> +srcPtr += 8;
>> +}
>> +
>> +LZ4_wildCopy8(dstPtr, srcPtr, dstEnd);
>> +}
>> +
>> +/* customized variant of memcpy, which can overwrite up to 32 bytes beyond 
>> dstEnd
>> + * this version copies two times 16 bytes (instead of one time 32 bytes)
>> + * because it must be compatible with offsets >= 16. */
>> +FORCE_O2_INLINE_GCC_PPC64LE void
>> +LZ4_wildCopy32(void *dstPtr, const void *srcPtr, void *dstEnd)
>> +{
>> +BYTE *d = (BYTE *) dstPtr;
>> +const BYTE *s 

Re: [PATCH] s390: add unreachable() to dump_fault_info() to fix -Wmaybe-uninitialized

2019-05-17 Thread Martin Schwidefsky
On Fri, 17 May 2019 15:49:22 +0900
Masahiro Yamada  wrote:

> When CONFIG_OPTIMIZE_INLINING is enabled for s390, I see this warning:
> 
> arch/s390/mm/fault.c:127:15: warning: 'asce' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
>   switch (asce & _ASCE_TYPE_MASK) {
> arch/s390/mm/fault.c:177:16: note: 'asce' was declared here
>   unsigned long asce;
> ^~~~
> 
> If get_fault_type() is not inlined, the compiler cannot deduce that
> all the possible paths in the 'switch' statement are covered.
> 
> Of course, we could mark get_fault_type() as __always_inline to get
> back the original behavior, but I do not think it sensible to force
> inlining just for the purpose of suppressing the warning. Since this
> is just a matter of warning, I want to keep as much room for compiler
> optimization as possible.
> 
> I added unreachable() to teach the compiler that the 'default' label
> is unreachable.
> 
> I got rid of the 'inline' marker. Even without the 'inline' hint,
> the compiler inlines functions based on its inlining heuristic.
> 
> Fixes: 9012d011660e ("compiler: allow all arches to enable 
> CONFIG_OPTIMIZE_INLINING")
> Signed-off-by: Masahiro Yamada 

Added to our internal tree and I will add it to s390/linux soon. Thanks.

> ---
> 
>  arch/s390/mm/fault.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index c220399ae196..91ce03fd0c84 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -85,7 +85,7 @@ static inline int notify_page_fault(struct pt_regs *regs)
>   * Find out which address space caused the exception.
>   * Access register mode is impossible, ignore space == 3.
>   */
> -static inline enum fault_type get_fault_type(struct pt_regs *regs)
> +static enum fault_type get_fault_type(struct pt_regs *regs)
>  {
>   unsigned long trans_exc_code;
> 
> @@ -211,6 +211,8 @@ static void dump_fault_info(struct pt_regs *regs)
>   asce = S390_lowcore.kernel_asce;
>   pr_cont("kernel ");
>   break;
> + default:
> + unreachable();
>   }
>   pr_cont("ASCE.\n");
>   dump_pagetable(asce, regs->int_parm_long & __FAIL_ADDR_MASK);


-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.



Re: [PATCH] s390: mark __cpacf_check_opcode() and cpacf_query_func() as __always_inline

2019-05-17 Thread Martin Schwidefsky
On Fri, 17 May 2019 15:54:24 +0900
Masahiro Yamada  wrote:

> Commit e60fb8bf68d4 ("s390/cpacf: mark scpacf_query() as __always_inline")
> was not enough to make sure to meet the 'i' (immediate) constraint for the
> asm operands.
> 
> With CONFIG_OPTIMIZE_INLINING enabled, Laura Abbott reported error
> with gcc 9.1.1:
> 
>   In file included from arch/s390/crypto/prng.c:29:
>   ./arch/s390/include/asm/cpacf.h: In function 'cpacf_query_func':
>   ./arch/s390/include/asm/cpacf.h:170:2: warning: asm operand 3 probably 
> doesn't match constraints
> 170 |  asm volatile(
> |  ^~~
>   ./arch/s390/include/asm/cpacf.h:170:2: error: impossible constraint in 'asm'
> 
> Add more __always_inline to force inlining.
> 
> Fixes: 9012d011660e ("compiler: allow all arches to enable 
> CONFIG_OPTIMIZE_INLINING")
> Reported-by: Laura Abbott 
> Signed-off-by: Masahiro Yamada 

Added to our internal tree and I will add it to s390/linux soon. Thanks.

Do you have a Kconfig patch in the works to enable OPTIMIZE_INLINING?
Otherwise we could just add it.

> ---
> 
>  arch/s390/include/asm/cpacf.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
> index f316de40e51b..19459dfb4295 100644
> --- a/arch/s390/include/asm/cpacf.h
> +++ b/arch/s390/include/asm/cpacf.h
> @@ -177,7 +177,7 @@ static inline void __cpacf_query(unsigned int opcode, 
> cpacf_mask_t *mask)
>   : "cc");
>  }
> 
> -static inline int __cpacf_check_opcode(unsigned int opcode)
> +static __always_inline int __cpacf_check_opcode(unsigned int opcode)
>  {
>   switch (opcode) {
>   case CPACF_KMAC:
> @@ -217,7 +217,7 @@ static inline int cpacf_test_func(cpacf_mask_t *mask, 
> unsigned int func)
>   return (mask->bytes[func >> 3] & (0x80 >> (func & 7))) != 0;
>  }
> 
> -static inline int cpacf_query_func(unsigned int opcode, unsigned int func)
> +static __always_inline int cpacf_query_func(unsigned int opcode, unsigned 
> int func)
>  {
>   cpacf_mask_t mask;
> 


-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.



Re: [PATCH 4/6] arm64: pmu: Add hook to handle pmu-related undefined instructions

2019-05-17 Thread Peter Zijlstra
On Thu, May 16, 2019 at 02:21:46PM +0100, Raphael Gault wrote:
> In order to prevent the userspace processes which are trying to access
> the registers from the pmu registers on a big.LITTLE environment we
> introduce a hook to handle undefined instructions.
> 
> The goal here is to prevent the process to be interrupted by a signal
> when the error is caused by the task being scheduled while accessing
> a counter, causing the counter access to be invalid. As we are not able
> to know efficiently the number of counters available physically on both
> pmu in that context we consider that any faulting access to a counter
> which is architecturally correct should not cause a SIGILL signal if
> the permissions are set accordingly.

The other approach is using rseq for this; with that you can guarantee
it will never issue the instruction on a wrong CPU.

That said; emulating the thing isn't horrible either.

> + /*
> +  * We put 0 in the target register if we
> +  * are reading from pmu register. If we are
> +  * writing, we do nothing.
> +  */

Wait _what_ ?!? userspace can _WRITE_ to these registers?


Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

2019-05-17 Thread David Howells
Christian Brauner  wrote:

> If you still prefer to have cloexec flags
> for the 4 new syscalls then yes,
> if they could at least all have the same name
> (FSMOUNT_CLOEXEC?) that would be good.

They don't all have the same value (see OPEN_TREE_CLOEXEC).

Note that I also don't want to blindly #define them to O_CLOEXEC because it's
not necessarily the same value on all arches.  Currently it can be 0200,
01000 or 0x40 for instance, which means that if it's sharing a mask
with other flags, at least three bits have to be reserved for it or we have to
have arch-dependent bit juggling.

One thing I like about your approach of just making them O_CLOEXEC by default
and removing the constants is that it avoids this mess entirely.

David


Re: [PATCH] KVM: selftests: Compile code with warnings enabled

2019-05-17 Thread Thomas Huth
On 17/05/2019 04.45, Peter Xu wrote:
> Hi, Thomas,
> 
> On Thu, May 16, 2019 at 03:02:57PM +0200, Thomas Huth wrote:
>> So far the KVM selftests are compiled without any compiler warnings
>> enabled. That's quite bad, since we miss a lot of possible bugs this
>> way. Let's enable at least "-Wall" and some other useful warning flags
>> now.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  This patch fixes most of the warnings in the x86 code already - but
>>  for some warnings, I was not quite sure (e.g. about the need for the
>>  kvm_get_supported_cpuid_entry(1) in some tests), so I did not touch
> 
> If you mean the two calls in state_test and evmcs_test I would agree
> they should be dropped directly.

Yes, that were the once I had in mind. I'll drop them in v2.

> Just to mention that the patch may not apply cleanly to kvm/queue now
> probably because the dirty-log-test.c touchup recently, so may need a
> rebase.  Otherwise it looks nice at least to me to have these checks.

Ok, thanks for the hint, I'll rebase and send a v2.

 Thomas


[PATCH] arch: s390: use struct_size() in kmalloc()

2019-05-17 Thread xiaolinkui
Use the new struct_size() helper to keep code simple.

Signed-off-by: xiaolinkui 
---
 arch/s390/include/asm/idals.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/idals.h b/arch/s390/include/asm/idals.h
index 15578fd..6fb7ace 100644
--- a/arch/s390/include/asm/idals.h
+++ b/arch/s390/include/asm/idals.h
@@ -122,8 +122,7 @@ idal_buffer_alloc(size_t size, int page_order)
 
nr_ptrs = (size + IDA_BLOCK_SIZE - 1) >> IDA_SIZE_LOG;
nr_chunks = (4096 << page_order) >> IDA_SIZE_LOG;
-   ib = kmalloc(sizeof(struct idal_buffer) + nr_ptrs*sizeof(void *),
-GFP_DMA | GFP_KERNEL);
+   ib = kmalloc(struct_size(ib, data, nr_ptrs), GFP_DMA | GFP_KERNEL);
if (ib == NULL)
return ERR_PTR(-ENOMEM);
ib->size = size;
-- 
2.7.4





Re: [PATCH 5.1 00/46] 5.1.3-stable review

2019-05-17 Thread Greg Kroah-Hartman
On Fri, May 17, 2019 at 12:34:02AM -0600, Kelsey Skunberg wrote:
> On Wed, May 15, 2019 at 12:56:24PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.3 release.
> > There are 46 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 Fri 17 May 2019 09:04:22 AM UTC.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.3-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.1.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Compiled and booted with no dmesg regressions on my system.

Thanks for testing some of these and letting me know.

greg k-h


Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

2019-05-17 Thread Miklos Szeredi
On Fri, May 17, 2019 at 9:13 AM David Howells  wrote:
>
> Christian Brauner  wrote:
>
> > If you still prefer to have cloexec flags
> > for the 4 new syscalls then yes,
> > if they could at least all have the same name
> > (FSMOUNT_CLOEXEC?) that would be good.
>
> They don't all have the same value (see OPEN_TREE_CLOEXEC).
>
> Note that I also don't want to blindly #define them to O_CLOEXEC because it's
> not necessarily the same value on all arches.  Currently it can be 0200,
> 01000 or 0x40 for instance, which means that if it's sharing a mask
> with other flags, at least three bits have to be reserved for it or we have to
> have arch-dependent bit juggling.
>
> One thing I like about your approach of just making them O_CLOEXEC by default
> and removing the constants is that it avoids this mess entirely.

+1.

Confusion caused by inconsistency of naming is going to hurt more than
inconsistency of semantics wrt. open(2).

Thanks,
Miklos


[PATCH V2] clk: imx: imx8mm: fix int pll clk gate

2019-05-17 Thread Peng Fan
Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm")
To Frac pll, the gate shift is 13, however to Int PLL the gate shift
is 11.

Cc: 
Signed-off-by: Peng Fan 
Reviewed-by: Fabio Estevam 
Reviewed-by: Jacky Bai 
---

V2:
 Update commit with Fixes, Add R-b and cc stable

 drivers/clk/imx/clk-imx8mm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1ef8438e3d6d..122a81ab8e48 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -449,12 +449,12 @@ static int __init imx8mm_clocks_init(struct device_node 
*ccm_node)
clks[IMX8MM_AUDIO_PLL2_OUT] = imx_clk_gate("audio_pll2_out", 
"audio_pll2_bypass", base + 0x14, 13);
clks[IMX8MM_VIDEO_PLL1_OUT] = imx_clk_gate("video_pll1_out", 
"video_pll1_bypass", base + 0x28, 13);
clks[IMX8MM_DRAM_PLL_OUT] = imx_clk_gate("dram_pll_out", 
"dram_pll_bypass", base + 0x50, 13);
-   clks[IMX8MM_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", 
"gpu_pll_bypass", base + 0x64, 13);
-   clks[IMX8MM_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", 
"vpu_pll_bypass", base + 0x74, 13);
-   clks[IMX8MM_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", 
"arm_pll_bypass", base + 0x84, 13);
-   clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", 
"sys_pll1_bypass", base + 0x94, 13);
-   clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", 
"sys_pll2_bypass", base + 0x104, 13);
-   clks[IMX8MM_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", 
"sys_pll3_bypass", base + 0x114, 13);
+   clks[IMX8MM_GPU_PLL_OUT] = imx_clk_gate("gpu_pll_out", 
"gpu_pll_bypass", base + 0x64, 11);
+   clks[IMX8MM_VPU_PLL_OUT] = imx_clk_gate("vpu_pll_out", 
"vpu_pll_bypass", base + 0x74, 11);
+   clks[IMX8MM_ARM_PLL_OUT] = imx_clk_gate("arm_pll_out", 
"arm_pll_bypass", base + 0x84, 11);
+   clks[IMX8MM_SYS_PLL1_OUT] = imx_clk_gate("sys_pll1_out", 
"sys_pll1_bypass", base + 0x94, 11);
+   clks[IMX8MM_SYS_PLL2_OUT] = imx_clk_gate("sys_pll2_out", 
"sys_pll2_bypass", base + 0x104, 11);
+   clks[IMX8MM_SYS_PLL3_OUT] = imx_clk_gate("sys_pll3_out", 
"sys_pll3_bypass", base + 0x114, 11);
 
/* SYS PLL fixed output */
clks[IMX8MM_SYS_PLL1_40M] = imx_clk_fixed_factor("sys_pll1_40m", 
"sys_pll1_out", 1, 20);
-- 
2.16.4



Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]

2019-05-17 Thread Christian Brauner
On May 17, 2019 9:13:26 AM GMT+02:00, David Howells  wrote:
>Christian Brauner  wrote:
>
>> If you still prefer to have cloexec flags
>> for the 4 new syscalls then yes,
>> if they could at least all have the same name
>> (FSMOUNT_CLOEXEC?) that would be good.
>
>They don't all have the same value (see OPEN_TREE_CLOEXEC).
>
>Note that I also don't want to blindly #define them to O_CLOEXEC
>because it's
>not necessarily the same value on all arches.  Currently it can be
>0200,
>01000 or 0x40 for instance, which means that if it's sharing a
>mask
>with other flags, at least three bits have to be reserved for it or we
>have to
>have arch-dependent bit juggling.


Ugh. Right, I forgot about that entirely.

Christian

>
>One thing I like about your approach of just making them O_CLOEXEC by
>default
>and removing the constants is that it avoids this mess entirely.
>
>David



Dear Friend,

2019-05-17 Thread manuelnu...@ono.com
Dear Friend,

With due respect to your person and much sincerity of purpose’ I have a 
business proposal which I will like to handle with you. $35 Million USD 
is involved. But be rest assured that everything is legal and risk free 
as I have concluded all the arrangements and the legal papers that will 
back the transaction up. Kindly indicate your interest as to enable me 
tell you more detail of the proposal.

Waiting for your urgent response

Yours Faithfully,
Mr. Bredoxn Philip


[PATCH 1/3] lib: assoc_array: use struct_size() in kmalloc()

2019-05-17 Thread xiaolinkui
Use the new struct_size() helper to keep code simple.

Signed-off-by: xiaolinkui 
---
 lib/assoc_array.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/assoc_array.c b/lib/assoc_array.c
index edc3c14..0e69b5b 100644
--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -1494,8 +1494,7 @@ int assoc_array_gc(struct assoc_array *array,
shortcut = assoc_array_ptr_to_shortcut(cursor);
keylen = round_up(shortcut->skip_to_level, 
ASSOC_ARRAY_KEY_CHUNK_SIZE);
keylen >>= ASSOC_ARRAY_KEY_CHUNK_SHIFT;
-   new_s = kmalloc(sizeof(struct assoc_array_shortcut) +
-   keylen * sizeof(unsigned long), GFP_KERNEL);
+   new_s = kmalloc(struct_size(new_s, index_key, keylen), 
GFP_KERNEL);
if (!new_s)
goto enomem;
pr_devel("dup shortcut %p -> %p\n", shortcut, new_s);
-- 
2.7.4





Re: [PATCH] ARM: dts: sun8i-h3: Fix wifi in Beelink X2 DT

2019-05-17 Thread Maxime Ripard
Hi,

On Thu, May 16, 2019 at 06:10:39PM +0200, Jernej Skrabec wrote:
> mmc1 node where wifi module is connected doesn't have properly defined
> power supplies so wifi module is never powered up. Fix that by
> specifying additional power supplies.
>
> Additionally, this STB may have either Realtek or Broadcom based wifi
> module. One based on Broadcom module also needs external clock to work
> properly. Fix that by adding clock property to wifi_pwrseq node.
>
> Fixes: e582b47a9252 ("ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB")
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts 
> b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> index 6277f13f3eb3..6a0ac85b4616 100644
> --- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> @@ -89,7 +89,10 @@
>
>   wifi_pwrseq: wifi_pwrseq {
>   compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";

pinctrl-names only make sense with another pinctrl-[0-255]
property. Did you forgot something here?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2] staging: vt6656: returns error code on vnt_int_start_interrupt fail

2019-05-17 Thread Greg Kroah-Hartman
On Thu, May 16, 2019 at 11:57:15AM +, Quentin Deslandes wrote:
> Returns error code from 'vnt_int_start_interrupt()' so the device's private
> buffers will be correctly freed and 'struct ieee80211_hw' start function
> will return an error code.
> 
> Signed-off-by: Quentin Deslandes 
> ---
>  drivers/staging/vt6656/int.c  |  4 +++-
>  drivers/staging/vt6656/int.h  |  2 +-
>  drivers/staging/vt6656/main_usb.c | 12 +---
>  3 files changed, 13 insertions(+), 5 deletions(-)

What changed from v1?  Always put that below the --- line.

Please fix up and resend a v3.

thanks,

greg k-h


Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6

2019-05-17 Thread Maxime Ripard
On Fri, May 17, 2019 at 02:10:47AM +0800, Frank Lee wrote:
> > On Sun, May 12, 2019 at 11:41:28PM +0200, Ondřej Jirman wrote:
> > > > > +static int tsens_get_temp(void *data, int *temp)
> > > > > +{
> > > > > + struct tsensor *s = data;
> > > > > + struct tsens_device *tmdev = s->tmdev;
> > > > > + int val;
> > > > > +
> > > > > + regmap_read(tmdev->regmap, tmdev->chip->temp_data_base +
> > > > > + 0x4 * s->id, );
> > > > > +
> > > > > + if (unlikely(val == 0))
> > > > > + return -EBUSY;
> > > >
> > > > I'm not sure why a val equals to 0 would be associated with EBUSY?
> > >
> > > Thermal zone driver can (will) call get_temp before we got the
> > > first interrupt and the thermal data. In that case val will be 0.
> > >
> > > Resulting in:
> > >
> > >  (val + offset) * scale = (-2794) * -67 = 187198
> > >
> > > 187°C and immediate shutdown during boot - based on cirtical
> > > temperature being reached.
> > >
> > > Busy here means, get_temp does not yet have data. Thermal zone
> > > driver just reports any error to dmesg output.
> >
> > Ah, that makes sense.
> >
> > I guess if we're switching to an interrupt-based driver, then we can
> > just use a waitqueue, or is get_temp supposed to be atomic?
>
> I think get_temp should not be bloacked.

Why not?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH] ACPI/PCI: PM: Add missing wakeup.flags.valid checks

2019-05-17 Thread Mika Westerberg
On Thu, May 16, 2019 at 12:42:20PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the
> current ACPI wakeup configuration of the device matches what is
> expected as far as system wakeup from sleep states is concerned, as
> reflected by the device_may_wakeup() return value for the device.
> 
> However, they only should do that if wakeup.flags.valid is set for
> the device's ACPI companion, because otherwise the wakeup.prepare_count
> value for it is meaningless.
> 
> Add the missing wakeup.flags.valid checks to these functions.
> 
> Signed-off-by: Rafael J. Wysocki 

Reviewed-by: Mika Westerberg 


Re: linux-next: Tree for May 17

2019-05-17 Thread Anders Roxell
On Fri, 17 May 2019 at 06:21, Stephen Rothwell  wrote:
>
> Hi all,
>
> Please do not add any v5.3 material to your linux-next included
> trees/branches until after v5.2-rc1 has been released.
>
> Changes since 20190516:
>
> The kvm tree gained conflicts against Linus' tree.

When I built arm64 I saw this build failure:
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c: In function ‘__kvm_map_gfn’:
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1764:9: error: implicit
declaration of function ‘memremap’; did you mean ‘memcmp’?
[-Werror=implicit-function-declaration]
   hva = memremap(pfn_to_hpa(pfn), PAGE_SIZE, MEMREMAP_WB);
 ^~~~
 memcmp
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1764:46: error:
‘MEMREMAP_WB’ undeclared (first use in this function)
   hva = memremap(pfn_to_hpa(pfn), PAGE_SIZE, MEMREMAP_WB);
  ^~~
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1764:46: note: each
undeclared identifier is reported only once for each function it
appears in
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c: In function ‘kvm_vcpu_unmap’:
../arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1796:3: error: implicit
declaration of function ‘memunmap’; did you mean ‘vm_munmap’?
[-Werror=implicit-function-declaration]
   memunmap(map->hva);
   ^~~~
   vm_munmap
cc1: some warnings being treated as errors
make[2]: *** [../scripts/Makefile.build:279:
arch/arm64/kvm/../../../virt/kvm/kvm_main.o] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [/home/anders/src/kernel/next/Makefile:1071:
arch/arm64/kvm] Error 2

is this something that should be added maybe?

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8d83a787fd6b..5c5102799c2c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 


Cheers,
Anders

>
> Non-merge commits (relative to Linus' tree): 1023
>  1119 files changed, 27058 insertions(+), 7629 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 298 trees (counting Linus' and 69 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 (01be377c6221 Merge tag 'media/v5.2-1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
> Merging fixes/master (2bbacd1a9278 Merge tag 'kconfig-v5.2' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
> Merging kspp-gustavo/for-next/kspp (ccaa75187a5f memstick: mark expected 
> switch fall-throughs)
> Merging kbuild-current/fixes (a2d635decbfa Merge tag 'drm-next-2019-05-09' of 
> git://anongit.freedesktop.org/drm/drm)
> Merging arc-current/for-curr (308a06dc72c0 ARC: mm: do_page_fault refactor 
> #8: release mmap_sem sooner)
> Merging arm-current/fixes (e17b1af96b2a ARM: 8857/1: efi: enable CP15 DMB 
> instructions before cleaning the cache)
> Merging arm64-fixes/for-next/fixes (7a0a93c51799 arm64: vdso: Explicitly add 
> build-id option)
> Merging m68k-current/for-linus (fdd20ec8786a Documentation/features/time: 
> Mark m68k having modern-timekeeping)
> Merging powerpc-fixes/fixes (12f363511d47 powerpc/32s: Fix BATs setting with 
> CONFIG_STRICT_KERNEL_RWX)
> Merging 

RE: [PATCH v2 1/2] dt-bindings: Add vendor prefix for HopeRun

2019-05-17 Thread Fabrizio Castro
Hello Rob,

> From: Rob Herring 
> Sent: 17 May 2019 03:31
> Subject: Re: [PATCH v2 1/2] dt-bindings: Add vendor prefix for HopeRun
> 
> On Wed, May 15, 2019 at 11:35 AM Fabrizio Castro
>  wrote:
> >
> > Add "Jiangsu HopeRun Software Co., Ltd." to the list of devicetree
> > vendor prefixes as "hoperun".
> >
> > Website: http://www.hoperun.com/en
> >
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Chris Paterson 
> >
> > ---
> > v1->v2:
> > * No change
> >
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> I've converted this file to json-schema as of v5.2-rc1. See commit
> 8122de54602e. Sorry, but you will have to rework this patch.

I see, will send a new version.

Thanks,
Fab

> 
> 
> Rob


Linux 4.4.180

2019-05-17 Thread Greg KH
I'm announcing the release of the 4.4.180 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/ABI/testing/sysfs-devices-system-cpu  |2 
 Documentation/hw-vuln/mds.rst   |  305 +
 Documentation/kernel-parameters.txt |  110 +++
 Documentation/networking/ip-sysctl.txt  |1 
 Documentation/spec_ctrl.txt |9 
 Documentation/usb/power-management.txt  |   14 
 Documentation/x86/mds.rst   |  225 ++
 Makefile|2 
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi|1 
 arch/arm/mach-iop13xx/setup.c   |8 
 arch/arm/mach-iop13xx/tpmi.c|   10 
 arch/arm/plat-iop/adma.c|6 
 arch/arm/plat-orion/common.c|4 
 arch/mips/kernel/scall64-o32.S  |2 
 arch/powerpc/Kconfig|7 
 arch/powerpc/include/asm/asm-prototypes.h   |   21 
 arch/powerpc/include/asm/barrier.h  |   21 
 arch/powerpc/include/asm/code-patching-asm.h|   18 
 arch/powerpc/include/asm/code-patching.h|2 
 arch/powerpc/include/asm/exception-64s.h|   35 +
 arch/powerpc/include/asm/feature-fixups.h   |   40 +
 arch/powerpc/include/asm/hvcall.h   |5 
 arch/powerpc/include/asm/paca.h |3 
 arch/powerpc/include/asm/ppc-opcode.h   |1 
 arch/powerpc/include/asm/ppc_asm.h  |   11 
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/include/asm/security_features.h|   92 ++
 arch/powerpc/include/asm/setup.h|   23 
 arch/powerpc/include/asm/uaccess.h  |   18 
 arch/powerpc/kernel/Makefile|1 
 arch/powerpc/kernel/asm-offsets.c   |3 
 arch/powerpc/kernel/entry_32.S  |   10 
 arch/powerpc/kernel/entry_64.S  |   69 ++
 arch/powerpc/kernel/exceptions-64e.S|   27 
 arch/powerpc/kernel/exceptions-64s.S|   98 +--
 arch/powerpc/kernel/head_booke.h|   12 
 arch/powerpc/kernel/head_fsl_booke.S|   15 
 arch/powerpc/kernel/module.c|   10 
 arch/powerpc/kernel/security.c  |  434 +
 arch/powerpc/kernel/setup_32.c  |3 
 arch/powerpc/kernel/setup_64.c  |   51 -
 arch/powerpc/kernel/vmlinux.lds.S   |   33 -
 arch/powerpc/kvm/bookehv_interrupts.S   |4 
 arch/powerpc/kvm/e500_emulate.c |7 
 arch/powerpc/lib/code-patching.c|   29 
 arch/powerpc/lib/feature-fixups.c   |  218 ++
 arch/powerpc/mm/mem.c   |2 
 arch/powerpc/mm/tlb_low_64e.S   |7 
 arch/powerpc/platforms/powernv/setup.c  |   99 ++-
 arch/powerpc/platforms/pseries/mobility.c   |3 
 arch/powerpc/platforms/pseries/pseries.h|2 
 arch/powerpc/platforms/pseries/setup.c  |   88 ++
 arch/powerpc/xmon/xmon.c|2 
 arch/x86/Kconfig|8 
 arch/x86/entry/common.c |3 
 arch/x86/entry/vdso/Makefile|3 
 arch/x86/include/asm/cpufeatures.h  |   12 
 arch/x86/include/asm/intel-family.h |   30 
 arch/x86/include/asm/irqflags.h |5 
 arch/x86/include/asm/microcode_intel.h  |   15 
 arch/x86/include/asm/msr-index.h|   30 
 arch/x86/include/asm/mwait.h|7 
 arch/x86/include/asm/nospec-branch.h|   66 ++
 arch/x86/include/asm/pgtable_64.h   |   16 
 arch/x86/include/asm/processor.h|7 
 arch/x86/include/asm/spec-ctrl.h|   20 
 arch/x86/include/asm/switch_to.h|3 
 arch/x86/include/asm/thread_info.h  |   20 
 arch/x86/include/asm/tlbflush.h |8 
 arch/x86/include/uapi/asm/Kbuild|1 
 arch/x86/include/uapi/asm/mce.h |4 
 arch/x86/kernel/cpu/bugs.c  |  643 
 arch/x86/kernel/cpu/common.c|  140 ++--
 arch/x86/kernel/cpu/intel.c  

Re: drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks

2019-05-17 Thread Sergey Senozhatsky
On (05/17/19 16:27), Sergey Senozhatsky wrote:
> > ... but most likely it's utterly wrong.
> > 
> 
> JFI, I removed kmemleak annotation

meeehhh

kmemleak: 2046 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

unreferenced object 0x95cbea4e6060 (size 16):
  comm "Web Content", pid 1191, jiffies 4294795669 (age 735.950s)
  hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] nvkm_memory_tags_get+0x8e/0x130
[<061f3c89>] gf100_vmm_valid+0x196/0x2f0
[] nvkm_vmm_map+0xa8/0x360
[] nvkm_vram_map+0x48/0x50
[<006adddb>] nvkm_uvmm_mthd+0x658/0x770
[] nvkm_ioctl+0xdf/0x177
[<03acea2c>] nvif_object_mthd+0xd4/0x100
[<33824292>] nvif_vmm_map+0xeb/0x100
[<537f8629>] nouveau_mem_map+0x79/0xd0
[] nouveau_vma_new+0x19d/0x1c0
[] nouveau_gem_object_open+0xd4/0x140
[<5a53123b>] drm_gem_handle_create_tail+0xe3/0x160
[] nouveau_gem_ioctl_new+0x6e/0xd0
[] drm_ioctl_kernel+0x8c/0xd0
[<4f28d8a6>] drm_ioctl+0x1c4/0x360
[] nouveau_drm_ioctl+0x63/0xb0

-ss


Re: [PATCH 4/6] arm64: pmu: Add hook to handle pmu-related undefined instructions

2019-05-17 Thread Raphael Gault
Hi,

On 5/17/19 8:10 AM, Peter Zijlstra wrote:
> On Thu, May 16, 2019 at 02:21:46PM +0100, Raphael Gault wrote:
>> In order to prevent the userspace processes which are trying to access
>> the registers from the pmu registers on a big.LITTLE environment we
>> introduce a hook to handle undefined instructions.
>>
>> The goal here is to prevent the process to be interrupted by a signal
>> when the error is caused by the task being scheduled while accessing
>> a counter, causing the counter access to be invalid. As we are not able
>> to know efficiently the number of counters available physically on both
>> pmu in that context we consider that any faulting access to a counter
>> which is architecturally correct should not cause a SIGILL signal if
>> the permissions are set accordingly.
>
> The other approach is using rseq for this; with that you can guarantee
> it will never issue the instruction on a wrong CPU.
>
> That said; emulating the thing isn't horrible either.
>
>> +/*
>> + * We put 0 in the target register if we
>> + * are reading from pmu register. If we are
>> + * writing, we do nothing.
>> + */
>
> Wait _what_ ?!? userspace can _WRITE_ to these registers?
>

The user can write to some pmu registers but those are not the ones that
interest us here. My comment was ill formed, indeed this hook can only
be triggered by reads in this case.
Sorry about that.

Thanks,

--
Raphael Gault
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


Re: Linux 4.9.177

2019-05-17 Thread Greg KH
diff --git a/Makefile b/Makefile
index 92fe701e5582..ceb8f4bf6245 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 176
+SUBLEVEL = 177
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 26a058d58d37..c7c31e214813 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -183,12 +183,6 @@ const char *get_system_type(void)
return ath79_sys_type;
 }
 
-int get_c0_perfcount_int(void)
-{
-   return ATH79_MISC_IRQ(5);
-}
-EXPORT_SYMBOL_GPL(get_c0_perfcount_int);
-
 unsigned int get_c0_compare_int(void)
 {
return CP0_LEGACY_COMPARE_IRQ;
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index 737e012ef56e..319ed53e503f 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -41,7 +41,7 @@
 #if defined(CONFIG_PPC_BOOK3E_64)
 #define MSR_64BIT  MSR_CM
 
-#define MSR_   (MSR_ME | MSR_CE)
+#define MSR_   (MSR_ME | MSR_RI | MSR_CE)
 #define MSR_KERNEL (MSR_ | MSR_64BIT)
 #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE)
 #define MSR_USER64 (MSR_USER32 | MSR_64BIT)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 30542e833ebe..f4a98d9c5913 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -4,6 +4,7 @@
 //
 // Copyright 2018, Michael Ellerman, IBM Corporation.
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 14535ad4cdd1..c312955977ce 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -23,7 +23,7 @@ int patch_instruction(unsigned int *addr, unsigned int instr)
int err;
 
/* Make sure we aren't patching a freed init section */
-   if (init_mem_is_free && init_section_contains(addr, 4)) {
+   if (*PTRRELOC(_mem_is_free) && init_section_contains(addr, 4)) {
pr_debug("Skipping init section patching addr: 0x%px\n", addr);
return 0;
}
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 756dc9432d15..0d3ebdfa0739 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -167,7 +167,8 @@ quiet_cmd_vdso = VDSO$@
 sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
 
 VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
-   $(call ld-option, --build-id) -Bsymbolic
+   $(call ld-option, --build-id) $(call ld-option, --eh-frame-hdr) \
+   -Bsymbolic
 GCOV_PROFILE := n
 
 #
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 4a12362a194a..c55b11fe8e9f 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -82,6 +82,19 @@ static int __init set_bios_reboot(const struct dmi_system_id 
*d)
return 0;
 }
 
+/*
+ * Some machines don't handle the default ACPI reboot method and
+ * require the EFI reboot method:
+ */
+static int __init set_efi_reboot(const struct dmi_system_id *d)
+{
+   if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
+   reboot_type = BOOT_EFI;
+   pr_info("%s series board detected. Selecting EFI-method for 
reboot.\n", d->ident);
+   }
+   return 0;
+}
+
 void __noreturn machine_real_restart(unsigned int type)
 {
local_irq_disable();
@@ -167,6 +180,14 @@ static struct dmi_system_id __initdata reboot_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
},
},
+   {   /* Handle reboot issue on Acer TravelMate X514-51T */
+   .callback = set_efi_reboot,
+   .ident = "Acer TravelMate X514-51T",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
+   },
+   },
 
/* Apple */
{   /* Handle problems with rebooting on Apple MacBook5 */
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 0a6cc6754ec5..ea618b713b6f 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -434,13 +434,13 @@ TRACE_EVENT(kvm_apic_ipi,
 );
 
 TRACE_EVENT(kvm_apic_accept_irq,
-   TP_PROTO(__u32 apicid, __u16 dm, __u8 tm, __u8 vec),
+   TP_PROTO(__u32 apicid, __u16 dm, __u16 tm, __u8 vec),
TP_ARGS(apicid, dm, tm, vec),
 
TP_STRUCT__entry(
__field(__u32,  apicid  )
__field(__u16,  dm  )
-   __field(__u8,   tm  )
+   __field(__u16,  tm  )
__field(__u8,   vec )
),
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 97828faf2a1f..d58991b06a47 100644
--- 

Linux 4.9.177

2019-05-17 Thread Greg KH
I'm announcing the release of the 4.9.177 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/mips/ath79/setup.c |6 
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/kernel/security.c  |1 
 arch/powerpc/lib/code-patching.c|2 
 arch/x86/entry/vdso/Makefile|3 
 arch/x86/kernel/reboot.c|   21 
 arch/x86/kvm/trace.h|4 
 drivers/gpu/drm/sun4i/sun4i_drv.c   |2 
 drivers/gpu/ipu-v3/ipu-dp.c |   12 
 drivers/hid/hid-input.c |   14 
 drivers/iio/adc/xilinx-xadc-core.c  |2 
 drivers/input/rmi4/rmi_driver.c |6 
 drivers/irqchip/irq-ath79-misc.c|   11 
 drivers/isdn/mISDN/socket.c |4 
 drivers/md/raid5.c  |   19 
 drivers/net/bonding/bond_options.c  |7 
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 
 drivers/net/phy/spi_ks8995.c|9 
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c |1 
 drivers/net/wireless/st/cw1200/scan.c   |5 
 drivers/nfc/st95hf/core.c   |7 
 drivers/nvdimm/btt_devs.c   |   18 
 drivers/nvdimm/namespace_devs.c |5 
 drivers/platform/x86/sony-laptop.c  |8 
 drivers/s390/block/dasd_eckd.c  |6 
 drivers/s390/char/con3270.c |2 
 drivers/s390/char/fs3270.c  |3 
 drivers/s390/char/raw3270.c |3 
 drivers/s390/char/raw3270.h |4 
 drivers/s390/char/tty3270.c |3 
 drivers/s390/net/ctcm_main.c|1 
 drivers/usb/serial/generic.c|   39 +
 drivers/virt/fsl_hypervisor.c   |   29 -
 include/linux/efi.h |7 
 include/linux/list_nulls.h  |5 
 include/linux/rculist_nulls.h   |   14 
 include/sound/pcm.h |2 
 init/main.c |4 
 kernel/bpf/hashtab.c|   99 ++--
 net/8021q/vlan_dev.c|4 
 net/bridge/br_if.c  |   13 
 net/core/fib_rules.c|6 
 net/ipv4/raw.c  |4 
 net/ipv6/sit.c  |2 
 net/mac80211/mesh_pathtbl.c |2 
 net/netfilter/ipvs/ip_vs_core.c |2 
 net/netfilter/x_tables.c|2 
 net/packet/af_packet.c  |   25 -
 sound/core/pcm_lib.c|2 
 sound/core/pcm_native.c |6 
 tools/lib/traceevent/event-parse.c  |2 
 tools/testing/selftests/net/run_netsocktests|2 
 tools/testing/selftests/netfilter/Makefile  |2 
 tools/testing/selftests/netfilter/conntrack_icmp_related.sh |  283 
 55 files changed, 604 insertions(+), 153 deletions(-)

Aditya Pakki (1):
  libnvdimm/btt: Fix a kmemdup failure check

Alexei Starovoitov (2):
  bpf: fix struct htab_elem layout
  bpf: convert htab map to hlist_nulls

Alistair Strachan (2):
  x86: vdso: Use $LD instead of $CC to link
  x86/vdso: Pass --eh-frame-hdr to the linker

Arnd Bergmann (1):
  s390: ctcm: fix ctcm_new_device error return code

Breno Leitao (1):
  powerpc/64s: Include cpu header

Christophe Leroy (2):
  net: ucc_geth - fix Oops when changing number of buffers in the ring
  powerpc/lib: fix book3s/32 boot failure due to code patching

Dan Carpenter (2):
  drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl
  

Linux 4.14.120

2019-05-17 Thread Greg KH
I'm announcing the release of the 4.14.120 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi   |   17 
 arch/arm64/kvm/hyp/tlb.c|   35 +
 arch/mips/ath79/setup.c |6 
 arch/mips/include/asm/processor.h   |2 
 arch/powerpc/Makefile   |   31 -
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/kernel/idle_book3s.S   |   20 
 arch/powerpc/kernel/security.c  |1 
 arch/s390/kernel/nospec-branch.c|1 
 arch/sparc/include/asm/switch_to_64.h   |3 
 arch/sparc/kernel/process_64.c  |   25 -
 arch/sparc/kernel/rtrap_64.S|1 
 arch/sparc/kernel/signal32.c|   12 
 arch/sparc/kernel/signal_64.c   |6 
 arch/sparc/mm/init_64.c |1 
 arch/x86/entry/vdso/Makefile|3 
 arch/x86/include/asm/efi.h  |6 
 arch/x86/include/asm/fpu/api.h  |   15 
 arch/x86/kernel/fpu/core.c  |6 
 arch/x86/kernel/kprobes/core.c  |   22 
 arch/x86/kernel/reboot.c|   21 
 arch/x86/kvm/lapic.c|4 
 arch/x86/kvm/trace.h|4 
 arch/xtensa/boot/dts/xtfpga.dtsi|2 
 drivers/acpi/acpica/dsopcode.c  |4 
 drivers/acpi/acpica/nsobject.c  |4 
 drivers/base/devres.c   |   10 
 drivers/clocksource/timer-oxnas-rps.c   |2 
 drivers/gpu/drm/i915/intel_pm.c |   45 +
 drivers/gpu/drm/imx/ipuv3-crtc.c|2 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |2 
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c |4 
 drivers/gpu/drm/sun4i/sun4i_drv.c   |2 
 drivers/gpu/ipu-v3/ipu-dp.c |   12 
 drivers/hid/hid-input.c |   14 
 drivers/hwmon/pwm-fan.c |2 
 drivers/iio/adc/xilinx-xadc-core.c  |2 
 drivers/infiniband/hw/vmw_pvrdma/pvrdma.h   |   35 +
 drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c|6 
 drivers/input/mouse/elan_i2c_core.c |   25 +
 drivers/input/rmi4/rmi_driver.c |6 
 drivers/irqchip/irq-ath79-misc.c|   11 
 drivers/isdn/mISDN/socket.c |4 
 drivers/leds/leds-pwm.c |5 
 drivers/md/bcache/super.c   |3 
 drivers/md/raid5.c  |   19 
 drivers/media/cec/cec-api.c |   19 
 drivers/media/cec/cec-edid.c|   60 --
 drivers/media/i2c/adv7604.c |4 
 drivers/media/i2c/adv7842.c |4 
 drivers/media/i2c/ov5640.c  |   12 
 drivers/net/Kconfig |4 
 drivers/net/bonding/bond_options.c  |7 
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c  |2 
 drivers/net/ethernet/freescale/fec_main.c   |   30 -
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 
 drivers/net/ethernet/hisilicon/hns/hns_enet.c   |   15 
 drivers/net/ethernet/mellanox/mlxsw/core.c  |6 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c|2 
 drivers/net/ethernet/seeq/sgiseeq.c |1 
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   |2 
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   |   23 
 drivers/net/phy/spi_ks8995.c|9 
 drivers/net/wireless/marvell/mwl8k.c|   13 
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c |1 
 

Linux 4.19.44

2019-05-17 Thread Greg KH
I'm announcing the release of the 4.19.44 kernel.

All users of the 4.19 kernel series must upgrade.

The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm/kernel/head-nommu.S|2 
 arch/mips/ath79/setup.c |6 
 arch/powerpc/include/asm/book3s/64/pgalloc.h|3 
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/kernel/idle_book3s.S   |   20 
 arch/powerpc/kernel/security.c  |1 
 arch/powerpc/kernel/smp.c   |   90 +--
 arch/um/drivers/port_user.c |2 
 arch/x86/kernel/kprobes/core.c  |   22 
 arch/x86/kernel/reboot.c|   21 
 arch/x86/kernel/vmlinux.lds.S   |2 
 arch/x86/kvm/lapic.c|4 
 arch/x86/kvm/trace.h|4 
 block/bfq-iosched.c |8 
 block/blk-mq.c  |2 
 drivers/acpi/nfit/core.c|   12 
 drivers/char/ipmi/ipmi_si_hardcode.c|2 
 drivers/clocksource/Kconfig |1 
 drivers/clocksource/timer-oxnas-rps.c   |2 
 drivers/gpu/drm/amd/display/dc/core/dc.c|   19 
 drivers/gpu/drm/amd/display/dc/dc.h |3 
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c|9 
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.h|6 
 drivers/gpu/drm/imx/ipuv3-crtc.c|2 
 drivers/gpu/drm/sun4i/sun4i_drv.c   |7 
 drivers/gpu/ipu-v3/ipu-dp.c |   12 
 drivers/hid/hid-input.c |   14 
 drivers/hwmon/pwm-fan.c |2 
 drivers/iio/adc/xilinx-xadc-core.c  |3 
 drivers/infiniband/hw/hns/hns_roce_qp.c |2 
 drivers/input/rmi4/rmi_driver.c |6 
 drivers/irqchip/irq-ath79-misc.c|   11 
 drivers/isdn/gigaset/bas-gigaset.c  |9 
 drivers/isdn/mISDN/socket.c |4 
 drivers/md/raid5.c  |   19 
 drivers/net/bonding/bond_options.c  |7 
 drivers/net/dsa/mv88e6xxx/port.c|   24 -
 drivers/net/ethernet/cadence/macb_main.c|6 
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c  |2 
 drivers/net/ethernet/freescale/fec_main.c   |   30 -
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 
 drivers/net/ethernet/mellanox/mlxsw/core.c  |6 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c|2 
 drivers/net/ethernet/mscc/ocelot.c  |2 
 drivers/net/ethernet/neterion/vxge/vxge-config.c|1 
 drivers/net/ethernet/qlogic/qede/qede_ptp.c |7 
 drivers/net/ethernet/seeq/sgiseeq.c |1 
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   |2 
 drivers/net/phy/spi_ks8995.c|9 
 drivers/net/tun.c   |   14 
 drivers/net/wireless/marvell/mwl8k.c|   13 
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c |1 
 drivers/net/wireless/st/cw1200/scan.c   |5 
 drivers/nfc/st95hf/core.c   |7 
 drivers/nvdimm/btt_devs.c   |   18 
 drivers/nvdimm/namespace_devs.c |5 
 drivers/nvdimm/pmem.c   |8 
 drivers/pci/controller/pci-hyperv.c |   23 
 drivers/platform/x86/dell-laptop.c  |6 
 drivers/platform/x86/sony-laptop.c  |8 
 drivers/platform/x86/thinkpad_acpi.c|   72 ++-
 drivers/s390/block/dasd_eckd.c  |6 
 drivers/s390/char/con3270.c |2 
 drivers/s390/char/fs3270.c  |3 
 drivers/s390/char/raw3270.c |3 
 

Re: Linux 4.14.120

2019-05-17 Thread Greg KH
diff --git a/Makefile b/Makefile
index a9de3c45a7ef..436d49582d3b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 119
+SUBLEVEL = 120
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi 
b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 30d48ecf46e0..27d2bd85d1ae 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -65,6 +65,23 @@
method = "smc";
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /*
+* This area matches the mapping done with a
+* mainline U-Boot, and should be updated by the
+* bootloader.
+*/
+
+   psci-area@400 {
+   reg = <0x0 0x400 0x0 0x20>;
+   no-map;
+   };
+   };
+
ap806 {
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 73464a96c365..db23c6e5c885 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -15,13 +15,18 @@
  * along with this program.  If not, see .
  */
 
+#include 
+
 #include 
 #include 
 
-static void __hyp_text __tlb_switch_to_guest_vhe(struct kvm *kvm)
+static void __hyp_text __tlb_switch_to_guest_vhe(struct kvm *kvm,
+unsigned long *flags)
 {
u64 val;
 
+   local_irq_save(*flags);
+
/*
 * With VHE enabled, we have HCR_EL2.{E2H,TGE} = {1,1}, and
 * most TLB operations target EL2/EL0. In order to affect the
@@ -36,7 +41,8 @@ static void __hyp_text __tlb_switch_to_guest_vhe(struct kvm 
*kvm)
isb();
 }
 
-static void __hyp_text __tlb_switch_to_guest_nvhe(struct kvm *kvm)
+static void __hyp_text __tlb_switch_to_guest_nvhe(struct kvm *kvm,
+ unsigned long *flags)
 {
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
@@ -47,7 +53,8 @@ static hyp_alternate_select(__tlb_switch_to_guest,
__tlb_switch_to_guest_vhe,
ARM64_HAS_VIRT_HOST_EXTN);
 
-static void __hyp_text __tlb_switch_to_host_vhe(struct kvm *kvm)
+static void __hyp_text __tlb_switch_to_host_vhe(struct kvm *kvm,
+   unsigned long flags)
 {
/*
 * We're done with the TLB operation, let's restore the host's
@@ -55,9 +62,12 @@ static void __hyp_text __tlb_switch_to_host_vhe(struct kvm 
*kvm)
 */
write_sysreg(0, vttbr_el2);
write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
+   isb();
+   local_irq_restore(flags);
 }
 
-static void __hyp_text __tlb_switch_to_host_nvhe(struct kvm *kvm)
+static void __hyp_text __tlb_switch_to_host_nvhe(struct kvm *kvm,
+unsigned long flags)
 {
write_sysreg(0, vttbr_el2);
 }
@@ -69,11 +79,13 @@ static hyp_alternate_select(__tlb_switch_to_host,
 
 void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
+   unsigned long flags;
+
dsb(ishst);
 
/* Switch to requested VMID */
kvm = kern_hyp_va(kvm);
-   __tlb_switch_to_guest()(kvm);
+   __tlb_switch_to_guest()(kvm, );
 
/*
 * We could do so much better if we had the VA as well.
@@ -116,36 +128,39 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, 
phys_addr_t ipa)
if (!has_vhe() && icache_is_vpipt())
__flush_icache_all();
 
-   __tlb_switch_to_host()(kvm);
+   __tlb_switch_to_host()(kvm, flags);
 }
 
 void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
 {
+   unsigned long flags;
+
dsb(ishst);
 
/* Switch to requested VMID */
kvm = kern_hyp_va(kvm);
-   __tlb_switch_to_guest()(kvm);
+   __tlb_switch_to_guest()(kvm, );
 
__tlbi(vmalls12e1is);
dsb(ish);
isb();
 
-   __tlb_switch_to_host()(kvm);
+   __tlb_switch_to_host()(kvm, flags);
 }
 
 void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
 {
struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+   unsigned long flags;
 
/* Switch to requested VMID */
-   __tlb_switch_to_guest()(kvm);
+   __tlb_switch_to_guest()(kvm, );
 
__tlbi(vmalle1);
dsb(nsh);
isb();
 
-   __tlb_switch_to_host()(kvm);
+   __tlb_switch_to_host()(kvm, flags);
 }
 
 void __hyp_text __kvm_flush_vm_context(void)
diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 26a058d58d37..c7c31e214813 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -183,12 +183,6 @@ const char *get_system_type(void)
  

Re: Linux 4.19.44

2019-05-17 Thread Greg KH
diff --git a/Makefile b/Makefile
index be894b3a97d5..dd11f5a83d2f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 19
-SUBLEVEL = 43
+SUBLEVEL = 44
 EXTRAVERSION =
 NAME = "People's Front"
 
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index ec29de250076..cab89479d15e 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -133,9 +133,9 @@ __secondary_data:
  */
.text
 __after_proc_init:
-#ifdef CONFIG_ARM_MPU
 M_CLASS(movw   r12, #:lower16:BASEADDR_V7M_SCB)
 M_CLASS(movt   r12, #:upper16:BASEADDR_V7M_SCB)
+#ifdef CONFIG_ARM_MPU
 M_CLASS(ldrr3, [r12, 0x50])
 AR_CLASS(mrc   p15, 0, r3, c0, c1, 4)  @ Read ID_MMFR0
and r3, r3, #(MMFR0_PMSA)   @ PMSA field
diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 4c7a93f4039a..7c0b2e6cdfbd 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -211,12 +211,6 @@ const char *get_system_type(void)
return ath79_sys_type;
 }
 
-int get_c0_perfcount_int(void)
-{
-   return ATH79_MISC_IRQ(5);
-}
-EXPORT_SYMBOL_GPL(get_c0_perfcount_int);
-
 unsigned int get_c0_compare_int(void)
 {
return CP0_LEGACY_COMPARE_IRQ;
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h 
b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 391ed2c3b697..f9019b579903 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -83,6 +83,9 @@ static inline pgd_t *pgd_alloc(struct mm_struct *mm)
 
pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
   pgtable_gfp_flags(mm, GFP_KERNEL));
+   if (unlikely(!pgd))
+   return pgd;
+
/*
 * Don't scan the PGD for pointers, it contains references to PUDs but
 * those references are not full pointers and so can't be recognised by
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index eb2a33d5df26..e382bd6ede84 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -41,7 +41,7 @@
 #if defined(CONFIG_PPC_BOOK3E_64)
 #define MSR_64BIT  MSR_CM
 
-#define MSR_   (MSR_ME | MSR_CE)
+#define MSR_   (MSR_ME | MSR_RI | MSR_CE)
 #define MSR_KERNEL (MSR_ | MSR_64BIT)
 #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE)
 #define MSR_USER64 (MSR_USER32 | MSR_64BIT)
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 7f5ac2e8581b..36178000a2f2 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -170,6 +170,9 @@ core_idle_lock_held:
bne-core_idle_lock_held
blr
 
+/* Reuse an unused pt_regs slot for IAMR */
+#define PNV_POWERSAVE_IAMR _DAR
+
 /*
  * Pass requested state in r3:
  * r3 - PNV_THREAD_NAP/SLEEP/WINKLE in POWER8
@@ -200,6 +203,12 @@ pnv_powersave_common:
/* Continue saving state */
SAVE_GPR(2, r1)
SAVE_NVGPRS(r1)
+
+BEGIN_FTR_SECTION
+   mfspr   r5, SPRN_IAMR
+   std r5, PNV_POWERSAVE_IAMR(r1)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
+
mfcrr5
std r5,_CCR(r1)
std r1,PACAR1(r13)
@@ -924,6 +933,17 @@ BEGIN_FTR_SECTION
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
REST_NVGPRS(r1)
REST_GPR(2, r1)
+
+BEGIN_FTR_SECTION
+   /* IAMR was saved in pnv_powersave_common() */
+   ld  r5, PNV_POWERSAVE_IAMR(r1)
+   mtspr   SPRN_IAMR, r5
+   /*
+* We don't need an isync here because the upcoming mtmsrd is
+* execution synchronizing.
+*/
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
+
ld  r4,PACAKMSR(r13)
ld  r5,_LINK(r1)
ld  r6,_CCR(r1)
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 4ccbf611a3c5..70568ccbd9fd 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -4,6 +4,7 @@
 //
 // Copyright 2018, Michael Ellerman, IBM Corporation.
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 61c1fadbc644..6dc43205382b 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -338,13 +338,12 @@ void arch_send_call_function_ipi_mask(const struct 
cpumask *mask)
  * NMI IPIs may not be recoverable, so should not be used as ongoing part of
  * a running system. They can be used for crash, debug, halt/reboot, etc.
  *
- * NMI IPIs are globally single threaded. No more than one in progress at
- * any time.
- *
  * The IPI call waits with interrupts disabled until all targets enter the
- * NMI handler, then the call returns.
+ * NMI handler, then returns. Subsequent IPIs can be issued before targets
+ * have returned from their handlers, so there is no guarantee about
+ * concurrency or re-entrancy.
  *
- * No new NMI can be initiated until targets exit 

Linux 5.0.17

2019-05-17 Thread Greg KH
I'm announcing the release of the 5.0.17 kernel.

All users of the 5.0 kernel series must upgrade.

The updated 5.0.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.0.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/net/davinci_emac.txt  |2 
 Documentation/devicetree/bindings/net/ethernet.txt  |2 
 Documentation/devicetree/bindings/net/macb.txt  |4 
 Makefile|2 
 arch/arm/Kconfig|2 
 arch/arm/Kconfig.debug  |6 
 arch/arm/kernel/head-nommu.S|2 
 arch/arm64/kernel/ftrace.c  |9 
 arch/mips/ath79/setup.c |6 
 arch/powerpc/include/asm/book3s/64/pgalloc.h|3 
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/kernel/idle_book3s.S   |   20 
 arch/x86/include/uapi/asm/vmx.h |1 
 arch/x86/kernel/reboot.c|   21 
 arch/x86/kernel/vmlinux.lds.S   |2 
 arch/x86/kvm/lapic.c|4 
 arch/x86/kvm/trace.h|4 
 arch/x86/kvm/vmx/nested.c   |   22 
 arch/x86/mm/dump_pagetables.c   |3 
 arch/x86/mm/ioremap.c   |2 
 block/bfq-iosched.c |8 
 block/blk-mq.c  |2 
 drivers/acpi/nfit/core.c|   12 
 drivers/char/ipmi/ipmi_si_hardcode.c|2 
 drivers/clocksource/Kconfig |1 
 drivers/clocksource/timer-oxnas-rps.c   |2 
 drivers/dma/bcm2835-dma.c   |2 
 drivers/gpio/gpiolib.c  |   12 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |1 
 drivers/gpu/drm/amd/display/dc/core/dc.c|   19 
 drivers/gpu/drm/amd/display/dc/dc.h |3 
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.c|9 
 drivers/gpu/drm/amd/display/dc/dce/dce_aux.h|6 
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   |4 
 drivers/gpu/drm/imx/ipuv3-crtc.c|2 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |2 
 drivers/gpu/drm/sun4i/sun4i_drv.c   |7 
 drivers/gpu/drm/ttm/ttm_bo.c|4 
 drivers/gpu/drm/virtio/virtgpu_drv.c|4 
 drivers/gpu/drm/virtio/virtgpu_drv.h|4 
 drivers/gpu/drm/virtio/virtgpu_prime.c  |   12 
 drivers/gpu/ipu-v3/ipu-dp.c |   12 
 drivers/hid/hid-input.c |   14 
 drivers/hwmon/occ/sysfs.c   |8 
 drivers/hwmon/pwm-fan.c |2 
 drivers/iio/adc/xilinx-xadc-core.c  |3 
 drivers/infiniband/hw/hns/hns_roce_qp.c |2 
 drivers/infiniband/hw/mlx5/main.c   |2 
 drivers/infiniband/hw/mlx5/qp.c |   11 
 drivers/input/keyboard/Kconfig  |2 
 drivers/input/rmi4/rmi_driver.c |6 
 drivers/irqchip/irq-ath79-misc.c|   11 
 drivers/isdn/gigaset/bas-gigaset.c  |9 
 drivers/isdn/mISDN/socket.c |4 
 drivers/md/raid5.c  |   19 
 drivers/net/bonding/bond_options.c  |7 
 drivers/net/ethernet/cadence/macb_main.c|6 
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c  |2 
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c |2 
 drivers/net/ethernet/mscc/ocelot.c  |2 
 drivers/net/ethernet/neterion/vxge/vxge-config.c|1 
 drivers/net/ethernet/qlogic/qed/qed.h   |7 
 drivers/net/ethernet/qlogic/qed/qed_dev.c   |   85 +--
 drivers/net/ethernet/qlogic/qed/qed_int.c   |   83 ++-
 drivers/net/ethernet/qlogic/qed/qed_int.h   |4 
 

Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6

2019-05-17 Thread Maxime Ripard
On Fri, May 17, 2019 at 01:51:56AM +0800, Frank Lee wrote:
> > > +struct sun50i_thermal_chip {
> > > + int sensor_num;
> > > + int offset;
> > > + int scale;
> > > + int ft_deviation;
> > > + int temp_calib_base;
> > > + int temp_data_base;
> > > + int (*enable)(struct tsens_device *tmdev);
> > > + int (*disable)(struct tsens_device *tmdev);
> > > +};
> >
> > I'm not super fond of having a lot of quirks that are not needed. If
> > we ever need those quirks when adding support for a new SoC, then
> > yeah, we should totally have some, but only when and if it's needed.
> >
> > Otherwise, the driver is more complicated for no particular reason.
>
> This is unavoidable because of the difference in soc.

I know, but this isn't my point.

My point is that at this time of the driver development, we don't know
what is going to be needed to support all of those SoCs.

Some of the parameters you added might not be needed, some parameters
might be missing, we don't know. So let's keep it simple for now.

> > > +static int tsens_probe(struct platform_device *pdev)
> > > +{
> > > + struct tsens_device *tmdev;
> > > + struct device *dev = >dev;
> > > + int ret;
> > > +
> > > + tmdev = devm_kzalloc(dev, sizeof(*tmdev), GFP_KERNEL);
> > > + if (!tmdev)
> > > + return -ENOMEM;
> > > +
> > > + tmdev->dev = dev;
> > > + tmdev->chip = of_device_get_match_data(>dev);
> > > + if (!tmdev->chip)
> > > + return -EINVAL;
> > > +
> > > + ret = tsens_init(tmdev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = tsens_register(tmdev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = tmdev->chip->enable(tmdev);
> > > + if (ret)
> > > + return ret;
> > >
> > > + platform_set_drvdata(pdev, tmdev);
> >
> > Your registration should be the very last thing you do. Otherwise, you
> > have a small window where the get_temp callback can be called, but the
> > driver will not be functional yet.
>
> No. Anyway, ths data qcquisition is ms level.

That's kind of irrelevant. There's nothing preventing get_temp to be
called right away.

> > > + ret = tsens_calibrate(tmdev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > +  * clkin = 24MHz
> > > +  * T acquire = clkin / (SUN50I_THS_CTRL0_T_ACQ + 1)
> > > +  *   = 20us
> > > +  */
> > > + regmap_write(tmdev->regmap, SUN50I_THS_CTRL0,
> > > +  SUN50I_THS_CTRL0_T_ACQ(479));
> > > + /* average over 4 samples */
> > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_MFC,
> > > +  SUN50I_THS_FILTER_EN |
> > > +  SUN50I_THS_FILTER_TYPE(1));
> > > + /* period = (SUN50I_H6_THS_PC_TEMP_PERIOD + 1) * 4096 / clkin; 
> > > ~10ms */
> > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_PC,
> > > +  SUN50I_H6_THS_PC_TEMP_PERIOD(58));
> > > + /* enable sensor */
> > > + val = GENMASK(tmdev->chip->sensor_num - 1, 0);
> > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_ENABLE, val);
> > > +
> > > + return 0;
> > > +
> > > +assert_reset:
> > > + reset_control_assert(tmdev->reset);
> > > +
> > > + return ret;
> >
> > Can't we do that with runtime_pm?
>
> Saving energy doesn't make much sense compared to system security.

I'm not sure what you mean by security.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Linux 5.1.3

2019-05-17 Thread Greg KH
I'm announcing the release of the 5.1.3 kernel.

All users of the 5.1 kernel series must upgrade.

The updated 5.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.1.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/powerpc/include/asm/book3s/64/pgalloc.h|3 
 arch/powerpc/include/asm/reg_booke.h|2 
 arch/powerpc/kernel/idle_book3s.S   |   20 +
 drivers/hwmon/occ/sysfs.c   |8 +-
 drivers/hwmon/pwm-fan.c |2 
 drivers/i2c/i2c-core-base.c |5 +
 drivers/isdn/gigaset/bas-gigaset.c  |9 +-
 drivers/md/raid5.c  |   19 +
 drivers/net/bonding/bond_options.c  |7 -
 drivers/net/ethernet/cadence/macb_main.c|6 -
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c  |2 
 drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 --
 drivers/net/ethernet/seeq/sgiseeq.c |1 
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   |2 
 drivers/net/phy/phy_device.c|   11 +--
 drivers/net/tun.c   |   14 +++
 drivers/net/wireless/marvell/mwl8k.c|   13 ++-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c |1 
 drivers/pci/controller/pci-hyperv.c |   23 ++
 drivers/platform/x86/dell-laptop.c  |6 -
 drivers/platform/x86/sony-laptop.c  |8 +-
 drivers/platform/x86/thinkpad_acpi.c|   72 +++-
 drivers/usb/serial/generic.c|   39 --
 drivers/virt/fsl_hypervisor.c   |   29 
 drivers/virt/vboxguest/vboxguest_core.c |   31 
 drivers/virtio/virtio_ring.c|1 
 fs/f2fs/data.c  |   17 +++-
 fs/f2fs/f2fs.h  |   13 +++
 fs/f2fs/file.c  |2 
 fs/f2fs/gc.c|2 
 fs/f2fs/segment.c   |   13 +--
 fs/kernfs/dir.c |5 -
 include/linux/i2c.h |3 
 net/8021q/vlan_dev.c|4 -
 net/bridge/br_if.c  |   13 +--
 net/core/fib_rules.c|6 -
 net/core/flow_dissector.c   |3 
 net/dsa/dsa.c   |   11 ++-
 net/ipv4/raw.c  |4 -
 net/ipv6/sit.c  |2 
 net/packet/af_packet.c  |   25 +-
 net/tipc/socket.c   |4 -
 security/selinux/hooks.c|8 +-
 tools/testing/selftests/seccomp/seccomp_bpf.c   |   43 ++-
 45 files changed, 375 insertions(+), 147 deletions(-)

Andrea Parri (1):
  kernfs: fix barrier usage in __kernfs_new_node()

Christophe Leroy (1):
  net: ucc_geth - fix Oops when changing number of buffers in the ring

Corentin Labbe (1):
  net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering

Damien Le Moal (1):
  f2fs: Fix use of number of devices

Dan Carpenter (2):
  drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl
  drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl

David Ahern (1):
  ipv4: Fix raw socket lookup for local traffic

Dexuan Cui (3):
  PCI: hv: Fix a memory leak in hv_eject_device_work()
  PCI: hv: Add hv_pci_remove_slots() when we unload the driver
  PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if 
necessary

Eric Dumazet (1):
  flow_dissector: disable preemption around BPF calls

Greg Kroah-Hartman (1):
  Linux 5.1.3

Gustavo A. R. Silva (2):
  platform/x86: sony-laptop: Fix unintentional fall-through
  rtlwifi: rtl8723ae: Fix missing break in switch statement

Hangbin Liu (2):
  fib_rules: return 0 directly if an exactly same rule exists when 
NLM_F_EXCL not supplied
  vlan: disable SIOCSHWTSTAMP in container

Hans de Goede (1):
  virt: vbox: Sanity-check parameter types for hgcm-calls coming from 
userspace

Harini Katakam (1):
  net: macb: Change interrupt and napi enable order in open

Heiner Kallweit (1):
  net: phy: fix phy_validate_pause

Jarod Wilson (1):
  bonding: fix arp_validate toggling in active-backup mode

Jason Wang (2):
  tuntap: fix dividing by zero in ebpf queue selection
  tuntap: 

Re: Linux 5.1.3

2019-05-17 Thread Greg KH
diff --git a/Makefile b/Makefile
index 58ec07990e76..f6c763aff4f3 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 5
 PATCHLEVEL = 1
-SUBLEVEL = 2
+SUBLEVEL = 3
 EXTRAVERSION =
 NAME = Shy Crocodile
 
diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h 
b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 138bc2ecc0c4..ba188797d940 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -81,6 +81,9 @@ static inline pgd_t *pgd_alloc(struct mm_struct *mm)
 
pgd = kmem_cache_alloc(PGT_CACHE(PGD_INDEX_SIZE),
   pgtable_gfp_flags(mm, GFP_KERNEL));
+   if (unlikely(!pgd))
+   return pgd;
+
/*
 * Don't scan the PGD for pointers, it contains references to PUDs but
 * those references are not full pointers and so can't be recognised by
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index eb2a33d5df26..e382bd6ede84 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -41,7 +41,7 @@
 #if defined(CONFIG_PPC_BOOK3E_64)
 #define MSR_64BIT  MSR_CM
 
-#define MSR_   (MSR_ME | MSR_CE)
+#define MSR_   (MSR_ME | MSR_RI | MSR_CE)
 #define MSR_KERNEL (MSR_ | MSR_64BIT)
 #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE)
 #define MSR_USER64 (MSR_USER32 | MSR_64BIT)
diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index 7f5ac2e8581b..36178000a2f2 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -170,6 +170,9 @@ core_idle_lock_held:
bne-core_idle_lock_held
blr
 
+/* Reuse an unused pt_regs slot for IAMR */
+#define PNV_POWERSAVE_IAMR _DAR
+
 /*
  * Pass requested state in r3:
  * r3 - PNV_THREAD_NAP/SLEEP/WINKLE in POWER8
@@ -200,6 +203,12 @@ pnv_powersave_common:
/* Continue saving state */
SAVE_GPR(2, r1)
SAVE_NVGPRS(r1)
+
+BEGIN_FTR_SECTION
+   mfspr   r5, SPRN_IAMR
+   std r5, PNV_POWERSAVE_IAMR(r1)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
+
mfcrr5
std r5,_CCR(r1)
std r1,PACAR1(r13)
@@ -924,6 +933,17 @@ BEGIN_FTR_SECTION
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
REST_NVGPRS(r1)
REST_GPR(2, r1)
+
+BEGIN_FTR_SECTION
+   /* IAMR was saved in pnv_powersave_common() */
+   ld  r5, PNV_POWERSAVE_IAMR(r1)
+   mtspr   SPRN_IAMR, r5
+   /*
+* We don't need an isync here because the upcoming mtmsrd is
+* execution synchronizing.
+*/
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
+
ld  r4,PACAKMSR(r13)
ld  r5,_LINK(r1)
ld  r6,_CCR(r1)
diff --git a/drivers/hwmon/occ/sysfs.c b/drivers/hwmon/occ/sysfs.c
index fe3d15e416e7..a71ca94c789f 100644
--- a/drivers/hwmon/occ/sysfs.c
+++ b/drivers/hwmon/occ/sysfs.c
@@ -42,16 +42,16 @@ static ssize_t occ_sysfs_show(struct device *dev,
val = !!(header->status & OCC_STAT_ACTIVE);
break;
case 2:
-   val = !!(header->status & OCC_EXT_STAT_DVFS_OT);
+   val = !!(header->ext_status & OCC_EXT_STAT_DVFS_OT);
break;
case 3:
-   val = !!(header->status & OCC_EXT_STAT_DVFS_POWER);
+   val = !!(header->ext_status & OCC_EXT_STAT_DVFS_POWER);
break;
case 4:
-   val = !!(header->status & OCC_EXT_STAT_MEM_THROTTLE);
+   val = !!(header->ext_status & OCC_EXT_STAT_MEM_THROTTLE);
break;
case 5:
-   val = !!(header->status & OCC_EXT_STAT_QUICK_DROP);
+   val = !!(header->ext_status & OCC_EXT_STAT_QUICK_DROP);
break;
case 6:
val = header->occ_state;
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 167221c7628a..e4c5197417a8 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -271,7 +271,7 @@ static int pwm_fan_probe(struct platform_device *pdev)
 
ret = pwm_fan_of_get_cooling_data(>dev, ctx);
if (ret)
-   return ret;
+   goto err_pwm_disable;
 
ctx->pwm_fan_state = ctx->pwm_fan_max_state;
if (IS_ENABLED(CONFIG_THERMAL)) {
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 688aa3b5f3ac..2f0f88b79c4b 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1871,8 +1871,11 @@ int __i2c_transfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
 
if (WARN_ON(!msgs || num < 1))
return -EINVAL;
-   if (WARN_ON(test_bit(I2C_ALF_IS_SUSPENDED, >locked_flags)))
+   if (test_bit(I2C_ALF_IS_SUSPENDED, >locked_flags)) {
+   if (!test_and_set_bit(I2C_ALF_SUSPEND_REPORTED, 
>locked_flags))
+   dev_WARN(>dev, "Transfer while 

Re: [PATCH 3/3] dt-bindings: thermal: add binding document for h6 thermal controller

2019-05-17 Thread Maxime Ripard
On Fri, May 17, 2019 at 02:13:58AM +0800, Frank Lee wrote:
> On Sun, May 12, 2019 at 9:41 PM Maxime Ripard  
> wrote:
> >
> > Hi,
> >
> > On Sun, May 12, 2019 at 04:26:14AM -0400, Yangtao Li wrote:
> > > This patch adds binding document for allwinner h6 thermal controller.
> > >
> > > Signed-off-by: Yangtao Li 
> > > ---
> > >  .../bindings/thermal/sun50i-thermal.txt   | 32 +++
> > >  1 file changed, 32 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/thermal/sun50i-thermal.txt
> >
> > We're starting to convert to YAML for binding descriptions that will
> > allow to validate that all DT are properly using the binding. It would
> > be great if you could use it as well.
>
> What have been changed to this now?

This needs a YAML file instead of the text file you introduced.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v3 02/13] [media] mtk-mipicsi: add mediatek mipicsi driver for mt2712

2019-05-17 Thread CK Hu
Hi, Stu:

On Tue, 2019-05-14 at 14:13 +0800, Stu Hsieh wrote:
> This patch add mediatek mipicsi driver for mt2712,
> including probe function to get the value from device tree,
> and register to v4l2 the host device.
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/media/platform/mtk-mipicsi/Makefile   |   4 +
>  .../media/platform/mtk-mipicsi/mtk_mipicsi.c  | 587 ++
>  2 files changed, 591 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-mipicsi/Makefile
>  create mode 100644 drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> 
> diff --git a/drivers/media/platform/mtk-mipicsi/Makefile 
> b/drivers/media/platform/mtk-mipicsi/Makefile
> new file mode 100644
> index ..326a5e3808fa
> --- /dev/null
> +++ b/drivers/media/platform/mtk-mipicsi/Makefile
> @@ -0,0 +1,4 @@
> +mtk-mipicsi-y += mtk_mipicsi.o
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_MIPICSI) += mtk-mipicsi.o
> +
> diff --git a/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c 
> b/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> new file mode 100644
> index ..4ae5b88abc5f
> --- /dev/null
> +++ b/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> @@ -0,0 +1,587 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 MediaTek Inc.
> + * Author: Ricky Zhang 
> + * Baoyin Zhang 
> + * Alan Yue 
> + * Stu Hsieh 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * http://www.gnu.org/licenses/gpl-2.0.html for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MTK_MIPICSI_DRV_NAME "mtk-mipicsi"
> +#define MTK_PLATFORM_STR "platform:mt2712"
> +#define MIPICSI_COMMON_CLK 2
> +#define MTK_CAMDMA_MAX_NUM 4U
> +#define MIPICSI_CLK (MIPICSI_COMMON_CLK + MTK_CAMDMA_MAX_NUM)
> +
> +#define MIPI_RX_ANA00_CSI0x00
> +#define MIPI_RX_ANA04_CSI0x04
> +#define MIPI_RX_ANA08_CSI0x08
> +#define MIPI_RX_ANA0C_CSI0x0c
> +#define MIPI_RX_ANA10_CSI0x10
> +#define MIPI_RX_ANA20_CSI0x20
> +#define MIPI_RX_ANA24_CSI0x24
> +#define MIPI_RX_ANA4C_CSI0x4c
> +#define MIPI_RX_ANA50_CSI0x50
> +
> +#define SENINF_CTRL  0x00
> +
> +#define SENINF_NCSI2_CAL_24  0x24
> +#define SENINF_NCSI2_CAL_38  0x38
> +#define SENINF_NCSI2_CAL_3C  0x3C
> +#define SENINF_NCSI2_CTL 0xA0
> +#define SENINF_NCSI2_LNRD_TIMING 0xA8
> +#define SENINF_NCSI2_INT_EN  0xB0
> +#define SENINF_NCSI2_INT_STATUS  0xB4
> +#define SENINF_NCSI2_DBG_SEL 0xB8
> +#define SENINF_NCSI2_HSRX_DBG0xD8
> +#define SENINF_NCSI2_DI  0xDC
> +#define SENINF_NCSI2_DI_CTRL 0xE4
> +
> +#define SENINF_TOP_CTRL  0x00
> +#define SENINF_TOP_CMODEL_PAR0x04
> +#define SENINF_TOP_MUX   0x08
> +
> +#define SENINF_MUX_CTRL  0x00
> +
> +#define CAMSV_MODULE_EN  0x10
> +#define CAMSV_FMT_SEL0x14
> +#define CAMSV_INT_EN 0x18
> +#define CAMSV_CLK_EN 0x30
> +
> +#define CAMSV_TG_SEN_MODE0x500
> +#define CAMSV_TG_SEN_GRAB_PXL0x508
> +#define CAMSV_TG_SEN_GRAB_LIN0x50C
> +#define CAMSV_TG_PATH_CFG0x510
> +
> +#define IMGO_XSIZE   0x230
> +#define IMGO_YSIZE   0x234
> +#define IMGO_STRIDE  0x238
> +#define DMA_FRAME_HEADER_EN  0xE00
> +
> +struct mtk_mipicsi_dev {
> + struct platform_device *pdev;
> + unsigned int camsv_num;
> + struct device 

Re: Linux 4.19 and GCC 9

2019-05-17 Thread Peter Zijlstra
On Fri, May 17, 2019 at 07:09:31AM +0200, Greg KH wrote:
> On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> > We are building the upstream kernel. There are a few patches, but
> > nothing related to objtool.
> > 
> > Unless you mean mainline/stable by upstream, I haven't tried that. We
> > stick to LTS.
> 
> Please work and all of these issues fixed up in Linus's tree and then I
> will be glad to take the fixed into the stable releases.

Right; if there is anything you can reproduce on linus.git I'll happily
have a look. If it doesn't reproduce all you have to do is find the
patches that make it work and ask Greg.


Великденски бонуси

2019-05-17 Thread Radoslav Dobrev
Здравейте!

Нуждаете ли се от мотивационен пакет за персонала, който е удобен и 
привлекателен, както за работодателя, така и за служителите?

В такъв случай Ви препоръчваме да обмислите използването на все по-популярните 
ваучери за храна - работодателят осигурява ваучери за определена сума, а 
служителят може да я използва в различни вериги хранителни магазини или 
заведения за хранене според своите предпочитания.

Ще се радвам да Ви представя възможностите на ваучерите  – мога ли да Ви се 
обадя, за да обсъдим в детайли?


Радослав Добрев
Head of HR Benefit Team
www.lunchkarty.eu


Re: [PATCH 4/4] serial: 8250-mtk: modify uart DMA rx

2019-05-17 Thread Long Cheng
On Wed, 2019-05-15 at 21:48 +0800, Nicolas Boichat wrote:
> On Sat, Apr 27, 2019 at 11:36 AM Long Cheng  wrote:
> >
> > Modify uart rx and complete for DMA.
> 
> I don't know much about the DMA framework, but can you please explain
> why you are making the changes in this CL? I see that you are dropping
> dma_sync_single_for_device calls, for example, why?
> 

the rx buffer is create by 'dma_alloc_coherent'. in the function, the
buffer is uncache. We don't need to sync between CPU and DMA. So I
remove it.

> >
> > Signed-off-by: Long Cheng 
> > ---
> >  drivers/tty/serial/8250/8250_mtk.c |   53 
> > 
> >  1 file changed, 23 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_mtk.c 
> > b/drivers/tty/serial/8250/8250_mtk.c
> > index c1fdbc0..04081a6 100644
> > --- a/drivers/tty/serial/8250/8250_mtk.c
> > +++ b/drivers/tty/serial/8250/8250_mtk.c
> > @@ -30,7 +30,6 @@
> >  #define MTK_UART_DMA_EN_TX 0x2
> >  #define MTK_UART_DMA_EN_RX 0x5
> >
> > -#define MTK_UART_TX_SIZE   UART_XMIT_SIZE
> >  #define MTK_UART_RX_SIZE   0x8000
> >  #define MTK_UART_TX_TRIGGER1
> >  #define MTK_UART_RX_TRIGGERMTK_UART_RX_SIZE
> > @@ -64,28 +63,30 @@ static void mtk8250_dma_rx_complete(void *param)
> > struct mtk8250_data *data = up->port.private_data;
> > struct tty_port *tty_port = >port.state->port;
> > struct dma_tx_state state;
> > +   int copied, cnt, tmp;
> > unsigned char *ptr;
> > -   int copied;
> >
> > -   dma_sync_single_for_cpu(dma->rxchan->device->dev, dma->rx_addr,
> > -   dma->rx_size, DMA_FROM_DEVICE);
> > +   if (data->rx_status == DMA_RX_SHUTDOWN)
> > +   return;
> >
> > dmaengine_tx_status(dma->rxchan, dma->rx_cookie, );
> > +   cnt = dma->rx_size - state.residue;
> > +   tmp = cnt;
> 
> I ponder, maybe we should rename cnt to left? (like, how many bytes
> are left to transfer, in total) Or maybe "total"
> Then maybe rename tmp to cnt.
> 
like better.

> >
> > -   if (data->rx_status == DMA_RX_SHUTDOWN)
> > -   return;
> > +   if ((data->rx_pos + cnt) > dma->rx_size)
> > +   tmp = dma->rx_size - data->rx_pos;
> 
> Maybe replace this and the line above:
> tmp = max_t(int, cnt, dma->rx_size - data->rx_pos);
> 
Yes. It's better.

> >
> > -   if ((data->rx_pos + state.residue) <= dma->rx_size) {
> > -   ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > -   copied = tty_insert_flip_string(tty_port, ptr, 
> > state.residue);
> > -   } else {
> > -   ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > -   copied = tty_insert_flip_string(tty_port, ptr,
> > -   dma->rx_size - 
> > data->rx_pos);
> > +   ptr = (unsigned char *)(data->rx_pos + dma->rx_buf);
> > +   copied = tty_insert_flip_string(tty_port, ptr, tmp);
> > +   data->rx_pos += tmp;
> > +
> > +   if (cnt > tmp) {
> > ptr = (unsigned char *)(dma->rx_buf);
> > -   copied += tty_insert_flip_string(tty_port, ptr,
> > -   data->rx_pos + state.residue - 
> > dma->rx_size);
> > +   tmp = cnt - tmp;
> > +   copied += tty_insert_flip_string(tty_port, ptr, tmp);
> > +   data->rx_pos = tmp;
> > }
> > +
> > up->port.icount.rx += copied;
> >
> > tty_flip_buffer_push(tty_port);
> > @@ -96,9 +97,7 @@ static void mtk8250_dma_rx_complete(void *param)
> >  static void mtk8250_rx_dma(struct uart_8250_port *up)
> >  {
> > struct uart_8250_dma *dma = up->dma;
> > -   struct mtk8250_data *data = up->port.private_data;
> > struct dma_async_tx_descriptor  *desc;
> > -   struct dma_tx_state  state;
> >
> > desc = dmaengine_prep_slave_single(dma->rxchan, dma->rx_addr,
> >dma->rx_size, DMA_DEV_TO_MEM,
> > @@ -113,12 +112,6 @@ static void mtk8250_rx_dma(struct uart_8250_port *up)
> >
> > dma->rx_cookie = dmaengine_submit(desc);
> >
> > -   dmaengine_tx_status(dma->rxchan, dma->rx_cookie, );
> > -   data->rx_pos = state.residue;
> > -
> > -   dma_sync_single_for_device(dma->rxchan->device->dev, dma->rx_addr,
> > -  dma->rx_size, DMA_FROM_DEVICE);
> > -
> > dma_async_issue_pending(dma->rxchan);
> >  }
> >
> > @@ -131,13 +124,13 @@ static void mtk8250_dma_enable(struct uart_8250_port 
> > *up)
> > if (data->rx_status != DMA_RX_START)
> > return;
> >
> > -   dma->rxconf.direction   = DMA_DEV_TO_MEM;
> > -   dma->rxconf.src_addr_width  = dma->rx_size / 1024;
> > -   dma->rxconf.src_addr= dma->rx_addr;
> > +   dma->rxconf.direction   = DMA_DEV_TO_MEM;
> > +   dma->rxconf.src_port_window_size= 

Re: [PATCH v2 0/2] add thermal driver for h6

2019-05-17 Thread Maxime Ripard
Hi,

On Thu, May 16, 2019 at 01:26:31PM -0400, Yangtao Li wrote:
> This patchset supprt H6 thermal controller.

The discussion is still ongoing on the v1, it would have been better
to wait a bit on it to settle before sending a new version.

Anyway, some comment made there still apply.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH 4.4 000/266] 4.4.180-stable review

2019-05-17 Thread Daniel Wagner
Hi Greg,

On 16.05.19 18:49, Greg Kroah-Hartman wrote:
> Jon, thanks for the testing, I'll go drop this patch now from the final
> version.

That's fine, I wanted to suggest this too. I have some time to look at
this next week. So there is no hurry with this patch.

> Daniel, if you can come up with a working series, I'll be glad to take
> it.  Or, I'd recommend you just move to a newer kernel :)

Sure, I will see what is missing.

@Jon if I get have something to test, would you have time to give it a
try first?

There is someone constantly updating the v4.4.y tree, which makes me
update the -rt patches all the time. Don't fear, I am not running 4.4.y,
this is only for important infrastructure :)

Thanks,
Daniel


Re: Getting empty callchain from perf_callchain_kernel()

2019-05-17 Thread Peter Zijlstra
On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
> Hi, 
> 
> We found a failure with selftests/bpf/tests_prog in test_stacktrace_map (on 
> bpf/master
> branch). 
> 
> After digging into the code, we found that perf_callchain_kernel() is giving 
> empty
> callchain for tracepoint sched/sched_switch. And it seems related to commit
> 
> d15d356887e770c5f2dcf963b52c7cb510c9e42d
> ("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
> 
> Before this commit, perf_callchain_kernel() returns callchain with regs->ip. 
> With
> this commit, regs->ip is not sent for !perf_hw_regs(regs) case. 

So while I think the below is indeed right; we should store regs->ip
regardless of the unwind path chosen, I still think there's something
fishy if this results in just the 1 entry.

The sched/sched_switch event really should have a non-trivial stack.

Let me see if I can reproduce with just perf.


Re: Linux 5.1.3

2019-05-17 Thread Bhaskar Chowdhury
Thanks, a bunch Greg! :) 


On 09:37 Fri 17 May , Greg KH wrote:

I'm announcing the release of the 5.1.3 kernel.

All users of the 5.1 kernel series must upgrade.

The updated 5.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.1.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



Makefile|2
arch/powerpc/include/asm/book3s/64/pgalloc.h|3
arch/powerpc/include/asm/reg_booke.h|2
arch/powerpc/kernel/idle_book3s.S   |   20 +
drivers/hwmon/occ/sysfs.c   |8 +-
drivers/hwmon/pwm-fan.c |2
drivers/i2c/i2c-core-base.c |5 +
drivers/isdn/gigaset/bas-gigaset.c  |9 +-
drivers/md/raid5.c  |   19 +
drivers/net/bonding/bond_options.c  |7 -
drivers/net/ethernet/cadence/macb_main.c|6 -
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c  |2
drivers/net/ethernet/freescale/ucc_geth_ethtool.c   |8 --
drivers/net/ethernet/seeq/sgiseeq.c |1
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c   |2
drivers/net/phy/phy_device.c|   11 +--
drivers/net/tun.c   |   14 +++
drivers/net/wireless/marvell/mwl8k.c|   13 ++-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c |1
drivers/pci/controller/pci-hyperv.c |   23 ++
drivers/platform/x86/dell-laptop.c  |6 -
drivers/platform/x86/sony-laptop.c  |8 +-
drivers/platform/x86/thinkpad_acpi.c|   72 +++-
drivers/usb/serial/generic.c|   39 --
drivers/virt/fsl_hypervisor.c   |   29 
drivers/virt/vboxguest/vboxguest_core.c |   31 
drivers/virtio/virtio_ring.c|1
fs/f2fs/data.c  |   17 +++-
fs/f2fs/f2fs.h  |   13 +++
fs/f2fs/file.c  |2
fs/f2fs/gc.c|2
fs/f2fs/segment.c   |   13 +--
fs/kernfs/dir.c |5 -
include/linux/i2c.h |3
net/8021q/vlan_dev.c|4 -
net/bridge/br_if.c  |   13 +--
net/core/fib_rules.c|6 -
net/core/flow_dissector.c   |3
net/dsa/dsa.c   |   11 ++-
net/ipv4/raw.c  |4 -
net/ipv6/sit.c  |2
net/packet/af_packet.c  |   25 +-
net/tipc/socket.c   |4 -
security/selinux/hooks.c|8 +-
tools/testing/selftests/seccomp/seccomp_bpf.c   |   43 ++-
45 files changed, 375 insertions(+), 147 deletions(-)

Andrea Parri (1):
 kernfs: fix barrier usage in __kernfs_new_node()

Christophe Leroy (1):
 net: ucc_geth - fix Oops when changing number of buffers in the ring

Corentin Labbe (1):
 net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering

Damien Le Moal (1):
 f2fs: Fix use of number of devices

Dan Carpenter (2):
 drivers/virt/fsl_hypervisor.c: dereferencing error pointers in ioctl
 drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl

David Ahern (1):
 ipv4: Fix raw socket lookup for local traffic

Dexuan Cui (3):
 PCI: hv: Fix a memory leak in hv_eject_device_work()
 PCI: hv: Add hv_pci_remove_slots() when we unload the driver
 PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

Eric Dumazet (1):
 flow_dissector: disable preemption around BPF calls

Greg Kroah-Hartman (1):
 Linux 5.1.3

Gustavo A. R. Silva (2):
 platform/x86: sony-laptop: Fix unintentional fall-through
 rtlwifi: rtl8723ae: Fix missing break in switch statement

Hangbin Liu (2):
 fib_rules: return 0 directly if an exactly same rule exists when 
NLM_F_EXCL not supplied
 vlan: disable SIOCSHWTSTAMP in container

Hans de Goede (1):
 virt: vbox: Sanity-check parameter types for hgcm-calls coming from 
userspace

Harini Katakam (1):
 net: macb: Change interrupt and napi enable order in open

Heiner Kallweit (1):
 net: phy: fix phy_validate_pause

Jarod Wilson (1):
 bonding: fix arp_validate toggling in active-backup mode

Jason Wang (2):
 tuntap: fix dividing by zero in ebpf queue selection
 tuntap: synchronize through 

Re: [PATCH v2] Staging: bcm2835-camera: Prefer kernel types

2019-05-17 Thread Stefan Wahren

Am 16.05.2019 um 23:33 schrieb Madhumitha Prabakaran:

Fix the warning issued by checkpatch
Prefer kernel type 'u32' over 'uint32_t'.
Along with that include a blank line after a declaration
to maintain Linux kernel coding style.

Signed-off-by: Madhumitha Prabakaran 


Acked-by: Stefan Wahren 



[PATCH v3] staging: vt6656: returns error code on vnt_int_start_interrupt fail

2019-05-17 Thread Quentin Deslandes
Returns error code from 'vnt_int_start_interrupt()' so the device's private
buffers will be correctly freed and 'struct ieee80211_hw' start function
will return an error code.

Signed-off-by: Quentin Deslandes 
---
v2: returns 'status' value to caller instead of removing it.
v3: add patch version details. Thanks to Greg K-H for his help.

 drivers/staging/vt6656/int.c  |  4 +++-
 drivers/staging/vt6656/int.h  |  2 +-
 drivers/staging/vt6656/main_usb.c | 12 +---
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/int.c b/drivers/staging/vt6656/int.c
index 504424b19fcf..f3ee2198e1b3 100644
--- a/drivers/staging/vt6656/int.c
+++ b/drivers/staging/vt6656/int.c
@@ -39,7 +39,7 @@ static const u8 fallback_rate1[5][5] = {
{RATE_54M, RATE_54M, RATE_36M, RATE_18M, RATE_18M}
 };
 
-void vnt_int_start_interrupt(struct vnt_private *priv)
+int vnt_int_start_interrupt(struct vnt_private *priv)
 {
unsigned long flags;
int status;
@@ -51,6 +51,8 @@ void vnt_int_start_interrupt(struct vnt_private *priv)
status = vnt_start_interrupt_urb(priv);
 
spin_unlock_irqrestore(>lock, flags);
+
+   return status;
 }
 
 static int vnt_int_report_rate(struct vnt_private *priv, u8 pkt_no, u8 tsr)
diff --git a/drivers/staging/vt6656/int.h b/drivers/staging/vt6656/int.h
index 987c454e99e9..8a6d60569ceb 100644
--- a/drivers/staging/vt6656/int.h
+++ b/drivers/staging/vt6656/int.h
@@ -41,7 +41,7 @@ struct vnt_interrupt_data {
u8 sw[2];
 } __packed;
 
-void vnt_int_start_interrupt(struct vnt_private *priv);
+int vnt_int_start_interrupt(struct vnt_private *priv);
 void vnt_int_process_data(struct vnt_private *priv);
 
 #endif /* __INT_H__ */
diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index ccafcc2c87ac..71e10b9ae253 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -483,6 +483,7 @@ static void vnt_tx_80211(struct ieee80211_hw *hw,
 
 static int vnt_start(struct ieee80211_hw *hw)
 {
+   int err = 0;
struct vnt_private *priv = hw->priv;
 
priv->rx_buf_sz = MAX_TOTAL_SIZE_WITH_ALL_HEADERS;
@@ -496,15 +497,20 @@ static int vnt_start(struct ieee80211_hw *hw)
 
if (vnt_init_registers(priv) == false) {
dev_dbg(>usb->dev, " init register fail\n");
+   err = -ENOMEM;
goto free_all;
}
 
-   if (vnt_key_init_table(priv))
+   if (vnt_key_init_table(priv)) {
+   err = -ENOMEM;
goto free_all;
+   }
 
priv->int_interval = 1;  /* bInterval is set to 1 */
 
-   vnt_int_start_interrupt(priv);
+   err = vnt_int_start_interrupt(priv);
+   if (err)
+   goto free_all;
 
ieee80211_wake_queues(hw);
 
@@ -518,7 +524,7 @@ static int vnt_start(struct ieee80211_hw *hw)
usb_kill_urb(priv->interrupt_urb);
usb_free_urb(priv->interrupt_urb);
 
-   return -ENOMEM;
+   return err;
 }
 
 static void vnt_stop(struct ieee80211_hw *hw)
-- 
2.17.1



[PATCH 1/4] s390: do not pass $(LINUXINCLUDE) to gen_opcode_table.c

2019-05-17 Thread Masahiro Yamada
I guess HOSTCFLAGS_gen_opcode_table.o was blindly copied from
HOSTCFLAGS_gen_facilities.o

The reason of adding $(LINUXINCLUDE) to HOSTCFLAGS_gen_facilities.o
is because gen_facilities.c references some CONFIG options. (Kbuild
does not cater to this for host tools automatically.)

On the other hand, gen_opcode_table.c does not reference CONFIG
options at all. So, there is no good reason to pass $(LINUXINCLUDE).

Signed-off-by: Masahiro Yamada 
---

 arch/s390/tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile
index 2342b84b3386..4ff6a2124522 100644
--- a/arch/s390/tools/Makefile
+++ b/arch/s390/tools/Makefile
@@ -15,7 +15,7 @@ hostprogs-y   += gen_facilities
 hostprogs-y+= gen_opcode_table
 
 HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE)
-HOSTCFLAGS_gen_opcode_table.o += -Wall $(LINUXINCLUDE)
+HOSTCFLAGS_gen_opcode_table.o += -Wall
 
 # Ensure output directory exists
 _dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
-- 
2.17.1



[PATCH 4/4] s390: drop meaningless 'targets' from tools Makefile

2019-05-17 Thread Masahiro Yamada
'targets' should be specified to include .*.cmd files to evaluate
if_changed or friends.

Here, facility-defs.h and dis-defs.h are generated by filechk.

Because filechk does not generate .*.cmd file, the 'targets' addition
is meaningless. The filechk correctly updates the target when its
content is changed.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/tools/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile
index 4864ea5e6ceb..b5e35e8f999a 100644
--- a/arch/s390/tools/Makefile
+++ b/arch/s390/tools/Makefile
@@ -6,7 +6,6 @@
 kapi := arch/$(ARCH)/include/generated/asm
 kapi-hdrs-y := $(kapi)/facility-defs.h $(kapi)/dis-defs.h
 
-targets += $(addprefix ../../../,$(kapi-hdrs-y))
 PHONY += kapi
 
 kapi:  $(kapi-hdrs-y)
-- 
2.17.1



Re: [PATCH] serial-uartlite: Fix null-ptr-deref in ulite_exit

2019-05-17 Thread Johan Hovold
On Thu, May 16, 2019 at 12:09:31PM +0800, YueHaibing wrote:
> If ulite_probe is not called or failed to registed
> uart_register_driver, unload the module will call
> uart_unregister_driver, which will tigger NULL
> pointer dereference like this:
> 
> BUG: KASAN: null-ptr-deref in tty_unregister_driver+0x19/0x100
> Read of size 4 at addr 0034 by task syz-executor.0/4246

> This patch fix this by moving uart_unregister_driver
> to ulite_remove.
> 
> Reported-by: Hulk Robot 
> Fixes: 415b43bdb008 ("tty: serial: uartlite: Move uart register to probe")
> Signed-off-by: YueHaibing 
> ---
>  drivers/tty/serial/uartlite.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
> index b8b912b..2e49fb6 100644
> --- a/drivers/tty/serial/uartlite.c
> +++ b/drivers/tty/serial/uartlite.c
> @@ -867,6 +867,7 @@ static int ulite_remove(struct platform_device *pdev)
>   pm_runtime_disable(>dev);
>   pm_runtime_set_suspended(>dev);
>   pm_runtime_dont_use_autosuspend(>dev);
> + uart_unregister_driver(_uart_driver);

This broken. Consider what happens if you have tho ports registered and
you unbind the first.

Someone else sent a fix for this here


https://lkml.kernel.org/r/20190514033219.169947-1-wangkefeng.w...@huawei.com

That fix also has some issues, but is still better given the current
state this driver is in.

>   return rc;
>  }
>  
> @@ -897,7 +898,6 @@ static int __init ulite_init(void)
>  static void __exit ulite_exit(void)
>  {
>   platform_driver_unregister(_platform_driver);
> - uart_unregister_driver(_uart_driver);
>  }
>  
>  module_init(ulite_init);

Johan


[PATCH 2/4] s390: drop unneeded -Wall addition from tools Makefile

2019-05-17 Thread Masahiro Yamada
The top level Makefile adds -Wall globally for all host tools:

  KBUILD_HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \

I see two "-Wall" added for compiling these tools.

Of course, it is allowed to pass the same option multiple times, but
we do not need to do so.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/tools/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile
index 4ff6a2124522..8fb66c99840a 100644
--- a/arch/s390/tools/Makefile
+++ b/arch/s390/tools/Makefile
@@ -14,8 +14,7 @@ kapi: $(kapi-hdrs-y)
 hostprogs-y+= gen_facilities
 hostprogs-y+= gen_opcode_table
 
-HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE)
-HOSTCFLAGS_gen_opcode_table.o += -Wall
+HOSTCFLAGS_gen_facilities.o += $(LINUXINCLUDE)
 
 # Ensure output directory exists
 _dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
-- 
2.17.1



[PATCH 3/4] s390: drop redundant directory creation from tools Makefile

2019-05-17 Thread Masahiro Yamada
As you can see in scripts/Kbuild.include, the filechk creates the
parent directory of the target as needed.

This Makefile does not need to explicitly create the directory.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/tools/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/s390/tools/Makefile b/arch/s390/tools/Makefile
index 8fb66c99840a..4864ea5e6ceb 100644
--- a/arch/s390/tools/Makefile
+++ b/arch/s390/tools/Makefile
@@ -16,9 +16,6 @@ hostprogs-y   += gen_opcode_table
 
 HOSTCFLAGS_gen_facilities.o += $(LINUXINCLUDE)
 
-# Ensure output directory exists
-_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
-
 filechk_facility-defs.h = $(obj)/gen_facilities
 
 filechk_dis-defs.h = \
-- 
2.17.1



Re: [PATCH] memcg: make it work on sparse non-0-node systems

2019-05-17 Thread Vladimir Davydov
On Fri, May 17, 2019 at 06:48:37AM +0200, Jiri Slaby wrote:
> On 16. 05. 19, 15:59, Michal Hocko wrote:
> >> However, I tend to agree with Michal that (ab)using node[0].memcg_lrus
> >> to check if a list_lru is memcg aware looks confusing. I guess we could
> >> simply add a bool flag to list_lru instead. Something like this, may be:
> > 
> > Yes, this makes much more sense to me!
> 
> I am not sure if I should send a patch with this solution or Vladimir
> will (given he is an author and has a diff already)?

I didn't even try to compile it, let alone test it. I'd appreciate if
you could wrap it up and send it out using your authorship. Feel free
to add my acked-by.


Re: [PATCH 4/6] arm64: pmu: Add hook to handle pmu-related undefined instructions

2019-05-17 Thread Mark Rutland
On Fri, May 17, 2019 at 09:10:18AM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2019 at 02:21:46PM +0100, Raphael Gault wrote:
> > In order to prevent the userspace processes which are trying to access
> > the registers from the pmu registers on a big.LITTLE environment we
> > introduce a hook to handle undefined instructions.
> > 
> > The goal here is to prevent the process to be interrupted by a signal
> > when the error is caused by the task being scheduled while accessing
> > a counter, causing the counter access to be invalid. As we are not able
> > to know efficiently the number of counters available physically on both
> > pmu in that context we consider that any faulting access to a counter
> > which is architecturally correct should not cause a SIGILL signal if
> > the permissions are set accordingly.
> 
> The other approach is using rseq for this; with that you can guarantee
> it will never issue the instruction on a wrong CPU.
> 
> That said; emulating the thing isn't horrible either.

Yup. Attempting to use rseq is on the todo list.

> > +   /*
> > +* We put 0 in the target register if we
> > +* are reading from pmu register. If we are
> > +* writing, we do nothing.
> > +*/
> 
> Wait _what_ ?!? userspace can _WRITE_ to these registers?

Remember that this is in an undefined (trap) handler.

If userspace _attempts_ to write to the registers, the CPU will trap to the
kernel. The comment is perhaps misleading; when we "do nothing", the common
trap handling code will send a SIGILL to userspace.

It would probably be better to say something like:

/*
 * If userspace is tries to read a counter that doesn't exist on this
 * CPU, we emulate it as reading as zero. This happens if userspace is
 * preempted between reading the idx and actually reading the counter,
 * and the seqlock and idx have already changed, so it's as-if the
 * counter has been reprogrammed with a different event.
 *
 * We don't permit userspace to write to these registers, and will
 * inject a SIGILL.
 */

There is one caveat: userspace can write to PMSELR without trapping, so we will
have to context-switch with the task. That only affects indirect addressing of
PMU registers, and doesn't have a functional effect on the behaviour of the
PMU, so that's benign from the PoV of perf.

Thanks,
Mark.


Re: [GIT PULL] updates to soc/fsl drivers for v5.2

2019-05-17 Thread Laurentiu Tudor
Hello,

Did this pull request somehow slipped through?

---
Thanks & Best Regards, Laurentiu

On 01.05.2019 23:37, Li Yang wrote:
> Hi arm-soc maintainers,
> 
> Please help to merge for-next patches for the upcoming merge window.  Thanks
> 
> Regards,
> Leo
> 
> 
> The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
> 
>Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
> 
> are available in the Git repository at:
> 
>git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
> tags/soc-fsl-next-v5.2
> 
> for you to fetch changes up to 1c8f39946c033de08e382025d7ac7f55fbca57eb:
> 
>soc: fsl: qbman_portals: add APIs to retrieve the probing status 
> (2019-05-01 15:09:59 -0500)
> 
> 
> NXP/FSL SoC driver updates for v5.2
> 
> DPAA2 Console driver
> - Add driver to export two char devices to dump logs for MC and
>AIOP
> 
> DPAA2 DPIO driver
> - Add support for memory backed QBMan portals
> - Increase the timeout period to prevent false error
> - Add APIs to retrieve QBMan portal probing status
> 
> DPAA Qman driver
> - Only make liodn fixup on powerpc SoCs with PAMU iommu
> 
> Guts driver
> - Add definition for LX2160a SoC
> 
> 
> Ioana Ciornei (2):
>Documentation: DT: Add entry for DPAA2 console
>soc: fsl: add DPAA2 console support
> 
> Laurentiu Tudor (2):
>soc: fsl: qman: fixup liodns only on ppc targets
>soc: fsl: qbman_portals: add APIs to retrieve the probing status
> 
> Roy Pledge (2):
>bus: mc-bus: Add support for mapping shareable portals
>soc: fsl: dpio: Add support for memory backed QBMan portals
> 
> Vabhav Sharma (1):
>soc: fsl: guts: Add definition for LX2160A
> 
> Youri Querry (1):
>soc: fsl: dpio: Increase timeout for QBMan Management Commands
> 
>   .../devicetree/bindings/misc/fsl,dpaa2-console.txt |  11 +
>   MAINTAINERS|   1 +
>   drivers/bus/fsl-mc/dprc.c  |  30 +-
>   drivers/bus/fsl-mc/fsl-mc-bus.c|  15 +-
>   drivers/bus/fsl-mc/fsl-mc-private.h|  17 +-
>   drivers/soc/fsl/Kconfig|  10 +
>   drivers/soc/fsl/Makefile   |   1 +
>   drivers/soc/fsl/dpaa2-console.c| 329 
> +
>   drivers/soc/fsl/dpio/dpio-driver.c |  23 +-
>   drivers/soc/fsl/dpio/qbman-portal.c| 148 +++--
>   drivers/soc/fsl/dpio/qbman-portal.h|   9 +-
>   drivers/soc/fsl/guts.c |   6 +
>   drivers/soc/fsl/qbman/bman_portal.c|  20 +-
>   drivers/soc/fsl/qbman/qman_ccsr.c  |   2 +-
>   drivers/soc/fsl/qbman/qman_portal.c|  21 +-
>   drivers/soc/fsl/qbman/qman_priv.h  |   9 +-
>   include/soc/fsl/bman.h |   8 +
>   include/soc/fsl/qman.h |   9 +
>   18 files changed, 618 insertions(+), 51 deletions(-)
>   create mode 100644 
> Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
>   create mode 100644 drivers/soc/fsl/dpaa2-console.c
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kerneldata=02%7C01%7Claurentiu.tudor%40nxp.com%7Cce3ff1bdc08b445447e408d6ce757dc9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636923401346806528sdata=DXh5Men7Mw1lttFbJskOzdLfSMqClpMr9lu9qJQV5H8%3Dreserved=0
> 

Re: [PATCH 4.4 180/266] x86: stop exporting msr-index.h to userland

2019-05-17 Thread Pavel Machek
Hi!

> commit 25dc1d6cc3082aab293e5dad47623b550f7ddd2a upstream.
> 
> Even if this file was not in an uapi directory, it was exported because
> it was listed in the Kbuild file.
> 

While good idea for mainline, I don't think this belongs to stable.

Dropping it should not result in problems.

Pavel


stable.> +++ b/arch/x86/include/uapi/asm/Kbuild
> @@ -27,7 +27,6 @@ header-y += ldt.h
>  header-y += mce.h
>  header-y += mman.h
>  header-y += msgbuf.h
> -header-y += msr-index.h
>  header-y += msr.h
>  header-y += mtrr.h
>  header-y += param.h
> 

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


signature.asc
Description: Digital signature


Re: [PATCH v3 1/2] mtd: Add flag to indicate panic_write

2019-05-17 Thread Richard Weinberger
On Thu, May 16, 2019 at 6:42 PM Kamal Dasu  wrote:
>
> Added a flag to indicate a panic_write so that low level drivers can
> use it to take required action where applicable, to ensure oops data
> gets written to assigned mtd device.
>
> Signed-off-by: Kamal Dasu 
> ---
>  drivers/mtd/mtdcore.c   | 3 +++
>  include/linux/mtd/mtd.h | 6 ++
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 76b4264..a83decd 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1138,6 +1138,9 @@ int mtd_panic_write(struct mtd_info *mtd, loff_t to, 
> size_t len, size_t *retlen,
> return -EROFS;
> if (!len)
> return 0;
> +   if (!mtd->oops_panic_write)
> +   mtd->oops_panic_write = true;
> +

You can set the flag unconditionally.
If it is set, it will stay so, and setting it again, won't hurt.

> return mtd->_panic_write(mtd, to, len, retlen, buf);
>  }
>  EXPORT_SYMBOL_GPL(mtd_panic_write);
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 677768b..791c34d 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -330,6 +330,12 @@ struct mtd_info {
> int (*_get_device) (struct mtd_info *mtd);
> void (*_put_device) (struct mtd_info *mtd);
>
> +   /*
> +* flag indicates a panic write, low level drivers can take 
> appropriate
> +* action if required to ensure writes go through
> +*/
> +   bool oops_panic_write;
> +

Maybe we find a better name for it.
panic_write_triggered?

-- 
Thanks,
//richard


Re: [PATCH 4.19 012/113] acpi/nfit: Always dump _DSM output payload

2019-05-17 Thread Pavel Machek
On Wed 2019-05-15 12:55:03, Greg Kroah-Hartman wrote:
> [ Upstream commit 351f339faa308c1c1461314a18c832239a841ca0 ]
> 
> The dynamic-debug statements for command payload output only get emitted
> when the command is not ND_CMD_CALL. Move the output payload dumping
> ahead of the early return path for ND_CMD_CALL.

I don't think this fixes problem serious enough for stable.

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


signature.asc
Description: Digital signature


Re: Getting empty callchain from perf_callchain_kernel()

2019-05-17 Thread Peter Zijlstra
On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
> > Hi, 
> > 
> > We found a failure with selftests/bpf/tests_prog in test_stacktrace_map (on 
> > bpf/master
> > branch). 
> > 
> > After digging into the code, we found that perf_callchain_kernel() is 
> > giving empty
> > callchain for tracepoint sched/sched_switch. And it seems related to commit
> > 
> > d15d356887e770c5f2dcf963b52c7cb510c9e42d
> > ("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
> > 
> > Before this commit, perf_callchain_kernel() returns callchain with 
> > regs->ip. With
> > this commit, regs->ip is not sent for !perf_hw_regs(regs) case. 
> 
> So while I think the below is indeed right; we should store regs->ip
> regardless of the unwind path chosen, I still think there's something
> fishy if this results in just the 1 entry.
> 
> The sched/sched_switch event really should have a non-trivial stack.
> 
> Let me see if I can reproduce with just perf.

$ perf record -g -e "sched:sched_switch" -- make clean
$ perf report -D

12 904071759467 0x1790 [0xd0]: PERF_RECORD_SAMPLE(IP, 0x1): 7236/7236: 
0x81c29562 period: 1 addr: 0
... FP chain: nr:10
.  0: ff80
.  1: 81c29562
.  2: 81c29933
.  3: 8111f688
.  4: 81120b9d
.  5: 81120ce5
.  6: 8100254a
.  7: 81e0007d
.  8: fe00
.  9: 7f9b6cd9682a
... thread: sh:7236
.. dso: /lib/modules/5.1.0-12177-g41bbb9129767/build/vmlinux


IOW, it seems to 'work'.



[PATCH] cifs: fix memory leak of pneg_inbuf on -EOPNOTSUPP ioctl case

2019-05-17 Thread Colin King
From: Colin Ian King 

Currently in the case where SMB2_ioctl returns the -EOPNOTSUPP error
there is a memory leak of pneg_inbuf. Fix this by returning via
the out_free_inbuf exit path that will perform the relevant kfree.

Addresses-Coverity: ("Resource leak")
Fixes: 969ae8e8d4ee ("cifs: Accept validate negotiate if server return 
NT_STATUS_NOT_SUPPORTED")
Signed-off-by: Colin Ian King 
---
 fs/cifs/smb2pdu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 710ceb875161..5b8d1482ffbd 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1054,7 +1054,8 @@ int smb3_validate_negotiate(const unsigned int xid, 
struct cifs_tcon *tcon)
 * not supported error. Client should accept it.
 */
cifs_dbg(VFS, "Server does not support validate negotiate\n");
-   return 0;
+   rc = 0;
+   goto out_free_inbuf;
} else if (rc != 0) {
cifs_dbg(VFS, "validate protocol negotiate failed: %d\n", rc);
rc = -EIO;
-- 
2.20.1



Re: [PATCH v3 2/2] mtd: nand: raw: brcmnand: When oops in progress use pio and interrupt polling

2019-05-17 Thread Richard Weinberger
On Thu, May 16, 2019 at 6:42 PM Kamal Dasu  wrote:
>
> If mtd_oops is in progress, switch to polling during NAND command
> completion instead of relying on DMA/interrupts so that the mtd_oops
> buffer can be completely written in the assigned NAND partition.

With the new flag the semantics change, as soon a panic write happened,
the flag will stay and *all* future operates will take the polling/pio path.

IMHO this is fine since the kernel cannot recover from an oops.
But just to make sure we all get this. :-)
An alternative would be to block all further non-panic writes.

-- 
Thanks,
//richard


Re: Getting empty callchain from perf_callchain_kernel()

2019-05-17 Thread Kairui Song
On Fri, May 17, 2019 at 4:11 PM Peter Zijlstra  wrote:
>
> On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
> > On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
> > > Hi,
> > >
> > > We found a failure with selftests/bpf/tests_prog in test_stacktrace_map 
> > > (on bpf/master
> > > branch).
> > >
> > > After digging into the code, we found that perf_callchain_kernel() is 
> > > giving empty
> > > callchain for tracepoint sched/sched_switch. And it seems related to 
> > > commit
> > >
> > > d15d356887e770c5f2dcf963b52c7cb510c9e42d
> > > ("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
> > >
> > > Before this commit, perf_callchain_kernel() returns callchain with 
> > > regs->ip. With
> > > this commit, regs->ip is not sent for !perf_hw_regs(regs) case.
> >
> > So while I think the below is indeed right; we should store regs->ip
> > regardless of the unwind path chosen, I still think there's something
> > fishy if this results in just the 1 entry.
> >
> > The sched/sched_switch event really should have a non-trivial stack.
> >
> > Let me see if I can reproduce with just perf.
>
> $ perf record -g -e "sched:sched_switch" -- make clean
> $ perf report -D
>
> 12 904071759467 0x1790 [0xd0]: PERF_RECORD_SAMPLE(IP, 0x1): 7236/7236: 
> 0x81c29562 period: 1 addr: 0
> ... FP chain: nr:10
> .  0: ff80
> .  1: 81c29562
> .  2: 81c29933
> .  3: 8111f688
> .  4: 81120b9d
> .  5: 81120ce5
> .  6: 8100254a
> .  7: 81e0007d
> .  8: fe00
> .  9: 7f9b6cd9682a
> ... thread: sh:7236
> .. dso: /lib/modules/5.1.0-12177-g41bbb9129767/build/vmlinux
>
>
> IOW, it seems to 'work'.
>

Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
some other bfp functions) is now broken, or, strating an unwind
directly inside a bpf program will end up strangely. It have following
kernel message:

WARNING: kernel stack frame pointer at 70cad07c in
test_progs:1242 has bad value ffd4497e

And in the debug message:

[  160.460287] 6e117175: aa23a0e8
(get_perf_callchain+0x148/0x280)
[  160.460287] 02e8715f: 00c6bba0 (0xc6bba0)
[  160.460288] b3d07758: 9ce3f979 (0x9ce3f979)
[  160.460289] 55c97836: 9ce3f979 (0x9ce3f979)
[  160.460289] 7cbb140a: 0001007f (0x1007f)
[  160.460290] 7dc62ac9:  ...
[  160.460290] 6b41e346: 1c7da01cd70c4000 (0x1c7da01cd70c4000)
[  160.460291] f23d1826: d89cffc3ae80 (0xd89cffc3ae80)
[  160.460292] f9a16017: 007f (0x7f)
[  160.460292] a8e62d44:  ...
[  160.460293] cbc83c97: b89d00d8d000 (0xb89d00d8d000)
[  160.460293] 92842522: 007f (0x7f)
[  160.460294] dafbec89: b89d00c6bc50 (0xb89d00c6bc50)
[  160.460296] 0777e4cf: aa225d97 (bpf_get_stackid+0x77/0x470)
[  160.460296] 9942ea16:  ...
[  160.460297] a08006b1: 0001 (0x1)
[  160.460298] 9f03b438: b89d00c6bc30 (0xb89d00c6bc30)
[  160.460299] 6caf8b32: aa074fe8 (__do_page_fault+0x58/0x90)
[  160.460300] 3a13d702:  ...
[  160.460300] e2e2496d: 9ce3 (0x9ce3)
[  160.460301] 8ee6b7c2: d89cffc3ae80 (0xd89cffc3ae80)
[  160.460301] a8cf6d55:  ...
[  160.460302] 59078076: d89cffc3ae80 (0xd89cffc3ae80)
[  160.460303] c6aac739: 9ce3f1e18eb0 (0x9ce3f1e18eb0)
[  160.460303] a39aff92: b89d00c6bc60 (0xb89d00c6bc60)
[  160.460305] 97498bf2: aa1f4791 (bpf_get_stackid_tp+0x11/0x20)
[  160.460306] 6992de1e: b89d00c6bc78 (0xb89d00c6bc78)
[  160.460307] dacd0ce5: c0405676 (0xc0405676)
[  160.460307] a81f2714:  ...

# Note here is the invalid frame pointer
[  160.460308] 70cad07c: b89d00a1d000 (0xb89d00a1d000)
[  160.460308] f8f194e4: 0001 (0x1)
[  160.460309] 2134f42a: d89cffc3ae80 (0xd89cffc3ae80)
[  160.460310] f9345889: 9ce3f1e18eb0 (0x9ce3f1e18eb0)
[  160.460310] 8ad22a42:  ...
[  160.460311] 73808173: b89d00c6bce0 (0xb89d00c6bce0)
[  160.460312] c9e4: aa1f48d1 (trace_call_bpf+0x81/0x100)
[  160.460313] c5d8ebd1: b89d00c6bcc0 (0xb89d00c6bcc0)
[  160.460315] bce0b072: ab651be0
(event_sched_migrate_task+0xa0/0xa0)
[  160.460316] 355cf319:  ...
[  160.460316] 3b67f2ad: d89cffc3ae80 (0xd89cffc3ae80)
[  160.460316] 9a77e20b: 9ce3fba25000 (0x9ce3fba25000)
[  160.460317] 32cf7376: 0001 (0x1)
[  160.460317] 

Re: [PATCH 4.19 042/113] ocelot: Dont sleep in atomic context (irqs_disabled())

2019-05-17 Thread Pavel Machek
On Wed 2019-05-15 12:55:33, Greg Kroah-Hartman wrote:
> [ Upstream commit a8fd48b50deaa20808bbf0f6685f6f1acba6a64c ]
> 
> Preemption disabled at:
>  [] dev_set_rx_mode+0x1c/0x38
>  Call trace:
>  [] dump_backtrace+0x0/0x3d0
>  [] show_stack+0x14/0x20
>  [] dump_stack+0xac/0xe4
>  [] ___might_sleep+0x164/0x238
>  [] __might_sleep+0x50/0x88
>  [] kmem_cache_alloc+0x17c/0x1d0
>  [] ocelot_set_rx_mode+0x108/0x188 [mscc_ocelot_common]
>  [] __dev_set_rx_mode+0x58/0xa0
>  [] dev_set_rx_mode+0x24/0x38
> 
> Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")

Is it right fix? Warning is gone, but now allocation is more likely to
fail, causing mc_add() to fail under memory pressure.

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


signature.asc
Description: Digital signature


Re: [PATCH] memcg: make it work on sparse non-0-node systems

2019-05-17 Thread Jiri Slaby
On 17. 05. 19, 10:00, Vladimir Davydov wrote:
> On Fri, May 17, 2019 at 06:48:37AM +0200, Jiri Slaby wrote:
>> On 16. 05. 19, 15:59, Michal Hocko wrote:
 However, I tend to agree with Michal that (ab)using node[0].memcg_lrus
 to check if a list_lru is memcg aware looks confusing. I guess we could
 simply add a bool flag to list_lru instead. Something like this, may be:
>>>
>>> Yes, this makes much more sense to me!
>>
>> I am not sure if I should send a patch with this solution or Vladimir
>> will (given he is an author and has a diff already)?
> 
> I didn't even try to compile it, let alone test it. I'd appreciate if
> you could wrap it up and send it out using your authorship. Feel free
> to add my acked-by.

OK, NP.

thanks,
-- 
js
suse labs


Re: [PATCH v2] kbuild: check uniqueness of module names

2019-05-17 Thread Alexander Kapshuk
On Fri, May 17, 2019 at 8:33 AM Masahiro Yamada
 wrote:
>
> In the recent build test of linux-next, Stephen saw a build error
> caused by a broken .tmp_versions/*.mod file:
>
>   https://lkml.org/lkml/2019/5/13/991
>
> drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
> basename, and there is a race in generating .tmp_versions/asix.mod
>
> Kbuild has not checked this before, and it suddenly shows up with
> obscure error message when this kind of race occurs.
>
> Non-unique module names cause various sort of problems, but it is
> not trivial to catch them by eyes.
>
> Hence, this script.
>
> It checks not only real modules, but also built-in modules (i.e.
> controlled by tristate CONFIG option, but currently compiled with =y).
> Non-unique names for built-in modules also cause problems because
> /sys/modules/ would fall over.
>
> I tested allmodconfig on the latest kernel, and it detected the
> following:
>
> warning: same basename if the following are built as modules:
>   drivers/regulator/88pm800.ko
>   drivers/mfd/88pm800.ko
> warning: same basename if the following are built as modules:
>   drivers/gpu/drm/bridge/adv7511/adv7511.ko
>   drivers/media/i2c/adv7511.ko
> warning: same basename if the following are built as modules:
>   drivers/net/phy/asix.ko
>   drivers/net/usb/asix.ko
> warning: same basename if the following are built as modules:
>   fs/coda/coda.ko
>   drivers/media/platform/coda/coda.ko
> warning: same basename if the following are built as modules:
>   drivers/net/phy/realtek.ko
>   drivers/net/dsa/realtek.ko
>
> Reported-by: Stephen Rothwell 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Kees Cook 
> ---
>
> Changes in v2:
>  - redirect messages to stderr
>  - use '--' after 'basename -a'
>  - use '-r' for xargs to cope with empty modules.order/modules.builtin
>
>  Makefile |  1 +
>  scripts/modules-check.sh | 20 
>  2 files changed, 21 insertions(+)
>  create mode 100755 scripts/modules-check.sh
>
> diff --git a/Makefile b/Makefile
> index a61a95b6b38f..30792fec7a12 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1290,6 +1290,7 @@ modules: $(vmlinux-dirs) $(if 
> $(KBUILD_BUILTIN),vmlinux) modules.builtin
> $(Q)$(AWK) '!x[$$0]++' $(vmlinux-dirs:%=$(objtree)/%/modules.order) > 
> $(objtree)/modules.order
> @$(kecho) '  Building modules, stage 2.';
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
> +   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh
>
>  modules.builtin: $(vmlinux-dirs:%=%/modules.builtin)
> $(Q)$(AWK) '!x[$$0]++' $^ > $(objtree)/modules.builtin
> diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
> new file mode 100755
> index ..c875f6eab01e
> --- /dev/null
> +++ b/scripts/modules-check.sh
> @@ -0,0 +1,20 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +set -e
> +
> +# Check uniqueness of module names
> +check_same_name_modules()
> +{
> +   same_name_modules=$(cat modules.order modules.builtin | \
> +   xargs -r basename -a -- | sort | uniq -d)
> +
> +   for m in $same_name_modules
> +   do
> +   echo "warning: same basename if the following are built as 
> modules:" >&2
> +   grep -h -e "/$m" modules.order modules.builtin | \
> +   sed 's:^kernel/:  :' >&2
> +   done
> +}
> +
> +check_same_name_modules
> --
> 2.17.1
>

The 'xargs' '-r' flag is a GNU extension.
If POSIX compliance is important here, the use of 'cat', 'xargs' and
'basename' may be substituted with that of 'sed' to initialise
same_name_modules:
sed 's!.*/!!' modules.order modules.builtin | sort | uniq -d

'Sed' may also be used on its own in the 'for' loop instead of as part
of a pipeline along with 'grep' to generate the desired output:
sed '/\/'$m'/!d;s:^kernel/:  :' modules.order modules.builtin

Just a suggestion.


Re: [PATCH 4.4 000/266] 4.4.180-stable review

2019-05-17 Thread Jon Hunter


On 17/05/2019 08:44, Daniel Wagner wrote:
> Hi Greg,
> 
> On 16.05.19 18:49, Greg Kroah-Hartman wrote:
>> Jon, thanks for the testing, I'll go drop this patch now from the final
>> version.
> 
> That's fine, I wanted to suggest this too. I have some time to look at
> this next week. So there is no hurry with this patch.
> 
>> Daniel, if you can come up with a working series, I'll be glad to take
>> it.  Or, I'd recommend you just move to a newer kernel :)
> 
> Sure, I will see what is missing.
> 
> @Jon if I get have something to test, would you have time to give it a
> try first?

Yes no problem.

Cheers
Jon

-- 
nvpublic


Re: [PATCH 4/4] vfio: vfio_iommu_type1: implement VFIO_IOMMU_INFO_CAPABILITIES

2019-05-17 Thread Pierre Morel

On 16/05/2019 20:40, Alex Williamson wrote:

On Fri, 10 May 2019 10:22:35 +0200
Pierre Morel  wrote:


We implement a capability intercafe for VFIO_IOMMU_GET_INFO and add the
first capability: VFIO_IOMMU_INFO_CAPABILITIES.

When calling the ioctl, the user must specify
VFIO_IOMMU_INFO_CAPABILITIES to retrieve the capabilities and must check
in the answer if capabilities are supported.
Older kernel will not check nor set the VFIO_IOMMU_INFO_CAPABILITIES in
the flags of vfio_iommu_type1_info.

The iommu get_attr callback will be called to retrieve the specific
attributes and fill the capabilities, VFIO_IOMMU_INFO_CAP_QFN for the
PCI query function attributes and VFIO_IOMMU_INFO_CAP_QGRP for the
PCI query function group.

Signed-off-by: Pierre Morel 
---
  drivers/vfio/vfio_iommu_type1.c | 95 -
  1 file changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index d0f731c..f7f8120 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1658,6 +1658,70 @@ static int vfio_domains_have_iommu_cache(struct 
vfio_iommu *iommu)
return ret;
  }
  
+int vfio_iommu_type1_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps,

+ size_t size)
+{
+   struct vfio_domain *d;
+   struct vfio_iommu_type1_info_block *info_fn;
+   struct vfio_iommu_type1_info_block *info_grp;
+   unsigned long total_size, fn_size, grp_size;
+   int ret;
+
+   d = list_first_entry(>domain_list, struct vfio_domain, next);
+   if (!d)
+   return -ENODEV;
+   /* The size of these capabilities are device dependent */
+   fn_size = iommu_domain_get_attr(d->domain,
+   DOMAIN_ATTR_ZPCI_FN_SIZE, NULL);
+   if (fn_size < 0)
+   return fn_size;


What if non-Z archs want to use this?  The function is architected
specifically for this one use case, fail if any component is not there
which means it requires a re-write to add further support.  If
ZPCI_FN_SIZE isn't support, move on to the next thing.


yes, clear.




+   fn_size +=  sizeof(struct vfio_info_cap_header);
+   total_size = fn_size;


Here too, total_size should be initialized to zero and each section +=
the size they'd like to add.


thanks, clear too.




+
+   grp_size = iommu_domain_get_attr(d->domain,
+DOMAIN_ATTR_ZPCI_GRP_SIZE, NULL);
+   if (grp_size < 0)
+   return grp_size;
+   grp_size +=  sizeof(struct vfio_info_cap_header);
+   total_size += grp_size;
+
+   /* Tell caller to call us with a greater buffer */
+   if (total_size > size) {
+   caps->size = total_size;
+   return 0;
+   }
+
+   info_fn = kzalloc(fn_size, GFP_KERNEL);
+   if (!info_fn)
+   return -ENOMEM;


Maybe fn_size was zero because we're not on Z.


+   ret = iommu_domain_get_attr(d->domain,
+   DOMAIN_ATTR_ZPCI_FN, _fn->data);


Kernel internal structures != user api.  Thanks,

Alex


Thanks a lot Alex,
I understand the concerns, I was too focussed on Z, I will rework this 
as you said:

- definition of the user API and
- take care that another architecture may want to use the interface.

Regards,
Pierre



--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany



Re: [PATCH V6 02/15] PCI/PME: Export pcie_pme_disable_msi() & pcie_pme_no_msi() APIs

2019-05-17 Thread Vidya Sagar

On 5/16/2019 7:04 PM, Bjorn Helgaas wrote:

On Tue, May 14, 2019 at 09:00:19AM +0530, Vidya Sagar wrote:

On 5/13/2019 12:55 PM, Christoph Hellwig wrote:

On Mon, May 13, 2019 at 10:36:13AM +0530, Vidya Sagar wrote:

Export pcie_pme_disable_msi() & pcie_pme_no_msi() APIs to enable drivers
using these APIs be able to build as loadable modules.


But this is a global setting.  If you root port is broken you need
a per-rootport quirk instead.


There is nothing broken in Tegra194 root port as such, rather, this
is more of software configuration choice and we are going with
legacy interrupts than MSI interrupts (as Tegra194 doesn't support
raising PME interrupts through MSI and please note that this doesn't
mean root port is broken).


I think the port *is* broken.  PCIe r4.0, sec 6.1.6, says

   If the Root Port is enabled for edge-triggered interrupt signaling
   using MSI or MSI-X, an interrupt message must be sent every time the
   logical AND of the following conditions transitions from FALSE to
   TRUE:

 * The associated vector is unmasked (not applicable if MSI does
   not support PVM).

 * The PME Interrupt Enable bit in the Root Control register is set
   to 1b.

 * The PME Status bit in the Root Status register is set.

The Tegra194 root port advertises MSI support, so the above should
apply.

I had a discussion with our hardware engineers and we are of the opinion
that the root port is not really broken w.r.t MSI as spec doesn't clearly
say that if root port advertises MSI support, it must generate MSI interrupts
for PME. All that it says is, if MSI is enabled, then MSI should be raised
for PME events. Here, by 'enable', we understand that as enabling at
hardware level to generate MSI interrupt which is not the case with Tegra194.
In Tegra194, root port is enabled to generate MSI only for hot-plug events and
legacy interrupts are used for PME, AER. Having said that I'm fine to add a
quick based on Vendor-ID and Device-IDs of root port in Tegra194 to set
pdev->no_msi to '1'.




Since Tegra194 has only Synopsys DesignWare core based host
controllers and not any other hosts, I think it is fine to call this
API in driver.


It's fine to add a per-device quirk to set pdev->no_msi or something
similar.

Bjorn





Re: [PATCH v2] configfs: Fix use-after-free when accessing sd->s_dentry

2019-05-17 Thread Christoph Hellwig
On Thu, May 16, 2019 at 06:27:53PM +0530, stumm...@codeaurora.org wrote:
> Hi Christoph, Al,
>
> Can you please consider this patch for merging?

I've been sitting on this for a while, mostly because I can't convince
myself it is safe.  What protects other threads from using ->s_dentry
just when we clear it?  Also why would sd->s_dentry == dentry ever be
false?


Re: [PATCH 4/6] arm64: pmu: Add hook to handle pmu-related undefined instructions

2019-05-17 Thread Peter Zijlstra
On Fri, May 17, 2019 at 09:04:20AM +0100, Mark Rutland wrote:

> Remember that this is in an undefined (trap) handler.
> 
> If userspace _attempts_ to write to the registers, the CPU will trap to the
> kernel. The comment is perhaps misleading; when we "do nothing", the common
> trap handling code will send a SIGILL to userspace.
> 
> It would probably be better to say something like:
> 
>   /*
>* If userspace is tries to read a counter that doesn't exist on this
>* CPU, we emulate it as reading as zero. This happens if userspace is
>* preempted between reading the idx and actually reading the counter,
>* and the seqlock and idx have already changed, so it's as-if the
>* counter has been reprogrammed with a different event.

Might be good to mention that userspace will/should discard the value it
reads, and therefore any value is good (including 0).

>* We don't permit userspace to write to these registers, and will
>* inject a SIGILL.
>*/
> 
> There is one caveat: userspace can write to PMSELR without trapping, so we 
> will
> have to context-switch with the task. That only affects indirect addressing of
> PMU registers, and doesn't have a functional effect on the behaviour of the
> PMU, so that's benign from the PoV of perf.

Sad though; ideally you'd state that indirect addressing is
out-of-bounds and they get to keep the pieces. But I suspect you're
right that people will do it anyway and complain once it comes apart.


Re: [PATCH v2 2/8] vsock/virtio: free packets during the socket release

2019-05-17 Thread Stefano Garzarella
On Thu, May 16, 2019 at 04:32:18PM +0100, Stefan Hajnoczi wrote:
> On Fri, May 10, 2019 at 02:58:37PM +0200, Stefano Garzarella wrote:
> > When the socket is released, we should free all packets
> > queued in the per-socket list in order to avoid a memory
> > leak.
> > 
> > Signed-off-by: Stefano Garzarella 
> > ---
> >  net/vmw_vsock/virtio_transport_common.c | 8 
> >  1 file changed, 8 insertions(+)
> 
> Ouch, this would be nice as a separate patch that can be merged right
> away (with s/virtio_vsock_buf/virtio_vsock_pkt/).

Okay, I'll fix this patch following the David's comment and I'll send
as a separate patch using the virtio_vsock_pkt.

Thanks,
Stefano


[PATCH] efi_64: Fix a missing-check bug in arch/x86/platform/efi/efi_64.c of Linux 5.1

2019-05-17 Thread Gen Zhang
save_pgd is allocated by kmalloc_array. And it is dereferenced in the
following codes. However, memory allocation functions such as
kmalloc_array may fail. Dereferencing this save_pgd null pointer may 
cause the kernel go wrong. Thus we should check this allocation and add
error handling code.

Signed-off-by: Gen Zhang 

---
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index cf0347f..fb9ae57 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -91,6 +91,8 @@ pgd_t * __init efi_call_phys_prolog(void)
 
n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
save_pgd = kmalloc_array(n_pgds, sizeof(*save_pgd), GFP_KERNEL);
+   if (!save_pgd)
+   goto err;
 
/*
 * Build 1:1 identity mapping for efi=old_map usage. Note that
@@ -142,6 +144,9 @@ pgd_t * __init efi_call_phys_prolog(void)
__flush_tlb_all();
 
return save_pgd;
+err:
+   __flush_tlb_all();
+   return ERR_PTR(-ENOMEM);
 }
 
 void __init efi_call_phys_epilog(pgd_t *save_pgd)
---


Re: [PATCH] jbd2: fix some print format mistakes

2019-05-17 Thread Jan Kara
On Fri 17-05-19 14:19:51, Gaowei Pu wrote:
> There are some print format mistakes in debug messages. Fix them.
> 
> Signed-off-by: Gaowei Pu 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/jbd2/journal.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 37e16d969925..565e99b67b30 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -203,7 +203,7 @@ static int kjournald2(void *arg)
>   if (journal->j_flags & JBD2_UNMOUNT)
>   goto end_loop;
>  
> - jbd_debug(1, "commit_sequence=%d, commit_request=%d\n",
> + jbd_debug(1, "commit_sequence=%u, commit_request=%u\n",
>   journal->j_commit_sequence, journal->j_commit_request);
>  
>   if (journal->j_commit_sequence != journal->j_commit_request) {
> @@ -324,7 +324,7 @@ static void journal_kill_thread(journal_t *journal)
>   * IO is in progress. do_get_write_access() handles this.
>   *
>   * The function returns a pointer to the buffer_head to be used for IO.
> - * 
> + *
>   *
>   * Return value:
>   *  <0: Error
> @@ -500,7 +500,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
> target)
>*/
>  
>   journal->j_commit_request = target;
> - jbd_debug(1, "JBD2: requesting commit %d/%d\n",
> + jbd_debug(1, "JBD2: requesting commit %u/%u\n",
> journal->j_commit_request,
> journal->j_commit_sequence);
>   journal->j_running_transaction->t_requested = jiffies;
> @@ -513,7 +513,7 @@ int __jbd2_log_start_commit(journal_t *journal, tid_t 
> target)
>   WARN_ONCE(1, "JBD2: bad log_start_commit: %u %u %u %u\n",
> journal->j_commit_request,
> journal->j_commit_sequence,
> -   target, journal->j_running_transaction ? 
> +   target, journal->j_running_transaction ?
> journal->j_running_transaction->t_tid : 0);
>   return 0;
>  }
> @@ -698,12 +698,12 @@ int jbd2_log_wait_commit(journal_t *journal, tid_t tid)
>  #ifdef CONFIG_JBD2_DEBUG
>   if (!tid_geq(journal->j_commit_request, tid)) {
>   printk(KERN_ERR
> -"%s: error: j_commit_request=%d, tid=%d\n",
> +"%s: error: j_commit_request=%u, tid=%u\n",
>  __func__, journal->j_commit_request, tid);
>   }
>  #endif
>   while (tid_gt(tid, journal->j_commit_sequence)) {
> - jbd_debug(1, "JBD2: want %d, j_commit_sequence=%d\n",
> + jbd_debug(1, "JBD2: want %u, j_commit_sequence=%u\n",
> tid, journal->j_commit_sequence);
>   read_unlock(>j_state_lock);
>   wake_up(>j_wait_commit);
> @@ -944,7 +944,7 @@ int __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
> unsigned long block)
>  
>   trace_jbd2_update_log_tail(journal, tid, block, freed);
>   jbd_debug(1,
> -   "Cleaning journal tail from %d to %d (offset %lu), "
> +   "Cleaning journal tail from %u to %u (offset %lu), "
> "freeing %lu\n",
> journal->j_tail_sequence, tid, block, freed);
>  
> @@ -1318,7 +1318,7 @@ static int journal_reset(journal_t *journal)
>*/
>   if (sb->s_start == 0) {
>   jbd_debug(1, "JBD2: Skipping superblock update on recovered sb "
> - "(start %ld, seq %d, errno %d)\n",
> + "(start %ld, seq %u, errno %d)\n",
>   journal->j_tail, journal->j_tail_sequence,
>   journal->j_errno);
>   journal->j_flags |= JBD2_FLUSHED;
> @@ -1453,7 +1453,7 @@ static void jbd2_mark_journal_empty(journal_t *journal, 
> int write_op)
>   return;
>   }
>  
> - jbd_debug(1, "JBD2: Marking journal as empty (seq %d)\n",
> + jbd_debug(1, "JBD2: Marking journal as empty (seq %u)\n",
> journal->j_tail_sequence);
>  
>   sb->s_sequence = cpu_to_be32(journal->j_tail_sequence);
> -- 
> 2.21.0
> 
> 
-- 
Jan Kara 
SUSE Labs, CR


Re: Getting empty callchain from perf_callchain_kernel()

2019-05-17 Thread Kairui Song
On Fri, May 17, 2019 at 4:15 PM Kairui Song  wrote:
>
> On Fri, May 17, 2019 at 4:11 PM Peter Zijlstra  wrote:
> >
> > On Fri, May 17, 2019 at 09:46:00AM +0200, Peter Zijlstra wrote:
> > > On Thu, May 16, 2019 at 11:51:55PM +, Song Liu wrote:
> > > > Hi,
> > > >
> > > > We found a failure with selftests/bpf/tests_prog in test_stacktrace_map 
> > > > (on bpf/master
> > > > branch).
> > > >
> > > > After digging into the code, we found that perf_callchain_kernel() is 
> > > > giving empty
> > > > callchain for tracepoint sched/sched_switch. And it seems related to 
> > > > commit
> > > >
> > > > d15d356887e770c5f2dcf963b52c7cb510c9e42d
> > > > ("perf/x86: Make perf callchains work without CONFIG_FRAME_POINTER")
> > > >
> > > > Before this commit, perf_callchain_kernel() returns callchain with 
> > > > regs->ip. With
> > > > this commit, regs->ip is not sent for !perf_hw_regs(regs) case.
> > >
> > > So while I think the below is indeed right; we should store regs->ip
> > > regardless of the unwind path chosen, I still think there's something
> > > fishy if this results in just the 1 entry.
> > >
> > > The sched/sched_switch event really should have a non-trivial stack.
> > >
> > > Let me see if I can reproduce with just perf.
> >
> > $ perf record -g -e "sched:sched_switch" -- make clean
> > $ perf report -D
> >
> > 12 904071759467 0x1790 [0xd0]: PERF_RECORD_SAMPLE(IP, 0x1): 7236/7236: 
> > 0x81c29562 period: 1 addr: 0
> > ... FP chain: nr:10
> > .  0: ff80
> > .  1: 81c29562
> > .  2: 81c29933
> > .  3: 8111f688
> > .  4: 81120b9d
> > .  5: 81120ce5
> > .  6: 8100254a
> > .  7: 81e0007d
> > .  8: fe00
> > .  9: 7f9b6cd9682a
> > ... thread: sh:7236
> > .. dso: /lib/modules/5.1.0-12177-g41bbb9129767/build/vmlinux
> >
> >
> > IOW, it seems to 'work'.
> >
>
> Hi, I think the actual problem is that bpf_get_stackid_tp (and maybe
> some other bfp functions) is now broken, or, strating an unwind
> directly inside a bpf program will end up strangely. It have following
> kernel message:
>
> WARNING: kernel stack frame pointer at 70cad07c in
> test_progs:1242 has bad value ffd4497e
>
> And in the debug message:
>
> [  160.460287] 6e117175: aa23a0e8
> (get_perf_callchain+0x148/0x280)
> [  160.460287] 02e8715f: 00c6bba0 (0xc6bba0)
> [  160.460288] b3d07758: 9ce3f979 (0x9ce3f979)
> [  160.460289] 55c97836: 9ce3f979 (0x9ce3f979)
> [  160.460289] 7cbb140a: 0001007f (0x1007f)
> [  160.460290] 7dc62ac9:  ...
> [  160.460290] 6b41e346: 1c7da01cd70c4000 (0x1c7da01cd70c4000)
> [  160.460291] f23d1826: d89cffc3ae80 (0xd89cffc3ae80)
> [  160.460292] f9a16017: 007f (0x7f)
> [  160.460292] a8e62d44:  ...
> [  160.460293] cbc83c97: b89d00d8d000 (0xb89d00d8d000)
> [  160.460293] 92842522: 007f (0x7f)
> [  160.460294] dafbec89: b89d00c6bc50 (0xb89d00c6bc50)
> [  160.460296] 0777e4cf: aa225d97 (bpf_get_stackid+0x77/0x470)
> [  160.460296] 9942ea16:  ...
> [  160.460297] a08006b1: 0001 (0x1)
> [  160.460298] 9f03b438: b89d00c6bc30 (0xb89d00c6bc30)
> [  160.460299] 6caf8b32: aa074fe8 (__do_page_fault+0x58/0x90)
> [  160.460300] 3a13d702:  ...
> [  160.460300] e2e2496d: 9ce3 (0x9ce3)
> [  160.460301] 8ee6b7c2: d89cffc3ae80 (0xd89cffc3ae80)
> [  160.460301] a8cf6d55:  ...
> [  160.460302] 59078076: d89cffc3ae80 (0xd89cffc3ae80)
> [  160.460303] c6aac739: 9ce3f1e18eb0 (0x9ce3f1e18eb0)
> [  160.460303] a39aff92: b89d00c6bc60 (0xb89d00c6bc60)
> [  160.460305] 97498bf2: aa1f4791 
> (bpf_get_stackid_tp+0x11/0x20)
> [  160.460306] 6992de1e: b89d00c6bc78 (0xb89d00c6bc78)
> [  160.460307] dacd0ce5: c0405676 (0xc0405676)
> [  160.460307] a81f2714:  ...
>
> # Note here is the invalid frame pointer
> [  160.460308] 70cad07c: b89d00a1d000 (0xb89d00a1d000)
> [  160.460308] f8f194e4: 0001 (0x1)
> [  160.460309] 2134f42a: d89cffc3ae80 (0xd89cffc3ae80)
> [  160.460310] f9345889: 9ce3f1e18eb0 (0x9ce3f1e18eb0)
> [  160.460310] 8ad22a42:  ...
> [  160.460311] 73808173: b89d00c6bce0 (0xb89d00c6bce0)
> [  160.460312] c9e4: aa1f48d1 (trace_call_bpf+0x81/0x100)
> [  160.460313] c5d8ebd1: b89d00c6bcc0 (0xb89d00c6bcc0)
> [  160.460315] bce0b072: ab651be0
> (event_sched_migrate_task+0xa0/0xa0)
> [  

[GIT PULL] nds32 patches for 5.2-rc1

2019-05-17 Thread Greentime Hu
Hi Linus,

The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:

  Linux 5.1 (2019-05-05 17:42:58 -0700)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git
tags/nds32-for-linus-5.2-rc1

for you to fetch changes up to af9abd65983cf3602c03ef3d16fe549ba1f3eeed:

  nds32: Fix vDSO clock_getres() (2019-05-16 15:07:08 +0800)


nds32 patches for 5.2-rc1

Here is the nds32 patchset based on 5.1
Contained in here are
1. Clean up codes and Makefile
2. Fix a vDSO bug
3. Remove useless functions/header files
4. Update git repo path in MAINTAINERS


Christoph Hellwig (2):
  nds32: remove __virt_to_bus and __bus_to_virt
  nds32: don't export low-level cache flushing routines

Enrico Weigelt, metux IT consult (1):
  arch: nds32: Kconfig: pedantic formatting

Greentime Hu (1):
  MAINTAINERS: update nds32 git repo path

Julien Grall (1):
  nds32: Removed unused thread flag TIF_USEDFPU

Masahiro Yamada (3):
  nds32: add vmlinux.lds and vdso.so to .gitignore
  nds32: vdso: fix and clean-up Makefile
  nds32: remove unused generic-y += cmpxchg-local.h

Nick Desaulniers (1):
  nds32: vdso: drop unnecessary cc-ldoption

Nishad Kamdar (1):
  nds32: Use the correct style for SPDX License Identifier

Valentin Schneider (1):
  nds32: ex-exit: Remove unneeded need_resched() loop

Vincenzo Frascino (1):
  nds32: Fix vDSO clock_getres()

Will Deacon (1):
  nds32/io: Remove useless definition of mmiowb()

Yang Wei (1):
  nds32: fix semicolon code style issue

 MAINTAINERS  |  2 +-
 arch/nds32/Kconfig   | 16 
 arch/nds32/include/asm/Kbuild|  1 -
 arch/nds32/include/asm/assembler.h   |  2 +-
 arch/nds32/include/asm/barrier.h |  2 +-
 arch/nds32/include/asm/bitfield.h|  2 +-
 arch/nds32/include/asm/cache.h   |  2 +-
 arch/nds32/include/asm/cache_info.h  |  2 +-
 arch/nds32/include/asm/cacheflush.h  |  2 +-
 arch/nds32/include/asm/current.h |  2 +-
 arch/nds32/include/asm/delay.h   |  2 +-
 arch/nds32/include/asm/elf.h |  2 +-
 arch/nds32/include/asm/fixmap.h  |  2 +-
 arch/nds32/include/asm/futex.h   |  2 +-
 arch/nds32/include/asm/highmem.h |  2 +-
 arch/nds32/include/asm/io.h  |  4 +---
 arch/nds32/include/asm/irqflags.h|  2 +-
 arch/nds32/include/asm/l2_cache.h|  2 +-
 arch/nds32/include/asm/linkage.h |  2 +-
 arch/nds32/include/asm/memory.h  | 10 +-
 arch/nds32/include/asm/mmu.h |  2 +-
 arch/nds32/include/asm/mmu_context.h |  2 +-
 arch/nds32/include/asm/module.h  |  2 +-
 arch/nds32/include/asm/nds32.h   |  2 +-
 arch/nds32/include/asm/page.h|  2 +-
 arch/nds32/include/asm/pgalloc.h |  2 +-
 arch/nds32/include/asm/pgtable.h |  2 +-
 arch/nds32/include/asm/proc-fns.h|  2 +-
 arch/nds32/include/asm/processor.h   |  2 +-
 arch/nds32/include/asm/ptrace.h  |  2 +-
 arch/nds32/include/asm/shmparam.h|  2 +-
 arch/nds32/include/asm/string.h  |  2 +-
 arch/nds32/include/asm/swab.h|  2 +-
 arch/nds32/include/asm/syscall.h |  2 +-
 arch/nds32/include/asm/syscalls.h|  2 +-
 arch/nds32/include/asm/thread_info.h |  4 +---
 arch/nds32/include/asm/tlb.h |  2 +-
 arch/nds32/include/asm/tlbflush.h|  2 +-
 arch/nds32/include/asm/uaccess.h |  2 +-
 arch/nds32/include/asm/unistd.h  |  2 +-
 arch/nds32/include/asm/vdso.h|  2 +-
 arch/nds32/include/asm/vdso_datapage.h   |  3 ++-
 arch/nds32/include/asm/vdso_timer_info.h |  2 +-
 arch/nds32/include/uapi/asm/auxvec.h |  2 +-
 arch/nds32/include/uapi/asm/byteorder.h  |  2 +-
 arch/nds32/include/uapi/asm/cachectl.h   |  2 +-
 arch/nds32/include/uapi/asm/param.h  |  2 +-
 arch/nds32/include/uapi/asm/ptrace.h |  2 +-
 arch/nds32/include/uapi/asm/sigcontext.h |  2 +-
 arch/nds32/include/uapi/asm/unistd.h |  2 +-
 arch/nds32/kernel/.gitignore |  1 +
 arch/nds32/kernel/cacheinfo.c|  2 +-
 arch/nds32/kernel/ex-exit.S  |  4 ++--
 arch/nds32/kernel/nds32_ksyms.c  |  6 --
 arch/nds32/kernel/vdso.c |  1 +
 arch/nds32/kernel/vdso/.gitignore|  1 +
 arch/nds32/kernel/vdso/Makefile  | 14 +-
 arch/nds32/kernel/vdso/gettimeofday.c|  4 +++-
 arch/nds32/mm/init.c |  2 +-
 59 files changed, 72 insertions(+), 89 deletions(-)
 create mode 100644 arch/nds32/kernel/.gitignore
 create mode 100644 arch/nds32/kernel/vdso/.gitignore


Re: Linux 4.19 and GCC 9

2019-05-17 Thread Miguel Ojeda
On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra  wrote:
>
> On Fri, May 17, 2019 at 07:09:31AM +0200, Greg KH wrote:
> > On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> > > We are building the upstream kernel. There are a few patches, but
> > > nothing related to objtool.
> > >
> > > Unless you mean mainline/stable by upstream, I haven't tried that. We
> > > stick to LTS.
> >
> > Please work and all of these issues fixed up in Linus's tree and then I
> > will be glad to take the fixed into the stable releases.
>
> Right; if there is anything you can reproduce on linus.git I'll happily
> have a look. If it doesn't reproduce all you have to do is find the
> patches that make it work and ask Greg.

Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.

Cheers,
Miguel


[RESEND v2 2/3] ARM: dts: stm32: enable Vivante GPU support on stm32mp157c-ed1 board

2019-05-17 Thread Pierre-Yves MORDRET
Enable Vivante GPU driver for stm32mp157c-ed1 board.

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
v2:
   * move GPU reserved memeory out of bottom DDR to let free this area for
 U-Boot
v1:
   * Initial
---
---
 arch/arm/boot/dts/stm32mp157c-ed1.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts 
b/arch/arm/boot/dts/stm32mp157c-ed1.dts
index 9fd7943..7bcc122 100644
--- a/arch/arm/boot/dts/stm32mp157c-ed1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ed1.dts
@@ -22,6 +22,17 @@
reg = <0xC000 0x4000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   gpu_reserved: gpu@e800 {
+   reg = <0xe800 0x800>;
+   no-map;
+   };
+   };
+
aliases {
serial0 = 
};
@@ -76,6 +87,11 @@
status = "okay";
 };
 
+ {
+   contiguous-area = <_reserved>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.7.4



[RESEND v2 1/3] ARM: dts: stm32: Add Vivante GPU support on STM32MP157c

2019-05-17 Thread Pierre-Yves MORDRET
Append Vivante GPU DT configuration.

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
v2:
v1:
   * Initial
---
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 6ce75f6..3310aba 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1136,6 +1136,16 @@
status = "disabled";
};
 
+   gpu: gpu@5900 {
+   compatible = "vivante,gc";
+   reg = <0x5900 0x800>;
+   interrupts = ;
+   clocks = < GPU>, < GPU_K>;
+   clock-names = "bus" ,"core";
+   resets = < GPU_R>;
+   status = "disabled";
+   };
+
dsi: dsi@5a00 {
compatible = "st,stm32-dsi";
reg = <0x5a00 0x800>;
-- 
2.7.4



[RESEND v2 0/3] Add Vivante GPU support on STM32MP157c

2019-05-17 Thread Pierre-Yves MORDRET
Add and enable Vivante GPU on stm32mp157c for ED1, DK1 and DK2 boards.
---
  Version history:
v2:
   * move GPU reserved memeory out of bottom DDR to let free this area for
 U-Boot
v1:
   * Initial
---
Pierre-Yves MORDRET (3):
  ARM: dts: stm32: Add Vivante GPU support on STM32MP157c
  ARM: dts: stm32: enable Vivante GPU support on stm32mp157c-ed1 board
  ARM: dts: stm32: enable Vivante GPU support on stm32mp157a-dk1 board

 arch/arm/boot/dts/stm32mp157a-dk1.dts | 16 
 arch/arm/boot/dts/stm32mp157c-ed1.dts | 16 
 arch/arm/boot/dts/stm32mp157c.dtsi| 10 ++
 3 files changed, 42 insertions(+)

-- 
2.7.4



[RESEND v2 3/3] ARM: dts: stm32: enable Vivante GPU support on stm32mp157a-dk1 board

2019-05-17 Thread Pierre-Yves MORDRET
Enable Vivante GPU driver for stm32mp157a-dk1 and dk2 boards.

Signed-off-by: Pierre-Yves MORDRET 
---
  Version history:
v2:
   * move GPU reserved memeory out of bottom DDR to let free this area for
 U-Boot
v1:
   * Initial
---
---
 arch/arm/boot/dts/stm32mp157a-dk1.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts 
b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 1b1886d..bd06f7b 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -27,6 +27,17 @@
reg = <0xc000 0x2000>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   gpu_reserved: gpu@d400 {
+   reg = <0xd400 0x400>;
+   no-map;
+   };
+   };
+
led {
compatible = "gpio-leds";
blue {
@@ -69,6 +80,11 @@
status = "okay";
 };
 
+ {
+   contiguous-area = <_reserved>;
+   status = "okay";
+};
+
  {
timeout-sec = <32>;
status = "okay";
-- 
2.7.4



  1   2   3   4   5   6   7   >