[lkp-robot] [init, tracing] 2580d6b795: BUG:kernel_reboot-without-warning_in_boot_stage

2018-04-08 Thread kernel test robot

FYI, we noticed the following commit (built with gcc-7):

commit: 2580d6b795e25879c825a0891cf67390f665b11f ("init, tracing: Have printk 
come through the trace events for initcall_debug")
url: 
https://github.com/0day-ci/linux/commits/Steven-Rostedt/init-tracing/20180407-130743


in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | ecf6709d07 
| 2580d6b795 |
+--+++
| boot_successes   | 0  
| 0  |
| boot_failures| 8  
| 8  |
| invoked_oom-killer:gfp_mask=0x   | 8  
||
| Mem-Info | 8  
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 8  
||
| BUG:kernel_reboot-without-warning_in_boot_stage  | 0  
| 8  |
+--+++



[0.00] RAMDISK: [mem 0x1b7e2000-0x1ffc]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F6860 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x1FFE1628 30 (v01 BOCHS  BXPCRSDT 
0001 BXPC 0001)
[0.00] ACPI: FACP 0x1FFE147C 74 (v01 BOCHS  BXPCFACP 
0001 BXPC 0001)
BUG: kernel reboot-without-warning in boot stage

Elapsed time: 10

#!/bin/bash



To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.16.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not 

[PATCH AUTOSEL for 4.14 141/161] selftests/ftrace: Add some missing glob checks

2018-04-08 Thread Sasha Levin
From: "Steven Rostedt (VMware)" 

[ Upstream commit 97fe22adf33f06519bfdf7dad33bcd562e366c8f ]

Al Viro discovered a bug in the glob ftrace filtering code where "*a*b" is
treated the same as "a*b", and functions that would be selected by "*a*b"
but not "a*b" are not selected with "*a*b".

Add tests for patterns "*a*b" and "a*b*" to the glob selftest.

Link: http://lkml.kernel.org/r/20180127170748.gf13...@zeniv.linux.org.uk

Cc: Shuah Khan 
Acked-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
index 589d52b211b7..27a54a17da65 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -29,6 +29,12 @@ ftrace_filter_check '*schedule*' '^.*schedule.*$'
 # filter by *, end match
 ftrace_filter_check 'schedule*' '^schedule.*$'
 
+# filter by *mid*end
+ftrace_filter_check '*aw*lock' '.*aw.*lock$'
+
+# filter by start*mid*
+ftrace_filter_check 'mutex*try*' '^mutex.*try.*'
+
 # Advanced full-glob matching feature is recently supported.
 # Skip the tests if we are sure the kernel does not support it.
 if grep -q 'accepts: .* glob-matching-pattern' README ; then
-- 
2.15.1


[PATCH AUTOSEL for 4.9 005/293] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2018-04-08 Thread Sasha Levin
From: Chris Wilson 

[ Upstream commit 833521ebc65b1c3092e5c0d8a97092f98eec595d ]

An error during suspend (e100e_pm_suspend),

[  429.994338] ACPI : EC: event blocked
[  429.994633] e1000e: EEE TX LPI TIMER: 0011
[  430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[  430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[  430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[  430.955581] PM: Some devices failed to suspend, or early wake event detected
[  430.957709] ACPI : EC: event unblocked

lead to complete failure:

[  432.585002] [ cut here ]
[  432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 
__free_irq+0x9f/0x280
[  432.585015] Trying to free already-free IRQ 20
[  432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal 
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci 
i915 mmc_core e1000e ptp pps_core prime_numbers
[  432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U  
4.10.0-rc8-CI-Patchwork_3870+ #1
[  432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[  432.585050] Workqueue: events_unbound async_run_entry_fn
[  432.585051] Call Trace:
[  432.585058]  dump_stack+0x67/0x92
[  432.585062]  __warn+0xc6/0xe0
[  432.585065]  warn_slowpath_fmt+0x4a/0x50
[  432.585070]  ? _raw_spin_lock_irqsave+0x49/0x60
[  432.585072]  __free_irq+0x9f/0x280
[  432.585075]  free_irq+0x34/0x80
[  432.585089]  e1000_free_irq+0x65/0x70 [e1000e]
[  432.585098]  e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[  432.585106]  e1000e_pm_suspend+0x21/0x30 [e1000e]
[  432.585113]  pci_pm_suspend+0x71/0x140
[  432.585118]  dpm_run_callback+0x6f/0x330
[  432.585122]  ? pci_pm_freeze+0xe0/0xe0
[  432.585125]  __device_suspend+0xea/0x330
[  432.585128]  async_suspend+0x1a/0x90
[  432.585132]  async_run_entry_fn+0x34/0x160
[  432.585137]  process_one_work+0x1f4/0x6d0
[  432.585140]  ? process_one_work+0x16e/0x6d0
[  432.585143]  worker_thread+0x49/0x4a0
[  432.585145]  kthread+0x107/0x140
[  432.585148]  ? process_one_work+0x6d0/0x6d0
[  432.585150]  ? kthread_create_on_node+0x40/0x40
[  432.585154]  ret_from_fork+0x2e/0x40
[  432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.

Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 528a926dd979..87cbefb16050 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6645,12 +6645,17 @@ static int e1000e_pm_thaw(struct device *dev)
 static int e1000e_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
+   int rc;
 
e1000e_flush_lpic(pdev);
 
e1000e_pm_freeze(dev);
 
-   return __e1000_shutdown(pdev, false);
+   rc = __e1000_shutdown(pdev, false);
+   if (rc)
+   e1000e_pm_thaw(dev);
+
+   return rc;
 }
 
 static int e1000e_pm_resume(struct device *dev)
-- 
2.15.1


[PATCH AUTOSEL for 4.14 079/161] RDMA/uverbs: Use an unambiguous errno for method not supported

2018-04-08 Thread Sasha Levin
From: Jason Gunthorpe 

[ Upstream commit 3624a8f02568f08aef299d3b117f2226f621177d ]

Returning EOPNOTSUPP is problematic because it can also be
returned by the method function, and we use it in quite a few
places in drivers these days.

Instead, dedicate EPROTONOSUPPORT to indicate that the ioctl framework
is enabled but the requested object and method are not supported by
the kernel. No other case will return this code, and it lets userspace
know to fall back to write().

grep says we do not use it today in drivers/infiniband subsystem.

Signed-off-by: Jason Gunthorpe 
Reviewed-by: Matan Barak 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/uverbs_ioctl.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/core/uverbs_ioctl.c 
b/drivers/infiniband/core/uverbs_ioctl.c
index 5286ad57d903..8f2dc79ad4ec 100644
--- a/drivers/infiniband/core/uverbs_ioctl.c
+++ b/drivers/infiniband/core/uverbs_ioctl.c
@@ -245,16 +245,13 @@ static long ib_uverbs_cmd_verbs(struct ib_device *ib_dev,
uintptr_t data[UVERBS_OPTIMIZE_USING_STACK_SZ / sizeof(uintptr_t)];
 #endif
 
-   if (hdr->reserved)
-   return -EINVAL;
-
object_spec = uverbs_get_object(ib_dev, hdr->object_id);
if (!object_spec)
-   return -EOPNOTSUPP;
+   return -EPROTONOSUPPORT;
 
method_spec = uverbs_get_method(object_spec, hdr->method_id);
if (!method_spec)
-   return -EOPNOTSUPP;
+   return -EPROTONOSUPPORT;
 
if ((method_spec->flags & UVERBS_ACTION_FLAG_CREATE_ROOT) ^ 
!file->ucontext)
return -EINVAL;
@@ -310,6 +307,16 @@ static long ib_uverbs_cmd_verbs(struct ib_device *ib_dev,
 
err = uverbs_handle_method(buf, ctx->uattrs, hdr->num_attrs, ib_dev,
   file, method_spec, ctx->uverbs_attr_bundle);
+
+   /*
+* EPROTONOSUPPORT is ONLY to be returned if the ioctl framework can
+* not invoke the method because the request is not supported.  No
+* other cases should return this code.
+   */
+   if (unlikely(err == -EPROTONOSUPPORT)) {
+   WARN_ON_ONCE(err == -EPROTONOSUPPORT);
+   err = -EINVAL;
+   }
 out:
 #ifdef UVERBS_OPTIMIZE_USING_STACK_SZ
if (ctx_size > UVERBS_OPTIMIZE_USING_STACK_SZ)
@@ -348,7 +355,7 @@ long ib_uverbs_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
 
if (hdr.reserved) {
-   err = -EOPNOTSUPP;
+   err = -EPROTONOSUPPORT;
goto out;
}
 
-- 
2.15.1


[PATCH AUTOSEL for 4.14 101/161] asm-generic: provide generic_pmdp_establish()

2018-04-08 Thread Sasha Levin
From: "Kirill A. Shutemov" 

[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]

Patch series "Do not lose dirty bit on THP pages", v4.

Vlastimil noted that pmdp_invalidate() is not atomic and we can lose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().

The bug can lead to data loss, but the race window is tiny and I haven't
seen any reports that suggested that it happens in reality.  So I don't
think it worth sending it to stable.

Unfortunately, there's no way to address the issue in a generic way.  We
need to fix all architectures that support THP one-by-one.

All architectures that have THP supported have to provide atomic
pmdp_invalidate() that returns previous value.

If generic implementation of pmdp_invalidate() is used, architecture
needs to provide atomic pmdp_estabish().

pmdp_estabish() is not used out-side generic implementation of
pmdp_invalidate() so far, but I think this can change in the future.

This patch (of 12):

This is an implementation of pmdp_establish() that is only suitable for
an architecture that doesn't have hardware dirty/accessed bits.  In this
case we can't race with CPU which sets these bits and non-atomic
approach is fine.

Link: 
http://lkml.kernel.org/r/20171213105756.69879-2-kirill.shute...@linux.intel.com
Signed-off-by: Kirill A. Shutemov 
Cc: Vlastimil Babka 
Cc: Andrea Arcangeli 
Cc: Michal Hocko 
Cc: Aneesh Kumar K.V 
Cc: Catalin Marinas 
Cc: David Daney 
Cc: David Miller 
Cc: H. Peter Anvin 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Martin Schwidefsky 
Cc: Nitin Gupta 
Cc: Ralf Baechle 
Cc: Thomas Gleixner 
Cc: Vineet Gupta 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 include/asm-generic/pgtable.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 77b891a8f191..2142bceaeb75 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -309,6 +309,21 @@ extern void pgtable_trans_huge_deposit(struct mm_struct 
*mm, pmd_t *pmdp,
 extern pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t 
*pmdp);
 #endif
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * This is an implementation of pmdp_establish() that is only suitable for an
+ * architecture that doesn't have hardware dirty/accessed bits. In this case we
+ * can't race with CPU which sets these bits and non-atomic aproach is fine.
+ */
+static inline pmd_t generic_pmdp_establish(struct vm_area_struct *vma,
+   unsigned long address, pmd_t *pmdp, pmd_t pmd)
+{
+   pmd_t old_pmd = *pmdp;
+   set_pmd_at(vma->vm_mm, address, pmdp, pmd);
+   return old_pmd;
+}
+#endif
+
 #ifndef __HAVE_ARCH_PMDP_INVALIDATE
 extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
-- 
2.15.1


[PATCH AUTOSEL for 4.14 095/161] fs/dax.c: release PMD lock even when there is no PMD support in DAX

2018-04-08 Thread Sasha Levin
From: Jan H. Schönherr 

[ Upstream commit ee190ca6516bc8257e3d36187ca6f0f71a9ec477 ]

follow_pte_pmd() can theoretically return after having acquired a PMD
lock, even when DAX was not compiled with CONFIG_FS_DAX_PMD.

Release the PMD lock unconditionally.

Link: http://lkml.kernel.org/r/20180118133839.20587-1-jscho...@amazon.de
Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
Signed-off-by: Jan H. Schönherr 
Reviewed-by: Ross Zwisler 
Reviewed-by: Andrew Morton 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index 191306cd8b6b..ddb4981ae32e 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -630,8 +630,8 @@ static void dax_mapping_entry_mkclean(struct address_space 
*mapping,
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
mmu_notifier_invalidate_range(vma->vm_mm, start, end);
 unlock_pmd:
-   spin_unlock(ptl);
 #endif
+   spin_unlock(ptl);
} else {
if (pfn != pte_pfn(*ptep))
goto unlock_pte;
-- 
2.15.1


[PATCH AUTOSEL for 4.14 113/161] s390/eadm: fix CONFIG_BLOCK include dependency

2018-04-08 Thread Sasha Levin
From: Sebastian Ott 

[ Upstream commit 366b77ae43c5a3bf1a367f15ec8bc16e05035f14 ]

Commit 2a842acab109 ("block: introduce new block status code type")
added blk_status_t usage to the eadm subchannel driver. However
blk_status_t is unknown when included via  for CONFIG_BLOCK=n.

Only include  since this is the only dependency eadm has.

This fixes build failures like below:
In file included from drivers/s390/cio/eadm_sch.c:24:0:
./arch/s390/include/asm/eadm.h:111:4: error: unknown type name 'blk_status_t'; 
did you mean 'si_status'?
blk_status_t error);

Reported-by: Heiko Carstens 
Signed-off-by: Sebastian Ott 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
---
 arch/s390/include/asm/eadm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/eadm.h b/arch/s390/include/asm/eadm.h
index eb5323161f11..bb63b2afdf6f 100644
--- a/arch/s390/include/asm/eadm.h
+++ b/arch/s390/include/asm/eadm.h
@@ -4,7 +4,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 struct arqb {
u64 data;
-- 
2.15.1


[PATCH AUTOSEL for 4.14 110/161] IB/ipoib: Fix for potential no-carrier state

2018-04-08 Thread Sasha Levin
From: Alex Estrin 

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).

Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by: Mike Marciniszyn 
Reviewed-by: Ira Weiny 
Signed-off-by: Alex Estrin 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index a009e943362a..6bc9a768f721 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2273,6 +2273,9 @@ static struct net_device *ipoib_add_port(const char 
*format,
  priv->ca, ipoib_event);
ib_register_event_handler(>event_handler);
 
+   /* call event handler to ensure pkey in sync */
+   queue_work(ipoib_workqueue, >flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error 
%d\n",
-- 
2.15.1


[PATCH AUTOSEL for 4.9 023/293] stmmac: fix ptp header for GMAC3 hw timestamp

2018-04-08 Thread Sasha Levin
From: Mario Molitor 

[ Upstream commit fd6720aefde06eacf17404eed2cad65c6ec103e1 ]

According the CYCLON V documention only the bit 16 of snaptypesel should
set.
(more information see Table 17-20 (cv_5v4.pdf) :
 Timestamp Snapshot Dependency on Register Bits)

Fixes: d2042052a0aa ("stmmac: update the PTP header file")
Signed-off-by: Mario Molitor 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  3 ++-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 98bbb91336e4..c212d1dd8bfd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -478,7 +478,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
/* PTP v1, UDP, any kind of event packet */
config.rx_filter = HWTSTAMP_FILTER_PTP_V1_L4_EVENT;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
 
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -510,7 +513,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
 
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
@@ -544,7 +550,10 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
/* take time stamp for all event messages */
-   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+   if (priv->plat->has_gmac4)
+   snap_type_sel = PTP_GMAC4_TCR_SNAPTYPSEL_1;
+   else
+   snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
 
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index c06938c47af5..174777cd888e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -63,7 +63,8 @@
 /* Enable Snapshot for Messages Relevant to Master */
 #definePTP_TCR_TSMSTRENA   BIT(15)
 /* Select PTP packets for Taking Snapshots */
-#definePTP_TCR_SNAPTYPSEL_1GENMASK(17, 16)
+#definePTP_TCR_SNAPTYPSEL_1BIT(16)
+#definePTP_GMAC4_TCR_SNAPTYPSEL_1  GENMASK(17, 16)
 /* Enable MAC address for PTP Frame Filtering */
 #definePTP_TCR_TSENMACADDR BIT(18)
 
-- 
2.15.1


[PATCH AUTOSEL for 4.9 024/293] geneve: add missing rx stats accounting

2018-04-08 Thread Sasha Levin
From: Girish Moodalbail 

[ Upstream commit fe741e2362f33bbea813bcc3a921de356c6653db ]

There are few places on the receive path where packet drops and packet
errors were not accounted for. This patch fixes that issue.

Signed-off-by: Girish Moodalbail 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/geneve.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 3c1f89ab0110..92ad43e53c72 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -209,6 +209,7 @@ static void geneve_rx(struct geneve_dev *geneve, struct 
geneve_sock *gs,
struct genevehdr *gnvh = geneve_hdr(skb);
struct metadata_dst *tun_dst = NULL;
struct pcpu_sw_netstats *stats;
+   unsigned int len;
int err = 0;
void *oiph;
 
@@ -222,8 +223,10 @@ static void geneve_rx(struct geneve_dev *geneve, struct 
geneve_sock *gs,
tun_dst = udp_tun_rx_dst(skb, geneve_get_sk_family(gs), flags,
 vni_to_tunnel_id(gnvh->vni),
 gnvh->opt_len * 4);
-   if (!tun_dst)
+   if (!tun_dst) {
+   geneve->dev->stats.rx_dropped++;
goto drop;
+   }
/* Update tunnel dst according to Geneve options. */
ip_tunnel_info_opts_set(_dst->u.tun_info,
gnvh->options, gnvh->opt_len * 4);
@@ -231,8 +234,11 @@ static void geneve_rx(struct geneve_dev *geneve, struct 
geneve_sock *gs,
/* Drop packets w/ critical options,
 * since we don't support any...
 */
-   if (gnvh->critical)
+   if (gnvh->critical) {
+   geneve->dev->stats.rx_frame_errors++;
+   geneve->dev->stats.rx_errors++;
goto drop;
+   }
}
 
skb_reset_mac_header(skb);
@@ -243,8 +249,10 @@ static void geneve_rx(struct geneve_dev *geneve, struct 
geneve_sock *gs,
skb_dst_set(skb, _dst->dst);
 
/* Ignore packet loops (and multicast echo) */
-   if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr))
+   if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr)) {
+   geneve->dev->stats.rx_errors++;
goto drop;
+   }
 
oiph = skb_network_header(skb);
skb_reset_network_header(skb);
@@ -276,13 +284,15 @@ static void geneve_rx(struct geneve_dev *geneve, struct 
geneve_sock *gs,
}
}
 
-   stats = this_cpu_ptr(geneve->dev->tstats);
-   u64_stats_update_begin(>syncp);
-   stats->rx_packets++;
-   stats->rx_bytes += skb->len;
-   u64_stats_update_end(>syncp);
-
-   gro_cells_receive(>gro_cells, skb);
+   len = skb->len;
+   err = gro_cells_receive(>gro_cells, skb);
+   if (likely(err == NET_RX_SUCCESS)) {
+   stats = this_cpu_ptr(geneve->dev->tstats);
+   u64_stats_update_begin(>syncp);
+   stats->rx_packets++;
+   stats->rx_bytes += len;
+   u64_stats_update_end(>syncp);
+   }
return;
 drop:
/* Consume bad packet */
@@ -332,7 +342,7 @@ static int geneve_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
struct geneve_sock *gs;
int opts_len;
 
-   /* Need Geneve and inner Ethernet header to be present */
+   /* Need UDP and Geneve header to be present */
if (unlikely(!pskb_may_pull(skb, GENEVE_BASE_HLEN)))
goto drop;
 
@@ -355,8 +365,10 @@ static int geneve_udp_encap_recv(struct sock *sk, struct 
sk_buff *skb)
opts_len = geneveh->opt_len * 4;
if (iptunnel_pull_header(skb, GENEVE_BASE_HLEN + opts_len,
 htons(ETH_P_TEB),
-!net_eq(geneve->net, dev_net(geneve->dev
+!net_eq(geneve->net, dev_net(geneve->dev {
+   geneve->dev->stats.rx_dropped++;
goto drop;
+   }
 
geneve_rx(geneve, gs, skb);
return 0;
-- 
2.15.1


[PATCH AUTOSEL for 4.14 124/161] MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS

2018-04-08 Thread Sasha Levin
From: Matt Redfearn 

[ Upstream commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 ]

When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
added board support for the RBTX4939, it added a call to
led_classdev_register even if the LED class is built as a module.
Built-in arch code cannot call module code directly like this. Commit
b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently
changed the inclusion of this code to a single check that
CONFIG_LEDS_CLASS is either builtin or a module, but the same issue
remains.

This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y
is set:

arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
make: *** [Makefile:999: vmlinux] Error 1

Fix this by using the IS_BUILTIN() macro instead.

Fixes: b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")
Signed-off-by: Matt Redfearn 
Reviewed-by: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18544/
Signed-off-by: James Hogan 
Signed-off-by: Sasha Levin 
---
 arch/mips/txx9/rbtx4939/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/txx9/rbtx4939/setup.c b/arch/mips/txx9/rbtx4939/setup.c
index 8b937300fb7f..fd26fadc8617 100644
--- a/arch/mips/txx9/rbtx4939/setup.c
+++ b/arch/mips/txx9/rbtx4939/setup.c
@@ -186,7 +186,7 @@ static void __init rbtx4939_update_ioc_pen(void)
 
 #define RBTX4939_MAX_7SEGLEDS  8
 
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
 static u8 led_val[RBTX4939_MAX_7SEGLEDS];
 struct rbtx4939_led_data {
struct led_classdev cdev;
@@ -261,7 +261,7 @@ static inline void rbtx4939_led_setup(void)
 
 static void __rbtx4939_7segled_putc(unsigned int pos, unsigned char val)
 {
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
unsigned long flags;
local_irq_save(flags);
/* bit7: reserved for LED class */
-- 
2.15.1


[PATCH AUTOSEL for 4.14 130/161] bpf: sockmap, fix leaking maps with attached but not detached progs

2018-04-08 Thread Sasha Levin
From: John Fastabend 

[ Upstream commit 3d9e952697de89b53227f06d4241f275eb99cfc4 ]

When a program is attached to a map we increment the program refcnt
to ensure that the program is not removed while it is potentially
being referenced from sockmap side. However, if this same program
also references the map (this is a reasonably common pattern in
my programs) then the verifier will also increment the maps refcnt
from the verifier. This is to ensure the map doesn't get garbage
collected while the program has a reference to it.

So we are left in a state where the map holds the refcnt on the
program stopping it from being removed and releasing the map refcnt.
And vice versa the program holds a refcnt on the map stopping it
from releasing the refcnt on the prog.

All this is fine as long as users detach the program while the
map fd is still around. But, if the user omits this detach command
we are left with a dangling map we can no longer release.

To resolve this when the map fd is released decrement the program
references and remove any reference from the map to the program.
This fixes the issue with possibly dangling map and creates a
user side API constraint. That is, the map fd must be held open
for programs to be attached to a map.

Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Signed-off-by: John Fastabend 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 kernel/bpf/sockmap.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 1890be7ea9cd..53a4787c08d8 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -601,11 +601,6 @@ static void sock_map_free(struct bpf_map *map)
}
rcu_read_unlock();
 
-   if (stab->bpf_verdict)
-   bpf_prog_put(stab->bpf_verdict);
-   if (stab->bpf_parse)
-   bpf_prog_put(stab->bpf_parse);
-
sock_map_remove_complete(stab);
 }
 
@@ -877,6 +872,19 @@ static int sock_map_update_elem(struct bpf_map *map,
return err;
 }
 
+static void sock_map_release(struct bpf_map *map, struct file *map_file)
+{
+   struct bpf_stab *stab = container_of(map, struct bpf_stab, map);
+   struct bpf_prog *orig;
+
+   orig = xchg(>bpf_parse, NULL);
+   if (orig)
+   bpf_prog_put(orig);
+   orig = xchg(>bpf_verdict, NULL);
+   if (orig)
+   bpf_prog_put(orig);
+}
+
 const struct bpf_map_ops sock_map_ops = {
.map_alloc = sock_map_alloc,
.map_free = sock_map_free,
@@ -884,6 +892,7 @@ const struct bpf_map_ops sock_map_ops = {
.map_get_next_key = sock_map_get_next_key,
.map_update_elem = sock_map_update_elem,
.map_delete_elem = sock_map_delete_elem,
+   .map_release = sock_map_release,
 };
 
 BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, bpf_sock,
-- 
2.15.1


[PATCH AUTOSEL for 4.14 148/161] SUNRPC: Don't call __UDPX_INC_STATS() from a preemptible context

2018-04-08 Thread Sasha Levin
From: Trond Myklebust 

[ Upstream commit 0afa6b4412988019db14c6bfb8c6cbdf120ca9ad ]

Calling __UDPX_INC_STATS() from a preemptible context leads to a
warning of the form:

 BUG: using __this_cpu_add() in preemptible [] code: kworker/u5:0/31
 caller is xs_udp_data_receive_workfn+0x194/0x270
 CPU: 1 PID: 31 Comm: kworker/u5:0 Not tainted 4.15.0-rc8-00076-g90ea9f1 #2
 Workqueue: xprtiod xs_udp_data_receive_workfn
 Call Trace:
  dump_stack+0x85/0xc1
  check_preemption_disabled+0xce/0xe0
  xs_udp_data_receive_workfn+0x194/0x270
  process_one_work+0x318/0x620
  worker_thread+0x20a/0x390
  ? process_one_work+0x620/0x620
  kthread+0x120/0x130
  ? __kthread_bind_mask+0x60/0x60
  ret_from_fork+0x24/0x30

Since we're taking a spinlock in those functions anyway, let's fix the
issue by moving the call so that it occurs under the spinlock.

Reported-by: kernel test robot 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 net/sunrpc/xprtsock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 8cb40f8ffa5b..30192abfdc3b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1069,18 +1069,18 @@ static void xs_udp_data_read_skb(struct rpc_xprt *xprt,
 
/* Suck it into the iovec, verify checksum if not done by hw. */
if (csum_partial_copy_to_xdr(>rq_private_buf, skb)) {
-   __UDPX_INC_STATS(sk, UDP_MIB_INERRORS);
spin_lock(>recv_lock);
+   __UDPX_INC_STATS(sk, UDP_MIB_INERRORS);
goto out_unpin;
}
 
-   __UDPX_INC_STATS(sk, UDP_MIB_INDATAGRAMS);
 
spin_lock_bh(>transport_lock);
xprt_adjust_cwnd(xprt, task, copied);
spin_unlock_bh(>transport_lock);
spin_lock(>recv_lock);
xprt_complete_rqst(task, copied);
+   __UDPX_INC_STATS(sk, UDP_MIB_INDATAGRAMS);
 out_unpin:
xprt_unpin_rqst(rovr);
  out_unlock:
-- 
2.15.1


[PATCH AUTOSEL for 4.14 136/161] bcache: properly set task state in bch_writeback_thread()

2018-04-08 Thread Sasha Levin
From: Coly Li 

[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]

Kernel thread routine bch_writeback_thread() has the following code block,

447 down_write(>writeback_lock);
448~450 if (check conditions) {
451 up_write(>writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }

If condition check is true, its task state is set to TASK_INTERRUPTIBLE
and call schedule() to wait for others to wake up it.

There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
   another process changes the condition and call wake_up_process(dc->
   writeback_thread), then at line 452 task state is set back to
   TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be
   waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
   will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and
   call do_exit(). It is not good to enter do_exit() with task state
   TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a
   warning message is reported by __might_sleep(): "WARNING: do not call
   blocking ops when !TASK_RUNNING; state=1 set at []".

For the first issue, task state should be set before condition checks.
Ineed because dc->writeback_lock is required when modifying all the
conditions, calling set_current_state() inside code block where dc->
writeback_lock is hold is safe. But this is quite implicit, so I still move
set_current_state() before all the condition checks.

For the second issue, frankley speaking it does not hurt when kernel thread
exits with TASK_INTERRUPTIBLE state, but this warning message scares users,
makes them feel there might be something risky with bcache and hurt their
data.  Setting task state to TASK_RUNNING before returning fixes this
problem.

In alloc.c:allocator_wait(), there is also a similar issue, and is also
fixed in this patch.

Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.

Signed-off-by: Coly Li 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Michael Lyle 
Cc: Michael Lyle 
Cc: Junhui Tang 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/alloc.c | 4 +++-
 drivers/md/bcache/writeback.c | 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/md/bcache/alloc.c b/drivers/md/bcache/alloc.c
index 934b1fce4ce1..02b576d55758 100644
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -287,8 +287,10 @@ do {   
\
break;  \
\
mutex_unlock(&(ca)->set->bucket_lock);  \
-   if (kthread_should_stop())  \
+   if (kthread_should_stop()) {\
+   set_current_state(TASK_RUNNING);\
return 0;   \
+   }   \
\
schedule(); \
mutex_lock(&(ca)->set->bucket_lock);\
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index 70454f2ad2fa..f046dedc59ab 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -420,18 +420,21 @@ static int bch_writeback_thread(void *arg)
 
while (!kthread_should_stop()) {
down_write(>writeback_lock);
+   set_current_state(TASK_INTERRUPTIBLE);
if (!atomic_read(>has_dirty) ||
(!test_bit(BCACHE_DEV_DETACHING, >disk.flags) &&
 !dc->writeback_running)) {
up_write(>writeback_lock);
-   set_current_state(TASK_INTERRUPTIBLE);
 
-   if (kthread_should_stop())
+   if (kthread_should_stop()) {
+   set_current_state(TASK_RUNNING);
return 0;
+   }
 
schedule();
continue;
}
+   set_current_state(TASK_RUNNING);
 
searched_full_index = refill_dirty(dc);
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 061/101] ext4: change fast symlink test to not rely on i_blocks

2018-04-08 Thread Sasha Levin
From: Tahsin Erdogan 

[ Upstream commit 407cd7fb83c0ebabb490190e673d8c71ee7df97e ]

ext4_inode_info->i_data is the storage area for 4 types of data:

  a) Extents data
  b) Inline data
  c) Block map
  d) Fast symlink data (symlink length < 60)

Extents data case is positively identified by EXT4_INODE_EXTENTS flag.
Inline data case is also obvious because of EXT4_INODE_INLINE_DATA
flag.

Distinguishing c) and d) however requires additional logic. This
currently relies on i_blocks count. After subtracting external xattr
block from i_blocks, if it is greater than 0 then we know that some
data blocks exist, so there must be a block map.

This logic got broken after ea_inode feature was added. That feature
charges the data blocks of external xattr inodes to the referencing
inode and so adds them to the i_blocks. To fix this, we could subtract
ea_inode blocks by iterating through all xattr entries and then check
whether remaining i_blocks count is zero. Besides being complicated,
this won't change the fact that the current way of distinguishing
between c) and d) is fragile.

The alternative solution is to test whether i_size is less than 60 to
determine fast symlink case. ext4_symlink() uses the same test to decide
whether to store the symlink in i_data. There is one caveat to address
before this can work though.

If an inode's i_nlink is zero during eviction, its i_size is set to
zero and its data is truncated. If system crashes before inode is removed
from the orphan list, next boot orphan cleanup may find the inode with
zero i_size. So, a symlink that had its data stored in a block may now
appear to be a fast symlink. The solution used in this patch is to treat
i_size = 0 as a non-fast symlink case. A zero sized symlink is not legal
so the only time this can happen is the mentioned scenario. This is also
logically correct because a i_size = 0 symlink has no data stored in
i_data.

Suggested-by: Andreas Dilger 
Signed-off-by: Tahsin Erdogan 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
Signed-off-by: Sasha Levin 
---
 fs/ext4/inode.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index c2434d72681e..c70d7d3832c4 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -140,16 +140,12 @@ static int ext4_meta_trans_blocks(struct inode *inode, 
int lblocks,
 
 /*
  * Test whether an inode is a fast symlink.
+ * A fast symlink has its symlink data stored in ext4_inode_info->i_data.
  */
 static int ext4_inode_is_fast_symlink(struct inode *inode)
 {
-int ea_blocks = EXT4_I(inode)->i_file_acl ?
-   EXT4_CLUSTER_SIZE(inode->i_sb) >> 9 : 0;
-
-   if (ext4_has_inline_data(inode))
-   return 0;
-
-   return (S_ISLNK(inode->i_mode) && inode->i_blocks - ea_blocks == 0);
+   return S_ISLNK(inode->i_mode) && inode->i_size &&
+  (inode->i_size < EXT4_N_BLOCKS * 4);
 }
 
 /*
@@ -253,6 +249,16 @@ void ext4_evict_inode(struct inode *inode)
 
if (IS_SYNC(inode))
ext4_handle_sync(handle);
+
+   /*
+* Set inode->i_size to 0 before calling ext4_truncate(). We need
+* special handling of symlinks here because i_size is used to
+* determine whether ext4_inode_info->i_data contains symlink data or
+* block mappings. Setting i_size to 0 will remove its fast symlink
+* status. Erase i_data so that it becomes a valid empty block map.
+*/
+   if (ext4_inode_is_fast_symlink(inode))
+   memset(EXT4_I(inode)->i_data, 0, sizeof(EXT4_I(inode)->i_data));
inode->i_size = 0;
err = ext4_mark_inode_dirty(handle, inode);
if (err) {
-- 
2.15.1


[PATCH AUTOSEL for 3.18 067/101] tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account

2018-04-08 Thread Sasha Levin
From: Anna-Maria Gleixner 

[ Upstream commit 91633eed73a3ac37aaece5c8c1f93a18bae616a9 ]

So far only CLOCK_MONOTONIC and CLOCK_REALTIME were taken into account as
well as HRTIMER_MODE_ABS/REL in the hrtimer_init tracepoint. The query for
detecting the ABS or REL timer modes is not valid anymore, it got broken
by the introduction of HRTIMER_MODE_PINNED.

HRTIMER_MODE_PINNED is not evaluated in the hrtimer_init() call, but for the
sake of completeness print all given modes.

Signed-off-by: Anna-Maria Gleixner 
Cc: Christoph Hellwig 
Cc: John Stultz 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: keesc...@chromium.org
Link: http://lkml.kernel.org/r/20171221104205.7269-9-anna-ma...@linutronix.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 include/trace/events/timer.h | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/timer.h b/include/trace/events/timer.h
index 68c2c2000f02..9e4af35b3beb 100644
--- a/include/trace/events/timer.h
+++ b/include/trace/events/timer.h
@@ -121,6 +121,20 @@ DEFINE_EVENT(timer_class, timer_cancel,
TP_ARGS(timer)
 );
 
+#define decode_clockid(type)   \
+   __print_symbolic(type,  \
+   { CLOCK_REALTIME,   "CLOCK_REALTIME"},  \
+   { CLOCK_MONOTONIC,  "CLOCK_MONOTONIC"   },  \
+   { CLOCK_BOOTTIME,   "CLOCK_BOOTTIME"},  \
+   { CLOCK_TAI,"CLOCK_TAI" })
+
+#define decode_hrtimer_mode(mode)  \
+   __print_symbolic(mode,  \
+   { HRTIMER_MODE_ABS, "ABS"   },  \
+   { HRTIMER_MODE_REL, "REL"   },  \
+   { HRTIMER_MODE_ABS_PINNED,  "ABS|PINNED"},  \
+   { HRTIMER_MODE_REL_PINNED,  "REL|PINNED"})
+
 /**
  * hrtimer_init - called when the hrtimer is initialized
  * @hrtimer:   pointer to struct hrtimer
@@ -147,10 +161,8 @@ TRACE_EVENT(hrtimer_init,
),
 
TP_printk("hrtimer=%p clockid=%s mode=%s", __entry->hrtimer,
- __entry->clockid == CLOCK_REALTIME ?
-   "CLOCK_REALTIME" : "CLOCK_MONOTONIC",
- __entry->mode == HRTIMER_MODE_ABS ?
-   "HRTIMER_MODE_ABS" : "HRTIMER_MODE_REL")
+ decode_clockid(__entry->clockid),
+ decode_hrtimer_mode(__entry->mode))
 );
 
 /**
-- 
2.15.1


[PATCH AUTOSEL for 3.18 070/101] dm thin: fix documentation relative to low water mark threshold

2018-04-08 Thread Sasha Levin
From: mulhern 

[ Upstream commit 9b28a1102efc75d81298198166ead87d643a29ce ]

Fixes:
1. The use of "exceeds" when the opposite of exceeds, falls below,
was meant.
2. Properly speaking, a table can not exceed a threshold.

It emphasizes the important point, which is that it is the userspace
daemon's responsibility to check for low free space when a device
is resumed, since it won't get a special event indicating low free
space in that situation.

Signed-off-by: mulhern 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin 
---
 Documentation/device-mapper/thin-provisioning.txt | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/device-mapper/thin-provisioning.txt 
b/Documentation/device-mapper/thin-provisioning.txt
index 2f5173500bd9..2800b014a619 100644
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -112,9 +112,11 @@ $low_water_mark is expressed in blocks of size 
$data_block_size.  If
 free space on the data device drops below this level then a dm event
 will be triggered which a userspace daemon should catch allowing it to
 extend the pool device.  Only one such event will be sent.
-Resuming a device with a new table itself triggers an event so the
-userspace daemon can use this to detect a situation where a new table
-already exceeds the threshold.
+
+No special event is triggered if a just resumed device's free space is below
+the low water mark. However, resuming a device always triggers an
+event; a userspace daemon should verify that free space exceeds the low
+water mark when handling this event.
 
 A low water mark for the metadata device is maintained in the kernel and
 will trigger a dm event if free space on the metadata device drops below
-- 
2.15.1


[PATCH AUTOSEL for 3.18 072/101] watchdog: sp5100_tco: Fix watchdog disable bit

2018-04-08 Thread Sasha Levin
From: Guenter Roeck 

[ Upstream commit f541c09ebfc61697b586b38c9ebaf4b70defb278 ]

According to all published information, the watchdog disable bit for SB800
compatible controllers is bit 1 of PM register 0x48, not bit 2. For the
most part that doesn't matter in practice, since the bit has to be cleared
to enable watchdog address decoding, which is the default setting, but it
still needs to be fixed.

Cc: Zoltán Böszörményi 
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin 
---
 drivers/watchdog/sp5100_tco.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h
index 2b28c00da0df..dfe20b81ced5 100644
--- a/drivers/watchdog/sp5100_tco.h
+++ b/drivers/watchdog/sp5100_tco.h
@@ -54,7 +54,7 @@
 #define SB800_PM_WATCHDOG_CONFIG   0x4C
 
 #define SB800_PCI_WATCHDOG_DECODE_EN   (1 << 0)
-#define SB800_PM_WATCHDOG_DISABLE  (1 << 2)
+#define SB800_PM_WATCHDOG_DISABLE  (1 << 1)
 #define SB800_PM_WATCHDOG_SECOND_RES   (3 << 0)
 #define SB800_ACPI_MMIO_DECODE_EN  (1 << 0)
 #define SB800_ACPI_MMIO_SEL(1 << 1)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 073/101] kconfig: Don't leak main menus during parsing

2018-04-08 Thread Sasha Levin
From: Ulf Magnusson 

[ Upstream commit 0724a7c32a54e3e50d28e19e30c59014f61d4e2c ]

If a 'mainmenu' entry appeared in the Kconfig files, two things would
leak:

- The 'struct property' allocated for the default "Linux Kernel
  Configuration" prompt.

- The string for the T_WORD/T_WORD_QUOTE prompt after the
  T_MAINMENU token, allocated on the heap in zconf.l.

To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches
if there's no 'mainmenu' and adds the default prompt. That means the
prompt only gets allocated once regardless of whether there's a
'mainmenu' statement or not, and managing it becomes simple.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
   definitely lost: 344,568 bytes in 14,352 blocks
   ...

Summary after the fix:

LEAK SUMMARY:
   definitely lost: 344,440 bytes in 14,350 blocks
   ...

Signed-off-by: Ulf Magnusson 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/kconfig/zconf.y | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 0f683cfa53e9..52dda772d181 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -102,7 +102,27 @@ static struct menu *current_menu, *current_entry;
 %%
 input: nl start | start;
 
-start: mainmenu_stmt stmt_list | stmt_list;
+start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+
+/* mainmenu entry */
+
+mainmenu_stmt: T_MAINMENU prompt nl
+{
+   menu_add_prompt(P_MENU, $2, NULL);
+};
+
+/* Default main menu, if there's no mainmenu entry */
+
+no_mainmenu_stmt: /* empty */
+{
+   /*
+* Hack: Keep the main menu title on the heap so we can safely free it
+* later regardless of whether it comes from the 'prompt' in
+* mainmenu_stmt or here
+*/
+   menu_add_prompt(P_MENU, strdup("Linux Kernel Configuration"), NULL);
+};
+
 
 stmt_list:
  /* empty */
@@ -339,13 +359,6 @@ if_block:
| if_block choice_stmt
 ;
 
-/* mainmenu entry */
-
-mainmenu_stmt: T_MAINMENU prompt nl
-{
-   menu_add_prompt(P_MENU, $2, NULL);
-};
-
 /* menu entry */
 
 menu: T_MENU prompt T_EOL
@@ -486,6 +499,7 @@ word_opt: /* empty */   { $$ = NULL; }
 
 void conf_parse(const char *name)
 {
+   const char *tmp;
struct symbol *sym;
int i;
 
@@ -493,7 +507,6 @@ void conf_parse(const char *name)
 
sym_init();
_menu_init();
-   rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", 
NULL);
 
if (getenv("ZCONF_DEBUG"))
zconfdebug = 1;
@@ -503,8 +516,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
 
+   tmp = rootmenu.prompt->text;
rootmenu.prompt->text = _(rootmenu.prompt->text);
rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
+   free((char*)tmp);
 
menu_finalize();
for_all_symbols(i, sym) {
-- 
2.15.1


[PATCH AUTOSEL for 3.18 066/101] kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl

2018-04-08 Thread Sasha Levin
From: Paolo Bonzini 

[ Upstream commit 51776043afa415435c7e4636204fbe4f7edc4501 ]

This ioctl is obsolete (it was used by Xenner as far as I know) but
still let's not break it gratuitously...  Its handler is copying
directly into struct kvm.  Go through a bounce buffer instead, with
the added benefit that we can actually do something useful with the
flags argument---the previous code was exiting with -EINVAL but still
doing the copy.

This technically is a userspace ABI breakage, but since no one should be
using the ioctl, it's a good occasion to see if someone actually
complains.

Cc: kernel-harden...@lists.openwall.com
Cc: Kees Cook 
Cc: Radim Krčmář 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Kees Cook 
Signed-off-by: Sasha Levin 
---
 arch/x86/kvm/x86.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f06fd2018651..4de23979d0ff 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4025,13 +4025,14 @@ long kvm_arch_vm_ioctl(struct file *filp,
break;
}
case KVM_XEN_HVM_CONFIG: {
+   struct kvm_xen_hvm_config xhc;
r = -EFAULT;
-   if (copy_from_user(>arch.xen_hvm_config, argp,
-  sizeof(struct kvm_xen_hvm_config)))
+   if (copy_from_user(, argp, sizeof(xhc)))
goto out;
r = -EINVAL;
-   if (kvm->arch.xen_hvm_config.flags)
+   if (xhc.flags)
goto out;
+   memcpy(>arch.xen_hvm_config, , sizeof(xhc));
r = 0;
break;
}
-- 
2.15.1


[PATCH AUTOSEL for 3.18 076/101] btrfs: Fix out of bounds access in btrfs_search_slot

2018-04-08 Thread Sasha Levin
From: Nikolay Borisov 

[ Upstream commit 9ea2c7c9da13c9073e371c046cbbc45481ecb459 ]

When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then
the level variable is going to be 7 (this is the max height of the
tree). On the other hand btrfs_cow_block is always called with
"level + 1" as an index into the nodes and slots arrays. This leads to
an out of bounds access. Admittdely this will be benign since an OOB
access of the nodes array will likely read the 0th element from the
slots array, which in this case is going to be 0 (since we start CoW at
the top of the tree). The OOB access into the slots array in turn will
read the 0th and 1st values of the locks array, which would both be 0
at the time. However, this benign behavior relies on the fact that the
path being passed hasn't been initialised, if it has already been used to
query a btree then it could potentially have populated the nodes/slots arrays.

Fix it by explicitly checking if we are at level 7 (the maximum allowed
index in nodes/slots arrays) and explicitly call the CoW routine with
NULL for parent's node/slot.

Signed-off-by: Nikolay Borisov 
Fixes-coverity-id: 711515
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/ctree.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 39c68ef10808..c221d37e3ec9 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -2758,6 +2758,8 @@ again:
 * contention with the cow code
 */
if (cow) {
+   bool last_level = (level == (BTRFS_MAX_LEVEL - 1));
+
/*
 * if we don't really need to cow this block
 * then we don't want to set the path blocking,
@@ -2782,9 +2784,13 @@ again:
}
 
btrfs_set_path_blocking(p);
-   err = btrfs_cow_block(trans, root, b,
- p->nodes[level + 1],
- p->slots[level + 1], );
+   if (last_level)
+   err = btrfs_cow_block(trans, root, b, NULL, 0,
+ );
+   else
+   err = btrfs_cow_block(trans, root, b,
+ p->nodes[level + 1],
+ p->slots[level + 1], );
if (err) {
ret = err;
goto done;
-- 
2.15.1


[PATCH AUTOSEL for 3.18 074/101] kconfig: Fix automatic menu creation mem leak

2018-04-08 Thread Sasha Levin
From: Ulf Magnusson 

[ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ]

expr_trans_compare() always allocates and returns a new expression,
giving the following leak outline:

...
*Allocate*
basedep = expr_trans_compare(basedep, E_UNEQUAL, _no);
...
for (menu = parent->next; menu; menu = menu->next) {
...
*Copy*
dep2 = expr_copy(basedep);
...
*Free copy*
expr_free(dep2);
}
*basedep lost!*

Fix by freeing 'basedep' after the loop.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
   definitely lost: 344,376 bytes in 14,349 blocks
   ...

Summary after the fix:

LEAK SUMMARY:
   definitely lost: 44,448 bytes in 1,852 blocks
   ...

Signed-off-by: Ulf Magnusson 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/kconfig/menu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 72c9dba84c5d..095a6094d736 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -364,6 +364,7 @@ void menu_finalize(struct menu *parent)
menu->parent = parent;
last_menu = menu;
}
+   expr_free(basedep);
if (last_menu) {
parent->list = parent->next;
parent->next = last_menu->next;
-- 
2.15.1


[PATCH AUTOSEL for 3.18 069/101] tools lib traceevent: Fix get_field_str() for dynamic strings

2018-04-08 Thread Sasha Levin
From: "Steven Rostedt (VMware)" 

[ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]

If a field is a dynamic string, get_field_str() returned just the
offset/size value and not the string. Have it parse the offset/size
correctly to return the actual string. Otherwise filtering fails when
trying to filter fields that are dynamic strings.

Reported-by: Gopanapalli Pradeep 
Signed-off-by: Steven Rostedt 
Acked-by: Namhyung Kim 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20180112004823.146333...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/lib/traceevent/parse-filter.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/lib/traceevent/parse-filter.c 
b/tools/lib/traceevent/parse-filter.c
index 88cccea3ca99..64309d73921b 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -1867,17 +1867,25 @@ static const char *get_field_str(struct filter_arg 
*arg, struct pevent_record *r
struct pevent *pevent;
unsigned long long addr;
const char *val = NULL;
+   unsigned int size;
char hex[64];
 
/* If the field is not a string convert it */
if (arg->str.field->flags & FIELD_IS_STRING) {
val = record->data + arg->str.field->offset;
+   size = arg->str.field->size;
+
+   if (arg->str.field->flags & FIELD_IS_DYNAMIC) {
+   addr = *(unsigned int *)val;
+   val = record->data + (addr & 0x);
+   size = addr >> 16;
+   }
 
/*
 * We need to copy the data since we can't be sure the field
 * is null terminated.
 */
-   if (*(val + arg->str.field->size - 1)) {
+   if (*(val + size - 1)) {
/* copy it */
memcpy(arg->str.buffer, val, arg->str.field->size);
/* the buffer is already NULL terminated */
-- 
2.15.1


[PATCH AUTOSEL for 3.18 033/101] i2c: ismt: fix wrong device address when unmap the data buffer

2018-04-08 Thread Sasha Levin
From: Liwei Song 

[ Upstream commit 17e83549e199d89aace7788a9f11c108671eecf5 ]

Fix the following kernel bug:

kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode:  [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS 
HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: 880175389950 ti: 880176bec000 task.ti: 880176bec000
RIP: 0010:[]  [] intel_unmap+0x25b/0x260
RSP: 0018:880176bef5e8  EFLAGS: 00010296
RAX: 0024 RBX: 8800773c7c88 RCX: ce04
RDX: 8000 RSI:  RDI: 0009
RBP: 880176bef638 R08: 0010 R09: 0004
R10: 880175389c78 R11: 0a4f R12: 8800773c7868
R13: ac88 R14: 8800773c7818 R15: 0001
FS:  7fef21258700() GS:88017b5c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0066d6d8 CR3: 7118c000 CR4: 003406e0
Stack:
 ac88 8199867f 880176bef5f8 88010030
 880176bef668 8800773c7c88 880178288098 8800772c0010
 8800773c7818 0001 880176bef648 8150a86e
Call Trace:
 [] ? printk+0x46/0x48
 [] intel_unmap_page+0xe/0x10
 [] ismt_access+0x27b/0x8fa [i2c_ismt]
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
 [] i2c_smbus_xfer+0xec/0x4b0
 [] ? vprintk_emit+0x345/0x530
 [] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
 [] ? vprintk_default+0x29/0x40
 [] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
 [] do_vfs_ioctl+0x328/0x5d0
 [] ? vfs_write+0x11c/0x190
 [] ? rt_up_read+0x19/0x20
 [] SyS_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x6e

This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.

After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().

To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.

Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host 
controller")
Signed-off-by: Liwei Song 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-ismt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c
index f771c6afbab5..beab499d182c 100644
--- a/drivers/i2c/busses/i2c-ismt.c
+++ b/drivers/i2c/busses/i2c-ismt.c
@@ -587,7 +587,7 @@ static int ismt_access(struct i2c_adapter *adap, u16 addr,
 
/* unmap the data buffer */
if (dma_size != 0)
-   dma_unmap_single(>dev, dma_addr, dma_size, dma_direction);
+   dma_unmap_single(dev, dma_addr, dma_size, dma_direction);
 
if (unlikely(!ret)) {
dev_err(dev, "completion wait timed out\n");
-- 
2.15.1


[PATCH AUTOSEL for 3.18 025/101] PCI: Add domain number check to find_smbios_instance_string()

2018-04-08 Thread Sasha Levin
From: Sujith Pandel 

[ Upstream commit 6c51c82c60991bdbfb937f3bf0cdbe68d042073d ]

The function find_smbios_instance_string() does not consider the
PCI domain number.  As a result, SMBIOS type 41 device type instance
would be exported to sysfs for all the PCI domains which have a
PCI device with same bus/device/function, though PCI bus/device/func
from a specific PCI domain has SMBIOS type 41 device type instance
defined.

Address the issue by making find_smbios_instance_string() check PCI domain
number as well.

Reported-by: Shai Fultheim 
Suggested-by: Shai Fultheim 
Tested-by: Shai Fultheim 
Signed-off-by: Sujith Pandel 
Signed-off-by: Narendra K 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
---
 drivers/pci/pci-label.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 2ab1b47c7651..2ded1394b51e 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -45,9 +45,11 @@ static size_t find_smbios_instance_string(struct pci_dev 
*pdev, char *buf,
 {
const struct dmi_device *dmi;
struct dmi_dev_onboard *donboard;
+   int domain_nr;
int bus;
int devfn;
 
+   domain_nr = pci_domain_nr(pdev->bus);
bus = pdev->bus->number;
devfn = pdev->devfn;
 
@@ -55,8 +57,9 @@ static size_t find_smbios_instance_string(struct pci_dev 
*pdev, char *buf,
while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD,
  NULL, dmi)) != NULL) {
donboard = dmi->device_data;
-   if (donboard && donboard->bus == bus &&
-   donboard->devfn == devfn) {
+   if (donboard && donboard->segment == domain_nr &&
+   donboard->bus == bus &&
+   donboard->devfn == devfn) {
if (buf) {
if (attribute == SMBIOS_ATTR_INSTANCE_SHOW)
return scnprintf(buf, PAGE_SIZE,
-- 
2.15.1


[PATCH AUTOSEL for 3.18 035/101] r8152: add byte_enable for ocp_read_word function

2018-04-08 Thread Sasha Levin
From: hayeswang 

[ Upstream commit d8fbd27469fc02049c674de296a3263bef089131 ]

Add byte_enable for ocp_read_word() to replace reading 4
bytes data with reading the desired 2 bytes data.

This is used to avoid the issue which is described in
commit b4d99def0938 ("r8152: remove sram_read"). The
original method always reads 4 bytes data, and it may
have problem when reading the PHY registers.

The new method is supported since RTL8153B, but it
doesn't influence the previous chips. The bits of the
byte_enable for the previous chips are the reserved
bits, and the hw would ignore them.

Signed-off-by: Hayes Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/r8152.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 31cb1cda7166..c0b6b8875eac 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -804,11 +804,13 @@ static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 
index)
 {
u32 data;
__le32 tmp;
+   u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
 
index &= ~3;
+   byen <<= shift;
 
-   generic_ocp_read(tp, index, sizeof(tmp), , type);
+   generic_ocp_read(tp, index, sizeof(tmp), , type | byen);
 
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
-- 
2.15.1


[PATCH AUTOSEL for 3.18 002/101] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2018-04-08 Thread Sasha Levin
From: Chris Wilson 

[ Upstream commit 833521ebc65b1c3092e5c0d8a97092f98eec595d ]

An error during suspend (e100e_pm_suspend),

[  429.994338] ACPI : EC: event blocked
[  429.994633] e1000e: EEE TX LPI TIMER: 0011
[  430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[  430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[  430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[  430.955581] PM: Some devices failed to suspend, or early wake event detected
[  430.957709] ACPI : EC: event unblocked

lead to complete failure:

[  432.585002] [ cut here ]
[  432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 
__free_irq+0x9f/0x280
[  432.585015] Trying to free already-free IRQ 20
[  432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal 
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci 
i915 mmc_core e1000e ptp pps_core prime_numbers
[  432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U  
4.10.0-rc8-CI-Patchwork_3870+ #1
[  432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 
07/02/2012
[  432.585050] Workqueue: events_unbound async_run_entry_fn
[  432.585051] Call Trace:
[  432.585058]  dump_stack+0x67/0x92
[  432.585062]  __warn+0xc6/0xe0
[  432.585065]  warn_slowpath_fmt+0x4a/0x50
[  432.585070]  ? _raw_spin_lock_irqsave+0x49/0x60
[  432.585072]  __free_irq+0x9f/0x280
[  432.585075]  free_irq+0x34/0x80
[  432.585089]  e1000_free_irq+0x65/0x70 [e1000e]
[  432.585098]  e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[  432.585106]  e1000e_pm_suspend+0x21/0x30 [e1000e]
[  432.585113]  pci_pm_suspend+0x71/0x140
[  432.585118]  dpm_run_callback+0x6f/0x330
[  432.585122]  ? pci_pm_freeze+0xe0/0xe0
[  432.585125]  __device_suspend+0xea/0x330
[  432.585128]  async_suspend+0x1a/0x90
[  432.585132]  async_run_entry_fn+0x34/0x160
[  432.585137]  process_one_work+0x1f4/0x6d0
[  432.585140]  ? process_one_work+0x16e/0x6d0
[  432.585143]  worker_thread+0x49/0x4a0
[  432.585145]  kthread+0x107/0x140
[  432.585148]  ? process_one_work+0x6d0/0x6d0
[  432.585150]  ? kthread_create_on_node+0x40/0x40
[  432.585154]  ret_from_fork+0x2e/0x40
[  432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.

Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 3df8366a8356..a82ff60f0921 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6357,12 +6357,17 @@ static int e1000e_pm_thaw(struct device *dev)
 static int e1000e_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
+   int rc;
 
e1000e_flush_lpic(pdev);
 
e1000e_pm_freeze(dev);
 
-   return __e1000_shutdown(pdev, false);
+   rc = __e1000_shutdown(pdev, false);
+   if (rc)
+   e1000e_pm_thaw(dev);
+
+   return rc;
 }
 
 static int e1000e_pm_resume(struct device *dev)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 032/101] firmware: dmi_scan: Check DMI structure length

2018-04-08 Thread Sasha Levin
From: Jean Delvare 

[ Upstream commit a814c3597a6b6040e2ef9459748081a6d5b7312d ]

Before accessing DMI data to record it for later, we should ensure
that the DMI structures are large enough to contain the data in
question.

Signed-off-by: Jean Delvare 
Reviewed-by: Mika Westerberg 
Cc: Dmitry Torokhov 
Cc: Andy Shevchenko 
Cc: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/dmi_scan.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 35286fe52823..f4dbe6fe9dd9 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -152,7 +152,7 @@ static void __init dmi_save_ident(const struct dmi_header 
*dm, int slot,
const char *d = (const char *) dm;
const char *p;
 
-   if (dmi_ident[slot])
+   if (dmi_ident[slot] || dm->length <= string)
return;
 
p = dmi_string(dm, d[string]);
@@ -165,13 +165,14 @@ static void __init dmi_save_ident(const struct dmi_header 
*dm, int slot,
 static void __init dmi_save_uuid(const struct dmi_header *dm, int slot,
int index)
 {
-   const u8 *d = (u8 *) dm + index;
+   const u8 *d;
char *s;
int is_ff = 1, is_00 = 1, i;
 
-   if (dmi_ident[slot])
+   if (dmi_ident[slot] || dm->length <= index + 16)
return;
 
+   d = (u8 *) dm + index;
for (i = 0; i < 16 && (is_ff || is_00); i++) {
if (d[i] != 0x00)
is_00 = 0;
@@ -202,16 +203,17 @@ static void __init dmi_save_uuid(const struct dmi_header 
*dm, int slot,
 static void __init dmi_save_type(const struct dmi_header *dm, int slot,
int index)
 {
-   const u8 *d = (u8 *) dm + index;
+   const u8 *d;
char *s;
 
-   if (dmi_ident[slot])
+   if (dmi_ident[slot] || dm->length <= index)
return;
 
s = dmi_alloc(4);
if (!s)
return;
 
+   d = (u8 *) dm + index;
sprintf(s, "%u", *d & 0x7F);
dmi_ident[slot] = s;
 }
@@ -252,9 +254,13 @@ static void __init dmi_save_devices(const struct 
dmi_header *dm)
 
 static void __init dmi_save_oem_strings_devices(const struct dmi_header *dm)
 {
-   int i, count = *(u8 *)(dm + 1);
+   int i, count;
struct dmi_device *dev;
 
+   if (dm->length < 0x05)
+   return;
+
+   count = *(u8 *)(dm + 1);
for (i = 1; i <= count; i++) {
const char *devname = dmi_string(dm, i);
 
@@ -321,6 +327,9 @@ static void __init dmi_save_extended_devices(const struct 
dmi_header *dm)
 {
const u8 *d = (u8 *) dm + 5;
 
+   if (dm->length < 0x0B)
+   return;
+
/* Skip disabled device */
if ((*d & 0x80) == 0)
return;
@@ -342,7 +351,7 @@ static void __init save_mem_devices(const struct dmi_header 
*dm, void *v)
const char *d = (const char *)dm;
static int nr;
 
-   if (dm->type != DMI_ENTRY_MEM_DEVICE)
+   if (dm->type != DMI_ENTRY_MEM_DEVICE || dm->length < 0x12)
return;
if (nr >= dmi_memdev_nr) {
pr_warn(FW_BUG "Too many DIMM entries in SMBIOS table\n");
-- 
2.15.1


[PATCH AUTOSEL for 3.18 029/101] ixgbe: avoid permanent lock of *_PTP_TX_IN_PROGRESS

2018-04-08 Thread Sasha Levin
From: Jacob Keller 

[ Upstream commit 5fef124d9c75942dc5c2445a3faa8ad37cbf4c82 ]

The ixgbe driver uses a state bit lock to avoid handling more than one Tx
timestamp request at once. This is required because hardware is limited
to a single set of registers for Tx timestamps.

The state bit lock is not properly cleaned up during
ixgbe_xmit_frame_ring() if the transmit fails such as due to DMA or TSO
failure. In some hardware this results in blocking timestamps until the
service task times out. In other hardware this results in a permanent
lock of the timestamp bit because we never receive an interrupt
indicating the timestamp occurred, since indeed the packet was never
transmitted.

Fix this by checking for DMA and TSO errors in ixgbe_xmit_frame_ring() and
properly cleaning up after ourselves when these occur.

Reported-by: Reported-by: David Mirabito 
Signed-off-by: Jacob Keller 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index b250aa806d07..95fab2867b31 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6776,9 +6776,9 @@ static inline int ixgbe_maybe_stop_tx(struct ixgbe_ring 
*tx_ring, u16 size)
 #define IXGBE_TXD_CMD (IXGBE_TXD_CMD_EOP | \
   IXGBE_TXD_CMD_RS)
 
-static void ixgbe_tx_map(struct ixgbe_ring *tx_ring,
-struct ixgbe_tx_buffer *first,
-const u8 hdr_len)
+static int ixgbe_tx_map(struct ixgbe_ring *tx_ring,
+   struct ixgbe_tx_buffer *first,
+   const u8 hdr_len)
 {
struct sk_buff *skb = first->skb;
struct ixgbe_tx_buffer *tx_buffer;
@@ -6901,7 +6901,7 @@ static void ixgbe_tx_map(struct ixgbe_ring *tx_ring,
ixgbe_write_tail(tx_ring, i);
}
 
-   return;
+   return 0;
 dma_error:
dev_err(tx_ring->dev, "TX DMA map failed\n");
 
@@ -6917,6 +6917,8 @@ dma_error:
}
 
tx_ring->next_to_use = i;
+
+   return -1;
 }
 
 static void ixgbe_atr(struct ixgbe_ring *ring,
@@ -7174,13 +7176,21 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
 #ifdef IXGBE_FCOE
 xmit_fcoe:
 #endif /* IXGBE_FCOE */
-   ixgbe_tx_map(tx_ring, first, hdr_len);
+   if (ixgbe_tx_map(tx_ring, first, hdr_len))
+   goto cleanup_tx_timestamp;
 
return NETDEV_TX_OK;
 
 out_drop:
dev_kfree_skb_any(first->skb);
first->skb = NULL;
+cleanup_tx_timestamp:
+   if (unlikely(tx_flags & IXGBE_TX_FLAGS_TSTAMP)) {
+   dev_kfree_skb_any(adapter->ptp_tx_skb);
+   adapter->ptp_tx_skb = NULL;
+   cancel_work_sync(>ptp_tx_work);
+   clear_bit_unlock(__IXGBE_PTP_TX_IN_PROGRESS, >state);
+   }
 
return NETDEV_TX_OK;
 }
-- 
2.15.1


[PATCH AUTOSEL for 3.18 030/101] net_sched: move tcf_lock down after gen_replace_estimator()

2018-04-08 Thread Sasha Levin
From: WANG Cong 

[ Upstream commit 74030603dfd9f76c0f279f19f1dd1ee3028fee7a ]

Laura reported a sleep-in-atomic kernel warning inside
tcf_act_police_init() which calls gen_replace_estimator() with
spinlock protection.

It is not necessary in this case, we already have RTNL lock here
so it is enough to protect concurrent writers. For the reader,
i.e. tcf_act_police(), it needs to make decision based on this
rate estimator, in the worst case we drop more/less packets than
necessary while changing the rate in parallel, it is still acceptable.

Reported-by: Laura Abbott 
Reported-by: Nick Huber 
Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 
Acked-by: Jamal Hadi Salim 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/sched/act_police.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 69791ca77a05..1a25d25b9a56 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -176,21 +176,21 @@ override:
}
}
 
-   spin_lock_bh(>tcf_lock);
if (est) {
err = gen_replace_estimator(>tcf_bstats, NULL,
>tcf_rate_est,
>tcf_lock, est);
if (err)
-   goto failure_unlock;
+   goto failure;
} else if (tb[TCA_POLICE_AVRATE] &&
   (ret == ACT_P_CREATED ||
!gen_estimator_active(>tcf_bstats,
  >tcf_rate_est))) {
err = -EINVAL;
-   goto failure_unlock;
+   goto failure;
}
 
+   spin_lock_bh(>tcf_lock);
/* No failure allowed after this point */
police->tcfp_mtu = parm->mtu;
if (police->tcfp_mtu == 0) {
@@ -242,8 +242,6 @@ override:
a->priv = police;
return ret;
 
-failure_unlock:
-   spin_unlock_bh(>tcf_lock);
 failure:
qdisc_put_rtab(P_tab);
qdisc_put_rtab(R_tab);
-- 
2.15.1


[PATCH AUTOSEL for 3.18 028/101] caif: Add sockaddr length check before accessing sa_family in connect handler

2018-04-08 Thread Sasha Levin
From: Mateusz Jurczyk 

[ Upstream commit 20a3d5bf5e5b13c02450ab6178ec374abd830686 ]

Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in the connect()
handler of the AF_CAIF socket. Since the syscall doesn't enforce a minimum
size of the corresponding memory region, very short sockaddrs (zero or one
byte long) result in operating on uninitialized memory while referencing
sa_family.

Signed-off-by: Mateusz Jurczyk 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/caif/caif_socket.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 5e10ee0efffb..40389e5b8b32 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -758,6 +758,10 @@ static int caif_connect(struct socket *sock, struct 
sockaddr *uaddr,
 
lock_sock(sk);
 
+   err = -EINVAL;
+   if (addr_len < offsetofend(struct sockaddr, sa_family))
+   goto out;
+
err = -EAFNOSUPPORT;
if (uaddr->sa_family != AF_CAIF)
goto out;
-- 
2.15.1


[PATCH AUTOSEL for 3.18 012/101] sparc64: ldc abort during vds iso boot

2018-04-08 Thread Sasha Levin
From: Jag Raman 

[ Upstream commit 6c95483b768c62f8ee933ae08a1bdbcb78b5410f ]

Orabug: 20902628

When an ldc control-only packet is received during data exchange in
read_nonraw(), a new rx head is calculated but the rx queue head is not
actually advanced (rx_set_head() is not called) and a branch is taken to
'no_data' at which point two things can happen depending on the value
of the newly calculated rx head and the current rx tail:

- If the rx queue is determined to be not empty, then the wrong packet
  is picked up.

- If the rx queue is determined to be empty, then a read error (EAGAIN)
  is eventually returned since it is falsely assumed that more data was
  expected.

The fix is to update the rx head and return in case of a control only
packet during data exchange.

Signed-off-by: Jagannathan Raman 
Reviewed-by: Aaron Young 
Reviewed-by: Alexandre Chartre 
Reviewed-by: Bijan Mottahedeh 
Reviewed-by: Liam Merwick 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 arch/sparc/kernel/ldc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/ldc.c b/arch/sparc/kernel/ldc.c
index 71762565513e..8bca543977fe 100644
--- a/arch/sparc/kernel/ldc.c
+++ b/arch/sparc/kernel/ldc.c
@@ -1693,9 +1693,14 @@ static int read_nonraw(struct ldc_channel *lp, void 
*buf, unsigned int size)
 
lp->rcv_nxt = p->seqid;
 
+   /*
+* If this is a control-only packet, there is nothing
+* else to do but advance the rx queue since the packet
+* was already processed above.
+*/
if (!(p->type & LDC_DATA)) {
new = rx_advance(lp, new);
-   goto no_data;
+   break;
}
if (p->stype & (LDC_ACK | LDC_NACK)) {
err = data_ack_nack(lp, p);
-- 
2.15.1


[PATCH AUTOSEL for 3.18 037/101] scsi: lpfc: Fix crash after firmware flash when IO is running.

2018-04-08 Thread Sasha Levin
From: James Smart 

[ Upstream commit 569dbe84a3e769009aa4a5d1030d000168889580 ]

OS crashes after the completion of firmware download.

Failure in posting SCSI SGL buffers because number of SGL buffers is
less than total count. Some of the pending IOs are not completed by
driver. SGL buffers for these IOs are not added back to the list.
Pending IOs are not completed because lpfc_wq_list list is initialized
before completion of pending IOs.

Postpone lpfc_wq_list reinitialization by moving
lpfc_sli4_queue_destroy() after lpfc_hba_down_post().

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/lpfc/lpfc_sli.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index c3cdb9f72bd8..1dfe31c5d916 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -4057,7 +4057,6 @@ lpfc_sli4_brdreset(struct lpfc_hba *phba)
 
/* Perform FCoE PCI function reset before freeing queue memory */
rc = lpfc_pci_function_reset(phba);
-   lpfc_sli4_queue_destroy(phba);
 
/* Restore PCI cmd register */
pci_write_config_word(phba->pcidev, PCI_COMMAND, cfg_value);
@@ -4180,6 +4179,7 @@ lpfc_sli_brdrestart_s4(struct lpfc_hba *phba)
pci_disable_pcie_error_reporting(phba->pcidev);
 
lpfc_hba_down_post(phba);
+   lpfc_sli4_queue_destroy(phba);
 
return rc;
 }
-- 
2.15.1


[PATCH AUTOSEL for 3.18 039/101] x86/nmi: Fix timeout test in test_nmi_ipi()

2018-04-08 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit c133c7615751008f6c32ccae7cdfc5ff6e989c35 ]

We're supposed to exit the loop with "timeout" set to zero.

Signed-off-by: Dan Carpenter 
Acked-by: Don Zickus 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Fixes: 99e8b9ca90d6 ("x86, NMI: Add NMI IPI selftest")
Link: http://lkml.kernel.org/r/20170619105304.GA23995@elgon.mountain
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/nmi_selftest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/nmi_selftest.c b/arch/x86/kernel/nmi_selftest.c
index 6d9582ec0324..d27f8d84c4ff 100644
--- a/arch/x86/kernel/nmi_selftest.c
+++ b/arch/x86/kernel/nmi_selftest.c
@@ -78,7 +78,7 @@ static void __init test_nmi_ipi(struct cpumask *mask)
 
/* Don't wait longer than a second */
timeout = USEC_PER_SEC;
-   while (!cpumask_empty(mask) && timeout--)
+   while (!cpumask_empty(mask) && --timeout)
udelay(1);
 
/* What happens if we timeout, do we still unregister?? */
-- 
2.15.1


[PATCH AUTOSEL for 4.4 114/162] tools lib traceevent: Fix get_field_str() for dynamic strings

2018-04-08 Thread Sasha Levin
From: "Steven Rostedt (VMware)" 

[ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]

If a field is a dynamic string, get_field_str() returned just the
offset/size value and not the string. Have it parse the offset/size
correctly to return the actual string. Otherwise filtering fails when
trying to filter fields that are dynamic strings.

Reported-by: Gopanapalli Pradeep 
Signed-off-by: Steven Rostedt 
Acked-by: Namhyung Kim 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/20180112004823.146333...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/lib/traceevent/parse-filter.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/lib/traceevent/parse-filter.c 
b/tools/lib/traceevent/parse-filter.c
index 88cccea3ca99..64309d73921b 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -1867,17 +1867,25 @@ static const char *get_field_str(struct filter_arg 
*arg, struct pevent_record *r
struct pevent *pevent;
unsigned long long addr;
const char *val = NULL;
+   unsigned int size;
char hex[64];
 
/* If the field is not a string convert it */
if (arg->str.field->flags & FIELD_IS_STRING) {
val = record->data + arg->str.field->offset;
+   size = arg->str.field->size;
+
+   if (arg->str.field->flags & FIELD_IS_DYNAMIC) {
+   addr = *(unsigned int *)val;
+   val = record->data + (addr & 0x);
+   size = addr >> 16;
+   }
 
/*
 * We need to copy the data since we can't be sure the field
 * is null terminated.
 */
-   if (*(val + arg->str.field->size - 1)) {
+   if (*(val + size - 1)) {
/* copy it */
memcpy(arg->str.buffer, val, arg->str.field->size);
/* the buffer is already NULL terminated */
-- 
2.15.1


[PATCH AUTOSEL for 4.4 115/162] iommu/vt-d: Use domain instead of cache fetching

2018-04-08 Thread Sasha Levin
From: Peter Xu 

[ Upstream commit 9d2e6505f6d6934e681aed502f566198cb25c74a ]

after commit a1ddcbe93010 ("iommu/vt-d: Pass dmar_domain directly into
iommu_flush_iotlb_psi", 2015-08-12), we have domain pointer as parameter
to iommu_flush_iotlb_psi(), so no need to fetch it from cache again.

More importantly, a NULL reference pointer bug is reported on RHEL7 (and
it can be reproduced on some old upstream kernels too, e.g., v4.13) by
unplugging an 40g nic from a VM (hard to test unplug on real host, but
it should be the same):

https://bugzilla.redhat.com/show_bug.cgi?id=1531367

[   24.391863] pciehp :00:03.0:pcie004: Slot(0): Attention button pressed
[   24.393442] pciehp :00:03.0:pcie004: Slot(0): Powering off due to button 
press
[   29.721068] i40evf :01:00.0: Unable to send opcode 2 to PF, err 
I40E_ERR_QUEUE_EMPTY, aq_err OK
[   29.783557] iommu: Removing device :01:00.0 from group 3
[   29.784662] BUG: unable to handle kernel NULL pointer dereference at 
0304
[   29.785817] IP: iommu_flush_iotlb_psi+0xcf/0x120
[   29.786486] PGD 0
[   29.786487] P4D 0
[   29.786812]
[   29.787390] Oops:  [#1] SMP
[   29.787876] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc 
ip6table_ng
[   29.795371] CPU: 0 PID: 156 Comm: kworker/0:2 Not tainted 4.13.0 #14
[   29.796366] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.11.0-1.el7 04/01/2014
[   29.797593] Workqueue: pciehp-0 pciehp_power_thread
[   29.798328] task: 94f5745b4a00 task.stack: b326805ac000
[   29.799178] RIP: 0010:iommu_flush_iotlb_psi+0xcf/0x120
[   29.799919] RSP: 0018:b326805afbd0 EFLAGS: 00010086
[   29.800666] RAX: 94f5bc56e800 RBX:  RCX: 00020025
[   29.801667] RDX: 94f5bc56e000 RSI: 0082 RDI: 
[   29.802755] RBP: b326805afbf8 R08:  R09: 94f5bc86bbf0
[   29.803772] R10: b326805afba8 R11: 000ffdc4 R12: 94f5bc86a400
[   29.804789] R13:  R14: ffdc4000 R15: 
[   29.805792] FS:  () GS:94f5bfc0() 
knlGS:
[   29.806923] CS:  0010 DS:  ES:  CR0: 80050033
[   29.807736] CR2: 0304 CR3: 3499d000 CR4: 06f0
[   29.808747] Call Trace:
[   29.809156]  flush_unmaps_timeout+0x126/0x1c0
[   29.809800]  domain_exit+0xd6/0x100
[   29.810322]  device_notifier+0x6b/0x70
[   29.810902]  notifier_call_chain+0x4a/0x70
[   29.812822]  __blocking_notifier_call_chain+0x47/0x60
[   29.814499]  blocking_notifier_call_chain+0x16/0x20
[   29.816137]  device_del+0x233/0x320
[   29.817588]  pci_remove_bus_device+0x6f/0x110
[   29.819133]  pci_stop_and_remove_bus_device+0x1a/0x20
[   29.820817]  pciehp_unconfigure_device+0x7a/0x1d0
[   29.822434]  pciehp_disable_slot+0x52/0xe0
[   29.823931]  pciehp_power_thread+0x8a/0xa0
[   29.825411]  process_one_work+0x18c/0x3a0
[   29.826875]  worker_thread+0x4e/0x3b0
[   29.828263]  kthread+0x109/0x140
[   29.829564]  ? process_one_work+0x3a0/0x3a0
[   29.831081]  ? kthread_park+0x60/0x60
[   29.832464]  ret_from_fork+0x25/0x30
[   29.833794] Code: 85 ed 74 0b 5b 41 5c 41 5d 41 5e 41 5f 5d c3 49 8b 54 24 
60 44 89 f8 0f b6 c4 48 8b 04 c2 48 85 c0 74 49 45 0f b6 ff 4a 8b 3c f8 <80> bf
[   29.838514] RIP: iommu_flush_iotlb_psi+0xcf/0x120 RSP: b326805afbd0
[   29.840362] CR2: 0304
[   29.841716] ---[ end trace b10ec0d6900868d3 ]---

This patch fixes that problem if applied to v4.13 kernel.

The bug does not exist on latest upstream kernel since it's fixed as a
side effect of commit 13cf01744608 ("iommu/vt-d: Make use of iova
deferred flushing", 2017-08-15).  But IMHO it's still good to have this
patch upstream.

CC: Alex Williamson 
Signed-off-by: Peter Xu 
Fixes: a1ddcbe93010 ("iommu/vt-d: Pass dmar_domain directly into 
iommu_flush_iotlb_psi")
Reviewed-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/intel-iommu.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 4efec2db4ee2..0a63a8bd6a8f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1573,8 +1573,7 @@ static void iommu_flush_iotlb_psi(struct intel_iommu 
*iommu,
 * flush. However, device IOTLB doesn't need to be flushed in this case.
 */
if (!cap_caching_mode(iommu->cap) || !map)
-   iommu_flush_dev_iotlb(get_iommu_domain(iommu, did),
- addr, mask);
+   iommu_flush_dev_iotlb(domain, addr, mask);
 }
 
 static void iommu_disable_protect_mem_regions(struct intel_iommu *iommu)
-- 
2.15.1


[PATCH AUTOSEL for 4.4 113/162] perf callchain: Fix attr.sample_max_stack setting

2018-04-08 Thread Sasha Levin
From: Arnaldo Carvalho de Melo 

[ Upstream commit 249d98e567e25dd03e015e2d31e1b7b9648f34df ]

When setting the "dwarf" unwinder for a specific event and not
specifying the max-stack, the attr.sample_max_stack ended up using an
uninitialized callchain_param.max_stack, fix it by using designated
initializers for that callchain_param variable, zeroing all non
explicitely initialized struct members.

Here is what happened:

  # perf trace -vv --no-syscalls --max-stack 4 -e 
probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  callchain: type DWARF
  callchain: stack dump size 8192
  perf_event_attr:
type 2
size 112
config   0x730
{ sample_period, sample_freq }   1
sample_type  
IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
exclude_callchain_user   1
{ wakeup_events, wakeup_watermark } 1
sample_regs_user 0xff0fff
sample_stack_user8192
sample_max_stack 50656
  sys_perf_event_open failed, error -75
  Value too large for defined data type
  # perf trace -vv --no-syscalls --max-stack 4 -e 
probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  callchain: type DWARF
  callchain: stack dump size 8192
  perf_event_attr:
type 2
size 112
config   0x730
sample_type  
IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
exclude_callchain_user   1
sample_regs_user 0xff0fff
sample_stack_user8192
sample_max_stack 30448
  sys_perf_event_open failed, error -75
  Value too large for defined data type
  #

Now the attr.sample_max_stack is set to zero and the above works as
expected:

  # perf trace --no-syscalls --max-stack 4 -e 
probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  PING ::1(::1) 56 data bytes
  64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms

  --- ::1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms
   0.000 probe_libc:inet_pton:(7feb7a998350))
 __inet_pton (inlined)
 gaih_inet.constprop.7 
(/usr/lib64/libc-2.26.so)
 __GI_getaddrinfo (inlined)
 [0xaa39b6108f3f] (/usr/bin/ping)
  #

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Hendrick Brueckner 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Thomas Richter 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-is9tramondqa9jlxxsgcm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/evsel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 397fb4ed3c97..f0bd4825f95a 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -624,13 +624,13 @@ static void apply_config_terms(struct perf_evsel *evsel,
struct perf_evsel_config_term *term;
struct list_head *config_terms = >config_terms;
struct perf_event_attr *attr = >attr;
-   struct callchain_param param;
+   /* callgraph default */
+   struct callchain_param param = {
+   .record_mode = callchain_param.record_mode,
+   };
u32 dump_size = 0;
char *callgraph_buf = NULL;
 
-   /* callgraph default */
-   param.record_mode = callchain_param.record_mode;
-
list_for_each_entry(term, config_terms, list) {
switch (term->type) {
case PERF_EVSEL__CONFIG_TERM_PERIOD:
-- 
2.15.1


[PATCH AUTOSEL for 4.4 118/162] clk: ingenic: Fix recalc_rate for clocks with fixed divider

2018-04-08 Thread Sasha Levin
From: Paul Cercueil 

[ Upstream commit e6cfa64375d34a6c8c1861868a381013b2d3b921 ]

Previously, the clocks with a fixed divider would report their rate
as being the same as the one of their parent, independently of the
divider in use. This commit fixes this behaviour.

This went unnoticed as neither the jz4740 nor the jz4780 CGU code
have clocks with fixed dividers yet.

Signed-off-by: Paul Cercueil 
Acked-by: Stephen Boyd 
Cc: Ralf Baechle 
Cc: Maarten ter Huurne 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18477/
Signed-off-by: James Hogan 
Signed-off-by: Sasha Levin 
---
 drivers/clk/ingenic/cgu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index 7cfb7b2a2ed6..e5b1bf4dadcc 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -327,6 +327,8 @@ ingenic_clk_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
div += 1;
 
rate /= div;
+   } else if (clk_info->type & CGU_CLK_FIXDIV) {
+   rate /= clk_info->fixdiv.div;
}
 
return rate;
-- 
2.15.1


[PATCH AUTOSEL for 4.4 103/162] irqchip/gic-v3: Honor forced affinity setting

2018-04-08 Thread Sasha Levin
From: Suzuki K Poulose 

[ Upstream commit 65a30f8b300107266f316d550f060ccc186201a3 ]

Honor the 'force' flag for set_affinity, by selecting a CPU
from the given mask (which may not be reported "online" by
the cpu_online_mask). Some drivers, like ARM PMU, rely on it.

Cc: Marc Zyngier 
Reported-by: Mark Rutland 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/irqchip/irq-gic-v3.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 5d93e0254d70..eed31f9bee05 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -627,11 +627,16 @@ static void gic_smp_init(void)
 static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
bool force)
 {
-   unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   unsigned int cpu;
void __iomem *reg;
int enabled;
u64 val;
 
+   if (force)
+   cpu = cpumask_first(mask_val);
+   else
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+
if (cpu >= nr_cpu_ids)
return -EINVAL;
 
-- 
2.15.1


[PATCH AUTOSEL for 4.4 123/162] mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()

2018-04-08 Thread Sasha Levin
From: "weiyongjun (A)" 

[ Upstream commit 0ddcff49b672239dda94d70d0fcf50317a9f4b51 ]

'hwname' is malloced in hwsim_new_radio_nl() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.

Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Wei Yongjun 
Reviewed-by: Ben Hutchings 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/mac80211_hwsim.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 8a9164da6c50..e8b770a95f7a 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2925,8 +2925,10 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, 
struct genl_info *info)
if (info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]) {
u32 idx = nla_get_u32(info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]);
 
-   if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom))
+   if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom)) {
+   kfree(hwname);
return -EINVAL;
+   }
param.regd = hwsim_world_regdom_custom[idx];
}
 
-- 
2.15.1


[PATCH AUTOSEL for 4.4 119/162] watchdog: sp5100_tco: Fix watchdog disable bit

2018-04-08 Thread Sasha Levin
From: Guenter Roeck 

[ Upstream commit f541c09ebfc61697b586b38c9ebaf4b70defb278 ]

According to all published information, the watchdog disable bit for SB800
compatible controllers is bit 1 of PM register 0x48, not bit 2. For the
most part that doesn't matter in practice, since the bit has to be cleared
to enable watchdog address decoding, which is the default setting, but it
still needs to be fixed.

Cc: Zoltán Böszörményi 
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin 
---
 drivers/watchdog/sp5100_tco.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h
index 2b28c00da0df..dfe20b81ced5 100644
--- a/drivers/watchdog/sp5100_tco.h
+++ b/drivers/watchdog/sp5100_tco.h
@@ -54,7 +54,7 @@
 #define SB800_PM_WATCHDOG_CONFIG   0x4C
 
 #define SB800_PCI_WATCHDOG_DECODE_EN   (1 << 0)
-#define SB800_PM_WATCHDOG_DISABLE  (1 << 2)
+#define SB800_PM_WATCHDOG_DISABLE  (1 << 1)
 #define SB800_PM_WATCHDOG_SECOND_RES   (3 << 0)
 #define SB800_ACPI_MMIO_DECODE_EN  (1 << 0)
 #define SB800_ACPI_MMIO_SEL(1 << 1)
-- 
2.15.1


[PATCH AUTOSEL for 4.4 124/162] ipmi/powernv: Fix error return code in ipmi_powernv_probe()

2018-04-08 Thread Sasha Levin
From: Wei Yongjun 

[ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]

Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.

Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
Signed-off-by: Wei Yongjun 
Reviewed-by: Alexey Kardashevskiy 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin 
---
 drivers/char/ipmi/ipmi_powernv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
index 6e658aa114f1..a70518a4fcec 100644
--- a/drivers/char/ipmi/ipmi_powernv.c
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -251,8 +251,9 @@ static int ipmi_powernv_probe(struct platform_device *pdev)
ipmi->irq = opal_event_request(prop);
}
 
-   if (request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
-   "opal-ipmi", ipmi)) {
+   rc = request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
+"opal-ipmi", ipmi);
+   if (rc) {
dev_warn(dev, "Unable to request irq\n");
goto err_dispose;
}
-- 
2.15.1


[PATCH AUTOSEL for 4.9 219/293] Input: psmouse - fix Synaptics detection when protocol is disabled

2018-04-08 Thread Sasha Levin
From: Dmitry Torokhov 

[ Upstream commit 2bc4298f59d2f15175bb568e2d356b5912d0cdd9 ]

When Synaptics protocol is disabled, we still need to try and detect the
hardware, so we can switch to SMBus device if SMbus is detected, or we know
that it is Synaptics device and reset it properly for the bare PS/2
protocol.

Fixes: c378b5119eb0 ("Input: psmouse - factor out common protocol probing code")
Reported-by: Matteo Croce 
Tested-by: Matteo Croce 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/mouse/psmouse-base.c | 34 +-
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/input/mouse/psmouse-base.c 
b/drivers/input/mouse/psmouse-base.c
index bee267424972..5cbf17aa8443 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -937,6 +937,21 @@ static void psmouse_apply_defaults(struct psmouse *psmouse)
psmouse->pt_deactivate = NULL;
 }
 
+static bool psmouse_do_detect(int (*detect)(struct psmouse *, bool),
+ struct psmouse *psmouse, bool allow_passthrough,
+ bool set_properties)
+{
+   if (psmouse->ps2dev.serio->id.type == SERIO_PS_PSTHRU &&
+   !allow_passthrough) {
+   return false;
+   }
+
+   if (set_properties)
+   psmouse_apply_defaults(psmouse);
+
+   return detect(psmouse, set_properties) == 0;
+}
+
 static bool psmouse_try_protocol(struct psmouse *psmouse,
 enum psmouse_type type,
 unsigned int *max_proto,
@@ -948,15 +963,8 @@ static bool psmouse_try_protocol(struct psmouse *psmouse,
if (!proto)
return false;
 
-   if (psmouse->ps2dev.serio->id.type == SERIO_PS_PSTHRU &&
-   !proto->try_passthru) {
-   return false;
-   }
-
-   if (set_properties)
-   psmouse_apply_defaults(psmouse);
-
-   if (proto->detect(psmouse, set_properties) != 0)
+   if (!psmouse_do_detect(proto->detect, psmouse, proto->try_passthru,
+  set_properties))
return false;
 
if (set_properties && proto->init && init_allowed) {
@@ -988,8 +996,8 @@ static int psmouse_extensions(struct psmouse *psmouse,
 * Always check for focaltech, this is safe as it uses pnp-id
 * matching.
 */
-   if (psmouse_try_protocol(psmouse, PSMOUSE_FOCALTECH,
-_proto, set_properties, false)) {
+   if (psmouse_do_detect(focaltech_detect,
+ psmouse, false, set_properties)) {
if (max_proto > PSMOUSE_IMEX &&
IS_ENABLED(CONFIG_MOUSE_PS2_FOCALTECH) &&
(!set_properties || focaltech_init(psmouse) == 0)) {
@@ -1035,8 +1043,8 @@ static int psmouse_extensions(struct psmouse *psmouse,
 * probing for IntelliMouse.
 */
if (max_proto > PSMOUSE_PS2 &&
-   psmouse_try_protocol(psmouse, PSMOUSE_SYNAPTICS, _proto,
-set_properties, false)) {
+   psmouse_do_detect(synaptics_detect,
+ psmouse, false, set_properties)) {
synaptics_hardware = true;
 
if (max_proto > PSMOUSE_IMEX) {
-- 
2.15.1


[PATCH AUTOSEL for 4.9 227/293] net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b

2018-04-08 Thread Sasha Levin
From: Martin Blumenstingl 

[ Upstream commit 433c6cab9d298687c097f6ee82e49157044dc7c6 ]

Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock
set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The
exact rate is 52394Hz, which is calculated in
drivers/clk/meson/clk-mpll.c using the following formula:
DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm)
Odroid-C1's u-boot configures MPLL2 with the following values:
- SDM_DEN = 16384
- SDM = 1638
- N2 = 5

The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from
the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the
common clock framework chooses a divider which is too big to generate
the 250MHz clock (a divider of 2 would be needed, but this is rounded up
to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1
because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds,
the IP block internally divides that down to 25MHz on 100Mbit/s
connections and 2.5MHz on 10Mbit/s connections - we don't need any
special configuration for that).

Round the divider to the closest value to prevent this issue on Meson8b.
This means we'll now end up with a clock rate for the RGMII TX clock of
125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz.
This has no effect on the Meson GX SoCs since there fclk_div2 is used as
input clock, which has a rate of 1000MHz (and thus is divisible cleanly
to 250MHz and 125MHz).

Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b 
/ GXBB DWMAC")
Reported-by: Emiliano Ingrassia 
Signed-off-by: Martin Blumenstingl 
Reviewed-by: Jerome Brunet 
Tested-by: Jerome Brunet 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index ffaed1f35efe..923033867a4d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -146,7 +146,9 @@ static int meson8b_init_clk(struct meson8b_dwmac *dwmac)
dwmac->m250_div.shift = PRG_ETH0_CLK_M250_DIV_SHIFT;
dwmac->m250_div.width = PRG_ETH0_CLK_M250_DIV_WIDTH;
dwmac->m250_div.hw.init = 
-   dwmac->m250_div.flags = CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO;
+   dwmac->m250_div.flags = CLK_DIVIDER_ONE_BASED |
+   CLK_DIVIDER_ALLOW_ZERO |
+   CLK_DIVIDER_ROUND_CLOSEST;
 
dwmac->m250_div_clk = devm_clk_register(dev, >m250_div.hw);
if (WARN_ON(IS_ERR(dwmac->m250_div_clk)))
-- 
2.15.1


[PATCH AUTOSEL for 4.9 237/293] Btrfs: set plug for fsync

2018-04-08 Thread Sasha Levin
From: Liu Bo 

[ Upstream commit 343e4fc1c60971b0734de26dbbd475d433950982 ]

Setting plug can merge adjacent IOs before dispatching IOs to the disk
driver.

Without plug, it'd not be a problem for single disk usecases, but for
multiple disks using raid profile, a large IO can be split to several
IOs of stripe length, and plug can be helpful to bring them together
for each disk so that we can save several disk access.

Moreover, fsync issues synchronous writes, so plug can really take
effect.

Signed-off-by: Liu Bo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/file.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index c95ff096cd24..437544846e4e 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1912,10 +1912,19 @@ int btrfs_release_file(struct inode *inode, struct file 
*filp)
 static int start_ordered_ops(struct inode *inode, loff_t start, loff_t end)
 {
int ret;
+   struct blk_plug plug;
 
+   /*
+* This is only called in fsync, which would do synchronous writes, so
+* a plug can merge adjacent IOs as much as possible.  Esp. in case of
+* multiple disks using raid profile, a large IO can be split to
+* several segments of stripe length (currently 64K).
+*/
+   blk_start_plug();
atomic_inc(_I(inode)->sync_writers);
ret = btrfs_fdatawrite_range(inode, start, end);
atomic_dec(_I(inode)->sync_writers);
+   blk_finish_plug();
 
return ret;
 }
-- 
2.15.1


[PATCH AUTOSEL for 4.9 240/293] btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP

2018-04-08 Thread Sasha Levin
From: Anand Jain 

[ Upstream commit 6f794e3c5c8f8fdd3b5bb20d9ded894e685b5bbe ]

It appears from the original commit [1] that there isn't any design
specific reason not to fail the mount instead of just warning. This
patch will change it to fail.

[1]
 commit 319e4d0661e5323c9f9945f0f8fb5905e5fe74c3
btrfs: Enhance super validation check

Fixes: 319e4d0661e5323 ("btrfs: Enhance super validation check")
Signed-off-by: Anand Jain 
Reviewed-by: Qu Wenruo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/disk-io.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 1cd325765aaa..e30aeedd326e 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -4142,9 +4142,11 @@ static int btrfs_check_super_valid(struct btrfs_fs_info 
*fs_info,
btrfs_err(fs_info, "no valid FS found");
ret = -EINVAL;
}
-   if (btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP)
-   btrfs_warn(fs_info, "unrecognized super flag: %llu",
+   if (btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP) {
+   btrfs_err(fs_info, "unrecognized or unsupported super flag: 
%llu",
btrfs_super_flags(sb) & ~BTRFS_SUPER_FLAG_SUPP);
+   ret = -EINVAL;
+   }
if (btrfs_super_root_level(sb) >= BTRFS_MAX_LEVEL) {
btrfs_err(fs_info, "tree_root level too big: %d >= %d",
btrfs_super_root_level(sb), BTRFS_MAX_LEVEL);
-- 
2.15.1


[PATCH AUTOSEL for 4.9 209/293] vmlfb: Fix error handling in cr_pll_init()

2018-04-08 Thread Sasha Levin
From: Alexey Khoroshilov 

[ Upstream commit 6af574e826740bf17663b48ba3f8fadb81d2113f ]

There is an error path, where iomemory is left mapped.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alan Hourihane 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/vermilion/cr_pll.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/vermilion/cr_pll.c 
b/drivers/video/fbdev/vermilion/cr_pll.c
index ebc6e6e0dd0f..ba105c876bed 100644
--- a/drivers/video/fbdev/vermilion/cr_pll.c
+++ b/drivers/video/fbdev/vermilion/cr_pll.c
@@ -185,6 +185,7 @@ static int __init cr_pll_init(void)
if (err) {
printk(KERN_ERR
   "Carillo Ranch failed to initialize vml_sys.\n");
+   iounmap(mch_regs_base);
pci_dev_put(mch_dev);
return err;
}
-- 
2.15.1


[PATCH AUTOSEL for 4.9 200/293] ext4: change fast symlink test to not rely on i_blocks

2018-04-08 Thread Sasha Levin
From: Tahsin Erdogan 

[ Upstream commit 407cd7fb83c0ebabb490190e673d8c71ee7df97e ]

ext4_inode_info->i_data is the storage area for 4 types of data:

  a) Extents data
  b) Inline data
  c) Block map
  d) Fast symlink data (symlink length < 60)

Extents data case is positively identified by EXT4_INODE_EXTENTS flag.
Inline data case is also obvious because of EXT4_INODE_INLINE_DATA
flag.

Distinguishing c) and d) however requires additional logic. This
currently relies on i_blocks count. After subtracting external xattr
block from i_blocks, if it is greater than 0 then we know that some
data blocks exist, so there must be a block map.

This logic got broken after ea_inode feature was added. That feature
charges the data blocks of external xattr inodes to the referencing
inode and so adds them to the i_blocks. To fix this, we could subtract
ea_inode blocks by iterating through all xattr entries and then check
whether remaining i_blocks count is zero. Besides being complicated,
this won't change the fact that the current way of distinguishing
between c) and d) is fragile.

The alternative solution is to test whether i_size is less than 60 to
determine fast symlink case. ext4_symlink() uses the same test to decide
whether to store the symlink in i_data. There is one caveat to address
before this can work though.

If an inode's i_nlink is zero during eviction, its i_size is set to
zero and its data is truncated. If system crashes before inode is removed
from the orphan list, next boot orphan cleanup may find the inode with
zero i_size. So, a symlink that had its data stored in a block may now
appear to be a fast symlink. The solution used in this patch is to treat
i_size = 0 as a non-fast symlink case. A zero sized symlink is not legal
so the only time this can happen is the mentioned scenario. This is also
logically correct because a i_size = 0 symlink has no data stored in
i_data.

Suggested-by: Andreas Dilger 
Signed-off-by: Tahsin Erdogan 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
Signed-off-by: Sasha Levin 
---
 fs/ext4/inode.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 58d57c56ec62..1c6c75ad1c60 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -143,16 +143,12 @@ static int ext4_meta_trans_blocks(struct inode *inode, 
int lblocks,
 
 /*
  * Test whether an inode is a fast symlink.
+ * A fast symlink has its symlink data stored in ext4_inode_info->i_data.
  */
 int ext4_inode_is_fast_symlink(struct inode *inode)
 {
-int ea_blocks = EXT4_I(inode)->i_file_acl ?
-   EXT4_CLUSTER_SIZE(inode->i_sb) >> 9 : 0;
-
-   if (ext4_has_inline_data(inode))
-   return 0;
-
-   return (S_ISLNK(inode->i_mode) && inode->i_blocks - ea_blocks == 0);
+   return S_ISLNK(inode->i_mode) && inode->i_size &&
+  (inode->i_size < EXT4_N_BLOCKS * 4);
 }
 
 /*
@@ -253,6 +249,16 @@ void ext4_evict_inode(struct inode *inode)
 
if (IS_SYNC(inode))
ext4_handle_sync(handle);
+
+   /*
+* Set inode->i_size to 0 before calling ext4_truncate(). We need
+* special handling of symlinks here because i_size is used to
+* determine whether ext4_inode_info->i_data contains symlink data or
+* block mappings. Setting i_size to 0 will remove its fast symlink
+* status. Erase i_data so that it becomes a valid empty block map.
+*/
+   if (ext4_inode_is_fast_symlink(inode))
+   memset(EXT4_I(inode)->i_data, 0, sizeof(EXT4_I(inode)->i_data));
inode->i_size = 0;
err = ext4_mark_inode_dirty(handle, inode);
if (err) {
-- 
2.15.1


[PATCH AUTOSEL for 4.9 177/293] iwlwifi: mvm: fix deduplication start logic

2018-04-08 Thread Sasha Levin
From: Johannes Berg 

[ Upstream commit 92c4dca6f5fd3d29d8c1daf02e210dd48dc756ac ]

If the first frame on a given TID is received with seqno 0 and needed
to be retransmitted, we erroneously drop it because the deduplication
data is initialized to zero, and then comparing

if (unlikely(ieee80211_has_retry(hdr->frame_control) &&
 dup_data->last_seq[tid] == hdr->seq_ctrl &&
 dup_data->last_sub_frame[tid] >= sub_frame_idx))
return true;

will return in iwl_mvm_is_dup() since last_sub_frame is also set to
zero, and sub_frame_idx is usually zero since this only covers the
relatively rare case of A-MSDU.

Fix this by initializing the last_seq array to 0x, which is an
impossible value for hdr->seq_ctrl to have here because the lower
four bits are the fragment number, and fragments aren't handled in
this code but go to mac80211 instead.

Fixes: a571f5f635ef ("iwlwifi: mvm: add duplicate packet detection per rx 
queue")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index bdd1deed55a4..8efe965cab0d 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1259,11 +1259,24 @@ int iwl_mvm_add_sta(struct iwl_mvm *mvm,
 
if (iwl_mvm_has_new_rx_api(mvm) &&
!test_bit(IWL_MVM_STATUS_IN_HW_RESTART, >status)) {
+   int q;
+
dup_data = kcalloc(mvm->trans->num_rx_queues,
-  sizeof(*dup_data),
-  GFP_KERNEL);
+  sizeof(*dup_data), GFP_KERNEL);
if (!dup_data)
return -ENOMEM;
+   /*
+* Initialize all the last_seq values to 0x which can never
+* compare equal to the frame's seq_ctrl in the check in
+* iwl_mvm_is_dup() since the lower 4 bits are the fragment
+* number and fragmented packets don't reach that function.
+*
+* This thus allows receiving a packet with seqno 0 and the
+* retry bit set as the very first packet on a new TID.
+*/
+   for (q = 0; q < mvm->trans->num_rx_queues; q++)
+   memset(dup_data[q].last_seq, 0xff,
+  sizeof(dup_data[q].last_seq));
mvm_sta->dup_data = dup_data;
}
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 008/101] xen: avoid type warning in xchg_xen_ulong

2018-04-08 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 9cc91f212111cdcbefa02dcdb7dd443f224bf52c ]

The improved type-checking version of container_of() triggers a warning for
xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t
contains a signed value:

drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events':
drivers/xen/events/events_2l.c:187:1020: error: call to 
'__compiletime_assert_187' declared with attribute error: pointer type mismatch 
in container_of()

This adds a cast to work around the warning.

Cc: Ian Abbott 
Fixes: 85323a991d40 ("xen: arm: mandate EABI and use generic atomic 
operations.")
Fixes: daa2ac80834d ("kernel.h: handle pointers to arrays better in 
container_of()")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
Acked-by: Ian Abbott 
Signed-off-by: Sasha Levin 
---
 arch/arm/include/asm/xen/events.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/events.h 
b/arch/arm/include/asm/xen/events.h
index 8b1f37bfeeec..b7aadab9b0e8 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((long long*)(ptr),\
atomic64_t, \
counter), (val))
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 005/101] MIPS: kprobes: flush_insn_slot should flush only if probe initialised

2018-04-08 Thread Sasha Levin
From: Marcin Nowakowski 

[ Upstream commit 698b851073ddf5a894910d63ca04605e0473414e ]

When ftrace is used with kprobes, it is possible for a kprobe to contain
an invalid location (ie. only initialised to 0 and not to a specific
location in the code). Trying to perform a cache flush on such location
leads to a crash r4k_flush_icache_range().

Fixes: c1bf207d6ee1 ("MIPS: kprobe: Add support.")
Signed-off-by: Marcin Nowakowski 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16296/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/include/asm/kprobes.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/kprobes.h b/arch/mips/include/asm/kprobes.h
index daba1f9a4f79..174aedce3167 100644
--- a/arch/mips/include/asm/kprobes.h
+++ b/arch/mips/include/asm/kprobes.h
@@ -40,7 +40,8 @@ typedef union mips_instruction kprobe_opcode_t;
 
 #define flush_insn_slot(p) \
 do {   \
-   flush_icache_range((unsigned long)p->addr,  \
+   if (p->addr)\
+   flush_icache_range((unsigned long)p->addr,  \
   (unsigned long)p->addr + \
   (MAX_INSN_SIZE * sizeof(kprobe_opcode_t)));  \
 } while (0)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 007/101] perf tests: Decompress kernel module before objdump

2018-04-08 Thread Sasha Levin
From: Namhyung Kim 

[ Upstream commit 94df1040b1e6aacd8dec0ba3c61d7e77cd695f26 ]

If a kernel modules is compressed, it should be decompressed before
running objdump to parse binary data correctly.  This fixes a failure of
object code reading test for me.

Signed-off-by: Namhyung Kim 
Acked-by: Adrian Hunter 
Acked-by: Jiri Olsa 
Cc: David Ahern 
Cc: Peter Zijlstra 
Cc: Wang Nan 
Cc: kernel-t...@lge.com
Link: http://lkml.kernel.org/r/20170608073109.30699-8-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/tests/code-reading.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 67f2d6323558..28dfd1f7f776 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -141,6 +141,8 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
unsigned char buf2[BUFSZ];
size_t ret_len;
u64 objdump_addr;
+   const char *objdump_name;
+   char decomp_name[KMOD_DECOMP_LEN];
int ret;
 
pr_debug("Reading object code for memory address: %#"PRIx64"\n", addr);
@@ -202,9 +204,25 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
state->done[state->done_cnt++] = al.map->start;
}
 
+   objdump_name = al.map->dso->long_name;
+   if (dso__needs_decompress(al.map->dso)) {
+   if (dso__decompress_kmodule_path(al.map->dso, objdump_name,
+decomp_name,
+sizeof(decomp_name)) < 0) {
+   pr_debug("decompression failed\n");
+   return -1;
+   }
+
+   objdump_name = decomp_name;
+   }
+
/* Read the object code using objdump */
objdump_addr = map__rip_2objdump(al.map, al.addr);
-   ret = read_via_objdump(al.map->dso->long_name, objdump_addr, buf2, len);
+   ret = read_via_objdump(objdump_name, objdump_addr, buf2, len);
+
+   if (dso__needs_decompress(al.map->dso))
+   unlink(objdump_name);
+
if (ret > 0) {
/*
 * The kernel maps are inaccurate - assume objdump is right in
-- 
2.15.1


[PATCH AUTOSEL for 4.4 162/162] irqchip/gic-v3: Change pr_debug message to pr_devel

2018-04-08 Thread Sasha Levin
From: Mark Salter 

[ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]

The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking
warning:

 GICv3: CPU10: ICC_SGI1R_EL1 5000400
 ==
 WARNING: possible circular locking dependency detected
 4.15.0+ #1 Tainted: GW
 --
 dynamic_debug01/1873 is trying to acquire lock:
  ((console_sem).lock){-...}, at: [<99c891ec>] down_trylock+0x20/0x4c

 but task is already holding lock:
  (>lock){-.-.}, at: [<842e1587>] __task_rq_lock+0x54/0xdc

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #2 (>lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock+0x4c/0x60
task_fork_fair+0x3c/0x148
sched_fork+0x10c/0x214
copy_process.isra.32.part.33+0x4e8/0x14f0
_do_fork+0xe8/0x78c
kernel_thread+0x48/0x54
rest_init+0x34/0x2a4
start_kernel+0x45c/0x488

 -> #1 (>pi_lock){-.-.}:
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
try_to_wake_up+0x48/0x600
wake_up_process+0x28/0x34
__up.isra.0+0x60/0x6c
up+0x60/0x68
__up_console_sem+0x4c/0x7c
console_unlock+0x328/0x634
vprintk_emit+0x25c/0x390
dev_vprintk_emit+0xc4/0x1fc
dev_printk_emit+0x88/0xa8
__dev_printk+0x58/0x9c
_dev_info+0x84/0xa8
usb_new_device+0x100/0x474
hub_port_connect+0x280/0x92c
hub_event+0x740/0xa84
process_one_work+0x240/0x70c
worker_thread+0x60/0x400
kthread+0x110/0x13c
ret_from_fork+0x10/0x18

 -> #0 ((console_sem).lock){-...}:
validate_chain.isra.34+0x6e4/0xa20
__lock_acquire+0x3b4/0x6e0
lock_acquire+0xf4/0x2a8
_raw_spin_lock_irqsave+0x58/0x70
down_trylock+0x20/0x4c
__down_trylock_console_sem+0x3c/0x9c
console_trylock+0x20/0xb0
vprintk_emit+0x254/0x390
vprintk_default+0x58/0x90
vprintk_func+0xbc/0x164
printk+0x80/0xa0
__dynamic_pr_debug+0x84/0xac
gic_raise_softirq+0x184/0x18c
smp_cross_call+0xac/0x218
smp_send_reschedule+0x3c/0x48
resched_curr+0x60/0x9c
check_preempt_curr+0x70/0xdc
wake_up_new_task+0x310/0x470
_do_fork+0x188/0x78c
SyS_clone+0x44/0x50
__sys_trace_return+0x0/0x4

 other info that might help us debug this:

 Chain exists of:
   (console_sem).lock --> >pi_lock --> >lock

  Possible unsafe locking scenario:

CPU0CPU1

   lock(>lock);
lock(>pi_lock);
lock(>lock);
   lock((console_sem).lock);

  *** DEADLOCK ***

 2 locks held by dynamic_debug01/1873:
  #0:  (>pi_lock){-.-.}, at: [<1366df53>] wake_up_new_task+0x40/0x470
  #1:  (>lock){-.-.}, at: [<842e1587>] __task_rq_lock+0x54/0xdc

 stack backtrace:
 CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: GW4.15.0+ #1
 Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
 Call trace:
  dump_backtrace+0x0/0x188
  show_stack+0x24/0x2c
  dump_stack+0xa4/0xe0
  print_circular_bug.isra.31+0x29c/0x2b8
  check_prev_add.constprop.39+0x6c8/0x6dc
  validate_chain.isra.34+0x6e4/0xa20
  __lock_acquire+0x3b4/0x6e0
  lock_acquire+0xf4/0x2a8
  _raw_spin_lock_irqsave+0x58/0x70
  down_trylock+0x20/0x4c
  __down_trylock_console_sem+0x3c/0x9c
  console_trylock+0x20/0xb0
  vprintk_emit+0x254/0x390
  vprintk_default+0x58/0x90
  vprintk_func+0xbc/0x164
  printk+0x80/0xa0
  __dynamic_pr_debug+0x84/0xac
  gic_raise_softirq+0x184/0x18c
  smp_cross_call+0xac/0x218
  smp_send_reschedule+0x3c/0x48
  resched_curr+0x60/0x9c
  check_preempt_curr+0x70/0xdc
  wake_up_new_task+0x310/0x470
  _do_fork+0x188/0x78c
  SyS_clone+0x44/0x50
  __sys_trace_return+0x0/0x4
 GICv3: CPU0: ICC_SGI1R_EL1 12000

This could be fixed with printk_deferred() but that might lessen its
usefulness for debugging. So change it to pr_devel to keep it out of
production kernels. Developers working on gic-v3 can enable it as
needed in their kernels.

Signed-off-by: Mark Salter 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/irqchip/irq-gic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index eed31f9bee05..cb0d0caadc3f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -589,7 +589,7 @@ static void gic_send_sgi(u64 cluster_id, u16 tlist, 
unsigned int irq)
   MPIDR_TO_SGI_AFFINITY(cluster_id, 1) |
   tlist << ICC_SGI1R_TARGET_LIST_SHIFT);

[PATCH AUTOSEL for 3.18 003/101] perf/core: Correct event creation with PERF_FORMAT_GROUP

2018-04-08 Thread Sasha Levin
From: Peter Zijlstra 

[ Upstream commit ba5213ae6b88fb170c4771fef6553f759c7d8cdd ]

Andi was asking about PERF_FORMAT_GROUP vs inherited events, which led
to the discovery of a bug from commit:

  3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")

 -   PERF_SAMPLE_GROUP   = 1U << 4,
 +   PERF_SAMPLE_READ= 1U << 4,

 -   if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP))
 +   if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))

is a clear fail :/

While this changes user visible behaviour; it was previously possible
to create an inherited event with PERF_SAMPLE_READ; this is deemed
acceptible because its results were always incorrect.

Reported-by: Andi Kleen 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes:  3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")
Link: 
http://lkml.kernel.org/r/20170530094512.dy2nljns2uq7q...@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/events/core.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index de3303aab7d6..9eb7710914fb 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4861,9 +4861,6 @@ static void perf_output_read_one(struct 
perf_output_handle *handle,
__output_copy(handle, values, n * sizeof(u64));
 }
 
-/*
- * XXX PERF_FORMAT_GROUP vs inherited events seems difficult.
- */
 static void perf_output_read_group(struct perf_output_handle *handle,
struct perf_event *event,
u64 enabled, u64 running)
@@ -4908,6 +4905,13 @@ static void perf_output_read_group(struct 
perf_output_handle *handle,
 #define PERF_FORMAT_TOTAL_TIMES (PERF_FORMAT_TOTAL_TIME_ENABLED|\
 PERF_FORMAT_TOTAL_TIME_RUNNING)
 
+/*
+ * XXX PERF_SAMPLE_READ vs inherited events seems difficult.
+ *
+ * The problem is that its both hard and excessively expensive to iterate the
+ * child list, not to mention that its impossible to IPI the children running
+ * on another CPU, from interrupt/NMI context.
+ */
 static void perf_output_read(struct perf_output_handle *handle,
 struct perf_event *event)
 {
@@ -7194,9 +7198,10 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
local64_set(>period_left, hwc->sample_period);
 
/*
-* we currently do not support PERF_FORMAT_GROUP on inherited events
+* We currently do not support PERF_SAMPLE_READ on inherited events.
+* See perf_output_read().
 */
-   if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))
+   if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ))
goto err_ns;
 
pmu = perf_init_event(event);
-- 
2.15.1


[PATCH AUTOSEL for 4.4 158/162] bcache: return attach error when no cache set exist

2018-04-08 Thread Sasha Levin
From: Tang Junhui 

[ Upstream commit 7f4fc93d4713394ee8f1cd44c238e046e11b4f15 ]

I attach a back-end device to a cache set, and the cache set is not
registered yet, this back-end device did not attach successfully, and no
error returned:
[root]# echo 87859280-fec6-4bcc-20df7ca8f86b > /sys/block/sde/bcache/attach
[root]#

In sysfs_attach(), the return value "v" is initialized to "size" in
the beginning, and if no cache set exist in bch_cache_sets, the "v" value
would not change any more, and return to sysfs, sysfs regard it as success
since the "size" is a positive number.

This patch fixes this issue by assigning "v" with "-ENOENT" in the
initialization.

Signed-off-by: Tang Junhui 
Reviewed-by: Michael Lyle 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/sysfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 1efe31615281..5a5c1f1bd8a5 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -191,7 +191,7 @@ STORE(__cached_dev)
 {
struct cached_dev *dc = container_of(kobj, struct cached_dev,
 disk.kobj);
-   ssize_t v = size;
+   ssize_t v;
struct cache_set *c;
struct kobj_uevent_env *env;
 
@@ -268,6 +268,7 @@ STORE(__cached_dev)
if (bch_parse_uuid(buf, set_uuid) < 16)
return -EINVAL;
 
+   v = -ENOENT;
list_for_each_entry(c, _cache_sets, list) {
v = bch_cached_dev_attach(dc, c, set_uuid);
if (!v)
@@ -275,7 +276,7 @@ STORE(__cached_dev)
}
 
pr_err("Can't attach %s: cache set not found", buf);
-   size = v;
+   return v;
}
 
if (attr == _detach && dc->disk.c)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 006/101] net: emac: fix reset timeout with AR8035 phy

2018-04-08 Thread Sasha Levin
From: Christian Lamparter 

[ Upstream commit 19d90ece81da802207a9b91ce95a29fbdc40626e ]

This patch fixes a problem where the AR8035 PHY can't be
detected on an Cisco Meraki MR24, if the ethernet cable is
not connected on boot.

Russell Senior provided steps to reproduce the issue:
|Disconnect ethernet cable, apply power, wait until device has booted,
|plug in ethernet, check for interfaces, no eth0 is listed.
|
|This appears to be a problem during probing of the AR8035 Phy chip.
|When ethernet has no link, the phy detection fails, and eth0 is not
|created. Plugging ethernet later has no effect, because there is no
|interface as far as the kernel is concerned. The relevant part of
|the boot log looks like this:
|this is the failing case:
|
|[0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[0.882532] /plb/opb/ethernet@ef600c00: reset timeout
|[0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
|and the succeeding case:
|
|[0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
|[0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)

Based on the comment and the commit message of
commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT").
This is because the AR8035 PHY doesn't provide the TX Clock,
if the ethernet cable is not attached. This causes the reset
to timeout and the PHY detection code in emac_init_phy() is
unable to detect the AR8035 PHY. As a result, the emac driver
bails out early and the user left with no ethernet.

In order to stay compatible with existing configurations, the driver
tries the current reset approach at first. Only if the first attempt
timed out, it does perform one more retry with the clock temporarily
switched to the internal source for just the duration of the reset.

LEDE-Bug: #687 

Cc: Chris Blake 
Reported-by: Russell Senior 
Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")
Signed-off-by: Christian Lamparter 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/ibm/emac/core.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ibm/emac/core.c 
b/drivers/net/ethernet/ibm/emac/core.c
index 87bd953cc2ee..41ce1aafcc1c 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -349,6 +349,7 @@ static int emac_reset(struct emac_instance *dev)
 {
struct emac_regs __iomem *p = dev->emacp;
int n = 20;
+   bool __maybe_unused try_internal_clock = false;
 
DBG(dev, "reset" NL);
 
@@ -361,6 +362,7 @@ static int emac_reset(struct emac_instance *dev)
}
 
 #ifdef CONFIG_PPC_DCR_NATIVE
+do_retry:
/*
 * PPC460EX/GT Embedded Processor Advanced User's Manual
 * section 28.10.1 Mode Register 0 (EMACx_MR0) states:
@@ -368,10 +370,19 @@ static int emac_reset(struct emac_instance *dev)
 * of the EMAC. If none is present, select the internal clock
 * (SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
 * After a soft reset, select the external clock.
+*
+* The AR8035-A PHY Meraki MR24 does not provide a TX Clk if the
+* ethernet cable is not attached. This causes the reset to timeout
+* and the PHY detection code in emac_init_phy() is unable to
+* communicate and detect the AR8035-A PHY. As a result, the emac
+* driver bails out early and the user has no ethernet.
+* In order to stay compatible with existing configurations, the
+* driver will temporarily switch to the internal clock, after
+* the first reset fails.
 */
if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
-   if (dev->phy_address == 0x &&
-   dev->phy_map == 0x) {
+   if (try_internal_clock || (dev->phy_address == 0x &&
+  dev->phy_map == 0x)) {
/* No PHY: select internal loop clock before reset */
dcri_clrset(SDR0, SDR0_ETH_CFG,
0, SDR0_ETH_CFG_ECS << dev->cell_index);
@@ -389,8 +400,15 @@ static int emac_reset(struct emac_instance *dev)
 
 #ifdef CONFIG_PPC_DCR_NATIVE
if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
-   if (dev->phy_address == 0x &&
-   dev->phy_map == 0x) {
+   if (!n && !try_internal_clock) {
+   /* first attempt has timed out. */
+   n = 20;
+   try_internal_clock = true;
+   goto 

Re: KASAN: use-after-free Read in inet_create

2018-04-08 Thread Sowmini Varadhan

#syz dup: KASAN: use-after-free Read in rds_cong_queue_updates

There  are a number of manifestations of this bug, basically
all suggest that the connect/reconnect etc workqs are somehow
being scheduled after the netns is deleted, despite the
code refactoring in Commit  3db6e0d172c (and looks like
the WARN_ONs in that commit are not even being triggered).
We've not been able to reproduce this issues, and without
a crash dump (or some hint of other threads that were running
at the time of the problem) are working on figuring out
the root-cause by code-inspection.

--Sowmini



[PATCH AUTOSEL for 4.4 095/162] fs: warn in case userspace lied about modprobe return

2018-04-08 Thread Sasha Levin
From: "Luis R. Rodriguez" 

[ Upstream commit 41124db869b7e00e12052555f8987867ac01d70c ]

kmod <= v19 was broken -- it could return 0 to modprobe calls,
incorrectly assuming that a kernel module was built-in, whereas in
reality the module was just forming in the kernel. The reason for this
is an incorrect userspace heuristics. A userspace kmod fix is available
for it [0], however should userspace break again we could go on with
an failed get_fs_type() which is hard to debug as the request_module()
is detected as returning 0. The first suspect would be that there is
something worth with the kernel's module loader and obviously in this
case that is not the issue.

Since these issues are painful to debug complain when we know userspace
has outright lied to us.

[0] 
http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkmod-module.c?id=fd44a98ae2eb5eb32161088954ab21e58e19dfc4

Suggested-by: Rusty Russell 
Cc: Jessica Yu 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin 
---
 fs/filesystems.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/filesystems.c b/fs/filesystems.c
index 5797d45a78cb..2a7ae03f821e 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -275,8 +275,10 @@ struct file_system_type *get_fs_type(const char *name)
int len = dot ? dot - name : strlen(name);
 
fs = __get_fs_type(name, len);
-   if (!fs && (request_module("fs-%.*s", len, name) == 0))
+   if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
fs = __get_fs_type(name, len);
+   WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no 
fs?\n", len, name);
+   }
 
if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
put_filesystem(fs);
-- 
2.15.1


[PATCH AUTOSEL for 4.4 086/162] MIPS: VDSO: Fix conversions in do_monotonic()/do_monotonic_coarse()

2018-04-08 Thread Sasha Levin
From: Goran Ferenc 

[ Upstream commit 8ec7f15b8cca4f790df5cdf33f26e2926d4ee2fd ]

Fix incorrect calculation in do_monotonic() and do_monotonic_coarse()
function that in turn caused incorrect values returned by the vdso
version of system call clock_gettime() on mips64 if its system clock
ID parameter was CLOCK_MONOTONIC or CLOCK_MONOTONIC_COARSE.

Consider these variables and their types on mips32 and mips64:

tk->wall_to_monotonic.tv_sec  s64, s64   (kernel/vdso.c)
vdso_data.wall_to_mono_secu32, u32   (kernel/vdso.c)
to_mono_sec   u32, u32   (vdso/gettimeofday.c)
ts->tv_secs32, s64   (vdso/gettimeofday.c)

For mips64 case, u32 vdso_data.wall_to_mono_sec variable is updated
from the 64-bit signed variable tk->wall_to_monotonic.tv_sec
(kernel/vdso.c:76) which is a negative number holding the time passed
from 1970-01-01 to the time boot started. This 64-bit signed value is
currently around 47+ years, in seconds. For instance, let this value
be:

-1489757461

or

 1010011100110101101011101011

By updating 32-bit vdso_data.wall_to_mono_sec variable, we lose upper
32 bits (signed 1's).

to_mono_sec variable is a parameter of do_monotonic() and
do_monotonic_coarse() functions which holds vdso_data.wall_to_mono_sec
value. Its value needs to be added (or subtracted considering it holds
negative value from the tk->wall_to_monotonic.tv_sec) to the current
time passed from 1970-01-01 (ts->tv_sec), which is again something like
47+ years, but increased by the time passed from the boot to the
current time. ts->tv_sec is 32-bit long in case of 32-bit architecture
and 64-bit long in case of 64-bit architecture. Consider the update of
ts->tv_sec (vdso/gettimeofday.c:55 & 167):

ts->tv_sec += to_mono_sec;

mips32 case: This update will be performed correctly, since both
ts->tv_sec and to_mono_sec are 32-bit long and the sign in to_mono_sec
is preserved. Implicit conversion from u32 to s32 will be done
correctly.

mips64 case: This update will be wrong, since the implicit conversion
will not be done correctly. The reason is that the conversion will be
from u32 to s64. This is because to_mono_sec is 32-bit long for both
mips32 and mips64 cases and s64..33 bits of converted to_mono_sec
variable will be zeros.

So, in order to make MIPS64 implementation work properly for
MONOTONIC and MONOTONIC_COARSE clock ids on mips64, the size of
wall_to_mono_sec variable in mips_vdso_data union and respective
parameters in do_monotonic() and do_monotonic_coarse() functions
should be changed from u32 to u64. Because of consistency, this
size change from u32 and u64 is also done for wall_to_mono_nsec
variable and corresponding function parameters.

As far as similar situations for other architectures are concerned,
let's take a look at arm. Arm has two distinct vdso_data structures
for 32-bit & 64-bit cases, and arm's wall_to_mono_sec and
wall_to_mono_nsec are u32 for 32-bit and u64 for 64-bit cases.
On the other hand, MIPS has only one structure (mips_vdso_data),
hence the need for changing the size of above mentioned parameters.

Signed-off-by: Goran Ferenc 
Signed-off-by: Miodrag Dinic 
Signed-off-by: Aleksandar Markovic 
Cc: Douglas Leung 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Petar Jovanovic 
Cc: Raghu Gandham 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16638/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/include/asm/vdso.h  | 4 ++--
 arch/mips/vdso/gettimeofday.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/mips/include/asm/vdso.h b/arch/mips/include/asm/vdso.h
index 8f4ca5dd992b..b7cd6cf77b83 100644
--- a/arch/mips/include/asm/vdso.h
+++ b/arch/mips/include/asm/vdso.h
@@ -79,8 +79,8 @@ union mips_vdso_data {
struct {
u64 xtime_sec;
u64 xtime_nsec;
-   u32 wall_to_mono_sec;
-   u32 wall_to_mono_nsec;
+   u64 wall_to_mono_sec;
+   u64 wall_to_mono_nsec;
u32 seq_count;
u32 cs_shift;
u8 clock_mode;
diff --git a/arch/mips/vdso/gettimeofday.c b/arch/mips/vdso/gettimeofday.c
index ce89c9e294f9..fd7d433970bf 100644
--- a/arch/mips/vdso/gettimeofday.c
+++ b/arch/mips/vdso/gettimeofday.c
@@ -39,8 +39,8 @@ static __always_inline int do_monotonic_coarse(struct 
timespec *ts,
   const union mips_vdso_data *data)
 {
u32 start_seq;
-   u32 to_mono_sec;
-   u32 to_mono_nsec;
+   u64 to_mono_sec;
+   u64 to_mono_nsec;
 
do {
start_seq = 

[PATCH AUTOSEL for 4.4 088/162] MIPS: VDSO: Add implementation of clock_gettime() fallback

2018-04-08 Thread Sasha Levin
From: Goran Ferenc 

[ Upstream commit 180902e08f051f72c89ffa366f4e4f7a8e9c753e ]

This patch adds clock_gettime_fallback() function that wraps assembly
invocation of clock_gettime() syscall using __NR_clock_gettime.

This function is used if pure VDSO implementation of clock_gettime()
does not succeed for any reason. For example, it is called if the
clkid parameter of clock_gettime() is not one of the clkids listed
in the switch-case block of the function __vdso_clock_gettime()
(one such case for clkid is CLOCK_BOOTIME).

If syscall invocation via __NR_clock_gettime fails, register a3 will
be set. So, after the syscall, register a3 is tested and the return
value is negated if it's set.

Signed-off-by: Goran Ferenc 
Signed-off-by: Miodrag Dinic 
Signed-off-by: Aleksandar Markovic 
Cc: Douglas Leung 
Cc: James Hogan 
Cc: Paul Burton 
Cc: Petar Jovanovic 
Cc: Raghu Gandham 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16639/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/vdso/gettimeofday.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/mips/vdso/gettimeofday.c b/arch/mips/vdso/gettimeofday.c
index fd7d433970bf..5f6337545ee2 100644
--- a/arch/mips/vdso/gettimeofday.c
+++ b/arch/mips/vdso/gettimeofday.c
@@ -20,6 +20,24 @@
 #include 
 #include 
 
+static __always_inline long clock_gettime_fallback(clockid_t _clkid,
+  struct timespec *_ts)
+{
+   register struct timespec *ts asm("a1") = _ts;
+   register clockid_t clkid asm("a0") = _clkid;
+   register long ret asm("v0");
+   register long nr asm("v0") = __NR_clock_gettime;
+   register long error asm("a3");
+
+   asm volatile(
+   "   syscall\n"
+   : "=r" (ret), "=r" (error)
+   : "r" (clkid), "r" (ts), "r" (nr)
+   : "memory");
+
+   return error ? -ret : ret;
+}
+
 static __always_inline int do_realtime_coarse(struct timespec *ts,
  const union mips_vdso_data *data)
 {
@@ -207,7 +225,7 @@ int __vdso_gettimeofday(struct timeval *tv, struct timezone 
*tz)
 int __vdso_clock_gettime(clockid_t clkid, struct timespec *ts)
 {
const union mips_vdso_data *data = get_vdso_data();
-   int ret;
+   int ret = -1;
 
switch (clkid) {
case CLOCK_REALTIME_COARSE:
@@ -223,10 +241,11 @@ int __vdso_clock_gettime(clockid_t clkid, struct timespec 
*ts)
ret = do_monotonic(ts, data);
break;
default:
-   ret = -ENOSYS;
break;
}
 
-   /* If we return -ENOSYS libc should fall back to a syscall. */
+   if (ret)
+   ret = clock_gettime_fallback(clkid, ts);
+
return ret;
 }
-- 
2.15.1


[PATCH AUTOSEL for 4.4 087/162] MIPS: Handle tlbex-tlbp race condition

2018-04-08 Thread Sasha Levin
From: Paul Burton 

[ Upstream commit f39878cc5b09c75d35eaf52131e920b872e3feb4 ]

In systems where there are multiple actors updating the TLB, the
potential exists for a race condition wherein a CPU hits a TLB exception
but by the time it reaches a TLBP instruction the affected TLB entry may
have been replaced. This can happen if, for example, a CPU shares the
TLB between hardware threads (VPs) within a core and one of them
replaces the entry that another has just taken a TLB exception for.

We handle this race in the case of the Hardware Table Walker (HTW) being
the other actor already, but didn't take into account the potential for
multiple threads racing. Include the code for aborting TLB exception
handling in affected multi-threaded systems, those being the I6400 &
I6500 CPUs which share TLB entries between VPs.

In the case of using RiXi without dedicated exceptions we have never
handled this race even for HTW. This patch adds WARN()s to these cases
which ought never to be hit because all CPUs with either HTW or shared
FTLB RAMs also include dedicated RiXi exceptions, but the WARN()s will
ensure this is always the case.

Signed-off-by: Paul Burton 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16203/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/mm/tlbex.c | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index 63b7d6f82d24..b639e12867ef 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -1876,6 +1876,26 @@ static void build_r3000_tlb_modify_handler(void)
 }
 #endif /* CONFIG_MIPS_PGD_C0_CONTEXT */
 
+static bool cpu_has_tlbex_tlbp_race(void)
+{
+   /*
+* When a Hardware Table Walker is running it can replace TLB entries
+* at any time, leading to a race between it & the CPU.
+*/
+   if (cpu_has_htw)
+   return true;
+
+   /*
+* If the CPU shares FTLB RAM with its siblings then our entry may be
+* replaced at any time by a sibling performing a write to the FTLB.
+*/
+   if (cpu_has_shared_ftlb_ram)
+   return true;
+
+   /* In all other cases there ought to be no race condition to handle */
+   return false;
+}
+
 /*
  * R4000 style TLB load/store/modify handlers.
  */
@@ -1912,7 +1932,7 @@ build_r4000_tlbchange_handler_head(u32 **p, struct 
uasm_label **l,
iPTE_LW(p, wr.r1, wr.r2); /* get even pte */
if (!m4kc_tlbp_war()) {
build_tlb_probe_entry(p);
-   if (cpu_has_htw) {
+   if (cpu_has_tlbex_tlbp_race()) {
/* race condition happens, leaving */
uasm_i_ehb(p);
uasm_i_mfc0(p, wr.r3, C0_INDEX);
@@ -1986,6 +2006,14 @@ static void build_r4000_tlb_load_handler(void)
}
uasm_i_nop();
 
+   /*
+* Warn if something may race with us & replace the TLB entry
+* before we read it here. Everything with such races should
+* also have dedicated RiXi exception handlers, so this
+* shouldn't be hit.
+*/
+   WARN(cpu_has_tlbex_tlbp_race(), "Unhandled race in RiXi path");
+
uasm_i_tlbr();
 
switch (current_cpu_type()) {
@@ -2053,6 +2081,14 @@ static void build_r4000_tlb_load_handler(void)
}
uasm_i_nop();
 
+   /*
+* Warn if something may race with us & replace the TLB entry
+* before we read it here. Everything with such races should
+* also have dedicated RiXi exception handlers, so this
+* shouldn't be hit.
+*/
+   WARN(cpu_has_tlbex_tlbp_race(), "Unhandled race in RiXi path");
+
uasm_i_tlbr();
 
switch (current_cpu_type()) {
-- 
2.15.1


[PATCH AUTOSEL for 4.4 080/162] s390/pci: improve error handling during interrupt deregistration

2018-04-08 Thread Sasha Levin
From: Sebastian Ott 

[ Upstream commit 4dfbd3efe3f0cf9ff1325b87491e1b1fe07afaf1 ]

When we ask a function to stop creating interrupts this may fail
due to the function being already gone (e.g. after hot-unplug).

Consequently we don't free associated resources like summary bits
and bit vectors used for irq processing. This could lead to
situations where we ran out of these resources and fail to setup
new interrupts.

The fix is to just ignore the errors in cases where we can be
sure no new interrupts are generated.

Signed-off-by: Sebastian Ott 
Reviewed-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
---
 arch/s390/include/asm/pci_insn.h |  2 +-
 arch/s390/pci/pci.c  | 29 +++--
 arch/s390/pci/pci_insn.c | 10 +-
 3 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/arch/s390/include/asm/pci_insn.h b/arch/s390/include/asm/pci_insn.h
index 9e02cb7955c1..a74efc02ad2c 100644
--- a/arch/s390/include/asm/pci_insn.h
+++ b/arch/s390/include/asm/pci_insn.h
@@ -76,7 +76,7 @@ struct zpci_fib {
u32 gd;
 } __packed __aligned(8);
 
-int zpci_mod_fc(u64 req, struct zpci_fib *fib);
+u8 zpci_mod_fc(u64 req, struct zpci_fib *fib, u8 *status);
 int zpci_refresh_trans(u64 fn, u64 addr, u64 range);
 int zpci_load(u64 *data, u64 req, u64 offset);
 int zpci_store(u64 data, u64 req, u64 offset);
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index ef0499b76c50..d95bfffdcc2e 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -113,6 +113,7 @@ static int zpci_set_airq(struct zpci_dev *zdev)
 {
u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_REG_INT);
struct zpci_fib fib = {0};
+   u8 status;
 
fib.isc = PCI_ISC;
fib.sum = 1;/* enable summary notifications */
@@ -122,7 +123,22 @@ static int zpci_set_airq(struct zpci_dev *zdev)
fib.aisb = (unsigned long) zpci_aisb_iv->vector + (zdev->aisb/64)*8;
fib.aisbo = zdev->aisb & 63;
 
-   return zpci_mod_fc(req, );
+   return zpci_mod_fc(req, , ) ? -EIO : 0;
+}
+
+/* Modify PCI: Unregister adapter interruptions */
+static int zpci_clear_airq(struct zpci_dev *zdev)
+{
+   u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_DEREG_INT);
+   struct zpci_fib fib = {0};
+   u8 cc, status;
+
+   cc = zpci_mod_fc(req, , );
+   if (cc == 3 || (cc == 1 && status == 24))
+   /* Function already gone or IRQs already deregistered. */
+   cc = 0;
+
+   return cc ? -EIO : 0;
 }
 
 struct mod_pci_args {
@@ -136,13 +152,14 @@ static int mod_pci(struct zpci_dev *zdev, int fn, u8 
dmaas, struct mod_pci_args
 {
u64 req = ZPCI_CREATE_REQ(zdev->fh, dmaas, fn);
struct zpci_fib fib = {0};
+   u8 status;
 
fib.pba = args->base;
fib.pal = args->limit;
fib.iota = args->iota;
fib.fmb_addr = args->fmb_addr;
 
-   return zpci_mod_fc(req, );
+   return zpci_mod_fc(req, , ) ? -EIO : 0;
 }
 
 /* Modify PCI: Register I/O address translation parameters */
@@ -164,14 +181,6 @@ int zpci_unregister_ioat(struct zpci_dev *zdev, u8 dmaas)
return mod_pci(zdev, ZPCI_MOD_FC_DEREG_IOAT, dmaas, );
 }
 
-/* Modify PCI: Unregister adapter interruptions */
-static int zpci_clear_airq(struct zpci_dev *zdev)
-{
-   struct mod_pci_args args = { 0, 0, 0, 0 };
-
-   return mod_pci(zdev, ZPCI_MOD_FC_DEREG_INT, 0, );
-}
-
 /* Modify PCI: Set PCI function measurement parameters */
 int zpci_fmb_enable_device(struct zpci_dev *zdev)
 {
diff --git a/arch/s390/pci/pci_insn.c b/arch/s390/pci/pci_insn.c
index bc065392f7ab..c005dbb01563 100644
--- a/arch/s390/pci/pci_insn.c
+++ b/arch/s390/pci/pci_insn.c
@@ -41,20 +41,20 @@ static inline u8 __mpcifc(u64 req, struct zpci_fib *fib, u8 
*status)
return cc;
 }
 
-int zpci_mod_fc(u64 req, struct zpci_fib *fib)
+u8 zpci_mod_fc(u64 req, struct zpci_fib *fib, u8 *status)
 {
-   u8 cc, status;
+   u8 cc;
 
do {
-   cc = __mpcifc(req, fib, );
+   cc = __mpcifc(req, fib, status);
if (cc == 2)
msleep(ZPCI_INSN_BUSY_DELAY);
} while (cc == 2);
 
if (cc)
-   zpci_err_insn(cc, status, req, 0);
+   zpci_err_insn(cc, *status, req, 0);
 
-   return (cc) ? -EIO : 0;
+   return cc;
 }
 
 /* Refresh PCI Translations */
-- 
2.15.1


[PATCH AUTOSEL for 4.4 090/162] arm64: ptrace: Avoid setting compat FP[SC]R to garbage if get_user fails

2018-04-08 Thread Sasha Levin
From: Dave Martin 

[ Upstream commit 53b1a742ed251780267a57415bc955bd50f40c3d ]

If get_user() fails when reading the new FPSCR value from userspace
in compat_vfp_get(), then garbage* will be written to the task's
FPSR and FPCR registers.

This patch prevents this by checking the return from get_user()
first.

[*] Actually, zero, due to the behaviour of get_user() on error, but
that's still not what userspace expects.

Fixes: 478fcb2cdb23 ("arm64: Debugging support")
Signed-off-by: Dave Martin 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
---
 arch/arm64/kernel/ptrace.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 183f39384e4c..b81fa63bc834 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -834,8 +834,10 @@ static int compat_vfp_set(struct task_struct *target,
 
if (count && !ret) {
ret = get_user(fpscr, (compat_ulong_t *)ubuf);
-   uregs->fpsr = fpscr & VFP_FPSCR_STAT_MASK;
-   uregs->fpcr = fpscr & VFP_FPSCR_CTRL_MASK;
+   if (!ret) {
+   uregs->fpsr = fpscr & VFP_FPSCR_STAT_MASK;
+   uregs->fpcr = fpscr & VFP_FPSCR_CTRL_MASK;
+   }
}
 
fpsimd_flush_task_state(target);
-- 
2.15.1


[PATCH AUTOSEL for 4.4 094/162] x86/um: thin archives build fix

2018-04-08 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit 827880ec260ba048f95fe646b96a205c394fa0f0 ]

The linker does not like vdso-syms.lds in input archive files.
Make it an extra-y instead.

Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: user-mode-linux-de...@lists.sourceforge.net
Signed-off-by: Nicholas Piggin 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 arch/x86/um/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 6c803ca49b5d..486f62c3bd04 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -50,7 +50,7 @@ CFLAGS_REMOVE_vdso-note.o = -pg -fprofile-arcs -ftest-coverage
 CFLAGS_REMOVE_um_vdso.o = -pg -fprofile-arcs -ftest-coverage
 
 targets += vdso-syms.lds
-obj-$(VDSO64-y)+= vdso-syms.lds
+extra-$(VDSO64-y)  += vdso-syms.lds
 
 #
 # Match symbols in the DSO that look like VDSO*; produce a file of constants.
-- 
2.15.1


[PATCH AUTOSEL for 4.4 051/162] mmc: mediatek: Fixed size in dma_free_coherent

2018-04-08 Thread Sasha Levin
From: Phong LE 

[ Upstream commit 16f2e0c6ffdfaf964bb0a6d5e67253a1c8116f0e ]

The dma gpd dma_free_coherent call size in invalid.

Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver")
Signed-off-by: Phong LE 
Signed-off-by: Neil Armstrong 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/mmc/host/mtk-sd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 0bf0d0e9dbdb..f701cbac2061 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1626,7 +1626,7 @@ static int msdc_drv_remove(struct platform_device *pdev)
pm_runtime_disable(host->dev);
pm_runtime_put_noidle(host->dev);
dma_free_coherent(>dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
host->dma.gpd, host->dma.gpd_addr);
dma_free_coherent(>dev, MAX_BD_NUM * sizeof(struct mt_bdma_desc),
host->dma.bd, host->dma.bd_addr);
-- 
2.15.1


[PATCH AUTOSEL for 4.4 045/162] NFC: nfcmrvl_uart: fix device-node leak during probe

2018-04-08 Thread Sasha Levin
From: Johan Hovold 

[ Upstream commit d0607aa4aee88cb097b694caa619e68f1e0a39c6 ]

Make sure to release the device-node reference when done parsing the
node.

Fixes: e097dc624f78 ("NFC: nfcmrvl: add UART driver")
Cc: Vincent Cuissard 
Signed-off-by: Johan Hovold 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Sasha Levin 
---
 drivers/nfc/nfcmrvl/uart.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nfc/nfcmrvl/uart.c b/drivers/nfc/nfcmrvl/uart.c
index 6c0c301611c4..91162f8e0366 100644
--- a/drivers/nfc/nfcmrvl/uart.c
+++ b/drivers/nfc/nfcmrvl/uart.c
@@ -84,6 +84,7 @@ static int nfcmrvl_uart_parse_dt(struct device_node *node,
ret = nfcmrvl_parse_dt(matched_node, pdata);
if (ret < 0) {
pr_err("Failed to get generic entries\n");
+   of_node_put(matched_node);
return ret;
}
 
@@ -97,6 +98,8 @@ static int nfcmrvl_uart_parse_dt(struct device_node *node,
else
pdata->break_control = 0;
 
+   of_node_put(matched_node);
+
return 0;
 }
 
-- 
2.15.1


Re: [PATCH] crypto: DRBG - guard uninstantion by lock

2018-04-08 Thread Theodore Y. Ts'o
On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote:
> Can you please check whether the attached patch fixes the issue?
> 

Stephan,

FYI, if you incude in your e-mail "#syz test  " as
the first line of your patch and the syzbot e-mail is cc'ed, the
syzbot will automatically apply the patch in the e-mail against the
git tree/branch specified in the "#syz test" line, and then try to see
if the problem it discovered still reproduces --- and then send you
e-mail one way or another.

So the syzbot will run while the patch goes through the normal e-mail
review process, which is kind of neat.  :-)

Cheers,

- Ted


[PATCH AUTOSEL for 4.15 133/189] IB/ipoib: Fix for potential no-carrier state

2018-04-08 Thread Sasha Levin
From: Alex Estrin 

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).

Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by: Mike Marciniszyn 
Reviewed-by: Ira Weiny 
Signed-off-by: Alex Estrin 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 160c5d9bca4c..4e75848f7a35 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2287,6 +2287,9 @@ static struct net_device *ipoib_add_port(const char 
*format,
  priv->ca, ipoib_event);
ib_register_event_handler(>event_handler);
 
+   /* call event handler to ensure pkey in sync */
+   queue_work(ipoib_workqueue, >flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error 
%d\n",
-- 
2.15.1


[PATCH AUTOSEL for 4.15 145/189] ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs

2018-04-08 Thread Sasha Levin
From: Hans de Goede 

[ Upstream commit 63347db0affadcbccd5613116ea8431c70139b3e ]

The acpi_get_bus_status wrapper for acpi_bus_get_status_handle has some
code to handle certain device quirks, in some cases we also need this
quirk handling for the initial _STA call.

Specifically on some devices calling _STA before all _DEP dependencies
are met results in errors like these:

[0.123579] ACPI Error: No handler for Region [ECRM] (ba9edc4c)
   [GenericSerialBus] (20170831/evregion-166)
[0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler
   (20170831/exfldio-299)
[0.123618] ACPI Error: Method parse/execution failed
   \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)

acpi_get_bus_status already has code to avoid this, so by using it we
also silence these errors from the initial _STA call.

Note that in order for the acpi_get_bus_status handling for this to work,
we initialize dep_unmet to 1 until acpi_device_dep_initialize gets called,
this means that battery devices will be instantiated with an initial
status of 0. This is not a problem, acpi_bus_attach will get called soon
after the instantiation anyways and it will update the status as first
point of order.

Signed-off-by: Hans de Goede 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/acpi/scan.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index b0fe5272c76a..8e63d937babb 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1565,6 +1565,8 @@ void acpi_init_device_object(struct acpi_device *device, 
acpi_handle handle,
device_initialize(>dev);
dev_set_uevent_suppress(>dev, true);
acpi_init_coherency(device);
+   /* Assume there are unmet deps until acpi_device_dep_initialize() runs 
*/
+   device->dep_unmet = 1;
 }
 
 void acpi_device_add_finalize(struct acpi_device *device)
@@ -1588,6 +1590,14 @@ static int acpi_add_single_object(struct acpi_device 
**child,
}
 
acpi_init_device_object(device, handle, type, sta);
+   /*
+* For ACPI_BUS_TYPE_DEVICE getting the status is delayed till here so
+* that we can call acpi_bus_get_status() and use its quirk handling.
+* Note this must be done before the get power-/wakeup_dev-flags calls.
+*/
+   if (type == ACPI_BUS_TYPE_DEVICE)
+   acpi_bus_get_status(device);
+
acpi_bus_get_power_flags(device);
acpi_bus_get_wakeup_device_flags(device);
 
@@ -1660,9 +1670,11 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
return -ENODEV;
 
*type = ACPI_BUS_TYPE_DEVICE;
-   status = acpi_bus_get_status_handle(handle, sta);
-   if (ACPI_FAILURE(status))
-   *sta = 0;
+   /*
+* acpi_add_single_object updates this once we've an acpi_device
+* so that acpi_bus_get_status' quirk handling can be used.
+*/
+   *sta = 0;
break;
case ACPI_TYPE_PROCESSOR:
*type = ACPI_BUS_TYPE_PROCESSOR;
@@ -1760,6 +1772,8 @@ static void acpi_device_dep_initialize(struct acpi_device 
*adev)
acpi_status status;
int i;
 
+   adev->dep_unmet = 0;
+
if (!acpi_has_method(adev->handle, "_DEP"))
return;
 
-- 
2.15.1


[PATCH AUTOSEL for 4.15 116/189] ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid

2018-04-08 Thread Sasha Levin
From: piaojun 

[ Upstream commit 025bcbde3634b2c9b316f227fed13ad6ad6817fb ]

If metadata is corrupted such as 'invalid inode block', we will get
failed by calling 'mount()' and then set filesystem readonly as below:

  ocfs2_mount
ocfs2_initialize_super
  ocfs2_init_global_system_inodes
ocfs2_iget
  ocfs2_read_locked_inode
ocfs2_validate_inode_block
  ocfs2_error
ocfs2_handle_error
  ocfs2_set_ro_flag(osb, 0);  // set readonly

In this situation we need return -EROFS to 'mount.ocfs2', so that user
can fix it by fsck.  And then mount again.  In addition, 'mount.ocfs2'
should be updated correspondingly as it only return 1 for all errno.
And I will post a patch for 'mount.ocfs2' too.

Link: http://lkml.kernel.org/r/5a4302fa.2010...@huawei.com
Signed-off-by: Jun Piao 
Reviewed-by: Alex Chen 
Reviewed-by: Joseph Qi 
Reviewed-by: Changwei Ge 
Reviewed-by: Gang He 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Junxiao Bi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 fs/ocfs2/super.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c
index 80efa5699fb0..63b3fa519758 100644
--- a/fs/ocfs2/super.c
+++ b/fs/ocfs2/super.c
@@ -474,9 +474,8 @@ static int ocfs2_init_global_system_inodes(struct 
ocfs2_super *osb)
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
-   status = -EINVAL;
+   status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog_errno(status);
-   /* FIXME: Should ERROR_RO_FS */
mlog(ML_ERROR, "Unable to load system inode %d, "
 "possibly corrupt fs?", i);
goto bail;
@@ -505,7 +504,7 @@ static int ocfs2_init_local_system_inodes(struct 
ocfs2_super *osb)
new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
if (!new) {
ocfs2_release_system_inodes(osb);
-   status = -EINVAL;
+   status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
mlog(ML_ERROR, "status=%d, sysfile=%d, slot=%d\n",
 status, i, osb->slot_num);
goto bail;
-- 
2.15.1


[PATCH AUTOSEL for 4.15 115/189] fs/dax.c: release PMD lock even when there is no PMD support in DAX

2018-04-08 Thread Sasha Levin
From: Jan H. Schönherr 

[ Upstream commit ee190ca6516bc8257e3d36187ca6f0f71a9ec477 ]

follow_pte_pmd() can theoretically return after having acquired a PMD
lock, even when DAX was not compiled with CONFIG_FS_DAX_PMD.

Release the PMD lock unconditionally.

Link: http://lkml.kernel.org/r/20180118133839.20587-1-jscho...@amazon.de
Fixes: f729c8c9b24f ("dax: wrprotect pmd_t in dax_mapping_entry_mkclean")
Signed-off-by: Jan H. Schönherr 
Reviewed-by: Ross Zwisler 
Reviewed-by: Andrew Morton 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index 95981591977a..c2ebf10b70da 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -636,8 +636,8 @@ static void dax_mapping_entry_mkclean(struct address_space 
*mapping,
pmd = pmd_mkclean(pmd);
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
 unlock_pmd:
-   spin_unlock(ptl);
 #endif
+   spin_unlock(ptl);
} else {
if (pfn != pte_pfn(*ptep))
goto unlock_pte;
-- 
2.15.1


[PATCH AUTOSEL for 4.15 120/189] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

2018-04-08 Thread Sasha Levin
From: Yisheng Xie 

[ Upstream commit 0486a38bcc4749808edbc848f1bcf232042770fc ]

As in manpage of migrate_pages, the errno should be set to EINVAL when
none of the node IDs specified by new_nodes are on-line and allowed by
the process's current cpuset context, or none of the specified nodes
contain memory.  However, when test by following case:

new_nodes = 0;
old_nodes = 0xf;
ret = migrate_pages(pid, old_nodes, new_nodes, MAX);

The ret will be 0 and no errno is set.  As the new_nodes is empty, we
should expect EINVAL as documented.

To fix the case like above, this patch check whether target nodes AND
current task_nodes is empty, and then check whether AND
node_states[N_MEMORY] is empty.

Link: 
http://lkml.kernel.org/r/1510882624-44342-4-git-send-email-xieyishe...@huawei.com
Signed-off-by: Yisheng Xie 
Acked-by: Vlastimil Babka 
Cc: Andi Kleen 
Cc: Chris Salls 
Cc: Christopher Lameter 
Cc: David Rientjes 
Cc: Ingo Molnar 
Cc: Naoya Horiguchi 
Cc: Tan Xiaojun 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 mm/mempolicy.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index c9b807eca74c..277b6454954e 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1435,10 +1435,14 @@ SYSCALL_DEFINE4(migrate_pages, pid_t, pid, unsigned 
long, maxnode,
goto out_put;
}
 
-   if (!nodes_subset(*new, node_states[N_MEMORY])) {
-   err = -EINVAL;
+   task_nodes = cpuset_mems_allowed(current);
+   nodes_and(*new, *new, task_nodes);
+   if (nodes_empty(*new))
+   goto out_put;
+
+   nodes_and(*new, *new, node_states[N_MEMORY]);
+   if (nodes_empty(*new))
goto out_put;
-   }
 
err = security_task_movememory(task);
if (err)
-- 
2.15.1


[PATCH AUTOSEL for 4.15 105/189] ntb_transport: Fix bug with max_mw_size parameter

2018-04-08 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit cbd27448faff4843ac4b66cc71445a10623ff48d ]

When using the max_mw_size parameter of ntb_transport to limit the size of
the Memory windows, communication cannot be established and the queues
freeze.

This is because the mw_size that's reported to the peer is correctly
limited but the size used locally is not. So the MW is initialized
with a buffer smaller than the window but the TX side is using the
full window. This means the TX side will be writing to a region of the
window that points nowhere.

This is easily fixed by applying the same limit to tx_size in
ntb_transport_init_queue().

Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Signed-off-by: Logan Gunthorpe 
Acked-by: Allen Hubbe 
Cc: Dave Jiang 
Signed-off-by: Jon Mason 
Signed-off-by: Sasha Levin 
---
 drivers/ntb/ntb_transport.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index 045e3dd4750e..9878c48826e3 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1003,6 +1003,9 @@ static int ntb_transport_init_queue(struct 
ntb_transport_ctx *nt,
mw_base = nt->mw_vec[mw_num].phys_addr;
mw_size = nt->mw_vec[mw_num].phys_size;
 
+   if (max_mw_size && mw_size > max_mw_size)
+   mw_size = max_mw_size;
+
tx_size = (unsigned int)mw_size / num_qps_mw;
qp_offset = tx_size * (qp_num / mw_count);
 
-- 
2.15.1


[PATCH AUTOSEL for 4.15 081/189] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-04-08 Thread Sasha Levin
From: David Herrmann 

[ Upstream commit 587d8628fb71c3bfae29fb2bbe84c1478c59bac8 ]

This patch prevents the thinkpad_acpi driver from warning about 2 event
codes returned for keyboard palm-detection. No behavioral changes,
other than suppressing the warning in the kernel log. The events are
still forwarded via acpi-netlink channels.

We could, optionally, decide to forward the event through a
input-switch on the tpacpi input device. However, so far no suitable
input-code exists, and no similar drivers report such events. Hence,
leave it an acpi event for now.

Note that the event-codes are named based on empirical studies. On the
ThinkPad X1 5th Gen the sensor can be found underneath the arrow key.

Cc: Matthew Thode 
Signed-off-by: David Herrmann 
Acked-by: Henrique de Moraes Holschuh 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/thinkpad_acpi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 117be48ff4de..128f91af716e 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -214,6 +214,10 @@ enum tpacpi_hkey_event_t {
/* AC-related events */
TP_HKEY_EV_AC_CHANGED   = 0x6040, /* AC status changed */
 
+   /* Further user-interface events */
+   TP_HKEY_EV_PALM_DETECTED= 0x60b0, /* palm hoveres keyboard */
+   TP_HKEY_EV_PALM_UNDETECTED  = 0x60b1, /* palm removed */
+
/* Misc */
TP_HKEY_EV_RFKILL_CHANGED   = 0x7000, /* rfkill switch changed */
 };
@@ -4079,6 +4083,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
*send_acpi_ev = false;
break;
 
+   case TP_HKEY_EV_PALM_DETECTED:
+   case TP_HKEY_EV_PALM_UNDETECTED:
+   /* palm detected hovering the keyboard, forward to user-space
+* via netlink for consumption */
+   return true;
+
default:
pr_warn("unknown possible thermal alarm or keyboard event 
received\n");
known = false;
-- 
2.15.1


[PATCH AUTOSEL for 4.15 143/189] ACPI: processor_perflib: Do not send _PPC change notification if not ready

2018-04-08 Thread Sasha Levin
From: Chen Yu 

[ Upstream commit ba1edb9a5125a617d612f98eead14b9b84e75c3a ]

The following warning was triggered after resumed from S3 -
if all the nonboot CPUs were put offline before suspend:

[ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 
0x86061e3a (native_read_msr+0xa/0x30)
[ 1840.329516] Call Trace:
[ 1840.329521]  __rdmsr_on_cpu+0x33/0x50
[ 1840.329525]  generic_exec_single+0x81/0xb0
[ 1840.329527]  smp_call_function_single+0xd2/0x100
[ 1840.329530]  ? acpi_ds_result_pop+0xdd/0xf2
[ 1840.329532]  ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329534]  rdmsrl_on_cpu+0x57/0x80
[ 1840.329536]  ? cpumask_next+0x1b/0x20
[ 1840.329538]  ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329541]  intel_pstate_update_perf_limits+0xf3/0x220
[ 1840.329544]  ? notifier_call_chain+0x4a/0x70
[ 1840.329546]  intel_pstate_set_policy+0x4e/0x150
[ 1840.329548]  cpufreq_set_policy+0xcd/0x2f0
[ 1840.329550]  cpufreq_update_policy+0xb2/0x130
[ 1840.329552]  ? cpufreq_update_policy+0x130/0x130
[ 1840.329556]  acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329558]  acpi_processor_notify+0x80/0x100
[ 1840.329561]  acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329563]  acpi_os_execute_deferred+0x14/0x20
[ 1840.329565]  process_one_work+0x193/0x3c0
[ 1840.329567]  worker_thread+0x35/0x3b0
[ 1840.329569]  kthread+0x125/0x140
[ 1840.329571]  ? process_one_work+0x3c0/0x3c0
[ 1840.329572]  ? kthread_park+0x60/0x60
[ 1840.329575]  ? do_syscall_64+0x67/0x180
[ 1840.329577]  ret_from_fork+0x25/0x30
[ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 
0x) at rIP: 0x86061f78 (native_write_msr+0x8/0x30)
[ 1840.329586] Call Trace:
[ 1840.329587]  __wrmsr_on_cpu+0x37/0x40
[ 1840.329589]  generic_exec_single+0x81/0xb0
[ 1840.329592]  smp_call_function_single+0xd2/0x100
[ 1840.329594]  ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329595]  ? cpumask_next+0x1b/0x20
[ 1840.329597]  wrmsrl_on_cpu+0x57/0x70
[ 1840.329598]  ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329599]  ? wrmsrl_on_cpu+0x57/0x70
[ 1840.329602]  intel_pstate_hwp_set+0xd3/0x150
[ 1840.329604]  intel_pstate_set_policy+0x119/0x150
[ 1840.329606]  cpufreq_set_policy+0xcd/0x2f0
[ 1840.329607]  cpufreq_update_policy+0xb2/0x130
[ 1840.329610]  ? cpufreq_update_policy+0x130/0x130
[ 1840.329613]  acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329615]  acpi_processor_notify+0x80/0x100
[ 1840.329617]  acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329619]  acpi_os_execute_deferred+0x14/0x20
[ 1840.329620]  process_one_work+0x193/0x3c0
[ 1840.329622]  worker_thread+0x35/0x3b0
[ 1840.329624]  kthread+0x125/0x140
[ 1840.329625]  ? process_one_work+0x3c0/0x3c0
[ 1840.329626]  ? kthread_park+0x60/0x60
[ 1840.329628]  ? do_syscall_64+0x67/0x180
[ 1840.329631]  ret_from_fork+0x25/0x30

This is because if there's only one online CPU, the MSR_PM_ENABLE
(package wide)can not be enabled after resumed, due to
intel_pstate_hwp_enable() will only be invoked on AP's online
process after resumed - if there's no AP online, the HWP remains
disabled after resumed (BIOS has disabled it in S3). Then if
there comes a _PPC change notification which touches HWP register
during this stage, the warning is triggered.

Since we don't call acpi_processor_register_performance() when
HWP is enabled, the pr->performance will be NULL. When this is
NULL we don't need to do _PPC change notification.

Reported-by: Doug Smythies 
Suggested-by: Srinivas Pandruvada 
Signed-off-by: Yu Chen 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/acpi/processor_perflib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 18b72eec3507..c7cf48ad5cb9 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -159,7 +159,7 @@ void acpi_processor_ppc_has_changed(struct acpi_processor 
*pr, int event_flag)
 {
int ret;
 
-   if (ignore_ppc) {
+   if (ignore_ppc || !pr->performance) {
/*
 * Only when it is notification event, the _OST object
 * will be evaluated. Otherwise it is skipped.
-- 
2.15.1


[PATCH AUTOSEL for 4.15 151/189] perf evsel: Fix period/freq terms setup

2018-04-08 Thread Sasha Levin
From: Jiri Olsa 

[ Upstream commit 49c0ae80eb32426fa133246200628e529067c595 ]

Stephane reported that we don't set properly PERIOD sample type for
events with period term defined.

Before:
  $ perf record -e cpu/cpu-cycles,period=1000/u ls
  $ perf evlist -v
  cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME|PERIOD, ...

After:
  $ perf record -e cpu/cpu-cycles,period=1000/u ls
  $ perf evlist -v
  cpu/cpu-cycles,period=1000/u: ... sample_type: IP|TID|TIME, ...

Setting PERIOD sample type based on period term setup.

Committer note:

When we use -c or a period=N term in the event definition, then we don't
need to ask the kernel, for this event, via perf_event_attr.sample_type
|= PERF_SAMPLE_PERIOD, to put the event period in each sample for this
event, as we know it already, it is in perf_event_attr.sample_period.

Reported-by: Stephane Eranian 
Signed-off-by: Jiri Olsa 
Tested-by: Stephane Eranian 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180201083812.11359-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/evsel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index d23a8c51b307..7349a5d22464 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -736,12 +736,14 @@ static void apply_config_terms(struct perf_evsel *evsel,
if (!(term->weak && opts->user_interval != ULLONG_MAX)) 
{
attr->sample_period = term->val.period;
attr->freq = 0;
+   perf_evsel__reset_sample_bit(evsel, PERIOD);
}
break;
case PERF_EVSEL__CONFIG_TERM_FREQ:
if (!(term->weak && opts->user_freq != UINT_MAX)) {
attr->sample_freq = term->val.freq;
attr->freq = 1;
+   perf_evsel__set_sample_bit(evsel, PERIOD);
}
break;
case PERF_EVSEL__CONFIG_TERM_TIME:
-- 
2.15.1


[PATCH AUTOSEL for 4.15 180/189] PM / wakeirq: Fix unbalanced IRQ enable for wakeirq

2018-04-08 Thread Sasha Levin
From: Tony Lindgren 

[ Upstream commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 ]

If a device is runtime PM suspended when we enter suspend and has
a dedicated wake IRQ, we can get the following warning:

WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
[  102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [] (dev_pm_arm_wake_irq+0x4c/0x60)
(dev_pm_arm_wake_irq) from []
 (device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from []
(dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from []
(suspend_devices_and_enter+0x30c/0xf14)
(suspend_devices_and_enter) from []
(enter_state+0xad4/0xbd8)
(enter_state) from [] (pm_suspend+0x38/0x98)
(pm_suspend) from [] (state_store+0x68/0xc8)

This is because the dedicated wake IRQ for the device may have been
already enabled earlier by dev_pm_enable_wake_irq_check().  Fix the
issue by checking for runtime PM suspended status.

This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal.  On resume, dmesg will have the warning above.

The reason why I have not run into this issue earlier has been that I
typically run my PM test cases from on a serial console instead over ssh.

Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend)
Signed-off-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/base/power/wakeirq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
index ae0429827f31..67c50738834b 100644
--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -323,7 +323,8 @@ void dev_pm_arm_wake_irq(struct wake_irq *wirq)
return;
 
if (device_may_wakeup(wirq->dev)) {
-   if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED)
+   if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED &&
+   !pm_runtime_status_suspended(wirq->dev))
enable_irq(wirq->irq);
 
enable_irq_wake(wirq->irq);
@@ -345,7 +346,8 @@ void dev_pm_disarm_wake_irq(struct wake_irq *wirq)
if (device_may_wakeup(wirq->dev)) {
disable_irq_wake(wirq->irq);
 
-   if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED)
+   if (wirq->status & WAKE_IRQ_DEDICATED_ALLOCATED &&
+   !pm_runtime_status_suspended(wirq->dev))
disable_irq_nosync(wirq->irq);
}
 }
-- 
2.15.1


[PATCH AUTOSEL for 4.15 161/189] bcache: fix for allocator and register thread race

2018-04-08 Thread Sasha Levin
From: Tang Junhui 

[ Upstream commit 682811b3ce1a5a4e20d700939a9042f01dbc66c4 ]

After long time running of random small IO writing,
I reboot the machine, and after the machine power on,
I found bcache got stuck, the stack is:
[root@ceph153 ~]# cat /proc/2510/task/*/stack
[] closure_sync+0x25/0x90 [bcache]
[] bch_journal+0x118/0x2b0 [bcache]
[] bch_journal_meta+0x47/0x70 [bcache]
[] bch_prio_write+0x237/0x340 [bcache]
[] bch_allocator_thread+0x3c8/0x3d0 [bcache]
[] kthread+0xcf/0xe0
[] ret_from_fork+0x58/0x90
[] 0x
[root@ceph153 ~]# cat /proc/2038/task/*/stack
[] __bch_btree_map_nodes+0x12d/0x150 [bcache]
[] bch_btree_insert+0xf1/0x170 [bcache]
[] bch_journal_replay+0x13f/0x230 [bcache]
[] run_cache_set+0x79a/0x7c2 [bcache]
[] register_bcache+0xd48/0x1310 [bcache]
[] kobj_attr_store+0xf/0x20
[] sysfs_write_file+0xc6/0x140
[] vfs_write+0xbd/0x1e0
[] SyS_write+0x7f/0xe0
[] system_call_fastpath+0x16/0x1
The stack shows the register thread and allocator thread
were getting stuck when registering cache device.

I reboot the machine several times, the issue always
exsit in this machine.

I debug the code, and found the call trace as bellow:
register_bcache()
   ==>run_cache_set()
  ==>bch_journal_replay()
 ==>bch_btree_insert()
==>__bch_btree_map_nodes()
   ==>btree_insert_fn()
  ==>btree_split() //node need split
 ==>btree_check_reserve()
In btree_check_reserve(), It will check if there is enough buckets
of RESERVE_BTREE type, since allocator thread did not work yet, so
no buckets of RESERVE_BTREE type allocated, so the register thread
waits on c->btree_cache_wait, and goes to sleep.

Then the allocator thread initialized, the call trace is bellow:
bch_allocator_thread()
==>bch_prio_write()
   ==>bch_journal_meta()
  ==>bch_journal()
 ==>journal_wait_for_write()
In journal_wait_for_write(), It will check if journal is full by
journal_full(), but the long time random small IO writing
causes the exhaustion of journal buckets(journal.blocks_free=0),
In order to release the journal buckets,
the allocator calls btree_flush_write() to flush keys to
btree nodes, and waits on c->journal.wait until btree nodes writing
over or there has already some journal buckets space, then the
allocator thread goes to sleep. but in btree_flush_write(), since
bch_journal_replay() is not finished, so no btree nodes have journal
(condition "if (btree_current_write(b)->journal)" never satisfied),
so we got no btree node to flush, no journal bucket released,
and allocator sleep all the times.

Through the above analysis, we can see that:
1) Register thread wait for allocator thread to allocate buckets of
   RESERVE_BTREE type;
2) Alloctor thread wait for register thread to replay journal, so it
   can flush btree nodes and get journal bucket.
   then they are all got stuck by waiting for each other.

Hua Rui provided a patch for me, by allocating some buckets of
RESERVE_BTREE type in advance, so the register thread can get bucket
when btree node splitting and no need to waiting for the allocator
thread. I tested it, it has effect, and register thread run a step
forward, but finally are still got stuck, the reason is only 8 bucket
of RESERVE_BTREE type were allocated, and in bch_journal_replay(),
after 2 btree nodes splitting, only 4 bucket of RESERVE_BTREE type left,
then btree_check_reserve() is not satisfied anymore, so it goes to sleep
again, and in the same time, alloctor thread did not flush enough btree
nodes to release a journal bucket, so they all got stuck again.

So we need to allocate more buckets of RESERVE_BTREE type in advance,
but how much is enough?  By experience and test, I think it should be
as much as journal buckets. Then I modify the code as this patch,
and test in the machine, and it works.

This patch modified base on Hua Rui’s patch, and allocate more buckets
of RESERVE_BTREE type in advance to avoid register thread and allocate
thread going to wait for each other.

[patch v2] ca->sb.njournal_buckets would be 0 in the first time after
cache creation, and no journal exists, so just 8 btree buckets is OK.

Signed-off-by: Hua Rui 
Signed-off-by: Tang Junhui 
Reviewed-by: Michael Lyle 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/btree.c |  9 ++---
 drivers/md/bcache/super.c | 13 -
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 81e8dc3dbe5e..45561f28e58a 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1871,14 +1871,17 @@ void bch_initial_gc_finish(struct cache_set *c)
 */
for_each_cache(ca, c, i) {
for_each_bucket(b, ca) {
-   if (fifo_full(>free[RESERVE_PRIO]))
+  

[PATCH AUTOSEL for 4.4 023/162] scsi: csiostor: Avoid content leaks and casts

2018-04-08 Thread Sasha Levin
From: Kees Cook 

[ Upstream commit 42c335f7e67029d2e01711f2f2bc6252277c8993 ]

When copying attributes, the len argument was padded out and the
resulting memcpy() would copy beyond the end of the source buffer.
Avoid this, and use size_t for val_len to avoid all the casts.
Similarly, avoid source buffer casts and use void *.

Additionally enforces val_len can be represented by u16 and that the DMA
buffer was not overflowed. Fixes the size of mfa, which is not
FC_FDMI_PORT_ATTR_MAXFRAMESIZE_LEN (but it will be padded up to 4). This
was noticed by the future CONFIG_FORTIFY_SOURCE checks.

Cc: Daniel Micay 
Signed-off-by: Kees Cook 
Acked-by: Varun Prakash 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/csiostor/csio_lnode.c | 43 +++---
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_lnode.c 
b/drivers/scsi/csiostor/csio_lnode.c
index c00b2ff72b55..be5ee2d37815 100644
--- a/drivers/scsi/csiostor/csio_lnode.c
+++ b/drivers/scsi/csiostor/csio_lnode.c
@@ -238,14 +238,23 @@ csio_osname(uint8_t *buf, size_t buf_len)
 }
 
 static inline void
-csio_append_attrib(uint8_t **ptr, uint16_t type, uint8_t *val, uint16_t len)
+csio_append_attrib(uint8_t **ptr, uint16_t type, void *val, size_t val_len)
 {
+   uint16_t len;
struct fc_fdmi_attr_entry *ae = (struct fc_fdmi_attr_entry *)*ptr;
+
+   if (WARN_ON(val_len > U16_MAX))
+   return;
+
+   len = val_len;
+
ae->type = htons(type);
len += 4;   /* includes attribute type and length */
len = (len + 3) & ~3;   /* should be multiple of 4 bytes */
ae->len = htons(len);
-   memcpy(ae->value, val, len);
+   memcpy(ae->value, val, val_len);
+   if (len > val_len)
+   memset(ae->value + val_len, 0, len - val_len);
*ptr += len;
 }
 
@@ -335,7 +344,7 @@ csio_ln_fdmi_rhba_cbfn(struct csio_hw *hw, struct 
csio_ioreq *fdmi_req)
numattrs++;
val = htonl(FC_PORTSPEED_1GBIT | FC_PORTSPEED_10GBIT);
csio_append_attrib(, FC_FDMI_PORT_ATTR_SUPPORTEDSPEED,
-  (uint8_t *),
+  ,
   FC_FDMI_PORT_ATTR_SUPPORTEDSPEED_LEN);
numattrs++;
 
@@ -346,23 +355,22 @@ csio_ln_fdmi_rhba_cbfn(struct csio_hw *hw, struct 
csio_ioreq *fdmi_req)
else
val = htonl(CSIO_HBA_PORTSPEED_UNKNOWN);
csio_append_attrib(, FC_FDMI_PORT_ATTR_CURRENTPORTSPEED,
-  (uint8_t *),
-  FC_FDMI_PORT_ATTR_CURRENTPORTSPEED_LEN);
+  , FC_FDMI_PORT_ATTR_CURRENTPORTSPEED_LEN);
numattrs++;
 
mfs = ln->ln_sparm.csp.sp_bb_data;
csio_append_attrib(, FC_FDMI_PORT_ATTR_MAXFRAMESIZE,
-  (uint8_t *), FC_FDMI_PORT_ATTR_MAXFRAMESIZE_LEN);
+  , sizeof(mfs));
numattrs++;
 
strcpy(buf, "csiostor");
csio_append_attrib(, FC_FDMI_PORT_ATTR_OSDEVICENAME, buf,
-  (uint16_t)strlen(buf));
+  strlen(buf));
numattrs++;
 
if (!csio_hostname(buf, sizeof(buf))) {
csio_append_attrib(, FC_FDMI_PORT_ATTR_HOSTNAME,
-  buf, (uint16_t)strlen(buf));
+  buf, strlen(buf));
numattrs++;
}
attrib_blk->numattrs = htonl(numattrs);
@@ -444,33 +452,32 @@ csio_ln_fdmi_dprt_cbfn(struct csio_hw *hw, struct 
csio_ioreq *fdmi_req)
 
strcpy(buf, "Chelsio Communications");
csio_append_attrib(, FC_FDMI_HBA_ATTR_MANUFACTURER, buf,
-  (uint16_t)strlen(buf));
+  strlen(buf));
numattrs++;
csio_append_attrib(, FC_FDMI_HBA_ATTR_SERIALNUMBER,
-  hw->vpd.sn, (uint16_t)sizeof(hw->vpd.sn));
+  hw->vpd.sn, sizeof(hw->vpd.sn));
numattrs++;
csio_append_attrib(, FC_FDMI_HBA_ATTR_MODEL, hw->vpd.id,
-  (uint16_t)sizeof(hw->vpd.id));
+  sizeof(hw->vpd.id));
numattrs++;
csio_append_attrib(, FC_FDMI_HBA_ATTR_MODELDESCRIPTION,
-  hw->model_desc, (uint16_t)strlen(hw->model_desc));
+  hw->model_desc, strlen(hw->model_desc));
numattrs++;
csio_append_attrib(, FC_FDMI_HBA_ATTR_HARDWAREVERSION,
-  hw->hw_ver, (uint16_t)sizeof(hw->hw_ver));
+  hw->hw_ver, sizeof(hw->hw_ver));
numattrs++;
csio_append_attrib(, FC_FDMI_HBA_ATTR_FIRMWAREVERSION,
-  hw->fwrev_str, (uint16_t)strlen(hw->fwrev_str));
+  

[PATCH AUTOSEL for 4.4 030/162] mtd: handle partitioning on devices with 0 erasesize

2018-04-08 Thread Sasha Levin
From: Chris Packham 

[ Upstream commit 1eeef2d7483a7e3f8d2dd2a5b9939b3b814dc549 ]

erasesize is meaningful for flash devices but for SRAM there is no
concept of an erase block so erasesize is set to 0. When partitioning
these devices instead of ensuring partitions fall on erasesize
boundaries we ensure they fall on writesize boundaries.

Helped-by: Boris Brezillon 
Signed-off-by: Chris Packham 
Acked-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin 
---
 drivers/mtd/mtdpart.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f8ba153f63bf..3b7ac1989f90 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -353,8 +353,12 @@ static struct mtd_part *allocate_partition(struct mtd_info 
*master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
 {
+   int wr_alignment = (master->flags & MTD_NO_ERASE) ? master->writesize:
+   master->erasesize;
struct mtd_part *slave;
+   u32 remainder;
char *name;
+   u64 tmp;
 
/* allocate the partition structure */
slave = kzalloc(sizeof(*slave), GFP_KERNEL);
@@ -449,10 +453,11 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
if (slave->offset == MTDPART_OFS_APPEND)
slave->offset = cur_offset;
if (slave->offset == MTDPART_OFS_NXTBLK) {
+   tmp = cur_offset;
slave->offset = cur_offset;
-   if (mtd_mod_by_eb(cur_offset, master) != 0) {
-   /* Round up to next erasesize */
-   slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) 
* master->erasesize;
+   remainder = do_div(tmp, wr_alignment);
+   if (remainder) {
+   slave->offset += wr_alignment - remainder;
printk(KERN_NOTICE "Moving partition %d: "
   "0x%012llx -> 0x%012llx\n", partno,
   (unsigned long long)cur_offset, (unsigned long 
long)slave->offset);
@@ -517,19 +522,22 @@ static struct mtd_part *allocate_partition(struct 
mtd_info *master,
slave->mtd.erasesize = master->erasesize;
}
 
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->offset, >mtd)) {
+   tmp = slave->offset;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
/* FIXME: Let it be writable if it is on a boundary of
 * _minor_ erase size though */
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase block boundary -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an 
erase/write block boundary -- force read-only\n",
part->name);
}
-   if ((slave->mtd.flags & MTD_WRITEABLE) &&
-   mtd_mod_by_eb(slave->mtd.size, >mtd)) {
+
+   tmp = slave->mtd.size;
+   remainder = do_div(tmp, wr_alignment);
+   if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
slave->mtd.flags &= ~MTD_WRITEABLE;
-   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase block -- force read-only\n",
+   printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an 
erase/write block -- force read-only\n",
part->name);
}
 
-- 
2.15.1


[PATCH AUTOSEL for 4.4 018/162] ACPICA: Events: Add runtime stub support for event APIs

2018-04-08 Thread Sasha Levin
From: Lv Zheng 

[ Upstream commit 861ba6351c520328e94a78c923b415faa9116287 ]

ACPICA commit 99bc3beca92c6574ea1d69de42e54f872e6373ce

It is reported that on Linux, RTC driver complains wrong errors on
hardware reduced platform:
  [4.085420] ACPI Warning: Could not enable fixed event - real_time_clock 
(4) (20160422/evxface-654)

This patch fixes this by correctly adding runtime reduced hardware check.
Reported by Chandan Tagore, fixed by Lv Zheng.

Link: https://github.com/acpica/acpica/commit/99bc3bec
Tested-by: Chandan Tagore 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/acpi/acpica/evxfevnt.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/acpi/acpica/evxfevnt.c b/drivers/acpi/acpica/evxfevnt.c
index 10ce48e16ebf..d830705f8a18 100644
--- a/drivers/acpi/acpica/evxfevnt.c
+++ b/drivers/acpi/acpica/evxfevnt.c
@@ -180,6 +180,12 @@ acpi_status acpi_enable_event(u32 event, u32 flags)
 
ACPI_FUNCTION_TRACE(acpi_enable_event);
 
+   /* If Hardware Reduced flag is set, there are no fixed events */
+
+   if (acpi_gbl_reduced_hardware) {
+   return_ACPI_STATUS(AE_OK);
+   }
+
/* Decode the Fixed Event */
 
if (event > ACPI_EVENT_MAX) {
@@ -237,6 +243,12 @@ acpi_status acpi_disable_event(u32 event, u32 flags)
 
ACPI_FUNCTION_TRACE(acpi_disable_event);
 
+   /* If Hardware Reduced flag is set, there are no fixed events */
+
+   if (acpi_gbl_reduced_hardware) {
+   return_ACPI_STATUS(AE_OK);
+   }
+
/* Decode the Fixed Event */
 
if (event > ACPI_EVENT_MAX) {
@@ -290,6 +302,12 @@ acpi_status acpi_clear_event(u32 event)
 
ACPI_FUNCTION_TRACE(acpi_clear_event);
 
+   /* If Hardware Reduced flag is set, there are no fixed events */
+
+   if (acpi_gbl_reduced_hardware) {
+   return_ACPI_STATUS(AE_OK);
+   }
+
/* Decode the Fixed Event */
 
if (event > ACPI_EVENT_MAX) {
-- 
2.15.1


[PATCH AUTOSEL for 4.9 265/293] IB/ipoib: Fix for potential no-carrier state

2018-04-08 Thread Sasha Levin
From: Alex Estrin 

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).

Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by: Mike Marciniszyn 
Reviewed-by: Ira Weiny 
Signed-off-by: Alex Estrin 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 0df7d4504c06..17c5bc7e8957 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2119,6 +2119,9 @@ static struct net_device *ipoib_add_port(const char 
*format,
goto event_failed;
}
 
+   /* call event handler to ensure pkey in sync */
+   queue_work(ipoib_workqueue, >flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error 
%d\n",
-- 
2.15.1


[PATCH AUTOSEL for 4.9 275/293] xen-netfront: Fix race between device setup and open

2018-04-08 Thread Sasha Levin
From: Ross Lagerwall 

[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]

When a netfront device is set up it registers a netdev fairly early on,
before it has set up the queues and is actually usable. A userspace tool
like NetworkManager will immediately try to open it and access its state
as soon as it appears. The bug can be reproduced by hotplugging VIFs
until the VM runs out of grant refs. It registers the netdev but fails
to set up any queues (since there are no more grant refs). In the
meantime, NetworkManager opens the device and the kernel crashes trying
to access the queues (of which there are none).

Fix this in two ways:
* For initial setup, register the netdev much later, after the queues
are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend
and the queues are recreated. It is possible (though highly unlikely) to
race with something opening the device and accessing the queues after
they have been destroyed but before they have been recreated. Extend the
region covered by the rtnl semaphore to protect against this race. There
is a possibility that we fail to recreate the queues so check for this
in the open function.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/net/xen-netfront.c | 46 --
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b09c81e882b4..9a583f862109 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -350,6 +350,9 @@ static int xennet_open(struct net_device *dev)
unsigned int i = 0;
struct netfront_queue *queue = NULL;
 
+   if (!np->queues)
+   return -ENODEV;
+
for (i = 0; i < num_queues; ++i) {
queue = >queues[i];
napi_enable(>napi);
@@ -1377,18 +1380,8 @@ static int netfront_probe(struct xenbus_device *dev,
 #ifdef CONFIG_SYSFS
info->netdev->sysfs_groups[0] = _dev_group;
 #endif
-   err = register_netdev(info->netdev);
-   if (err) {
-   pr_warn("%s: register_netdev err=%d\n", __func__, err);
-   goto fail;
-   }
 
return 0;
-
- fail:
-   xennet_free_netdev(netdev);
-   dev_set_drvdata(>dev, NULL);
-   return err;
 }
 
 static void xennet_end_access(int ref, void *page)
@@ -1757,8 +1750,6 @@ static void xennet_destroy_queues(struct netfront_info 
*info)
 {
unsigned int i;
 
-   rtnl_lock();
-
for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
struct netfront_queue *queue = >queues[i];
 
@@ -1767,8 +1758,6 @@ static void xennet_destroy_queues(struct netfront_info 
*info)
netif_napi_del(>napi);
}
 
-   rtnl_unlock();
-
kfree(info->queues);
info->queues = NULL;
 }
@@ -1784,8 +1773,6 @@ static int xennet_create_queues(struct netfront_info 
*info,
if (!info->queues)
return -ENOMEM;
 
-   rtnl_lock();
-
for (i = 0; i < *num_queues; i++) {
struct netfront_queue *queue = >queues[i];
 
@@ -1794,7 +1781,7 @@ static int xennet_create_queues(struct netfront_info 
*info,
 
ret = xennet_init_queue(queue);
if (ret < 0) {
-   dev_warn(>netdev->dev,
+   dev_warn(>xbdev->dev,
 "only created %d queues\n", i);
*num_queues = i;
break;
@@ -1808,10 +1795,8 @@ static int xennet_create_queues(struct netfront_info 
*info,
 
netif_set_real_num_tx_queues(info->netdev, *num_queues);
 
-   rtnl_unlock();
-
if (*num_queues == 0) {
-   dev_err(>netdev->dev, "no queues\n");
+   dev_err(>xbdev->dev, "no queues\n");
return -EINVAL;
}
return 0;
@@ -1853,6 +1838,7 @@ static int talk_to_netback(struct xenbus_device *dev,
goto out;
}
 
+   rtnl_lock();
if (info->queues)
xennet_destroy_queues(info);
 
@@ -1863,6 +1849,7 @@ static int talk_to_netback(struct xenbus_device *dev,
info->queues = NULL;
goto out;
}
+   rtnl_unlock();
 
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
@@ -1959,8 +1946,10 @@ abort_transaction_no_dev_fatal:
xenbus_transaction_end(xbt, 1);
  destroy_ring:
xennet_disconnect_backend(info);
+   rtnl_lock();
xennet_destroy_queues(info);
  out:
+   rtnl_unlock();
device_unregister(>dev);
return err;
 }
@@ -1996,6 +1985,15 @@ static int xennet_connect(struct net_device *dev)

[PATCH AUTOSEL for 4.4 029/162] PCI: Add domain number check to find_smbios_instance_string()

2018-04-08 Thread Sasha Levin
From: Sujith Pandel 

[ Upstream commit 6c51c82c60991bdbfb937f3bf0cdbe68d042073d ]

The function find_smbios_instance_string() does not consider the
PCI domain number.  As a result, SMBIOS type 41 device type instance
would be exported to sysfs for all the PCI domains which have a
PCI device with same bus/device/function, though PCI bus/device/func
from a specific PCI domain has SMBIOS type 41 device type instance
defined.

Address the issue by making find_smbios_instance_string() check PCI domain
number as well.

Reported-by: Shai Fultheim 
Suggested-by: Shai Fultheim 
Tested-by: Shai Fultheim 
Signed-off-by: Sujith Pandel 
Signed-off-by: Narendra K 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
---
 drivers/pci/pci-label.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 024b5c179348..5986aad76088 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -43,9 +43,11 @@ static size_t find_smbios_instance_string(struct pci_dev 
*pdev, char *buf,
 {
const struct dmi_device *dmi;
struct dmi_dev_onboard *donboard;
+   int domain_nr;
int bus;
int devfn;
 
+   domain_nr = pci_domain_nr(pdev->bus);
bus = pdev->bus->number;
devfn = pdev->devfn;
 
@@ -53,8 +55,9 @@ static size_t find_smbios_instance_string(struct pci_dev 
*pdev, char *buf,
while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD,
  NULL, dmi)) != NULL) {
donboard = dmi->device_data;
-   if (donboard && donboard->bus == bus &&
-   donboard->devfn == devfn) {
+   if (donboard && donboard->segment == domain_nr &&
+   donboard->bus == bus &&
+   donboard->devfn == devfn) {
if (buf) {
if (attribute == SMBIOS_ATTR_INSTANCE_SHOW)
return scnprintf(buf, PAGE_SIZE,
-- 
2.15.1


[PATCH AUTOSEL for 4.4 047/162] Btrfs: tolerate errors if we have retried successfully

2018-04-08 Thread Sasha Levin
From: Liu Bo 

[ Upstream commit e3d37faba2eb19a1d459917bbf54ac1c65711510 ]

With raid1 profile, dio read isn't tolerating IO errors if read length is
less than the stripe length (64K).

Our bio didn't get split in btrfs_submit_direct_hook() if (dip->flags &
BTRFS_DIO_ORIG_BIO_SUBMITTED) is true and that happens when the read
length is less than 64k.  In this case, if the underlying device returns
error somehow, bio->bi_error has recorded that error.

If we could recover the correct data from another copy in profile raid1/10/5/6,
with btrfs_subio_endio_read() returning 0, bio would have the correct data in
its vector, but bio->bi_error is not updated accordingly so that the following
dio_end_io(dio_bio, bio->bi_error) makes directIO think this read has failed.

This fixes the problem by setting bio's error to 0 if a good copy has been
found.

Signed-off-by: Liu Bo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/inode.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 81b5a461d94e..d56520e52dce 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8029,8 +8029,11 @@ static void btrfs_endio_direct_read(struct bio *bio)
struct btrfs_io_bio *io_bio = btrfs_io_bio(bio);
int err = bio->bi_error;
 
-   if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED)
+   if (dip->flags & BTRFS_DIO_ORIG_BIO_SUBMITTED) {
err = btrfs_subio_endio_read(inode, io_bio, err);
+   if (!err)
+   bio->bi_error = 0;
+   }
 
unlock_extent(_I(inode)->io_tree, dip->logical_offset,
  dip->logical_offset + dip->bytes - 1);
-- 
2.15.1


[PATCH AUTOSEL for 4.9 269/293] firmware: dmi_scan: Fix handling of empty DMI strings

2018-04-08 Thread Sasha Levin
From: Jean Delvare 

[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
  empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
  string.
* Strings starting with 8 spaces are all considered empty, even if
  non-space characters follow (sounds like a weird thing to do, but
  I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
  instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.

So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.

Signed-off-by: Jean Delvare 
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/dmi_scan.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 18afa448bb9a..659d5b29952f 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -18,7 +18,7 @@ EXPORT_SYMBOL_GPL(dmi_kobj);
  * of and an antecedent to, SMBIOS, which stands for System
  * Management BIOS.  See further: http://www.dmtf.org/standards
  */
-static const char dmi_empty_string[] = "";
+static const char dmi_empty_string[] = "";
 
 static u32 dmi_ver __initdata;
 static u32 dmi_len;
@@ -44,25 +44,21 @@ static int dmi_memdev_nr;
 static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
 {
const u8 *bp = ((u8 *) dm) + dm->length;
+   const u8 *nsp;
 
if (s) {
-   s--;
-   while (s > 0 && *bp) {
+   while (--s > 0 && *bp)
bp += strlen(bp) + 1;
-   s--;
-   }
-
-   if (*bp != 0) {
-   size_t len = strlen(bp)+1;
-   size_t cmp_len = len > 8 ? 8 : len;
 
-   if (!memcmp(bp, dmi_empty_string, cmp_len))
-   return dmi_empty_string;
+   /* Strings containing only spaces are considered empty */
+   nsp = bp;
+   while (*nsp == ' ')
+   nsp++;
+   if (*nsp != '\0')
return bp;
-   }
}
 
-   return "";
+   return dmi_empty_string;
 }
 
 static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
-- 
2.15.1


[PATCH AUTOSEL for 4.9 291/293] irqchip/gic-v3: Ignore disabled ITS nodes

2018-04-08 Thread Sasha Levin
From: Stephen Boyd 

[ Upstream commit 95a2562590c2f64a0398183f978d5cf3db6d0284 ]

On some platforms there's an ITS available but it's not enabled
because reading or writing the registers is denied by the
firmware. In fact, reading or writing them will cause the system
to reset. We could remove the node from DT in such a case, but
it's better to skip nodes that are marked as "disabled" in DT so
that we can describe the hardware that exists and use the status
property to indicate how the firmware has configured things.

Cc: Stuart Yoder 
Cc: Laurentiu Tudor 
Cc: Greg Kroah-Hartman 
Cc: Marc Zyngier 
Cc: Rajendra Nayak 
Signed-off-by: Stephen Boyd 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 drivers/irqchip/irq-gic-v3-its-pci-msi.c   | 2 ++
 drivers/irqchip/irq-gic-v3-its-platform-msi.c  | 2 ++
 drivers/irqchip/irq-gic-v3-its.c   | 2 ++
 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index 77931214d954..6b5f50e1fc72 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -132,6 +132,8 @@ static int __init its_pci_of_msi_init(void)
 
for (np = of_find_matching_node(NULL, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
+   if (!of_device_is_available(np))
+   continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
 
diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c 
b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
index 470b4aa7d62c..e4768fcdc672 100644
--- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
@@ -80,6 +80,8 @@ static int __init its_pmsi_init(void)
 
for (np = of_find_matching_node(NULL, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
+   if (!of_device_is_available(np))
+   continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
 
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ac15e5d5d9b2..558c7589c329 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1807,6 +1807,8 @@ static int __init its_of_probe(struct device_node *node)
 
for (np = of_find_matching_node(node, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
+   if (!of_device_is_available(np))
+   continue;
if (!of_property_read_bool(np, "msi-controller")) {
pr_warn("%s: no msi-controller property, ITS ignored\n",
np->full_name);
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c 
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index eaeb3c51e14b..cb95c3e940f1 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -75,6 +75,8 @@ int __init its_fsl_mc_msi_init(void)
 
for (np = of_find_matching_node(NULL, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
+   if (!of_device_is_available(np))
+   continue;
if (!of_property_read_bool(np, "msi-controller"))
continue;
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 096/101] bcache: properly set task state in bch_writeback_thread()

2018-04-08 Thread Sasha Levin
From: Coly Li 

[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]

Kernel thread routine bch_writeback_thread() has the following code block,

447 down_write(>writeback_lock);
448~450 if (check conditions) {
451 up_write(>writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }

If condition check is true, its task state is set to TASK_INTERRUPTIBLE
and call schedule() to wait for others to wake up it.

There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
   another process changes the condition and call wake_up_process(dc->
   writeback_thread), then at line 452 task state is set back to
   TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be
   waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
   will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and
   call do_exit(). It is not good to enter do_exit() with task state
   TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a
   warning message is reported by __might_sleep(): "WARNING: do not call
   blocking ops when !TASK_RUNNING; state=1 set at []".

For the first issue, task state should be set before condition checks.
Ineed because dc->writeback_lock is required when modifying all the
conditions, calling set_current_state() inside code block where dc->
writeback_lock is hold is safe. But this is quite implicit, so I still move
set_current_state() before all the condition checks.

For the second issue, frankley speaking it does not hurt when kernel thread
exits with TASK_INTERRUPTIBLE state, but this warning message scares users,
makes them feel there might be something risky with bcache and hurt their
data.  Setting task state to TASK_RUNNING before returning fixes this
problem.

In alloc.c:allocator_wait(), there is also a similar issue, and is also
fixed in this patch.

Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.

Signed-off-by: Coly Li 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Michael Lyle 
Cc: Michael Lyle 
Cc: Junhui Tang 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/alloc.c | 4 +++-
 drivers/md/bcache/writeback.c | 7 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/md/bcache/alloc.c b/drivers/md/bcache/alloc.c
index ea47980949ef..c1da2321bf26 100644
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -285,8 +285,10 @@ do {   
\
break;  \
\
mutex_unlock(&(ca)->set->bucket_lock);  \
-   if (kthread_should_stop())  \
+   if (kthread_should_stop()) {\
+   set_current_state(TASK_RUNNING);\
return 0;   \
+   }   \
\
try_to_freeze();\
schedule(); \
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index b0667b321a3f..50726f12a7c3 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -425,19 +425,22 @@ static int bch_writeback_thread(void *arg)
 
while (!kthread_should_stop()) {
down_write(>writeback_lock);
+   set_current_state(TASK_INTERRUPTIBLE);
if (!atomic_read(>has_dirty) ||
(!test_bit(BCACHE_DEV_DETACHING, >disk.flags) &&
 !dc->writeback_running)) {
up_write(>writeback_lock);
-   set_current_state(TASK_INTERRUPTIBLE);
 
-   if (kthread_should_stop())
+   if (kthread_should_stop()) {
+   set_current_state(TASK_RUNNING);
return 0;
+   }
 
try_to_freeze();
schedule();
continue;
}
+   set_current_state(TASK_RUNNING);
 
searched_full_index = refill_dirty(dc);
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 100/101] nfsd: return RESOURCE not GARBAGE_ARGS on too many ops

2018-04-08 Thread Sasha Levin
From: "J. Bruce Fields" 

[ Upstream commit 0078117c6d9160031b866cfa1853514d4f6865d2 ]

A client that sends more than a hundred ops in a single compound
currently gets an rpc-level GARBAGE_ARGS error.

It would be more helpful to return NFS4ERR_RESOURCE, since that gives
the client a better idea how to recover (for example by splitting up the
compound into smaller compounds).

This is all a bit academic since we've never actually seen a reason for
clients to send such long compounds, but we may as well fix it.

While we're there, just use NFSD4_MAX_OPS_PER_COMPOUND == 16, the
constant we already use in the 4.1 case, instead of hard-coding 100.
Chances anyone actually uses even 16 ops per compound are small enough
that I think there's a neglible risk or any regression.

This fixes pynfs test COMP6.

Reported-by: "Lu, Xinyu" 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin 
---
 fs/nfsd/nfs4proc.c | 3 +++
 fs/nfsd/nfs4xdr.c  | 9 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index f6429b3d89e2..a976c87eae49 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1342,6 +1342,9 @@ nfsd4_proc_compound(struct svc_rqst *rqstp,
status = nfserr_minor_vers_mismatch;
if (nfsd_minorversion(args->minorversion, NFSD_TEST) <= 0)
goto out;
+   status = nfserr_resource;
+   if (args->opcnt > NFSD_MAX_OPS_PER_COMPOUND)
+   goto out;
 
status = nfs41_check_op_ordering(args);
if (status) {
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 660c813467e2..c8ebd89f0f2d 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1655,8 +1655,13 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)
 
if (argp->taglen > NFSD4_MAX_TAGLEN)
goto xdr_error;
-   if (argp->opcnt > 100)
-   goto xdr_error;
+   /*
+* NFS4ERR_RESOURCE is a more helpful error than GARBAGE_ARGS
+* here, so we return success at the xdr level so that
+* nfsd4_proc can handle this is an NFS-level error.
+*/
+   if (argp->opcnt > NFSD_MAX_OPS_PER_COMPOUND)
+   return 0;
 
if (argp->opcnt > ARRAY_SIZE(argp->iops)) {
argp->ops = kzalloc(argp->opcnt * sizeof(*argp->ops), 
GFP_KERNEL);
-- 
2.15.1


[PATCH AUTOSEL for 3.18 090/101] firmware: dmi_scan: Fix handling of empty DMI strings

2018-04-08 Thread Sasha Levin
From: Jean Delvare 

[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
  empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
  string.
* Strings starting with 8 spaces are all considered empty, even if
  non-space characters follow (sounds like a weird thing to do, but
  I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
  instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.

So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.

Signed-off-by: Jean Delvare 
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Signed-off-by: Sasha Levin 
---
 drivers/firmware/dmi_scan.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index f4dbe6fe9dd9..0694e1b4004c 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -15,7 +15,7 @@
  * of and an antecedent to, SMBIOS, which stands for System
  * Management BIOS.  See further: http://www.dmtf.org/standards
  */
-static const char dmi_empty_string[] = "";
+static const char dmi_empty_string[] = "";
 
 static u16 __initdata dmi_ver;
 /*
@@ -36,25 +36,21 @@ static int dmi_memdev_nr;
 static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
 {
const u8 *bp = ((u8 *) dm) + dm->length;
+   const u8 *nsp;
 
if (s) {
-   s--;
-   while (s > 0 && *bp) {
+   while (--s > 0 && *bp)
bp += strlen(bp) + 1;
-   s--;
-   }
-
-   if (*bp != 0) {
-   size_t len = strlen(bp)+1;
-   size_t cmp_len = len > 8 ? 8 : len;
 
-   if (!memcmp(bp, dmi_empty_string, cmp_len))
-   return dmi_empty_string;
+   /* Strings containing only spaces are considered empty */
+   nsp = bp;
+   while (*nsp == ' ')
+   nsp++;
+   if (*nsp != '\0')
return bp;
-   }
}
 
-   return "";
+   return dmi_empty_string;
 }
 
 static const char * __init dmi_string(const struct dmi_header *dm, u8 s)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 088/101] IB/ipoib: Fix for potential no-carrier state

2018-04-08 Thread Sasha Levin
From: Alex Estrin 

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its
event handler, which could result in missing pkey event and leave root
interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will
fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value
opensm put in pkey table idx 0, resulting in connectivity issues
(different mcast groups, for example).

Close the window by calling event handler after registration
to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by: Mike Marciniszyn 
Reviewed-by: Ira Weiny 
Signed-off-by: Alex Estrin 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index dce94ba467b6..0e58a705b37e 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1644,6 +1644,9 @@ static struct net_device *ipoib_add_port(const char 
*format,
goto event_failed;
}
 
+   /* call event handler to ensure pkey in sync */
+   queue_work(ipoib_workqueue, >flush_heavy);
+
result = register_netdev(priv->dev);
if (result) {
printk(KERN_WARNING "%s: couldn't register ipoib port %d; error 
%d\n",
-- 
2.15.1


[PATCH AUTOSEL for 3.18 093/101] xen/grant-table: Use put_page instead of free_page

2018-04-08 Thread Sasha Levin
From: Ross Lagerwall 

[ Upstream commit 3ac7292a25db1c607a50752055a18aba32ac2176 ]

The page given to gnttab_end_foreign_access() to free could be a
compound page so use put_page() instead of free_page() since it can
handle both compound and single pages correctly.

This bug was discovered when migrating a Xen VM with several VIFs and
CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10
iterations. All netfront devices disconnect from the backend during a
suspend/resume and this will call gnttab_end_foreign_access() if a
netfront queue has an outstanding skb. The mismatch between calling
get_page() and free_page() on a compound page causes a reference
counting error which is detected when DEBUG_VM is enabled.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
---
 drivers/xen/grant-table.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7786291ba229..abdb152236c1 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -322,7 +322,7 @@ static void gnttab_handle_deferred(unsigned long unused)
if (entry->page) {
pr_debug("freeing g.e. %#x (pfn %#lx)\n",
 entry->ref, page_to_pfn(entry->page));
-   __free_page(entry->page);
+   put_page(entry->page);
} else
pr_info("freeing g.e. %#x\n", entry->ref);
kfree(entry);
@@ -378,7 +378,7 @@ void gnttab_end_foreign_access(grant_ref_t ref, int 
readonly,
if (gnttab_end_foreign_access_ref(ref, readonly)) {
put_free_entry(ref);
if (page != 0)
-   free_page(page);
+   put_page(virt_to_page(page));
} else
gnttab_add_deferred(ref, readonly,
page ? virt_to_page(page) : NULL);
-- 
2.15.1


[PATCH AUTOSEL for 3.18 023/101] usb: usbip tool: Fix refresh_imported_device_list()

2018-04-08 Thread Sasha Levin
From: Yuyang Du 

[ Upstream commit fd92b7deb98a4edd31ffcc2d64cee36103805ff5 ]

The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications
to vhci driver") introduced multiple controllers, but the status
of the ports are only extracted from the first status file, fix it.

Reviewed-by: Krzysztof Opasiak 
Signed-off-by: Yuyang Du 
Acked-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 tools/usb/usbip/libsrc/vhci_driver.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index c589cfbd1cfe..1305a36f95d8 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -107,18 +107,33 @@ static int parse_status(const char *value)
return 0;
 }
 
+#define MAX_STATUS_NAME 16
+
 static int refresh_imported_device_list(void)
 {
const char *attr_status;
+   char status[MAX_STATUS_NAME+1] = "status";
+   int i, ret;
 
-   attr_status = udev_device_get_sysattr_value(vhci_driver->hc_device,
-  "status");
-   if (!attr_status) {
-   err("udev_device_get_sysattr_value failed");
-   return -1;
+   for (i = 0; i < vhci_driver->ncontrollers; i++) {
+   if (i > 0)
+   snprintf(status, sizeof(status), "status.%d", i);
+
+   attr_status = 
udev_device_get_sysattr_value(vhci_driver->hc_device,
+   status);
+   if (!attr_status) {
+   err("udev_device_get_sysattr_value failed");
+   return -1;
+   }
+
+   dbg("controller %d", i);
+
+   ret = parse_status(attr_status);
+   if (ret != 0)
+   return ret;
}
 
-   return parse_status(attr_status);
+   return 0;
 }
 
 static int get_nports(void)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 022/101] usb: usbip tool: Check the return of get_nports()

2018-04-08 Thread Sasha Levin
From: Yuyang Du 

[ Upstream commit c3509715fc9484a48b69a9f0196b728c960840c9 ]

If we get nonpositive number of ports, there is no sense to
continue, then fail gracefully.

In addition, the commit 0775a9cbc694e8c72 ("usbip: vhci extension:
modifications to vhci driver") introduced configurable numbers of
controllers and ports, but we have a static port number maximum,
MAXNPORT. If exceeded, the idev array will be overflown. We fix
it by validating the nports to make sure the port number max is
not exceeded.

Reviewed-by: Krzysztof Opasiak 
Signed-off-by: Yuyang Du 
Acked-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 tools/usb/usbip/libsrc/vhci_driver.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index 1274f326242c..c589cfbd1cfe 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -238,9 +238,16 @@ int usbip_vhci_driver_open(void)
}
 
vhci_driver->nports = get_nports();
-
dbg("available ports: %d", vhci_driver->nports);
 
+   if (vhci_driver->nports <= 0) {
+   err("no available ports");
+   goto err;
+   } else if (vhci_driver->nports > MAXNPORT) {
+   err("port number exceeds %d", MAXNPORT);
+   goto err;
+   }
+
if (refresh_imported_device_list())
goto err;
 
-- 
2.15.1


[PATCH AUTOSEL for 4.4 157/162] bcache: fix for data collapse after re-attaching an attached device

2018-04-08 Thread Sasha Levin
From: Tang Junhui 

[ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]

back-end device sdm has already attached a cache_set with ID
f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with
another cache set, and it returns with an error:
[root]# cd /sys/block/sdm/bcache
[root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach
-bash: echo: write error: Invalid argument

After that, execute a command to modify the label of bcache
device:
[root]# echo data_disk1 > label

Then we reboot the system, when the system power on, the back-end
device can not attach to cache_set, a messages show in the log:
Feb  5 12:05:52 ceph152 kernel: [922385.508498] bcache:
bch_cached_dev_attach() couldn't find uuid for sdm in set

In sysfs_attach(), dc->sb.set_uuid was assigned to the value
which input through sysfs, no matter whether it is success
or not in bch_cached_dev_attach(). For example, If the back-end
device has already attached to an cache set, bch_cached_dev_attach()
would fail, but dc->sb.set_uuid was changed. Then modify the
label of bcache device, it will call bch_write_bdev_super(),
which would write the dc->sb.set_uuid to the super block, so we
record a wrong cache set ID in the super block, after the system
reboot, the cache set couldn't find the uuid of the back-end
device, so the bcache device couldn't exist and use any more.

In this patch, we don't assigned cache set ID to dc->sb.set_uuid
in sysfs_attach() directly, but input it into bch_cached_dev_attach(),
and assigned dc->sb.set_uuid to the cache set ID after the back-end
device attached to the cache set successful.

Signed-off-by: Tang Junhui 
Reviewed-by: Michael Lyle 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/md/bcache/bcache.h |  2 +-
 drivers/md/bcache/super.c  | 10 ++
 drivers/md/bcache/sysfs.c  |  6 --
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index 02619cabda8b..7fe7df56fa33 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -904,7 +904,7 @@ void bcache_write_super(struct cache_set *);
 
 int bch_flash_dev_create(struct cache_set *c, uint64_t size);
 
-int bch_cached_dev_attach(struct cached_dev *, struct cache_set *);
+int bch_cached_dev_attach(struct cached_dev *, struct cache_set *, uint8_t *);
 void bch_cached_dev_detach(struct cached_dev *);
 void bch_cached_dev_run(struct cached_dev *);
 void bcache_device_stop(struct bcache_device *);
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 132d6417c66e..4a3ae14d25e0 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -930,7 +930,8 @@ void bch_cached_dev_detach(struct cached_dev *dc)
cached_dev_put(dc);
 }
 
-int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c)
+int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
+ uint8_t *set_uuid)
 {
uint32_t rtime = cpu_to_le32(get_seconds());
struct uuid_entry *u;
@@ -939,7 +940,8 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct 
cache_set *c)
 
bdevname(dc->bdev, buf);
 
-   if (memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16))
+   if ((set_uuid && memcmp(set_uuid, c->sb.set_uuid, 16)) ||
+   (!set_uuid && memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16)))
return -ENOENT;
 
if (dc->disk.c) {
@@ -1183,7 +1185,7 @@ static void register_bdev(struct cache_sb *sb, struct 
page *sb_page,
 
list_add(>list, _devices);
list_for_each_entry(c, _cache_sets, list)
-   bch_cached_dev_attach(dc, c);
+   bch_cached_dev_attach(dc, c, NULL);
 
if (BDEV_STATE(>sb) == BDEV_STATE_NONE ||
BDEV_STATE(>sb) == BDEV_STATE_STALE)
@@ -1705,7 +1707,7 @@ static void run_cache_set(struct cache_set *c)
bcache_write_super(c);
 
list_for_each_entry_safe(dc, t, _devices, list)
-   bch_cached_dev_attach(dc, c);
+   bch_cached_dev_attach(dc, c, NULL);
 
flash_devs_run(c);
 
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 4fbb5532f24c..1efe31615281 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -263,11 +263,13 @@ STORE(__cached_dev)
}
 
if (attr == _attach) {
-   if (bch_parse_uuid(buf, dc->sb.set_uuid) < 16)
+   uint8_t set_uuid[16];
+
+   if (bch_parse_uuid(buf, set_uuid) < 16)
return -EINVAL;
 
list_for_each_entry(c, _cache_sets, list) {
-   v = bch_cached_dev_attach(dc, c);
+   v = bch_cached_dev_attach(dc, c, set_uuid);
if (!v)
return size;
}
-- 
2.15.1


[PATCH AUTOSEL for 3.18 027/101] platform/x86: acer-wmi: Detect RF Button capability

2018-04-08 Thread Sasha Levin
From: João Paulo Rechi Vita 

[ Upstream commit 3e2bc5c5b3274ec7402fabbfba557ea58084985e ]

If a machine reports a RF Button in the communication button device
bitmap, we need to remove it before calling Get Device Status otherwise
it will return the "Undefined device" (0xE2) error code.

Although this may be a BIOS bug, we don't really need to get or set the
RF Button status. The status indicator LED embedded in the button is
controlled by firmware logic, depending on the status of the wireless
radios present on the machine (WiFi || WWAN).

This commit fixes the wireless status indicator LED on the Acer
TravelMate P648-G2-MG, and cleans the following message from the kernel
log: "Get Current Device Status failed: 0xe2 - 0x0".

Signed-off-by: João Paulo Rechi Vita 
Reviewed-by: "Lee, Chun-Yi" 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/acer-wmi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index e89f88c437f3..4949cfc19eff 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -148,6 +148,8 @@ struct event_return_value {
 #define ACER_WMID3_GDS_THREEG  (1<<6)  /* 3G */
 #define ACER_WMID3_GDS_WIMAX   (1<<7)  /* WiMAX */
 #define ACER_WMID3_GDS_BLUETOOTH   (1<<11) /* BT */
+#define ACER_WMID3_GDS_RFBTN   (1<<14) /* RF Button */
+
 #define ACER_WMID3_GDS_TOUCHPAD(1<<1)  /* Touchpad */
 
 struct lm_input_params {
@@ -205,6 +207,7 @@ struct hotkey_function_type_aa {
 #define ACER_CAP_BRIGHTNESS(1<<3)
 #define ACER_CAP_THREEG(1<<4)
 #define ACER_CAP_ACCEL (1<<5)
+#define ACER_CAP_RFBTN (1<<6)
 #define ACER_CAP_ANY   (0x)
 
 /*
@@ -1217,6 +1220,10 @@ static void __init type_aa_dmi_decode(const struct 
dmi_header *header, void *d)
interface->capability |= ACER_CAP_THREEG;
if (type_aa->commun_func_bitmap & ACER_WMID3_GDS_BLUETOOTH)
interface->capability |= ACER_CAP_BLUETOOTH;
+   if (type_aa->commun_func_bitmap & ACER_WMID3_GDS_RFBTN) {
+   interface->capability |= ACER_CAP_RFBTN;
+   commun_func_bitmap &= ~ACER_WMID3_GDS_RFBTN;
+   }
 
commun_fn_key_number = type_aa->commun_fn_key_number;
 }
-- 
2.15.1


[PATCH AUTOSEL for 3.18 017/101] s390/dasd: Display read-only attribute correctly

2018-04-08 Thread Sasha Levin
From: Jan Höppner 

[ Upstream commit b487a914f853545842a0899329b6b72fe56c4081 ]

We have two flags, DASD_FLAG_DEVICE_RO and DASD_FEATURE_READONLY, that
tell us whether a device is read-only. DASD_FLAG_DEVICE_RO is set when a
device is attached as read-only to z/VM and DASD_FEATURE_READONLY is set
when either the corresponding kernel parameter is configured, or the
read-only state is changed via sysfs.
This is valuable information in any case. However, only the feature flag
is being checked at the moment when we display the current state.

Fix this by checking both flags.

Reviewed-by: Stefan Haberland 
Signed-off-by: Jan Höppner 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin 
---
 drivers/s390/block/dasd_devmap.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/s390/block/dasd_devmap.c b/drivers/s390/block/dasd_devmap.c
index 8286f742436b..f61a8e0ae7c8 100644
--- a/drivers/s390/block/dasd_devmap.c
+++ b/drivers/s390/block/dasd_devmap.c
@@ -758,13 +758,22 @@ static ssize_t
 dasd_ro_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
struct dasd_devmap *devmap;
-   int ro_flag;
+   struct dasd_device *device;
+   int ro_flag = 0;
 
devmap = dasd_find_busid(dev_name(dev));
-   if (!IS_ERR(devmap))
-   ro_flag = (devmap->features & DASD_FEATURE_READONLY) != 0;
-   else
-   ro_flag = (DASD_FEATURE_DEFAULT & DASD_FEATURE_READONLY) != 0;
+   if (IS_ERR(devmap))
+   goto out;
+
+   ro_flag = !!(devmap->features & DASD_FEATURE_READONLY);
+
+   spin_lock(_devmap_lock);
+   device = devmap->device;
+   if (device)
+   ro_flag |= test_bit(DASD_FLAG_DEVICE_RO, >flags);
+   spin_unlock(_devmap_lock);
+
+out:
return snprintf(buf, PAGE_SIZE, ro_flag ? "1\n" : "0\n");
 }
 
-- 
2.15.1


[PATCH AUTOSEL for 3.18 021/101] scsi: lpfc: Fix return value of board_mode store routine in case of online failure

2018-04-08 Thread Sasha Levin
From: James Smart 

[ Upstream commit 522dceeb62ded1a7b538d2f1f61cc69a1402537d ]

On hbacmd reset failure, observing wrong string "nline" in kernel log.

On failure, non negative value (1) is returned from sysfs store
routine. It is interpreted as count by kernel and store routine is
called again with the remaining characters as input.

Fix: Return negative error code (-EIO) in case of failure.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/lpfc/lpfc_attr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index a53dc1c71fd2..55c843f5cc34 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -1085,6 +1085,8 @@ lpfc_board_mode_store(struct device *dev, struct 
device_attribute *attr,
goto board_mode_out;
}
wait_for_completion(_compl);
+   if (status)
+   status = -EIO;
} else if (strncmp(buf, "offline", sizeof("offline") - 1) == 0)
status = lpfc_do_offline(phba, LPFC_EVT_OFFLINE);
else if (strncmp(buf, "warm", sizeof("warm") - 1) == 0)
-- 
2.15.1


[PATCH AUTOSEL for 3.18 020/101] scsi: megaraid: Fix a sleep-in-atomic bug

2018-04-08 Thread Sasha Levin
From: Jia-Ju Bai 

[ Upstream commit 896f6966fc815abe71f85fb26f0193875df8a035 ]

The driver may sleep under a spin lock, and the function call path is:
mraid_mm_attach_buf (acquire the lock by spin_lock_irqsave)
  pci_pool_alloc(GFP_KERNEL) --> may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

[mkp: fixed whitespace]

Signed-off-by: Jia-Ju Bai 
Acked-by: Sumit Saxena 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/megaraid/megaraid_mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_mm.c 
b/drivers/scsi/megaraid/megaraid_mm.c
index a70692779a16..bfc7984a1c17 100644
--- a/drivers/scsi/megaraid/megaraid_mm.c
+++ b/drivers/scsi/megaraid/megaraid_mm.c
@@ -570,7 +570,7 @@ mraid_mm_attach_buf(mraid_mmadp_t *adp, uioc_t *kioc, int 
xferlen)
 
kioc->pool_index= right_pool;
kioc->free_buf  = 1;
-   kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_KERNEL,
+   kioc->buf_vaddr = pci_pool_alloc(pool->handle, GFP_ATOMIC,
>buf_paddr);
spin_unlock_irqrestore(>lock, flags);
 
-- 
2.15.1


[PATCH AUTOSEL for 4.4 122/162] kconfig: Fix expr_free() E_NOT leak

2018-04-08 Thread Sasha Levin
From: Ulf Magnusson 

[ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ]

Only the E_NOT operand and not the E_NOT node itself was freed, due to
accidentally returning too early in expr_free(). Outline of leak:

switch (e->type) {
...
case E_NOT:
expr_free(e->left.expr);
return;
...
}
*Never reached, 'e' leaked*
free(e);

Fix by changing the 'return' to a 'break'.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

LEAK SUMMARY:
   definitely lost: 44,448 bytes in 1,852 blocks
   ...

Summary after the fix:

LEAK SUMMARY:
   definitely lost: 1,608 bytes in 67 blocks
   ...

Signed-off-by: Ulf Magnusson 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/kconfig/expr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c
index cbf4996dd9c1..ed29bad1f03a 100644
--- a/scripts/kconfig/expr.c
+++ b/scripts/kconfig/expr.c
@@ -113,7 +113,7 @@ void expr_free(struct expr *e)
break;
case E_NOT:
expr_free(e->left.expr);
-   return;
+   break;
case E_EQUAL:
case E_GEQ:
case E_GTH:
-- 
2.15.1


<    1   2   3   4   5   6   7   8   9   10   >