[PATCH 4.9 125/171] perf tests: Fix indexing when invoking subtests

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit aa90f9f9554616d5738f7bedb4a8f0e5e14d1bc6 ]

Recently, the subtest numbering was changed to start from 1.  While it
is fine for displaying results, this should not be the case when the
subtests are actually invoked.

Typically, the subtests are stored in zero-indexed arrays and invoked
based on the index passed to the main test function.  Since the index
now starts from 1, the second subtest in the array (index 1) gets
invoked instead of the first (index 0).  This applies to all of the
following subtests but for the last one, the subtest always fails
because it does not meet the boundary condition of the subtest index
being lesser than the number of subtests.

This can be observed on powerpc64 and x86_64 systems running Fedora 28
as shown below.

Before:

  # perf test "builtin clang support"
  55: builtin clang support :
  55.1: builtin clang compile C source to IR: Ok
  55.2: builtin clang compile C source to ELF object: FAILED!

  # perf test "LLVM search and compile"
  38: LLVM search and compile   :
  38.1: Basic BPF llvm compile  : Ok
  38.2: kbuild searching: Ok
  38.3: Compile source for BPF prologue generation  : Ok
  38.4: Compile source for BPF relocation   : FAILED!

  # perf test "BPF filter"
  40: BPF filter:
  40.1: Basic BPF filtering : Ok
  40.2: BPF pinning : Ok
  40.3: BPF prologue generation : Ok
  40.4: BPF relocation checker  : FAILED!

After:

  # perf test "builtin clang support"
  55: builtin clang support :
  55.1: builtin clang compile C source to IR: Ok
  55.2: builtin clang compile C source to ELF object: Ok

  # perf test "LLVM search and compile"
  38: LLVM search and compile   :
  38.1: Basic BPF llvm compile  : Ok
  38.2: kbuild searching: Ok
  38.3: Compile source for BPF prologue generation  : Ok
  38.4: Compile source for BPF relocation   : Ok

  # perf test "BPF filter"
  40: BPF filter:
  40.1: Basic BPF filtering : Ok
  40.2: BPF pinning : Ok
  40.3: BPF prologue generation : Ok
  40.4: BPF relocation checker  : Ok

Signed-off-by: Sandipan Das 
Reported-by: Arnaldo Carvalho de Melo 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Heiko Carstens 
Cc: Hendrik Brueckner 
Cc: Jiri Olsa 
Cc: Martin Schwidefsky 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Thomas Richter 
Fixes: 9ef0112442bd ("perf test: Fix subtest number when showing results")
Link: http://lkml.kernel.org/r/20180726171733.33208-1-sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/tests/builtin-test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index ade7213943ad..03239956987f 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -335,7 +335,7 @@ static int test_and_print(struct test *t, bool force_skip, 
int subtest)
if (!t->subtest.get_nr)
pr_debug("%s:", t->desc);
else
-   pr_debug("%s subtest %d:", t->desc, subtest);
+   pr_debug("%s subtest %d:", t->desc, subtest + 1);
 
switch (err) {
case TEST_OK:
@@ -413,7 +413,7 @@ static int __cmd_test(int argc, const char *argv[], struct 
intlist *skiplist)
for (subi = 0; subi < subn; subi++) {
pr_info("%2d.%1d: %-*s:", i, subi + 1, subw,
t->subtest.get_desc(subi));
-   err = test_and_print(t, skip, subi + 1);
+   err = test_and_print(t, skip, subi);
if (err != TEST_OK && t->subtest.skip_if_fail)
skip = true;
}
-- 
2.17.1





[PATCH 4.9 124/171] xhci: Fix USB3 NULL pointer dereference at logical disconnect.

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 2278446e2b7cd33ad894b32e7eb63afc7db6c86e ]

Hub driver will try to disable a USB3 device twice at logical disconnect,
racing with xhci_free_dev() callback from the first port disable.

This can be triggered with "udisksctl power-off --block-device "
or by writing "1" to the "remove" sysfs file for a USB3 device
in 4.17-rc4.

USB3 devices don't have a similar disabled link state as USB2 devices,
and use a U3 suspended link state instead. In this state the port
is still enabled and connected.

hub_port_connect() first disconnects the device, then later it notices
that device is still enabled (due to U3 states) it will try to disable
the port again (set to U3).

The xhci_free_dev() called during device disable is async, so checking
for existing xhci->devs[i] when setting link state to U3 the second time
was successful, even if device was being freed.

The regression was caused by, and whole thing revealed by,
Commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned.
and causes a NULL pointer dereference the second time we try to set U3.

Fix this by checking xhci->devs[i]->udev exists before setting link state.

The original patch went to stable so this fix needs to be applied there as
well.

Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
Cc: 
Reported-by: Jordan Glover 
Tested-by: Jordan Glover 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/host/xhci-hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 45a03eff4db1..0f09ab5399f4 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -366,7 +366,7 @@ int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct 
xhci_hcd *xhci,
 
slot_id = 0;
for (i = 0; i < MAX_HC_SLOTS; i++) {
-   if (!xhci->devs[i])
+   if (!xhci->devs[i] || !xhci->devs[i]->udev)
continue;
speed = xhci->devs[i]->udev->speed;
if (((speed >= USB_SPEED_SUPER) == (hcd->speed >= HCD_USB3))
-- 
2.17.1





[PATCH 4.9 103/171] Btrfs: incremental send, fix invalid memory access

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 24e52b11e0ca788513b945a87b57cc0522a92933 ]

When doing an incremental send, while processing an extent that changed
between the parent and send snapshots and that extent was an inline extent
in the parent snapshot, it's possible to access a memory region beyond
the end of leaf if the inline extent is very small and it is the first
item in a leaf.

An example scenario is described below.

The send snapshot has the following leaf:

 leaf 33865728 items 33 free space 773 generation 46 owner 5
 fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7
 chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f
(...)
item 14 key (335 EXTENT_DATA 0) itemoff 3052 itemsize 53
generation 36 type 1 (regular)
extent data disk byte 12791808 nr 4096
extent data offset 0 nr 4096 ram 4096
extent compression 0 (none)
item 15 key (335 EXTENT_DATA 8192) itemoff 2999 itemsize 53
generation 36 type 1 (regular)
extent data disk byte 138170368 nr 225280
extent data offset 0 nr 225280 ram 225280
extent compression 0 (none)
(...)

And the parent snapshot has the following leaf:

 leaf 31272960 items 17 free space 17 generation 31 owner 5
 fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7
 chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f
item 0 key (335 EXTENT_DATA 0) itemoff 3951 itemsize 44
generation 31 type 0 (inline)
inline extent data size 23 ram_bytes 613 compression 1 (zlib)
(...)

When computing the send stream, it is detected that the extent of inode
335, at file offset 0, and at fs/btrfs/send.c:is_extent_unchanged() we
grab the leaf from the parent snapshot and access the inline extent item.
However, before jumping to the 'out' label, we access the 'offset' and
'disk_bytenr' fields of the extent item, which should not be done for
inline extents since the inlined data starts at the offset of the
'disk_bytenr' field and can be very small. For example accessing the
'offset' field of the file extent item results in the following trace:

[  599.705368] general protection fault:  [#1] PREEMPT SMP
[  599.706296] Modules linked in: btrfs psmouse i2c_piix4 ppdev acpi_cpufreq 
serio_raw parport_pc i2c_core evdev tpm_tis tpm_tis_core sg pcspkr parport tpm 
button su$
[  599.709340] CPU: 7 PID: 5283 Comm: btrfs Not tainted 
4.10.0-rc8-btrfs-next-46+ #1
[  599.709340] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[  599.709340] task: 88023eedd040 task.stack: c90006658000
[  599.709340] RIP: 0010:read_extent_buffer+0xdb/0xf4 [btrfs]
[  599.709340] RSP: 0018:c9000665ba00 EFLAGS: 00010286
[  599.709340] RAX: db738800 RBX:  RCX: 0001
[  599.709340] RDX: c9000665ba60 RSI: db738800 RDI: c9000665ba5f
[  599.709340] RBP: c9000665ba30 R08: 0001 R09: 88020dc5e098
[  599.709340] R10: 1000 R11: 1600 R12: 6db6db6db6db6db7
[  599.709340] R13: 8800 R14:  R15: 88020dc5e088
[  599.709340] FS:  7f519555a8c0() GS:88023f3c() 
knlGS:
[  599.709340] CS:  0010 DS:  ES:  CR0: 80050033
[  599.709340] CR2: 7f1411afd000 CR3: 000235f8e000 CR4: 06e0
[  599.709340] Call Trace:
[  599.709340]  btrfs_get_token_64+0x93/0xce [btrfs]
[  599.709340]  ? printk+0x48/0x50
[  599.709340]  btrfs_get_64+0xb/0xd [btrfs]
[  599.709340]  process_extent+0x3a1/0x1106 [btrfs]
[  599.709340]  ? btree_read_extent_buffer_pages+0x5/0xef [btrfs]
[  599.709340]  changed_cb+0xb03/0xb3d [btrfs]
[  599.709340]  ? btrfs_get_token_32+0x7a/0xcc [btrfs]
[  599.709340]  btrfs_compare_trees+0x432/0x53d [btrfs]
[  599.709340]  ? process_extent+0x1106/0x1106 [btrfs]
[  599.709340]  btrfs_ioctl_send+0x960/0xe26 [btrfs]
[  599.709340]  btrfs_ioctl+0x181b/0x1fed [btrfs]
[  599.709340]  ? trace_hardirqs_on_caller+0x150/0x1ac
[  599.709340]  vfs_ioctl+0x21/0x38
[  599.709340]  ? vfs_ioctl+0x21/0x38
[  599.709340]  do_vfs_ioctl+0x611/0x645
[  599.709340]  ? rcu_read_unlock+0x5b/0x5d
[  599.709340]  ? __fget+0x6d/0x79
[  599.709340]  SyS_ioctl+0x57/0x7b
[  599.709340]  entry_SYSCALL_64_fastpath+0x18/0xad
[  599.709340] RIP: 0033:0x7f51945eec47
[  599.709340] RSP: 002b:7ffc21c13e98 EFLAGS: 0202 ORIG_RAX: 
0010
[  599.709340] RAX: ffda RBX: 81096459 RCX: 7f51945eec47
[  599.709340] RDX: 7ffc21c13f20 RSI: 40489426 RDI: 0004
[  599.709340] RBP: c9000665bf98 R08: 7f519450d700 R09: 7f519450d700
[  599.709340] R10: 7f519450d9d0 R11: 0202 R12: 0046
[  599.709340] R13: c9000665bf78 R14:  R15: 7f5195574040
[  

[PATCH 4.9 123/171] libertas: call into generic suspend code before turning off power

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 4f75cdff0b986195413215eb062b7da6586f ]

When powering down a SDIO connected card during suspend, make sure to call
into the generic lbs_suspend() function before pulling the plug. This will
make sure the card is successfully deregistered from the system to avoid
communication to the card starving out.

Fixes: 7444a8092906 ("libertas: fix suspend and resume for SDIO connected 
cards")
Signed-off-by: Daniel Mack 
Reviewed-by: Ulf Hansson 
Acked-by: Kalle Valo 
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/marvell/libertas/if_sdio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/marvell/libertas/if_sdio.c 
b/drivers/net/wireless/marvell/libertas/if_sdio.c
index a0ae8d8763bb..06a57c708992 100644
--- a/drivers/net/wireless/marvell/libertas/if_sdio.c
+++ b/drivers/net/wireless/marvell/libertas/if_sdio.c
@@ -1368,6 +1368,10 @@ static int if_sdio_suspend(struct device *dev)
if (priv->wol_criteria == EHS_REMOVE_WAKEUP) {
dev_info(dev, "Suspend without wake params -- powering down 
card\n");
if (priv->fw_ready) {
+   ret = lbs_suspend(priv);
+   if (ret)
+   return ret;
+
priv->power_up_on_resume = true;
if_sdio_power_off(card);
}
-- 
2.17.1





[PATCH 4.9 105/171] module: fix DEBUG_SET_MODULE_RONX typo

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 4d217a5adccf5e806790c37c61cc374a08bd7381 ]

The newly added 'rodata_enabled' global variable is protected by
the wrong #ifdef, leading to a link error when CONFIG_DEBUG_SET_MODULE_RONX
is turned on:

kernel/module.o: In function `disable_ro_nx':
module.c:(.text.unlikely.disable_ro_nx+0x88): undefined reference to 
`rodata_enabled'
kernel/module.o: In function `module_disable_ro':
module.c:(.text.module_disable_ro+0x8c): undefined reference to `rodata_enabled'
kernel/module.o: In function `module_enable_ro':
module.c:(.text.module_enable_ro+0xb0): undefined reference to `rodata_enabled'

CONFIG_SET_MODULE_RONX does not exist, so use the correct one instead.

Fixes: 39290b389ea2 ("module: extend 'rodata=off' boot cmdline parameter to 
module mappings")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Jessica Yu 
Signed-off-by: Sasha Levin 
---
 init/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index 4313772d634a..3c7f71d8e704 100644
--- a/init/main.c
+++ b/init/main.c
@@ -915,7 +915,7 @@ static int try_to_run_init_process(const char 
*init_filename)
 
 static noinline void __init kernel_init_freeable(void);
 
-#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_SET_MODULE_RONX)
+#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
 bool rodata_enabled __ro_after_init = true;
 static int __init set_debug_rodata(char *str)
 {
-- 
2.17.1





[PATCH 4.9 101/171] i40e: avoid NVM acquire deadlock during NVM update

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 09f79fd49d94cda5837e9bfd0cb32b3b6d9f ]

X722 devices use the AdminQ to access the NVM, and this requires taking
the AdminQ lock. Because of this, we lock the AdminQ during
i40e_read_nvm(), which is also called in places where the lock is
already held, such as the firmware update path which wants to lock once
and then unlock when finished after performing several tasks.

Although this should have only affected X722 devices, commit
96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
2016-12-02) added locking for all NVM reads, regardless of device
family.

This resulted in us accidentally causing NVM acquire timeouts on all
devices, causing failed firmware updates which left the eeprom in
a corrupt state.

Create unsafe non-locked variants of i40e_read_nvm_word and
i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer
respectively. These variants will not take the NVM lock and are expected
to only be called in places where the NVM lock is already held if
needed.

Since the only caller of i40e_read_nvm_buffer() was in such a path,
remove it entirely in favor of the unsafe version. If necessary we can
always add it back in the future.

Additionally, we now need to hold the NVM lock in i40e_validate_checksum
because the call to i40e_calc_nvm_checksum now assumes that the NVM lock
is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD
up a bit so that we do not need to acquire the NVM lock twice.

This should resolve firmware updates and also fix potential raise that
could have caused the driver to report an invalid NVM checksum upon
driver load.

Reported-by: Stefan Assmann 
Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices", 
2016-12-02)
Signed-off-by: Anjali Singhai Jain 
Signed-off-by: Jacob Keller 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/i40e/i40e_nvm.c| 98 ---
 .../net/ethernet/intel/i40e/i40e_prototype.h  |  2 -
 2 files changed, 60 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_nvm.c 
b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
index abe290bfc638..8408682efd86 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -266,7 +266,7 @@ static i40e_status i40e_read_nvm_aq(struct i40e_hw *hw, u8 
module_pointer,
  * @offset: offset of the Shadow RAM word to read (0x00 - 0x001FFF)
  * @data: word read from the Shadow RAM
  *
- * Reads one 16 bit word from the Shadow RAM using the GLNVM_SRCTL register.
+ * Reads one 16 bit word from the Shadow RAM using the AdminQ
  **/
 static i40e_status i40e_read_nvm_word_aq(struct i40e_hw *hw, u16 offset,
 u16 *data)
@@ -280,27 +280,49 @@ static i40e_status i40e_read_nvm_word_aq(struct i40e_hw 
*hw, u16 offset,
 }
 
 /**
- * i40e_read_nvm_word - Reads Shadow RAM
+ * __i40e_read_nvm_word - Reads nvm word, assumes called does the locking
  * @hw: pointer to the HW structure
  * @offset: offset of the Shadow RAM word to read (0x00 - 0x001FFF)
  * @data: word read from the Shadow RAM
  *
- * Reads one 16 bit word from the Shadow RAM using the GLNVM_SRCTL register.
+ * Reads one 16 bit word from the Shadow RAM.
+ *
+ * Do not use this function except in cases where the nvm lock is already
+ * taken via i40e_acquire_nvm().
+ **/
+static i40e_status __i40e_read_nvm_word(struct i40e_hw *hw,
+   u16 offset, u16 *data)
+{
+   i40e_status ret_code = 0;
+
+   if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE)
+   ret_code = i40e_read_nvm_word_aq(hw, offset, data);
+   else
+   ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
+   return ret_code;
+}
+
+/**
+ * i40e_read_nvm_word - Reads nvm word and acquire lock if necessary
+ * @hw: pointer to the HW structure
+ * @offset: offset of the Shadow RAM word to read (0x00 - 0x001FFF)
+ * @data: word read from the Shadow RAM
+ *
+ * Reads one 16 bit word from the Shadow RAM.
  **/
 i40e_status i40e_read_nvm_word(struct i40e_hw *hw, u16 offset,
   u16 *data)
 {
-   enum i40e_status_code ret_code = 0;
+   i40e_status ret_code = 0;
 
ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
-   if (!ret_code) {
-   if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
-   ret_code = i40e_read_nvm_word_aq(hw, offset, data);
-   } else {
-   ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
-   }
-   i40e_release_nvm(hw);
-   }
+   if (ret_code)
+   return ret_code;
+
+   ret_code = __i40e_read_nvm_word(hw, offset, data);
+
+   i40e_release_nvm(hw);
+
return ret_code;
 }
 
@@ 

[PATCH 4.9 110/171] cifs: Use ULL suffix for 64-bit constant

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 3995bbf53bd2047f2720c6fdd4bf38f6d942a0c0 ]

On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):

fs/cifs/inode.c: In function ‘simple_hashstr’:
fs/cifs/inode.c:713: warning: integer constant is too large for ‘long’ type

Fixes: 7ea884c77e5c97f1 ("smb3: Fix root directory when server returns inode 
number of zero")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Steve French 
Reviewed-by: Aurelien Aptel 
Signed-off-by: Sasha Levin 
---
 fs/cifs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index a012f70bba5c..77a18fe10805 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -704,7 +704,7 @@ cgfi_exit:
 /* Simple function to return a 64 bit hash of string.  Rarely called */
 static __u64 simple_hashstr(const char *str)
 {
-   const __u64 hash_mult =  1125899906842597L; /* a big enough prime */
+   const __u64 hash_mult =  1125899906842597ULL; /* a big enough prime */
__u64 hash = 0;
 
while (*str)
-- 
2.17.1





[PATCH 4.9 109/171] perf/core: Fix locking for children siblings group read

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 2aeb1883547626d82c597cce2c99f0b9c62e2425 ]

We're missing ctx lock when iterating children siblings
within the perf_read path for group reading. Following
race and crash can happen:

User space doing read syscall on event group leader:

T1:
  perf_read
lock event->ctx->mutex
perf_read_group
  lock leader->child_mutex
  __perf_read_group_add(child)
list_for_each_entry(sub, >sibling_list, group_entry)

>   sub might be invalid at this point, because it could
get removed via perf_event_exit_task_context in T2

Child exiting and cleaning up its events:

T2:
  perf_event_exit_task_context
lock ctx->mutex
list_for_each_entry_safe(child_event, next, _ctx->event_list,...
  perf_event_exit_event(child)
lock ctx->lock
perf_group_detach(child)
unlock ctx->lock

>   child is removed from sibling_list without any sync
with T1 path above

...
free_event(child)

Before the child is removed from the leader's child_list,
(and thus is omitted from perf_read_group processing), we
need to ensure that perf_read_group touches child's
siblings under its ctx->lock.

Peter further notes:

| One additional note; this bug got exposed by commit:
|
|   ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
|
| which made it possible to actually trigger this code-path.

Tested-by: Andi Kleen 
Signed-off-by: Jiri Olsa 
Acked-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: ba5213ae6b88 ("perf/core: Correct event creation with PERF_FORMAT_GROUP")
Link: http://lkml.kernel.org/r/20170720141455.2106-1-jo...@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/events/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 95bd00d9f2c3..06b359af4322 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4331,7 +4331,9 @@ EXPORT_SYMBOL_GPL(perf_event_read_value);
 static int __perf_read_group_add(struct perf_event *leader,
u64 read_format, u64 *values)
 {
+   struct perf_event_context *ctx = leader->ctx;
struct perf_event *sub;
+   unsigned long flags;
int n = 1; /* skip @nr */
int ret;
 
@@ -4361,12 +4363,15 @@ static int __perf_read_group_add(struct perf_event 
*leader,
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
 
+   raw_spin_lock_irqsave(>lock, flags);
+
list_for_each_entry(sub, >sibling_list, group_entry) {
values[n++] += perf_event_count(sub);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
}
 
+   raw_spin_unlock_irqrestore(>lock, flags);
return 0;
 }
 
-- 
2.17.1





[PATCH 4.9 142/171] net: stmmac: Fix stmmac_mdio_reset() when building stmmac as modules

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Niklas Cassel 

[ Upstream commit 30549aab146ccb1275230c3b4b4bc6b4181fd54e ]

When building stmmac, it is only possible to select CONFIG_DWMAC_GENERIC,
or any of the glue drivers, when CONFIG_STMMAC_PLATFORM is set.
The only exception is CONFIG_STMMAC_PCI.

When calling of_mdiobus_register(), it will call our ->reset()
callback, which is set to stmmac_mdio_reset().

Most of the code in stmmac_mdio_reset() is protected by a
"#if defined(CONFIG_STMMAC_PLATFORM)", which will evaluate
to false when CONFIG_STMMAC_PLATFORM=m.

Because of this, the phy reset gpio will only be pulled when
stmmac is built as built-in, but not when built as modules.

Fix this by using "#if IS_ENABLED()" instead of "#if defined()".

Signed-off-by: Niklas Cassel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -216,7 +216,7 @@ static int stmmac_mdio_write_gmac4(struc
  */
 int stmmac_mdio_reset(struct mii_bus *bus)
 {
-#if defined(CONFIG_STMMAC_PLATFORM)
+#if IS_ENABLED(CONFIG_STMMAC_PLATFORM)
struct net_device *ndev = bus->priv;
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;




[PATCH 4.9 107/171] l2tp: remove configurable payload offset

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 900631ee6a2651dc4fbaecb8ef9fa5f1e3378853 ]

If L2TP_ATTR_OFFSET is set to a non-zero value in L2TPv3 tunnels, it
results in L2TPv3 packets being transmitted which might not be
compliant with the L2TPv3 RFC. This patch has l2tp ignore the offset
setting and send all packets with no offset.

In more detail:

L2TPv2 supports a variable offset from the L2TPv2 header to the
payload. The offset value is indicated by an optional field in the
L2TP header.  Our L2TP implementation already detects the presence of
the optional offset and skips that many bytes when handling data
received packets. All transmitted packets are always transmitted with
no offset.

L2TPv3 has no optional offset field in the L2TPv3 packet
header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific
Sublayer". At the time when the original L2TP code was written, there
was talk at IETF of offset being implemented in a new Layer-2 Specific
Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this
offset could be configured and the intention was to allow it to be
also used to set the tx offset for L2TPv2. However, no L2TPv3 offset
was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten
about.

Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted
with the specified number of bytes padding between L2TPv3 header and
payload. This is not compliant with L2TPv3 RFC3931. This change
removes the configurable offset altogether while retaining
L2TP_ATTR_OFFSET for backwards compatibility. Any L2TP_ATTR_OFFSET
value is ignored.

Signed-off-by: James Chapman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/l2tp/l2tp_core.c| 14 --
 net/l2tp/l2tp_core.h|  3 ---
 net/l2tp/l2tp_debugfs.c |  4 ++--
 net/l2tp/l2tp_netlink.c |  3 ---
 4 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index a5333f6cb65a..b96dbe38ecad 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -845,10 +845,8 @@ void l2tp_recv_common(struct l2tp_session *session, struct 
sk_buff *skb,
}
}
 
-   /* Session data offset is handled differently for L2TPv2 and
-* L2TPv3. For L2TPv2, there is an optional 16-bit value in
-* the header. For L2TPv3, the offset is negotiated using AVPs
-* in the session setup control protocol.
+   /* Session data offset is defined only for L2TPv2 and is
+* indicated by an optional 16-bit value in the header.
 */
if (tunnel->version == L2TP_HDR_VER_2) {
/* If offset bit set, skip it. */
@@ -856,8 +854,7 @@ void l2tp_recv_common(struct l2tp_session *session, struct 
sk_buff *skb,
offset = ntohs(*(__be16 *)ptr);
ptr += 2 + offset;
}
-   } else
-   ptr += session->offset;
+   }
 
offset = ptr - optr;
if (!pskb_may_pull(skb, offset))
@@ -1141,8 +1138,6 @@ static int l2tp_build_l2tpv3_header(struct l2tp_session 
*session, void *buf)
}
bufp += session->l2specific_len;
}
-   if (session->offset)
-   bufp += session->offset;
 
return bufp - optr;
 }
@@ -1827,7 +1822,7 @@ void l2tp_session_set_header_len(struct l2tp_session 
*session, int version)
if (session->send_seq)
session->hdr_len += 4;
} else {
-   session->hdr_len = 4 + session->cookie_len + 
session->l2specific_len + session->offset;
+   session->hdr_len = 4 + session->cookie_len + 
session->l2specific_len;
if (session->tunnel->encap == L2TP_ENCAPTYPE_UDP)
session->hdr_len += 4;
}
@@ -1878,7 +1873,6 @@ struct l2tp_session *l2tp_session_create(int priv_size, 
struct l2tp_tunnel *tunn
session->recv_seq = cfg->recv_seq;
session->lns_mode = cfg->lns_mode;
session->reorder_timeout = cfg->reorder_timeout;
-   session->offset = cfg->offset;
session->l2specific_type = cfg->l2specific_type;
session->l2specific_len = cfg->l2specific_len;
session->cookie_len = cfg->cookie_len;
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index 42419f1c24cf..86356a23a0a7 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -68,7 +68,6 @@ struct l2tp_session_cfg {
int debug;  /* bitmask of debug message
 * categories */
u16 vlan_id;/* VLAN pseudowire only */
-   u16 offset; /* offset to payload */
u16 l2specific_len; /* Layer 2 specific length 

[PATCH 4.4 083/114] MIPS: DEC: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 68fe55680d0f3342969f49412fceabb90bdfadba ]

Fix a commit 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in
delay slots") regression and remove assembly errors:

arch/mips/dec/int-handler.S: Assembler messages:
arch/mips/dec/int-handler.S:162: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:163: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:229: Error: Macro used $at after ".set noat"
arch/mips/dec/int-handler.S:230: Error: Macro used $at after ".set noat"

triggering with with the CPU_DADDI_WORKAROUNDS option set and the DADDIU
instruction.  This is because with that option in place the instruction
becomes a macro, which expands to an LI/DADDU (or actually ADDIU/DADDU)
sequence that uses $at as a temporary register.

With CPU_DADDI_WORKAROUNDS we only support `-msym32' compilation though,
and this is already enforced in arch/mips/Makefile, so choose the 32-bit
expansion variant for the supported configurations and then replace the
64-bit variant with #error just in case.

Fixes: 3021773c7c3e ("MIPS: DEC: Avoid la pseudo-instruction in delay slots")
Signed-off-by: Maciej W. Rozycki 
Cc: linux-m...@linux-mips.org
Cc: sta...@vger.kernel.org # 4.8+
Patchwork: https://patchwork.linux-mips.org/patch/16893/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin 
---
 arch/mips/dec/int-handler.S | 34 ++
 1 file changed, 6 insertions(+), 28 deletions(-)

diff --git a/arch/mips/dec/int-handler.S b/arch/mips/dec/int-handler.S
index 554d1da97743..21f4a9fe82fa 100644
--- a/arch/mips/dec/int-handler.S
+++ b/arch/mips/dec/int-handler.S
@@ -147,23 +147,12 @@
 * Find irq with highest priority
 */
# open coded PTR_LA t1, cpu_mask_nr_tbl
-#if (_MIPS_SZPTR == 32)
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
# open coded la t1, cpu_mask_nr_tbl
lui t1, %hi(cpu_mask_nr_tbl)
addiu   t1, %lo(cpu_mask_nr_tbl)
-
-#endif
-#if (_MIPS_SZPTR == 64)
-   # open coded dla t1, cpu_mask_nr_tbl
-   .setpush
-   .setnoat
-   lui t1, %highest(cpu_mask_nr_tbl)
-   lui AT, %hi(cpu_mask_nr_tbl)
-   daddiu  t1, t1, %higher(cpu_mask_nr_tbl)
-   daddiu  AT, AT, %lo(cpu_mask_nr_tbl)
-   dsllt1, 32
-   daddu   t1, t1, AT
-   .setpop
+#else
+#error GCC `-msym32' option required for 64-bit DECstation builds
 #endif
 1: lw  t2,(t1)
nop
@@ -214,23 +203,12 @@
 * Find irq with highest priority
 */
# open coded PTR_LA t1,asic_mask_nr_tbl
-#if (_MIPS_SZPTR == 32)
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
# open coded la t1, asic_mask_nr_tbl
lui t1, %hi(asic_mask_nr_tbl)
addiu   t1, %lo(asic_mask_nr_tbl)
-
-#endif
-#if (_MIPS_SZPTR == 64)
-   # open coded dla t1, asic_mask_nr_tbl
-   .setpush
-   .setnoat
-   lui t1, %highest(asic_mask_nr_tbl)
-   lui AT, %hi(asic_mask_nr_tbl)
-   daddiu  t1, t1, %higher(asic_mask_nr_tbl)
-   daddiu  AT, AT, %lo(asic_mask_nr_tbl)
-   dsllt1, 32
-   daddu   t1, t1, AT
-   .setpop
+#else
+#error GCC `-msym32' option required for 64-bit DECstation builds
 #endif
 2: lw  t2,(t1)
nop
-- 
2.17.1





[PATCH 4.4 088/114] bridge: do not add port to router list when receives query with source 0.0.0.0

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Hangbin Liu 

commit 5a2de63fd1a59c30c02526d427bc014b98adf508 upstream.

Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules

  The switch supporting IGMP snooping must maintain a list of
  multicast routers and the ports on which they are attached.  This
  list can be constructed in any combination of the following ways:

  a) This list should be built by the snooping switch sending
 Multicast Router Solicitation messages as described in IGMP
 Multicast Router Discovery [MRDISC].  It may also snoop
 Multicast Router Advertisement messages sent by and to other
 nodes.

  b) The arrival port for IGMP Queries (sent by multicast routers)
 where the source address is not 0.0.0.0.

We should not add the port to router list when receives query with source
0.0.0.0.

Reported-by: Ying Xu 
Signed-off-by: Hangbin Liu 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 net/bridge/br_multicast.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1261,7 +1261,15 @@ static void br_multicast_query_received(
return;
 
br_multicast_update_query_timer(br, query, max_delay);
-   br_multicast_mark_router(br, port);
+
+   /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
+* the arrival port for IGMP Queries where the source address
+* is 0.0.0.0 should not be added to router port list.
+*/
+   if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
+   (saddr->proto == htons(ETH_P_IPV6) &&
+!ipv6_addr_any(>u.ip6)))
+   br_multicast_mark_router(br, port);
 }
 
 static int br_ip4_multicast_query(struct net_bridge *br,




[PATCH 4.4 093/114] net: sched: gred: pass the right attribute to gred_change_table_def()

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jakub Kicinski 

[ Upstream commit 38b4f18d56372e1e21771ab7b0357b853330186c ]

gred_change_table_def() takes a pointer to TCA_GRED_DPS attribute,
and expects it will be able to interpret its contents as
struct tc_gred_sopt.  Pass the correct gred attribute, instead of
TCA_OPTIONS.

This bug meant the table definition could never be changed after
Qdisc was initialized (unless whatever TCA_OPTIONS contained both
passed netlink validation and was a valid struct tc_gred_sopt...).

Old behaviour:
$ ip link add type dummy
$ tc qdisc replace dev dummy0 parent root handle 7: \
 gred setup vqs 4 default 0
$ tc qdisc replace dev dummy0 parent root handle 7: \
 gred setup vqs 4 default 0
RTNETLINK answers: Invalid argument

Now:
$ ip link add type dummy
$ tc qdisc replace dev dummy0 parent root handle 7: \
 gred setup vqs 4 default 0
$ tc qdisc replace dev dummy0 parent root handle 7: \
 gred setup vqs 4 default 0
$ tc qdisc replace dev dummy0 parent root handle 7: \
 gred setup vqs 4 default 0

Fixes: f62d6b936df5 ("[PKT_SCHED]: GRED: Use central VQ change procedure")
Signed-off-by: Jakub Kicinski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/sched/sch_gred.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -444,7 +444,7 @@ static int gred_change(struct Qdisc *sch
if (tb[TCA_GRED_PARMS] == NULL && tb[TCA_GRED_STAB] == NULL) {
if (tb[TCA_GRED_LIMIT] != NULL)
sch->limit = nla_get_u32(tb[TCA_GRED_LIMIT]);
-   return gred_change_table_def(sch, opt);
+   return gred_change_table_def(sch, tb[TCA_GRED_DPS]);
}
 
if (tb[TCA_GRED_PARMS] == NULL ||




[PATCH 4.4 092/114] net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: David Ahern 

[ Upstream commit 4ba4c566ba8448a05e6257e0b98a21f1a0d55315 ]

The loop wants to skip previously dumped addresses, so loops until
current index >= saved index. If the message fills it wants to save
the index for the next address to dump - ie., the one that did not
fit in the current message.

Currently, it is incrementing the index counter before comparing to the
saved index, and then the saved index is off by 1 - it assumes the
current address is going to fit in the message.

Change the index handling to increment only after a succesful dump.

Fixes: 502a2ffd7376a ("ipv6: convert idev_list to list macros")
Signed-off-by: David Ahern 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/addrconf.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4439,8 +4439,8 @@ static int in6_dump_addrs(struct inet6_d
 
/* unicast address incl. temp addr */
list_for_each_entry(ifa, >addr_list, if_list) {
-   if (++ip_idx < s_ip_idx)
-   continue;
+   if (ip_idx < s_ip_idx)
+   goto next;
err = inet6_fill_ifaddr(skb, ifa,
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
@@ -4449,6 +4449,8 @@ static int in6_dump_addrs(struct inet6_d
if (err < 0)
break;
nl_dump_check_consistent(cb, nlmsg_hdr(skb));
+next:
+   ip_idx++;
}
break;
}




[PATCH 4.4 089/114] net: bridge: remove ipv6 zero address check in mcast queries

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Nikolay Aleksandrov 

commit 0fe5119e267f3e3d8ac206895f5922195ec55a8a upstream.

Recently a check was added which prevents marking of routers with zero
source address, but for IPv6 that cannot happen as the relevant RFCs
actually forbid such packets:
RFC 2710 (MLDv1):
"To be valid, the Query message MUST
 come from a link-local IPv6 Source Address, be at least 24 octets
 long, and have a correct MLD checksum."

Same goes for RFC 3810.

And also it can be seen as a requirement in ipv6_mc_check_mld_query()
which is used by the bridge to validate the message before processing
it. Thus any queries with :: source address won't be processed anyway.
So just remove the check for zero IPv6 source address from the query
processing function.

Fixes: 5a2de63fd1a5 ("bridge: do not add port to router list when receives 
query with source 0.0.0.0")
Signed-off-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller 
Cc: Hangbin Liu 
Signed-off-by: Greg Kroah-Hartman 

---
 net/bridge/br_multicast.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1267,8 +1267,7 @@ static void br_multicast_query_received(
 * is 0.0.0.0 should not be added to router port list.
 */
if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
-   (saddr->proto == htons(ETH_P_IPV6) &&
-!ipv6_addr_any(>u.ip6)))
+   saddr->proto == htons(ETH_P_IPV6))
br_multicast_mark_router(br, port);
 }
 




[PATCH 4.4 087/114] perf tools: Disable parallelism for make clean

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit da15fc2fa9c07b23db8f5e479bd8a9f0d741ca07 ]

The Yocto build system does a 'make clean' when rebuilding due to
changed dependencies, and that consistently fails for me (causing the
whole BSP build to fail) with errors such as

| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: find: 
'[...]/perf/1.0-r9/perf-1.0/libtraceevent.a''[...]/perf/1.0-r9/perf-1.0/libtraceevent.a':
 No such file or directory: No such file or directory
|
[...]
| find: cannot delete 
'/mnt/xfs/devel/pil/yocto/tmp-glibc/work/wandboard-oe-linux-gnueabi/perf/1.0-r9/perf-1.0/util/.pstack.o.cmd':
 No such file or directory

Apparently (despite the comment), 'make clean' ends up launching
multiple sub-makes that all want to remove the same things - perhaps
this only happens in combination with a O=... parameter. In any case, we
don't lose much by explicitly disabling the parallelism for the clean
target, and it makes automated builds much more reliable.

Signed-off-by: Rasmus Villemoes 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180705131527.19749-1-li...@rasmusvillemoes.dk
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/Makefile |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -69,10 +69,10 @@ all tags TAGS:
$(make)
 
 #
-# The clean target is not really parallel, don't print the jobs info:
+# Explicitly disable parallelism for the clean target.
 #
 clean:
-   $(make)
+   $(make) -j1
 
 #
 # The build-test target is not really parallel, don't print the jobs info:




[PATCH 4.4 100/114] rtnetlink: Disallow FDB configuration for non-Ethernet device

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Ido Schimmel 

[ Upstream commit da71577545a52be3e0e9225a946e5fd79cfab015 ]

When an FDB entry is configured, the address is validated to have the
length of an Ethernet address, but the device for which the address is
configured can be of any type.

The above can result in the use of uninitialized memory when the address
is later compared against existing addresses since 'dev->addr_len' is
used and it may be greater than ETH_ALEN, as with ip6tnl devices.

Fix this by making sure that FDB entries are only configured for
Ethernet devices.

BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
CPU: 1 PID: 4318 Comm: syz-executor998 Not tainted 4.19.0-rc3+ #49
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x14b/0x190 lib/dump_stack.c:113
  kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
  __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
  memcmp+0x11d/0x180 lib/string.c:863
  dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
  ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
  rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
  rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
  netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
  rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
  netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
  netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
  netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:621 [inline]
  sock_sendmsg net/socket.c:631 [inline]
  ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
  __sys_sendmsg net/socket.c:2152 [inline]
  __do_sys_sendmsg net/socket.c:2161 [inline]
  __se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
  do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
  entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x440ee9
Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff6a93b518 EFLAGS: 0213 ORIG_RAX: 002e
RAX: ffda RBX:  RCX: 00440ee9
RDX:  RSI: 2240 RDI: 0003
RBP:  R08: 004002c8 R09: 004002c8
R10: 004002c8 R11: 0213 R12: b4b0
R13: 00401ec0 R14:  R15: 

Uninit was created at:
  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
  kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
  kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
  kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
  slab_post_alloc_hook mm/slab.h:446 [inline]
  slab_alloc_node mm/slub.c:2718 [inline]
  __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
  __kmalloc_reserve net/core/skbuff.c:138 [inline]
  __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
  alloc_skb include/linux/skbuff.h:996 [inline]
  netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
  netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
  sock_sendmsg_nosec net/socket.c:621 [inline]
  sock_sendmsg net/socket.c:631 [inline]
  ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
  __sys_sendmsg net/socket.c:2152 [inline]
  __do_sys_sendmsg net/socket.c:2161 [inline]
  __se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
  do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
  entry_SYSCALL_64_after_hwframe+0x63/0xe7

v2:
* Make error message more specific (David)

Fixes: 090096bf3db1 ("net: generic fdb support for drivers without 
ndo_fdb_")
Signed-off-by: Ido Schimmel 
Reported-and-tested-by: syzbot+3a288d5f5530b9013...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+d53ab4e92a1db0411...@syzkaller.appspotmail.com
Cc: Vlad Yasevich 
Cc: David Ahern 
Reviewed-by: David Ahern 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/core/rtnetlink.c |   10 ++
 1 file changed, 10 insertions(+)

--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2734,6 +2734,11 @@ static int rtnl_fdb_add(struct sk_buff *
return -EINVAL;
}
 
+   if (dev->type != ARPHRD_ETHER) {
+   pr_info("PF_BRIDGE: FDB add only supported for Ethernet 
devices");
+   return -EINVAL;
+   }
+
addr = nla_data(tb[NDA_LLADDR]);
 
err = fdb_vid_parse(tb[NDA_VLAN], );
@@ -2836,6 +2841,11 @@ static int rtnl_fdb_del(struct sk_buff *
return -EINVAL;
}
 
+   if (dev->type != ARPHRD_ETHER) {
+   pr_info("PF_BRIDGE: FDB delete only supported for Ethernet 
devices");
+   return -EINVAL;
+   }
+
  

[PATCH 4.4 099/114] vhost: Fix Spectre V1 vulnerability

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jason Wang 

[ Upstream commit ff002269a4ee9c769dbf9365acef633ebcbd6cbe ]

The idx in vhost_vring_ioctl() was controlled by userspace, hence a
potential exploitation of the Spectre variant 1 vulnerability.

Fixing this by sanitizing idx before using it to index d->vqs.

Cc: Michael S. Tsirkin 
Cc: Josh Poimboeuf 
Cc: Andrea Arcangeli 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/vhost/vhost.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vhost.h"
 
@@ -748,6 +749,7 @@ long vhost_vring_ioctl(struct vhost_dev
if (idx >= d->nvqs)
return -ENOBUFS;
 
+   idx = array_index_nospec(idx, d->nvqs);
vq = d->vqs[idx];
 
mutex_lock(>mutex);




[PATCH 4.4 098/114] net: drop skb on failure in ip_check_defrag()

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Cong Wang 

[ Upstream commit 7de414a9dd91426318df7b63da024b2b07e53df5 ]

Most callers of pskb_trim_rcsum() simply drop the skb when
it fails, however, ip_check_defrag() still continues to pass
the skb up to stack. This is suspicious.

In ip_check_defrag(), after we learn the skb is an IP fragment,
passing the skb to callers makes no sense, because callers expect
fragments are defrag'ed on success. So, dropping the skb when we
can't defrag it is reasonable.

Note, prior to commit 88078d98d1bb, this is not a big problem as
checksum will be fixed up anyway. After it, the checksum is not
correct on failure.

Found this during code review.

Fixes: 88078d98d1bb ("net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends")
Cc: Eric Dumazet 
Signed-off-by: Cong Wang 
Reviewed-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv4/ip_fragment.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -716,10 +716,14 @@ struct sk_buff *ip_check_defrag(struct n
if (ip_is_fragment()) {
skb = skb_share_check(skb, GFP_ATOMIC);
if (skb) {
-   if (!pskb_may_pull(skb, netoff + iph.ihl * 4))
-   return skb;
-   if (pskb_trim_rcsum(skb, netoff + len))
-   return skb;
+   if (!pskb_may_pull(skb, netoff + iph.ihl * 4)) {
+   kfree_skb(skb);
+   return NULL;
+   }
+   if (pskb_trim_rcsum(skb, netoff + len)) {
+   kfree_skb(skb);
+   return NULL;
+   }
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
if (ip_defrag(net, skb, user))
return NULL;




[PATCH 4.4 097/114] sctp: fix race on sctp_id2asoc

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Marcelo Ricardo Leitner 

[ Upstream commit b336decab22158937975293aea79396525f92bb3 ]

syzbot reported an use-after-free involving sctp_id2asoc.  Dmitry Vyukov
helped to root cause it and it is because of reading the asoc after it
was freed:

CPU 1   CPU 2
(working on socket 1)(working on socket 2)
 sctp_association_destroy
sctp_id2asoc
   spin lock
 grab the asoc from idr
   spin unlock
   spin lock
 remove asoc from idr
   spin unlock
   free(asoc)
   if asoc->base.sk != sk ... [*]

This can only be hit if trying to fetch asocs from different sockets. As
we have a single IDR for all asocs, in all SCTP sockets, their id is
unique on the system. An application can try to send stuff on an id
that matches on another socket, and the if in [*] will protect from such
usage. But it didn't consider that as that asoc may belong to another
socket, it may be freed in parallel (read: under another socket lock).

We fix it by moving the checks in [*] into the protected region. This
fixes it because the asoc cannot be freed while the lock is held.

Reported-by: syzbot+c7dd55d7aec49d48e...@syzkaller.appspotmail.com
Acked-by: Dmitry Vyukov 
Signed-off-by: Marcelo Ricardo Leitner 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/sctp/socket.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -248,11 +248,10 @@ struct sctp_association *sctp_id2assoc(s
 
spin_lock_bh(_assocs_id_lock);
asoc = (struct sctp_association *)idr_find(_assocs_id, (int)id);
+   if (asoc && (asoc->base.sk != sk || asoc->base.dead))
+   asoc = NULL;
spin_unlock_bh(_assocs_id_lock);
 
-   if (!asoc || (asoc->base.sk != sk) || asoc->base.dead)
-   return NULL;
-
return asoc;
 }
 




[PATCH 4.4 094/114] net: socket: fix a missing-check bug

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Wenwen Wang 

[ Upstream commit b6168562c8ce2bd5a30e213021650422e08764dc ]

In ethtool_ioctl(), the ioctl command 'ethcmd' is checked through a switch
statement to see whether it is necessary to pre-process the ethtool
structure, because, as mentioned in the comment, the structure
ethtool_rxnfc is defined with padding. If yes, a user-space buffer 'rxnfc'
is allocated through compat_alloc_user_space(). One thing to note here is
that, if 'ethcmd' is ETHTOOL_GRXCLSRLALL, the size of the buffer 'rxnfc' is
partially determined by 'rule_cnt', which is actually acquired from the
user-space buffer 'compat_rxnfc', i.e., 'compat_rxnfc->rule_cnt', through
get_user(). After 'rxnfc' is allocated, the data in the original user-space
buffer 'compat_rxnfc' is then copied to 'rxnfc' through copy_in_user(),
including the 'rule_cnt' field. However, after this copy, no check is
re-enforced on 'rxnfc->rule_cnt'. So it is possible that a malicious user
race to change the value in the 'compat_rxnfc->rule_cnt' between these two
copies. Through this way, the attacker can bypass the previous check on
'rule_cnt' and inject malicious data. This can cause undefined behavior of
the kernel and introduce potential security risk.

This patch avoids the above issue via copying the value acquired by
get_user() to 'rxnfc->rule_cn', if 'ethcmd' is ETHTOOL_GRXCLSRLALL.

Signed-off-by: Wenwen Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/socket.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/net/socket.c
+++ b/net/socket.c
@@ -2760,9 +2760,14 @@ static int ethtool_ioctl(struct net *net
copy_in_user(>fs.ring_cookie,
 _rxnfc->fs.ring_cookie,
 (void __user *)(>fs.location + 1) -
-(void __user *)>fs.ring_cookie) ||
-   copy_in_user(>rule_cnt, _rxnfc->rule_cnt,
-sizeof(rxnfc->rule_cnt)))
+(void __user *)>fs.ring_cookie))
+   return -EFAULT;
+   if (ethcmd == ETHTOOL_GRXCLSRLALL) {
+   if (put_user(rule_cnt, >rule_cnt))
+   return -EFAULT;
+   } else if (copy_in_user(>rule_cnt,
+   _rxnfc->rule_cnt,
+   sizeof(rxnfc->rule_cnt)))
return -EFAULT;
}
 




[PATCH 4.4 091/114] ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are called

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Brivio 

[ Upstream commit ee1abcf689353f36d9322231b4320926096bdee0 ]

Commit a61bbcf28a8c ("[NET]: Store skb->timestamp as offset to a base
timestamp") introduces a neighbour control buffer and zeroes it out in
ndisc_rcv(), as ndisc_recv_ns() uses it.

Commit f2776ff04722 ("[IPV6]: Fix address/interface handling in UDP and
DCCP, according to the scoping architecture.") introduces the usage of the
IPv6 control buffer in protocol error handlers (e.g. inet6_iif() in
present-day __udp6_lib_err()).

Now, with commit b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate
redirect, instead of rt6_redirect()."), we call protocol error handlers
from ndisc_redirect_rcv(), after the control buffer is already stolen and
some parts are already zeroed out. This implies that inet6_iif() on this
path will always return zero.

This gives unexpected results on UDP socket lookup in __udp6_lib_err(), as
we might actually need to match sockets for a given interface.

Instead of always claiming the control buffer in ndisc_rcv(), do that only
when needed.

Fixes: b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate redirect, instead 
of rt6_redirect().")
Signed-off-by: Stefano Brivio 
Reviewed-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ndisc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1649,10 +1649,9 @@ int ndisc_rcv(struct sk_buff *skb)
return 0;
}
 
-   memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
-
switch (msg->icmph.icmp6_type) {
case NDISC_NEIGHBOUR_SOLICITATION:
+   memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
ndisc_recv_ns(skb);
break;
 




[PATCH 4.4 053/114] fuse: Dont call set_page_dirty_lock() for ITER_BVEC pages for async_dio

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 61c12b49e1c9c77d7a1bcc161de540d0fd21cf0c ]

Commit 8fba54aebbdf ("fuse: direct-io: don't dirty ITER_BVEC pages") fixes
the ITER_BVEC page deadlock for direct io in fuse by checking in
fuse_direct_io(), whether the page is a bvec page or not, before locking
it.  However, this check is missed when the "async_dio" mount option is
enabled.  In this case, set_page_dirty_lock() is called from the req->end
callback in request_end(), when the fuse thread is returning from userspace
to respond to the read request.  This will cause the same deadlock because
the bvec condition is not checked in this path.

Here is the stack of the deadlocked thread, while returning from userspace:

[13706.656686] INFO: task glusterfs:3006 blocked for more than 120 seconds.
[13706.657808] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[13706.658788] glusterfs   D 816c80f0 0  3006  1
0x0080
[13706.658797]  8800d6713a58 0086 8800d9ad7000
8800d9ad5400
[13706.658799]  88011ffd5cc0 8800d6710008 88011fd176c0
7fff
[13706.658801]  0002 816c80f0 8800d6713a78
816c790e
[13706.658803] Call Trace:
[13706.658809]  [] ? bit_wait_io_timeout+0x80/0x80
[13706.658811]  [] schedule+0x3e/0x90
[13706.658813]  [] schedule_timeout+0x1b5/0x210
[13706.658816]  [] ? gup_pud_range+0x1db/0x1f0
[13706.658817]  [] ? kvm_clock_read+0x1e/0x20
[13706.658819]  [] ? kvm_clock_get_cycles+0x9/0x10
[13706.658822]  [] ? ktime_get+0x52/0xc0
[13706.658824]  [] io_schedule_timeout+0xa4/0x110
[13706.658826]  [] bit_wait_io+0x36/0x50
[13706.658828]  [] __wait_on_bit_lock+0x76/0xb0
[13706.658831]  [] ? lock_request+0x46/0x70 [fuse]
[13706.658834]  [] __lock_page+0xaa/0xb0
[13706.658836]  [] ? wake_atomic_t_function+0x40/0x40
[13706.658838]  [] set_page_dirty_lock+0x58/0x60
[13706.658841]  [] fuse_release_user_pages+0x58/0x70 [fuse]
[13706.658844]  [] ? fuse_aio_complete+0x190/0x190 [fuse]
[13706.658847]  [] fuse_aio_complete_req+0x29/0x90 [fuse]
[13706.658849]  [] request_end+0xd9/0x190 [fuse]
[13706.658852]  [] fuse_dev_do_write+0x336/0x490 [fuse]
[13706.658854]  [] fuse_dev_write+0x6e/0xa0 [fuse]
[13706.658857]  [] ? security_file_permission+0x23/0x90
[13706.658859]  [] do_iter_readv_writev+0x60/0x90
[13706.658862]  [] ? fuse_dev_splice_write+0x350/0x350
[fuse]
[13706.658863]  [] do_readv_writev+0x171/0x1f0
[13706.658866]  [] ? try_to_wake_up+0x210/0x210
[13706.658868]  [] vfs_writev+0x41/0x50
[13706.658870]  [] SyS_writev+0x56/0xf0
[13706.658872]  [] ? syscall_trace_leave+0xf1/0x160
[13706.658874]  [] system_call_fastpath+0x12/0x71

Fix this by making should_dirty a fuse_io_priv parameter that can be
checked in fuse_aio_complete_req().

Reported-by: Tiger Yang 
Signed-off-by: Ashish Samant 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Sasha Levin 
---
 fs/fuse/file.c   | 6 +++---
 fs/fuse/fuse_i.h | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 8577f3ba6dc6..7014318f6d18 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -625,7 +625,7 @@ static void fuse_aio_complete_req(struct fuse_conn *fc, 
struct fuse_req *req)
struct fuse_io_priv *io = req->io;
ssize_t pos = -1;
 
-   fuse_release_user_pages(req, !io->write);
+   fuse_release_user_pages(req, io->should_dirty);
 
if (io->write) {
if (req->misc.write.in.size != req->misc.write.out.size)
@@ -1333,7 +1333,6 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct 
iov_iter *iter,
   loff_t *ppos, int flags)
 {
int write = flags & FUSE_DIO_WRITE;
-   bool should_dirty = !write && iter_is_iovec(iter);
int cuse = flags & FUSE_DIO_CUSE;
struct file *file = io->file;
struct inode *inode = file->f_mapping->host;
@@ -1362,6 +1361,7 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct 
iov_iter *iter,
mutex_unlock(>i_mutex);
}
 
+   io->should_dirty = !write && iter_is_iovec(iter);
while (count) {
size_t nres;
fl_owner_t owner = current->files;
@@ -1378,7 +1378,7 @@ ssize_t fuse_direct_io(struct fuse_io_priv *io, struct 
iov_iter *iter,
nres = fuse_send_read(req, io, pos, nbytes, owner);
 
if (!io->async)
-   fuse_release_user_pages(req, should_dirty);
+   fuse_release_user_pages(req, io->should_dirty);
if (req->out.h.error) {
if (!res)
res = req->out.h.error;
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index 7aafe9acc6c0..c6eb35a95fcc 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -252,6 +252,7 @@ struct fuse_io_priv {
size_t size;
__u64 offset;
bool write;
+   

Re: [patch 2/2] Documentation/process: Add tip tree handbook

2018-11-08 Thread Greg KH
On Thu, Nov 08, 2018 at 05:19:47PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 01:04:49PM -0800, Greg KH wrote:
> > > (Also note that even with fast SSD's and/or everything in page cache,
> > > runnning "tag --contains " will take a good 3-4 seconds, and
> > > if the git packs are not in the page cache, and/or you're unfortunate
> > > enough to have your git trees on an HDD it's not pretty.)
> > 
> > I recommend the "static cache" or whatever that thing is called, that
> > helps out a _LOT_ with stuff like this.  For the kernel tree, which is
> > never rebased, it speeds up this so much.
> 
> At the risk of asking a stupid question, which cache is this?  I don't
> think it's the untrackedCache; is it the BitmapHashCache?

It's the 'commitGraph', here's the article I was trying to remember I
learned this from:

https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/

greg k-h


[PATCH 4.4 038/114] aacraid: Start adapter after updating number of MSIX vectors

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 116d77fea02e2a5aded7d29ba4c692774cb339f1 ]

The adapter has to be started after updating the number of MSIX Vectors

Fixes: ecc479e00db8 (aacraid: Set correct MSIX count for EEH recovery)
Cc: sta...@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/aacraid/linit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 8da8b46da722..1c447405ebbf 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1416,8 +1416,8 @@ static int aac_acquire_resources(struct aac_dev *dev)
/* After EEH recovery or suspend resume, max_msix count
 * may change, therfore updating in init as well.
 */
-   aac_adapter_start(dev);
dev->init->Sa_MSIXVectors = cpu_to_le32(dev->max_msix);
+   aac_adapter_start(dev);
}
return 0;
 
-- 
2.17.1





[PATCH 4.4 057/114] ixgbe: fix RSS limit for X550

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e9ee3238f8a480bbca58e51d02a93628d7c1f265 ]

X550 allows for up to 64 RSS queues, but the driver can have max
of 63 (-1 MSIX vector for link).

On systems with >= 64 CPUs the driver will set the redirection table
for all 64 queues which will result in packets being dropped.

Signed-off-by: Emil Tantilov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 1d2174526a4c..18e4e4a69262 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -312,7 +312,7 @@ enum ixgbe_ring_f_enum {
 };
 
 #define IXGBE_MAX_RSS_INDICES  16
-#define IXGBE_MAX_RSS_INDICES_X550 64
+#define IXGBE_MAX_RSS_INDICES_X550 63
 #define IXGBE_MAX_VMDQ_INDICES 64
 #define IXGBE_MAX_FDIR_INDICES 63  /* based on q_vector limit */
 #define IXGBE_MAX_FCOE_INDICES 8
-- 
2.17.1





[PATCH 4.4 056/114] net/mlx5e: Correctly handle RSS indirection table when changing number of channels

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 85082dba0a5059c538cfa786d07f5ec5370d22fe ]

Upon changing num_channels, reset the RSS indirection table to
match the new value.

Fixes: 2d75b2bc8a8c ('net/mlx5e: Add ethtool RSS configuration options')
Signed-off-by: Tariq Toukan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |  2 ++
 .../net/ethernet/mellanox/mlx5/core/en_ethtool.c  |  2 ++
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 15 +++
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 22e72bf1ae48..7a716733d9ca 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -586,6 +586,8 @@ int mlx5e_redirect_rqt(struct mlx5e_priv *priv, enum 
mlx5e_rqt_ix rqt_ix);
 
 int mlx5e_open_locked(struct net_device *netdev);
 int mlx5e_close_locked(struct net_device *netdev);
+void mlx5e_build_default_indir_rqt(u32 *indirection_rqt, int len,
+  int num_channels);
 
 static inline void mlx5e_tx_notify_hw(struct mlx5e_sq *sq,
  struct mlx5e_tx_wqe *wqe, int bf_sz)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 7cc9df717323..7ee301310817 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -385,6 +385,8 @@ static int mlx5e_set_channels(struct net_device *dev,
mlx5e_close_locked(dev);
 
priv->params.num_channels = count;
+   mlx5e_build_default_indir_rqt(priv->params.indirection_rqt,
+ MLX5E_INDIR_RQT_SIZE, count);
 
if (was_opened)
err = mlx5e_open_locked(dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 765b069d6a90..26d25ecdca7e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1186,7 +1186,6 @@ static void mlx5e_fill_indir_rqt_rqns(struct mlx5e_priv 
*priv, void *rqtc)
ix = mlx5e_bits_invert(i, MLX5E_LOG_INDIR_RQT_SIZE);
 
ix = priv->params.indirection_rqt[ix];
-   ix = ix % priv->params.num_channels;
MLX5_SET(rqtc, rqtc, rq_num[i],
 test_bit(MLX5E_STATE_OPENED, >state) ?
 priv->channel[ix]->rq.rqn :
@@ -1983,12 +1982,20 @@ u16 mlx5e_get_max_inline_cap(struct mlx5_core_dev *mdev)
   2 /*sizeof(mlx5e_tx_wqe.inline_hdr_start)*/;
 }
 
+void mlx5e_build_default_indir_rqt(u32 *indirection_rqt, int len,
+  int num_channels)
+{
+   int i;
+
+   for (i = 0; i < len; i++)
+   indirection_rqt[i] = i % num_channels;
+}
+
 static void mlx5e_build_netdev_priv(struct mlx5_core_dev *mdev,
struct net_device *netdev,
int num_channels)
 {
struct mlx5e_priv *priv = netdev_priv(netdev);
-   int i;
 
priv->params.log_sq_size   =
MLX5E_PARAMS_DEFAULT_LOG_SQ_SIZE;
@@ -2012,8 +2019,8 @@ static void mlx5e_build_netdev_priv(struct mlx5_core_dev 
*mdev,
netdev_rss_key_fill(priv->params.toeplitz_hash_key,
sizeof(priv->params.toeplitz_hash_key));
 
-   for (i = 0; i < MLX5E_INDIR_RQT_SIZE; i++)
-   priv->params.indirection_rqt[i] = i % num_channels;
+   mlx5e_build_default_indir_rqt(priv->params.indirection_rqt,
+ MLX5E_INDIR_RQT_SIZE, num_channels);
 
priv->params.lro_wqe_sz=
MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ;
-- 
2.17.1





[PATCH 4.4 055/114] net/mlx5e: Fix LRO modify

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ab0394fe2c258fdb5086c51a251b28f8ee7ab35c ]

Ethtool LRO enable/disable is broken, as of today we only modify TCP
TIRs in order to apply the requested configuration.

Hardware requires that all TIRs pointing to the same RQ should share the
same LRO configuration. For that all other TIRs' LRO fields must be
modified as well.

Fixes: 5c50368f3831 ('net/mlx5e: Light-weight netdev open/stop')
Signed-off-by: Tariq Toukan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 90e876ecc720..765b069d6a90 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -1304,7 +1304,7 @@ static void mlx5e_build_tir_ctx_lro(void *tirc, struct 
mlx5e_priv *priv)
  lro_timer_supported_periods[2]));
 }
 
-static int mlx5e_modify_tir_lro(struct mlx5e_priv *priv, int tt)
+static int mlx5e_modify_tirs_lro(struct mlx5e_priv *priv)
 {
struct mlx5_core_dev *mdev = priv->mdev;
 
@@ -1312,6 +1312,7 @@ static int mlx5e_modify_tir_lro(struct mlx5e_priv *priv, 
int tt)
void *tirc;
int inlen;
int err;
+   int tt;
 
inlen = MLX5_ST_SZ_BYTES(modify_tir_in);
in = mlx5_vzalloc(inlen);
@@ -1323,7 +1324,11 @@ static int mlx5e_modify_tir_lro(struct mlx5e_priv *priv, 
int tt)
 
mlx5e_build_tir_ctx_lro(tirc, priv);
 
-   err = mlx5_core_modify_tir(mdev, priv->tirn[tt], in, inlen);
+   for (tt = 0; tt < MLX5E_NUM_TT; tt++) {
+   err = mlx5_core_modify_tir(mdev, priv->tirn[tt], in, inlen);
+   if (err)
+   break;
+   }
 
kvfree(in);
 
@@ -1870,8 +1875,10 @@ static int mlx5e_set_features(struct net_device *netdev,
mlx5e_close_locked(priv->netdev);
 
priv->params.lro_en = !!(features & NETIF_F_LRO);
-   mlx5e_modify_tir_lro(priv, MLX5E_TT_IPV4_TCP);
-   mlx5e_modify_tir_lro(priv, MLX5E_TT_IPV6_TCP);
+   err = mlx5e_modify_tirs_lro(priv);
+   if (err)
+   mlx5_core_warn(priv->mdev, "lro modify failed, %d\n",
+  err);
 
if (was_opened)
err = mlx5e_open_locked(priv->netdev);
-- 
2.17.1





[PATCH 4.4 017/114] perf/ring_buffer: Prevent concurent ring buffer access

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit cd6fb677ce7e460c25bdd66f689734102ec7d642 ]

Some of the scheduling tracepoints allow the perf_tp_event
code to write to ring buffer under different cpu than the
code is running on.

This results in corrupted ring buffer data demonstrated in
following perf commands:

  # perf record -e 'sched:sched_switch,sched:sched_wakeup' perf bench sched 
messaging
  # Running 'sched/messaging' benchmark:
  # 20 sender and receiver processes per group
  # 10 groups == 400 processes run

   Total time: 0.383 [sec]
  [ perf record: Woken up 8 times to write data ]
  0x42b890 [0]: failed to process type: -1765585640
  [ perf record: Captured and wrote 4.825 MB perf.data (29669 samples) ]

  # perf report --stdio
  0x42b890 [0]: failed to process type: -1765585640

The reason for the corruption are some of the scheduling tracepoints,
that have __perf_task dfined and thus allow to store data to another
cpu ring buffer:

  sched_waking
  sched_wakeup
  sched_wakeup_new
  sched_stat_wait
  sched_stat_sleep
  sched_stat_iowait
  sched_stat_blocked

The perf_tp_event function first store samples for current cpu
related events defined for tracepoint:

hlist_for_each_entry_rcu(event, head, hlist_entry)
  perf_swevent_event(event, count, , regs);

And then iterates events of the 'task' and store the sample
for any task's event that passes tracepoint checks:

  ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]);

  list_for_each_entry_rcu(event, >event_list, event_entry) {
if (event->attr.type != PERF_TYPE_TRACEPOINT)
  continue;
if (event->attr.config != entry->type)
  continue;

perf_swevent_event(event, count, , regs);
  }

Above code can race with same code running on another cpu,
ending up with 2 cpus trying to store under the same ring
buffer, which is specifically not allowed.

This patch prevents the problem, by allowing only events with the same
current cpu to receive the event.

NOTE: this requires the use of (per-task-)per-cpu buffers for this
feature to work; perf-record does this.

Signed-off-by: Jiri Olsa 
[peterz: small edits to Changelog]
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Andrew Vagin 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: e6dab5ffab59 ("perf/trace: Add ability to set a target task for events")
Link: http://lkml.kernel.org/r/20180923161343.GB15054@krava
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/events/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 990ac41d8a5f..330fcd1b1822 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7018,6 +7018,8 @@ void perf_tp_event(u64 addr, u64 count, void *record, int 
entry_size,
goto unlock;
 
list_for_each_entry_rcu(event, >event_list, event_entry) {
+   if (event->cpu != smp_processor_id())
+   continue;
if (event->attr.type != PERF_TYPE_TRACEPOINT)
continue;
if (event->attr.config != entry->type)
-- 
2.17.1





[PATCH 4.4 049/114] sch_red: update backlog as well

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit d7f4f332f082c4d4ba53582f902ed6b44fd6f45e ]

Fixes: 2f5fb43f ("net_sched: update hierarchical backlog too")
Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/sched/sch_red.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 0505b8408c8b..4bf2b599ef98 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -97,6 +97,7 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch)
 
ret = qdisc_enqueue(skb, child);
if (likely(ret == NET_XMIT_SUCCESS)) {
+   qdisc_qstats_backlog_inc(sch, skb);
sch->q.qlen++;
} else if (net_xmit_drop_count(ret)) {
q->stats.pdrop++;
@@ -118,6 +119,7 @@ static struct sk_buff *red_dequeue(struct Qdisc *sch)
skb = child->dequeue(child);
if (skb) {
qdisc_bstats_update(sch, skb);
+   qdisc_qstats_backlog_dec(sch, skb);
sch->q.qlen--;
} else {
if (!red_is_idling(>vars))
@@ -143,6 +145,7 @@ static unsigned int red_drop(struct Qdisc *sch)
if (child->ops->drop && (len = child->ops->drop(child)) > 0) {
q->stats.other++;
qdisc_qstats_drop(sch);
+   sch->qstats.backlog -= len;
sch->q.qlen--;
return len;
}
@@ -158,6 +161,7 @@ static void red_reset(struct Qdisc *sch)
struct red_sched_data *q = qdisc_priv(sch);
 
qdisc_reset(q->qdisc);
+   sch->qstats.backlog = 0;
sch->q.qlen = 0;
red_restart(>vars);
 }
-- 
2.17.1





[PATCH 4.4 061/114] gro: Allow tunnel stacking in the case of FOU/GUE

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit c3483384ee511ee2af40b4076366cd82a6a47b86 ]

This patch should fix the issues seen with a recent fix to prevent
tunnel-in-tunnel frames from being generated with GRO.  The fix itself is
correct for now as long as we do not add any devices that support
NETIF_F_GSO_GRE_CSUM.  When such a device is added it could have the
potential to mess things up due to the fact that the outer transport header
points to the outer UDP header and not the GRE header as would be expected.

Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of 
encapsulation.")
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/ipv4/fou.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 08d8ee124538..d83888bc33d3 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -195,6 +195,14 @@ static struct sk_buff **fou_gro_receive(struct sk_buff 
**head,
u8 proto = NAPI_GRO_CB(skb)->proto;
const struct net_offload **offloads;
 
+   /* We can clear the encap_mark for FOU as we are essentially doing
+* one of two possible things.  We are either adding an L4 tunnel
+* header to the outer L3 tunnel header, or we are are simply
+* treating the GRE tunnel header as though it is a UDP protocol
+* specific header such as VXLAN or GENEVE.
+*/
+   NAPI_GRO_CB(skb)->encap_mark = 0;
+
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[proto]);
@@ -354,6 +362,14 @@ static struct sk_buff **gue_gro_receive(struct sk_buff 
**head,
}
}
 
+   /* We can clear the encap_mark for GUE as we are essentially doing
+* one of two possible things.  We are either adding an L4 tunnel
+* header to the outer L3 tunnel header, or we are are simply
+* treating the GRE tunnel header as though it is a UDP protocol
+* specific header such as VXLAN or GENEVE.
+*/
+   NAPI_GRO_CB(skb)->encap_mark = 0;
+
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[guehdr->proto_ctype]);
-- 
2.17.1





[PATCH 4.4 060/114] vti6: flush x-netns xfrm cache when vti interface is removed

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 7f92083eb58f85ea114d97f65fcbe22be5b0468d ]

This is the same fix than commit a5d0dc810abf ("vti: flush x-netns xfrm
cache when vti interface is removed")

This patch fixes a refcnt problem when a x-netns vti6 interface is removed:
unregister_netdevice: waiting for vti6_test to become free. Usage count = 1

Here is a script to reproduce the problem:

ip link set dev ntfp2 up
ip addr add dev ntfp2 2001::1/64
ip link add vti6_test type vti6 local 2001::1 remote 2001::2 key 1
ip netns add secure
ip link set vti6_test netns secure
ip netns exec secure ip link set vti6_test up
ip netns exec secure ip link s lo up
ip netns exec secure ip addr add dev vti6_test 2003::1/64
ip -6 xfrm policy add dir out tmpl src 2001::1 dst 2001::2 proto esp \
   mode tunnel mark 1
ip -6 xfrm policy add dir in tmpl src 2001::2 dst 2001::1 proto esp \
   mode tunnel mark 1
ip xfrm state add src 2001::1 dst 2001::2 proto esp spi 1 mode tunnel \
   enc des3_ede 0x112233445566778811223344556677881122334455667788 mark 
1
ip xfrm state add src 2001::2 dst 2001::1 proto esp spi 1 mode tunnel \
   enc des3_ede 0x112233445566778811223344556677881122334455667788 mark 
1
ip netns exec secure  ping6 -c 4 2003::2
ip netns del secure

CC: Lance Richardson 
Signed-off-by: Nicolas Dichtel 
Acked-by: Lance Richardson 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/ipv6/ip6_vti.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 60d4052d97a6..51da5987952c 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -1140,6 +1140,33 @@ static struct xfrm6_protocol vti_ipcomp6_protocol 
__read_mostly = {
.priority   =   100,
 };
 
+static bool is_vti6_tunnel(const struct net_device *dev)
+{
+   return dev->netdev_ops == _netdev_ops;
+}
+
+static int vti6_device_event(struct notifier_block *unused,
+unsigned long event, void *ptr)
+{
+   struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+   struct ip6_tnl *t = netdev_priv(dev);
+
+   if (!is_vti6_tunnel(dev))
+   return NOTIFY_DONE;
+
+   switch (event) {
+   case NETDEV_DOWN:
+   if (!net_eq(t->net, dev_net(dev)))
+   xfrm_garbage_collect(t->net);
+   break;
+   }
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block vti6_notifier_block __read_mostly = {
+   .notifier_call = vti6_device_event,
+};
+
 /**
  * vti6_tunnel_init - register protocol and reserve needed resources
  *
@@ -1150,6 +1177,8 @@ static int __init vti6_tunnel_init(void)
const char *msg;
int err;
 
+   register_netdevice_notifier(_notifier_block);
+
msg = "tunnel device";
err = register_pernet_device(_net_ops);
if (err < 0)
@@ -1182,6 +1211,7 @@ xfrm_proto_ah_failed:
 xfrm_proto_esp_failed:
unregister_pernet_device(_net_ops);
 pernet_dev_failed:
+   unregister_netdevice_notifier(_notifier_block);
pr_err("vti6 init: failed to register %s\n", msg);
return err;
 }
@@ -1196,6 +1226,7 @@ static void __exit vti6_tunnel_cleanup(void)
xfrm6_protocol_deregister(_ah6_protocol, IPPROTO_AH);
xfrm6_protocol_deregister(_esp6_protocol, IPPROTO_ESP);
unregister_pernet_device(_net_ops);
+   unregister_netdevice_notifier(_notifier_block);
 }
 
 module_init(vti6_tunnel_init);
-- 
2.17.1





[PATCH 4.4 062/114] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 5ea59db8a375216e6c915c5586f556766673b5a7 ]

An earlier change to this function (3bdae810721b) fixed a leak in the
case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
glom_skb buffer, used for emulating a scattering read, is never used
or referenced after its contents are copied into the destination
buffers, and therefore always needs to be freed by the end of the
function.

Fixes: 3bdae810721b ("brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain")
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without 
sg support")
Cc: sta...@vger.kernel.org # 4.9.x-
Signed-off-by: Peter S. Housel 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 91da67657f81..72e1796c8167 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -705,7 +705,7 @@ done:
 int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
   struct sk_buff_head *pktq, uint totlen)
 {
-   struct sk_buff *glom_skb;
+   struct sk_buff *glom_skb = NULL;
struct sk_buff *skb;
u32 addr = sdiodev->sbwad;
int err = 0;
@@ -726,10 +726,8 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
return -ENOMEM;
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
 glom_skb);
-   if (err) {
-   brcmu_pkt_buf_free_skb(glom_skb);
+   if (err)
goto done;
-   }
 
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
@@ -740,6 +738,7 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
pktq);
 
 done:
+   brcmu_pkt_buf_free_skb(glom_skb);
return err;
 }
 
-- 
2.17.1





[PATCH 4.4 054/114] ixgbevf: Fix handling of NAPI budget when multiple queues are enabled per vector

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit d0f71afffa1c3d5a36a4a278f1dbbd2643176dc3 ]

This is the same patch as for ixgbe but applied differently according to
busy polling.  See commit 5d6002b7b822c74 ("ixgbe: Fix handling of NAPI
budget when multiple queues are enabled per vector")

Signed-off-by: William Dauchy 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c 
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 50bbad37d640..723bda33472a 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1014,6 +1014,8 @@ static int ixgbevf_poll(struct napi_struct *napi, int 
budget)
ixgbevf_for_each_ring(ring, q_vector->tx)
clean_complete &= ixgbevf_clean_tx_irq(q_vector, ring);
 
+   if (budget <= 0)
+   return budget;
 #ifdef CONFIG_NET_RX_BUSY_POLL
if (!ixgbevf_qv_lock_napi(q_vector))
return budget;
-- 
2.17.1





[PATCH 3.18 132/144] ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are called

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Brivio 

[ Upstream commit ee1abcf689353f36d9322231b4320926096bdee0 ]

Commit a61bbcf28a8c ("[NET]: Store skb->timestamp as offset to a base
timestamp") introduces a neighbour control buffer and zeroes it out in
ndisc_rcv(), as ndisc_recv_ns() uses it.

Commit f2776ff04722 ("[IPV6]: Fix address/interface handling in UDP and
DCCP, according to the scoping architecture.") introduces the usage of the
IPv6 control buffer in protocol error handlers (e.g. inet6_iif() in
present-day __udp6_lib_err()).

Now, with commit b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate
redirect, instead of rt6_redirect()."), we call protocol error handlers
from ndisc_redirect_rcv(), after the control buffer is already stolen and
some parts are already zeroed out. This implies that inet6_iif() on this
path will always return zero.

This gives unexpected results on UDP socket lookup in __udp6_lib_err(), as
we might actually need to match sockets for a given interface.

Instead of always claiming the control buffer in ndisc_rcv(), do that only
when needed.

Fixes: b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate redirect, instead 
of rt6_redirect().")
Signed-off-by: Stefano Brivio 
Reviewed-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ndisc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1610,10 +1610,9 @@ int ndisc_rcv(struct sk_buff *skb)
return 0;
}
 
-   memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
-
switch (msg->icmph.icmp6_type) {
case NDISC_NEIGHBOUR_SOLICITATION:
+   memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
ndisc_recv_ns(skb);
break;
 




[PATCH 3.18 112/144] perf: Fix PERF_EVENT_IOC_PERIOD deadlock

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 642c2d671ceff40e9453203ea0c66e991e11e249 ]

Dmitry reported a fairly silly recursive lock deadlock for
PERF_EVENT_IOC_PERIOD, fix this by explicitly doing the inactive part of
__perf_event_period() instead of calling that function.

Reported-by: Dmitry Vyukov 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexander Potapenko 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Eric Dumazet 
Cc: Jiri Olsa 
Cc: Kostya Serebryany 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: c7999c6f3fed ("perf: Fix PERF_EVENT_IOC_PERIOD migration race")
Link: 
http://lkml.kernel.org/r/20151130115615.gj17...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/events/core.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1f08f691de59..7b2f9d432fe7 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3929,7 +3929,14 @@ retry:
goto retry;
}
 
-   __perf_event_period();
+   if (event->attr.freq) {
+   event->attr.sample_freq = value;
+   } else {
+   event->attr.sample_period = value;
+   event->hw.sample_period = value;
+   }
+
+   local64_set(>hw.period_left, 0);
raw_spin_unlock_irq(>lock);
 
return 0;
-- 
2.17.1





[PATCH 3.18 111/144] libata: blacklist Micron 500IT SSD with MU01 firmware

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c ]

While whitelisting Micron M500DC drives, the tweaked blacklist entry
enabled queued TRIM from M500IT variants also. But these do not support
queued TRIM. And while using those SSDs with the latest kernel we have
seen errors and even the partition table getting corrupted.

Some part from the dmesg:
[6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
[6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[6.741026] ata1.00: supports DRM functions and may not be fully accessible
[6.759887] ata1.00: configured for UDMA/133
[6.762256] scsi 0:0:0:0: Direct-Access ATA  Micron_M500IT_MT MU01 
PQ: 0 ANSI: 5

and then for the error:
[  120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 
frozen
[  120.860338] ata1.00: irq_stat 0x4008
[  120.860342] ata1.00: failed command: SEND FPDMA QUEUED
[  120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 
512 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
[  120.860353] ata1.00: status: { DRDY }
[  120.860543] ata1: hard resetting link
[  121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  121.166376] ata1.00: supports DRM functions and may not be fully accessible
[  121.186238] ata1.00: supports DRM functions and may not be fully accessible
[  121.204445] ata1.00: configured for UDMA/133
[  121.204454] ata1.00: device reported invalid CHS sector 0
[  121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 
driverbyte=0x08
[  121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
[  121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
[  121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 
04 28 80 00 00 00 30 00 00
[  121.204559] print_req_error: I/O error, dev sda, sector 272512

After few reboots with these errors, and the SSD is corrupted.
After blacklisting it, the errors are not seen and the SSD does not get
corrupted any more.

Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC")
Cc: Martin K. Petersen 
Cc: sta...@vger.kernel.org
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
---
 drivers/ata/libata-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index cd589d012ef1..6629a5deccbd 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4249,6 +4249,8 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
ATA_HORKAGE_NOLPM, },
 
/* devices that don't properly handle queued TRIM commands */
+   { "Micron_M500IT_*","MU01", ATA_HORKAGE_NO_NCQ_TRIM |
+   ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M500_*",  NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*",   NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
-- 
2.17.1





[PATCH 3.18 110/144] igb: Unpair the queues when changing the number of queues

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 37a5d163fb447b39f7960d0534de30e88ad395bb ]

By the commit 72ddef0506da ("igb: Fix oops caused by missing queue
pairing"), the IGB_FLAG_QUEUE_PAIRS flag can now be set when changing the
number of queues by "ethtool -L", but it is never cleared unless the igb
driver is reloaded.
This patch clears it if queue pairing becomes unnecessary as a result of
"ethtool -L".

Signed-off-by: Shota Suzuki 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index 1ffad88e8a29..84049078c4f0 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2941,6 +2941,8 @@ void igb_set_flag_queue_pairs(struct igb_adapter *adapter,
 */
if (adapter->rss_queues > (max_rss_queues / 2))
adapter->flags |= IGB_FLAG_QUEUE_PAIRS;
+   else
+   adapter->flags &= ~IGB_FLAG_QUEUE_PAIRS;
break;
}
 }
-- 
2.17.1





[GIT PULL] xfs: fixes for v4.20-rc2

2018-11-08 Thread Darrick J. Wong
Hi Linus,

Here's the start of the stabilization fixes for 4.20.  Let me know if
there are any problems merging; I just did it against current master and
saw no issues.

--D

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-4.20-fixes-1

for you to fetch changes up to 837514f7a4ca4aca06aec5caa5ff56d33ef06976:

  xfs: fix overflow in xfs_attr3_leaf_verify (2018-11-06 07:50:50 -0800)


Changes since last update:
- fix incorrect dropping of error code from bmap
- print buffer offsets instead of useless hashed pointers when dumping
  corrupt metadata
- fix integer overflow in attribute verifier


Christophe JAILLET (1):
  xfs: Fix error code in 'xfs_ioc_getbmap()'

Darrick J. Wong (1):
  xfs: print buffer offsets when dumping corrupt buffers

Dave Chinner (1):
  xfs: fix overflow in xfs_attr3_leaf_verify

 fs/xfs/libxfs/xfs_attr_leaf.c | 11 +--
 fs/xfs/xfs_ioctl.c|  2 +-
 fs/xfs/xfs_message.c  |  2 +-
 3 files changed, 11 insertions(+), 4 deletions(-)


[PATCH 3.18 108/144] tty: audit: Fix audit source

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 6b2a3d628aa752f0ab825fc6d4d07b09e274d1c1 ]

The data to audit/record is in the 'from' buffer (ie., the input
read buffer).

Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode")
Cc: stable  # 4.1+
Cc: Miloslav Trmač 
Signed-off-by: Peter Hurley 
Acked-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/n_tty.c | 2 +-
 drivers/tty/tty_audit.c | 2 +-
 include/linux/tty.h | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 0ed99ad74bee..f53682bb30cf 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -195,7 +195,7 @@ static inline int tty_copy_to_user(struct tty_struct *tty,
 {
struct n_tty_data *ldata = tty->disc_data;
 
-   tty_audit_add_data(tty, to, n, ldata->icanon);
+   tty_audit_add_data(tty, from, n, ldata->icanon);
return copy_to_user(to, from, n);
 }
 
diff --git a/drivers/tty/tty_audit.c b/drivers/tty/tty_audit.c
index 90ca082935f6..3d245cd3d8e6 100644
--- a/drivers/tty/tty_audit.c
+++ b/drivers/tty/tty_audit.c
@@ -265,7 +265,7 @@ static struct tty_audit_buf *tty_audit_buf_get(struct 
tty_struct *tty,
  *
  * Audit @data of @size from @tty, if necessary.
  */
-void tty_audit_add_data(struct tty_struct *tty, unsigned char *data,
+void tty_audit_add_data(struct tty_struct *tty, const void *data,
size_t size, unsigned icanon)
 {
struct tty_audit_buf *buf;
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 4858a3b79b7a..47d0bfa536e7 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -587,7 +587,7 @@ extern void n_tty_inherit_ops(struct tty_ldisc_ops *ops);
 
 /* tty_audit.c */
 #ifdef CONFIG_AUDIT
-extern void tty_audit_add_data(struct tty_struct *tty, unsigned char *data,
+extern void tty_audit_add_data(struct tty_struct *tty, const void *data,
   size_t size, unsigned icanon);
 extern void tty_audit_exit(void);
 extern void tty_audit_fork(struct signal_struct *sig);
@@ -595,8 +595,8 @@ extern void tty_audit_tiocsti(struct tty_struct *tty, char 
ch);
 extern void tty_audit_push(struct tty_struct *tty);
 extern int tty_audit_push_current(void);
 #else
-static inline void tty_audit_add_data(struct tty_struct *tty,
-   unsigned char *data, size_t size, unsigned icanon)
+static inline void tty_audit_add_data(struct tty_struct *tty, const void *data,
+ size_t size, unsigned icanon)
 {
 }
 static inline void tty_audit_tiocsti(struct tty_struct *tty, char ch)
-- 
2.17.1





[PATCH 3.18 085/144] x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable()

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit d97eb8966c91f2c9d05f0a22eb89ed5b76d966d1 ]

When an interrupt is migrated away from a cpu it will stay
in its vector_irq array until smp_irq_move_cleanup_interrupt
succeeded. The cfg->move_in_progress flag is cleared already
when the IPI was sent.

When the interrupt is destroyed after migration its 'struct
irq_desc' is freed and the vector_irq arrays are cleaned up.
But since cfg->move_in_progress is already 0 the references
at cpus before the last migration will not be cleared. So
this would leave a reference to an already destroyed irq
alive.

When the cpu is taken down at this point, the
check_irq_vectors_for_cpu_disable() function finds a valid irq
number in the vector_irq array, but gets NULL for its
descriptor and dereferences it, causing a kernel panic.

This has been observed on real systems at shutdown. Add a
check to check_irq_vectors_for_cpu_disable() for a valid
'struct irq_desc' to prevent this issue.

Signed-off-by: Joerg Roedel 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Jiang Liu 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: K. Y. Srinivasan 
Cc: Linus Torvalds 
Cc: Prarit Bhargava 
Cc: Rasmus Villemoes 
Cc: Yinghai Lu 
Cc: alno...@suse.com
Cc: j...@8bytes.org
Link: http://lkml.kernel.org/r/20150204132754.ga10...@suse.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 37907756fc41..1d6e2946a3da 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -302,6 +302,9 @@ int check_irq_vectors_for_cpu_disable(void)
irq = __this_cpu_read(vector_irq[vector]);
if (irq >= 0) {
desc = irq_to_desc(irq);
+   if (!desc)
+   continue;
+
data = irq_desc_get_irq_data(desc);
cpumask_copy(_new, data->affinity);
cpu_clear(this_cpu, affinity_new);
-- 
2.17.1





[PATCH 3.18 076/144] perf tools: Avoid build splat for syscall numbers with uclibc

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ea1fe3a88763d4dfef7e2529ba606f96e8e6b271 ]

This is due to duplicated unistd inclusion (via uClibc headers + kernel headers)
Also seen on ARM uClibc based tools

   --- ARC build -->8-

  CC   util/evlist.o
In file included from
~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0,
 from util/../perf-sys.h:10,
 from util/../perf.h:15,
 from util/event.h:7,
 from util/event.c:3:
~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0:
warning: "__NR_fcntl64" redefined [enabled by default]
 #define __NR_fcntl64 __NR3264_fcntl
 ^
In file included from
~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0,
 from util/../perf-sys.h:6,
   ->8---

   --- ARM build -->8-

  CC FPIC  plugin_scsi.o
In file included from util/../perf-sys.h:9:0,
 from util/../perf.h:15,
 from util/cache.h:7,
 from perf.c:12:
~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0:
warning: "__NR_restart_syscall" redefined [enabled by default]
In file included from
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0,
 from util/../perf-sys.h:6,
 from util/../perf.h:15,
 from util/cache.h:7,
 from perf.c:12:
~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0:
note: this is the location of the previous definition
   ->8---

Signed-off-by: Vineet Gupta 
Cc: Alexey Brodkin 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgu...@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/bench/sched-pipe.c | 2 +-
 tools/perf/builtin-top.c  | 1 -
 tools/perf/perf-sys.h | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 07a8d7646a15..005cc283790c 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -19,12 +19,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 8e37334db4fa..c5b9c3f01d85 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -66,7 +66,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 static volatile int done;
diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h
index a3b13d7dc1d4..6ef68165c9db 100644
--- a/tools/perf/perf-sys.h
+++ b/tools/perf/perf-sys.h
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #if defined(__i386__)
 #define mb()   asm volatile("lock; addl $0,0(%%esp)" ::: "memory")
-- 
2.17.1





[PATCH 3.18 099/144] dm9000: Fix irq trigger type setup on non-dt platforms

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit a96d3b7593a3eefab62dd930e5c99201c3678ee4 ]

Commit b5a099c67a1c36b "net: ethernet: davicom: fix devicetree irq
resource" causes an interrupt storm after the ethernet interface
is activated on S3C24XX platform (ARM non-dt), due to the interrupt
trigger type not being set properly.

It seems, after adding parsing of IRQ flags in commit 7085a7401ba54e92b
"drivers: platform: parse IRQ flags from resources", there is no path
for non-dt platforms where irq_set_type callback could be invoked when
we don't pass the trigger type flags to the request_irq() call.

In case of a board where the regression is seen the interrupt trigger
type flags are passed through a platform device's resource and it is
not currently handled properly without passing the irq trigger type
flags to the request_irq() call.  In case of OF an of_irq_get() call
within platform_get_irq() function seems to be ensuring required irq_chip
setup, but there is no equivalent code for non OF/ACPI platforms.

This patch mostly restores irq trigger type setting code which has been
removed in commit ("net: ethernet: davicom: fix devicetree irq resource").

Fixes: b5a099c67a1c36b913 ("net: ethernet: davicom: fix devicetree irq 
resource")

Signed-off-by: Sylwester Nawrocki 
Acked-by: Robert Jarzmik 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/davicom/dm9000.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/davicom/dm9000.c 
b/drivers/net/ethernet/davicom/dm9000.c
index ef24b60b4d3f..d2e0a10a8511 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1296,6 +1296,7 @@ static int
 dm9000_open(struct net_device *dev)
 {
struct board_info *db = netdev_priv(dev);
+   unsigned int irq_flags = irq_get_trigger_type(dev->irq);
 
if (netif_msg_ifup(db))
dev_dbg(db->dev, "enabling %s\n", dev->name);
@@ -1303,9 +1304,11 @@ dm9000_open(struct net_device *dev)
/* If there is no IRQ type specified, tell the user that this is a
 * problem
 */
-   if (irq_get_trigger_type(dev->irq) == IRQF_TRIGGER_NONE)
+   if (irq_flags == IRQF_TRIGGER_NONE)
dev_warn(db->dev, "WARNING: no IRQ resource flags set.\n");
 
+   irq_flags |= IRQF_SHARED;
+
/* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
mdelay(1); /* delay needs by DM9000B */
@@ -1313,8 +1316,7 @@ dm9000_open(struct net_device *dev)
/* Initialize DM9000 board */
dm9000_init_dm9000(dev);
 
-   if (request_irq(dev->irq, dm9000_interrupt, IRQF_SHARED,
-   dev->name, dev))
+   if (request_irq(dev->irq, dm9000_interrupt, irq_flags, dev->name, dev))
return -EAGAIN;
/* Now that we have an interrupt handler hooked up we can unmask
 * our interrupts
-- 
2.17.1





[PATCH 3.18 024/144] xfrm: validate template mode

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 32bf94fb5c2ec4ec842152d0e5937cd4bb6738fa ]

XFRM mode parameters passed as part of the user templates
in the IP_XFRM_POLICY are never properly validated. Passing
values other than valid XFRM modes can cause stack-out-of-bounds
reads to occur later in the XFRM processing:

[  140.535608] 
[  140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
[  140.550306] Read of size 4 at addr ffc0238a7a58 by task repro/5148
[  140.557369]
[  140.558927] Call trace:
[  140.558936] dump_backtrace+0x0/0x388
[  140.558940] show_stack+0x24/0x30
[  140.558946] __dump_stack+0x24/0x2c
[  140.558949] dump_stack+0x8c/0xd0
[  140.558956] print_address_description+0x74/0x234
[  140.558960] kasan_report+0x240/0x264
[  140.558963] __asan_report_load4_noabort+0x2c/0x38
[  140.558967] xfrm_state_find+0x17e4/0x1cc4
[  140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
[  140.558975] xfrm_lookup+0x238/0x1444
[  140.558977] xfrm_lookup_route+0x48/0x11c
[  140.558984] ip_route_output_flow+0x88/0xc4
[  140.558991] raw_sendmsg+0xa74/0x266c
[  140.558996] inet_sendmsg+0x258/0x3b0
[  140.559002] sock_sendmsg+0xbc/0xec
[  140.559005] SyS_sendto+0x3a8/0x5a8
[  140.559008] el0_svc_naked+0x34/0x38
[  140.559009]
[  140.592245] page dumped because: kasan: bad access detected
[  140.597981] page_owner info is not active (free page?)
[  140.603267]
[  140.653503] 

Signed-off-by: Sean Tranchetti 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index ca99638b5d5a..017b1c91d58e 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1381,6 +1381,9 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl 
*ut, u16 family)
(ut[i].family != prev_family))
return -EINVAL;
 
+   if (ut[i].mode >= XFRM_MODE_MAX)
+   return -EINVAL;
+
prev_family = ut[i].family;
 
switch (ut[i].family) {
-- 
2.17.1





[PATCH 3.18 000/144] 3.18.125-stable review

2018-11-08 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.125 release.
There are 144 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Nov 10 21:50:17 UTC 2018.
Anything received after that time might be too late.

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

https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.125-rc1.gz
or in the git tree and branch at:

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

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.18.125-rc1

Phil Auld 
sched/fair: Fix throttle_list starvation with low CFS quota

Alan Stern 
USB: fix the usbfs flag sanitization for control transfers

Tobias Herzog 
cdc-acm: correct counting of UART states in serial state notification

Al Viro 
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)

Jakub Kicinski 
net: sched: gred: pass the right attribute to gred_change_table_def()

Ido Schimmel 
rtnetlink: Disallow FDB configuration for non-Ethernet device

Cong Wang 
net: drop skb on failure in ip_check_defrag()

Marcelo Ricardo Leitner 
sctp: fix race on sctp_id2asoc

Heiner Kallweit 
r8169: fix NAPI handling under high load

Niklas Cassel 
net: stmmac: Fix stmmac_mdio_reset() when building stmmac as modules

Wenwen Wang 
net: socket: fix a missing-check bug

David Ahern 
net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs

Stefano Brivio 
ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are 
called

Eric Dumazet 
ipv6: mcast: fix a use-after-free in inet6_mc_check

Linus Torvalds 
mremap: properly flush TLB before releasing the page

Linus Torvalds 
/proc/iomem: only expose physical resource addresses to privileged users

Rasmus Villemoes 
perf tools: Disable parallelism for 'make clean'

Khazhismel Kumykov 
fs/fat/fatent.c: add cond_resched() to fat_count_free_clusters()

Hannes Frederic Sowa 
unix: correctly track in-flight fds in sending process user_struct

Prarit Bhargava 
x86/PCI: Mark Broadwell-EP Home Agent 1 as having non-compliant BARs

Hannes Frederic Sowa 
net: fix warnings in 'make htmldocs' by moving macro definition out of 
field declaration

Alan Stern 
USB: hub: fix up early-exit pathway in hub_activate

Eric Biggers 
KEYS: put keyring if install_session_keyring_to_cred() fails

Jan Beulich 
igb: fix NULL derefs due to skipped SR-IOV enabling

Miklos Szeredi 
ovl: fix open in stacked overlay

Arik Nemtsov 
iwlwifi: pcie: correctly define 7265-D cfg

Xin Long 
sctp: translate network order to host order when users get a hmacid

Jan Kara 
vfs: Make sendfile(2) killable even better

Alex Williamson 
PCI: Fix devfn for VPD access through function 0

Jan Beulich 
x86/ldt: Fix small LDT allocation for Xen

Ken Xue 
Revert "SCSI: Fix NULL pointer dereference in runtime PM"

Naoya Horiguchi 
mm: migrate: hugetlb: putback destination hugepage to active list

Peter Zijlstra 
perf: Fix PERF_EVENT_IOC_PERIOD deadlock

Sudip Mukherjee 
libata: blacklist Micron 500IT SSD with MU01 firmware

Shota Suzuki 
igb: Unpair the queues when changing the number of queues

Filipe Manana 
Btrfs: do not ignore errors from btrfs_lookup_xattr in do_setxattr

Peter Hurley 
tty: audit: Fix audit source

Anssi Hannula 
ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly

Mateusz Sylwestrzak 
ALSA: hda - Add headset mic support for Acer Aspire V5-573G

Larry Finger 
rtlwifi: rtl8821ae: Fix lockups on boot

Larry Finger 
rtlwifi: rtl8821ae: Fix system lockups on boot

Chris Mi 
selftests: Introduce a new script to generate tc batch file

Brian Norris 
mtd: blkdevs: fix potential deadlock + lockdep warnings

Lars-Peter Clausen 
ASoC: dapm: Don't add prefix to widget stream name

Daniel Borkmann 
lib: make memzero_explicit more robust against dead store elimination

Sylwester Nawrocki 
dm9000: Fix irq trigger type setup on non-dt platforms

Ezequiel Garcia 
MIPS: Fix up obsolete cpu_set usage

Srikar Dronamraju 
perf bench numa: Fix to show proper convergence stats

Robert Jarzmik 
net: ethernet: davicom: fix devicetree irq resource

Theodore Ts'o 
ext4: fix an ext3 collapse range regression in xfstests

Jisheng Zhang 
x86/idle: Restore trace_cpu_idle to mwait_idle() calls

Stefan Agner 
tty: serial: fsl_lpuart: fix clearing of receive flag

Alex Williamson 
iommu/vt-d: Fix VM domain ID leak

Eugenia Emantayev 
net/mlx4_en: Remove dependency between timestamping capability and 
service_task

Marc Zyngier 
arm/arm64: KVM: Take mmap_sem in stage2_unmap_vm

Junichi Nomura 
dm: fix AB-BA 

[PATCH 3.18 023/144] ARM: 8799/1: mm: fix pci_ioremap_io() offset check

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 3a58ac65e2d7969bcdf1b6acb70fa4d12a88e53e ]

IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e
something like 0xf (and not 0x10).

Therefore, when offset = 0xf is passed as argument, this function
fails even though the offset + SZ_64K fits below the
IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space
not usable as it cannot be mapped.

This patch fixes that by substracing 1 to offset + SZ_64K, so that we
compare the addrss of the last byte of the I/O space against
IO_SPACE_LIMIT instead of the address of the first byte of what is
after the I/O space.

Fixes: c2794437091a4 ("ARM: Add fixed PCI i/o mapping")
Signed-off-by: Thomas Petazzoni 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
---
 arch/arm/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index d1e5ad7ab3bc..1500d3befe02 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -447,7 +447,7 @@ void pci_ioremap_set_mem_type(int mem_type)
 
 int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
 {
-   BUG_ON(offset + SZ_64K > IO_SPACE_LIMIT);
+   BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
 
return ioremap_page_range(PCI_IO_VIRT_BASE + offset,
  PCI_IO_VIRT_BASE + offset + SZ_64K,
-- 
2.17.1





[PATCH 3.18 012/144] team: Forbid enslaving team device to itself

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Ido Schimmel 

[ Upstream commit 471b83bd8bbe4e89743683ef8ecb78f7029d8288 ]

team's ndo_add_slave() acquires 'team->lock' and later tries to open the
newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
that causes the VLAN driver to add VLAN 0 on the team device. team's
ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
deadlock.

Fix this by checking early at the enslavement function that a team
device is not being enslaved to itself.

A similar check was added to the bond driver in commit 09a89c219baf
("bonding: disallow enslaving a bond to itself").

WARNING: possible recursive locking detected
4.18.0-rc7+ #176 Not tainted

syz-executor4/6391 is trying to acquire lock:
(ptrval) (>lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 
drivers/net/team/team.c:1868

but task is already holding lock:
(ptrval) (>lock){+.+.}, at: team_add_slave+0xdb/0x1c30 
drivers/net/team/team.c:1947

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(>lock);
  lock(>lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by syz-executor4/6391:
 #0: (ptrval) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 
[inline]
 #0: (ptrval) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 
net/core/rtnetlink.c:4662
 #1: (ptrval) (>lock){+.+.}, at: team_add_slave+0xdb/0x1c30 
drivers/net/team/team.c:1947

stack backtrace:
CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
 check_deadlock kernel/locking/lockdep.c:1809 [inline]
 validate_chain kernel/locking/lockdep.c:2405 [inline]
 __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
 lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
 __mutex_lock_common kernel/locking/mutex.c:757 [inline]
 __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
 team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
 vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210
 __vlan_vid_add net/8021q/vlan_core.c:278 [inline]
 vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308
 vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381
 notifier_call_chain+0x180/0x390 kernel/notifier.c:93
 __raw_notifier_call_chain kernel/notifier.c:394 [inline]
 raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
 call_netdevice_notifiers net/core/dev.c:1753 [inline]
 dev_open+0x173/0x1b0 net/core/dev.c:1433
 team_port_add drivers/net/team/team.c:1219 [inline]
 team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948
 do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248
 do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382
 rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636
 rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455
 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
 netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
 netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908
 sock_sendmsg_nosec net/socket.c:642 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:652
 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
 __sys_sendmsg+0x11d/0x290 net/socket.c:2164
 __do_sys_sendmsg net/socket.c:2173 [inline]
 __se_sys_sendmsg net/socket.c:2171 [inline]
 __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456b29
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f9706bf8c78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 7f9706bf96d4 RCX: 00456b29
RDX:  RSI: 2240 RDI: 0004
RBP: 009300a0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 004d3548 R14: 004c8227 R15: 

Fixes: 87002b03baab ("net: introduce vlan_vid_[add/del] and use them instead of 
direct [add/kill]_vid ndo calls")
Signed-off-by: Ido Schimmel 
Reported-and-tested-by: syzbot+bd051aba086537515...@syzkaller.appspotmail.com
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/team/team.c |5 +
 1 file changed, 5 insertions(+)

--- 

[PATCH 3.18 007/144] ip_tunnel: be careful when accessing the inner header

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Paolo Abeni 

[ Upstream commit ccfec9e5cb2d48df5a955b7bf47f7782157d3bc2]

Cong noted that we need the same checks introduced by commit 76c0ddd8c3a6
("ip6_tunnel: be careful when accessing the inner header")
even for ipv4 tunnels.

Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Suggested-by: Cong Wang 
Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv4/ip_tunnel.c |9 +
 1 file changed, 9 insertions(+)

--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -641,6 +641,7 @@ void ip_tunnel_xmit(struct sk_buff *skb,
const struct iphdr *tnl_params, u8 protocol)
 {
struct ip_tunnel *tunnel = netdev_priv(dev);
+   unsigned int inner_nhdr_len = 0;
const struct iphdr *inner_iph;
struct flowi4 fl4;
u8 tos, ttl;
@@ -651,6 +652,14 @@ void ip_tunnel_xmit(struct sk_buff *skb,
int err;
bool connected;
 
+   /* ensure we can access the inner net header, for several users below */
+   if (skb->protocol == htons(ETH_P_IP))
+   inner_nhdr_len = sizeof(struct iphdr);
+   else if (skb->protocol == htons(ETH_P_IPV6))
+   inner_nhdr_len = sizeof(struct ipv6hdr);
+   if (unlikely(!pskb_may_pull(skb, inner_nhdr_len)))
+   goto tx_error;
+
inner_iph = (const struct iphdr *)skb_inner_network_header(skb);
connected = (tunnel->parms.iph.daddr != 0);
 




[PATCH 3.18 004/144] mach64: detect the dot clock divider correctly on sparc

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Mikulas Patocka 

commit 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 upstream.

On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display quality is very low).

The reason is this: Older mach64 cards set the divider in the register
VCLK_POST_DIV. The register has four 2-bit fields (the field that is
actually used is specified in the lowest two bits of the register
CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
there's another bit added - the top four bits of PLL_EXT_CNTL extend the
divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
them, so it can work regardless if the card supports them. However, the
sparc64 firmware may set these extended dividers during boot - and the
mach64 driver detects incorrect dot clock in this case.

This patch makes the driver read the additional divider bit from
PLL_EXT_CNTL and calculate the initial refresh rate properly.

Signed-off-by: Mikulas Patocka 
Cc: sta...@vger.kernel.org
Acked-by: David S. Miller 
Reviewed-by: Ville Syrjälä 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/video/fbdev/aty/atyfb.h  |3 ++-
 drivers/video/fbdev/aty/atyfb_base.c |7 ---
 drivers/video/fbdev/aty/mach64_ct.c  |   10 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -335,6 +335,8 @@ extern const struct aty_pll_ops aty_pll_
 extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll 
*pll);
 extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
 
+extern const u8 aty_postdividers[8];
+
 
 /*
  *  Hardware cursor support
@@ -361,7 +363,6 @@ static inline void wait_for_idle(struct
 
 extern void aty_reset_engine(const struct atyfb_par *par);
 extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
-extern u8   aty_ld_pll_ct(int offset, const struct atyfb_par *par);
 
 void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
 void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3112,17 +3112,18 @@ static int atyfb_setup_sparc(struct pci_
/*
 * PLL Reference Divider M:
 */
-   M = pll_regs[2];
+   M = pll_regs[PLL_REF_DIV];
 
/*
 * PLL Feedback Divider N (Dependent on CLOCK_CNTL):
 */
-   N = pll_regs[7 + (clock_cntl & 3)];
+   N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
 
/*
 * PLL Post Divider P (Dependent on CLOCK_CNTL):
 */
-   P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
+   P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl 
& 3) << 1)) & 3) |
+((pll_regs[PLL_EXT_CNTL] >> (2 + 
(clock_cntl & 3))) & 4)];
 
/*
 * PLL Divider Q:
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -114,7 +114,7 @@ static void aty_st_pll_ct(int offset, u8
  */
 
 #define Maximum_DSP_PRECISION 7
-static u8 postdividers[] = {1,2,4,8,3};
+const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
 
 static int aty_dsp_gt(const struct fb_info *info, u32 bpp, struct pll_ct *pll)
 {
@@ -221,7 +221,7 @@ static int aty_valid_pll_ct(const struct
pll->vclk_post_div += (q <  64*8);
pll->vclk_post_div += (q <  32*8);
}
-   pll->vclk_post_div_real = postdividers[pll->vclk_post_div];
+   pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];
//pll->vclk_post_div <<= 6;
pll->vclk_fb_div = q * pll->vclk_post_div_real / 8;
pllvclk = (100 * 2 * pll->vclk_fb_div) /
@@ -512,7 +512,7 @@ static int aty_init_pll_ct(const struct
u8 mclk_fb_div, pll_ext_cntl;
pll->ct.pll_ref_div = aty_ld_pll_ct(PLL_REF_DIV, par);
pll_ext_cntl = aty_ld_pll_ct(PLL_EXT_CNTL, par);
-   pll->ct.xclk_post_div_real = postdividers[pll_ext_cntl & 0x07];
+   pll->ct.xclk_post_div_real = aty_postdividers[pll_ext_cntl & 
0x07];
mclk_fb_div = aty_ld_pll_ct(MCLK_FB_DIV, par);
if (pll_ext_cntl & PLL_MFB_TIMES_4_2B)
mclk_fb_div <<= 1;
@@ -534,7 +534,7 @@ static int aty_init_pll_ct(const struct
xpost_div += (q <  64*8);

[PATCH 3.18 003/144] stmmac: fix valid numbers of unicast filter entries

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Jongsung Kim 

[ Upstream commit edf2ef7242805e53ec2e0841db26e06d8bc7da70 ]

Synopsys DWC Ethernet MAC can be configured to have 1..32, 64, or
128 unicast filter entries. (Table 7-8 MAC Address Registers from
databook) Fix dwmac1000_validate_ucast_entries() to accept values
between 1 and 32 in addition.

Signed-off-by: Jongsung Kim 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -85,7 +85,7 @@ static int dwmac1000_validate_mcast_bins
 
 /* This function validates the number of Unicast address entries supported
  * by a particular Synopsys 10/100/1000 controller. The Synopsys controller
- * supports 1, 32, 64, or 128 Unicast filter entries for it's Unicast filter
+ * supports 1..32, 64, or 128 Unicast filter entries for it's Unicast filter
  * logic. This function validates a valid, supported configuration is
  * selected, and defaults to 1 Unicast address if an unsupported
  * configuration is selected.
@@ -95,8 +95,7 @@ static int dwmac1000_validate_ucast_entr
int x = ucast_entries;
 
switch (x) {
-   case 1:
-   case 32:
+   case 1 ... 32:
case 64:
case 128:
break;




RE: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller

2018-11-08 Thread Leo Li



> -Original Message-
> From: Z.q. Hou
> Sent: Tuesday, November 6, 2018 7:21 AM
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao ; Z.q. Hou
> 
> Subject: [PATCH 21/23] dt-bindings: pci: Add NXP LX SoCs PCIe controller
> 
> From: Hou Zhiqiang 
> 
> Add PCIe controller DT bindings of NXP LX series SoCs.

I'm not sure if this is a good idea to name this controller LX PCIe controller. 
 Right now, it could be true that it is only used on LX series SoCs.  But I'm 
not sure if the LS series will not use this controller or LX series will only 
use this controller in the future.

Since the LX series is still using the layerscape branding, so probably we 
should keep using the layerscape-pci.txt and define the PCIe Gen4 variant?

Same comment for other places using the LX naming in this driver.

> 
> Signed-off-by: Hou Zhiqiang 
> ---
>  .../devicetree/bindings/pci/lx-pci.txt| 52 +++
>  MAINTAINERS   |  8 +++
>  2 files changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/lx-pci.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/lx-pci.txt
> b/Documentation/devicetree/bindings/pci/lx-pci.txt
> new file mode 100644
> index ..dc602fef93b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/lx-pci.txt
> @@ -0,0 +1,52 @@
> +NXP LX PCIe controller
> +
> +This PCIe controller is based on the Mobiveil PCIe IP and thus inherits
> +all the common properties defined in mobiveil-pcie.txt.
> +
> +Required properties:
> +- compatible: should contain the platform identifier such as:
> +  "fsl,lx2160a-pcie"
> +- reg: base addresses and lengths of the PCIe controller register blocks.
> +  "config_axi_slave": PCIe controller registers
> +  "csr_axi_slave": Bridge config registers
> +- interrupts: A list of interrupt outputs of the controller. Must
> +contain an
> +  entry for each entry in the interrupt-names property.
> +- interrupt-names: It could include the following entries:
> +  "intr": The interrupt that is asserted for controller interrupts
> +  "aer": Asserted for aer interrupt when chip support the aer interrupt with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> aer.
> +  "pme": Asserted for pme interrupt when chip support the pme interrupt
> with
> +  none MSI/MSI-X/INTx mode,but there is interrupt line for
> pme.
> +- dma-coherent: Indicates that the hardware IP block can ensure the
> +coherency
> +  of the data transferred from/to the IP block. This can avoid the
> +software
> +  cache flush/invalid actions, and improve the performance significantly.
> +- msi-parent : See the generic MSI binding described in
> +  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +Example:
> +
> + pcie@340 {
> + compatible = "fsl,lx2160a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010   /* controller
> registers */
> +0x80 0x 0x0 0x1000>; /* configuration
> space */
> + reg-names = "csr_axi_slave", "config_axi_slave";
> + interrupts = , /* AER
> interrupt */
> +  , /* PME
> interrupt */
> +  ; /*
> controller interrupt */
> + interrupt-names = "aer", "pme", "intr";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + apio-wins = <8>;
> + ppio-wins = <8>;
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + msi-parent = <>;
> + ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1  GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2  GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3  GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4  GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0c57ccff3188..7da555c8e2f5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11252,6 +11252,14 @@ L:   linux-arm-ker...@lists.infradead.org
>  S:   Maintained
>  F:   drivers/pci/controller/dwc/*layerscape*
> 
> +PCI DRIVER FOR NXP LX
> +M:   Hou Zhiqiang 
> +L:   linux-...@vger.kernel.org
> +L:   linux-arm-ker...@lists.infradead.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/pci/lx-pci.txt
> +F:   drivers/pci/controller/mobibeil/pci-lx.c
> +
>  PCI DRIVER FOR GENERIC OF HOSTS
>  M:   Will Deacon 
>  L:   

Re: [PATCH 00/12] Series short description

2018-11-08 Thread J. Bruce Fields
On Mon, Nov 05, 2018 at 12:30:47PM +1100, NeilBrown wrote:
> Here is the respin on this series with the file_lock properly
> initlized for unlock requests.
> I found one that I had missed before - in locks_remove_flock()
> The change makes this code smaller!
> 
> Original series description:
> 
> If you have a many-core machine, and have many threads all wanting to
> briefly lock a give file (udev is known to do this), you can get quite
> poor performance.
> 
> When one thread releases a lock, it wakes up all other threads that
> are waiting (classic thundering-herd) - one will get the lock and the
> others go to sleep.
> When you have few cores, this is not very noticeable: by the time the
> 4th or 5th thread gets enough CPU time to try to claim the lock, the
> earlier threads have claimed it, done what was needed, and released.
> With 50+ cores, the contention can easily be measured.
> 
> This patchset creates a tree of pending lock request in which siblings
> don't conflict and each lock request does conflict with its parent.
> When a lock is released, only requests which don't conflict with each
> other a woken.
> 
> Testing shows that lock-acquisitions-per-second is now fairly stable even
> as number of contending process goes to 1000.  Without this patch,
> locks-per-second drops off steeply after a few 10s of processes.
> 
> There is a small cost to this extra complexity.
> At 20 processes running a particular test on 72 cores, the lock
> acquisitions per second drops from 1.8 million to 1.4 million with
> this patch.  For 100 processes, this patch still provides 1.4 million
> while without this patch there are about 700,000.

These details are all really useful motivation for the patches.  It'd be
nice to have them in the permanent record somehow.  Maybe just merge it
into the changelog on "fs/locks: create a tree of dependent requests."?

--b.

> 
> NeilBrown
> 
> 
> ---
> 
> NeilBrown (12):
>   fs/locks: rename some lists and pointers.
>   fs/locks: split out __locks_wake_up_blocks().
>   NFS: use locks_copy_lock() to copy locks.
>   gfs2: properly initial file_lock used for unlock.
>   ocfs2: properly initial file_lock used for unlock.
>   locks: use properly initialized file_lock when unlocking.
>   fs/locks: allow a lock request to block other requests.
>   fs/locks: always delete_block after waiting.
>   fs/locks: change all *_conflict() functions to return bool.
>   fs/locks: create a tree of dependent requests.
>   locks: merge posix_unblock_lock() and locks_delete_block()
>   VFS: locks: remove unnecessary white space.
> 
> 
>  fs/cifs/file.c  |4 -
>  fs/gfs2/file.c  |   10 +-
>  fs/lockd/svclock.c  |2 
>  fs/locks.c  |  253 
> +--
>  fs/nfs/nfs4proc.c   |6 +
>  fs/nfsd/nfs4state.c |6 -
>  fs/ocfs2/locks.c|   10 +-
>  include/linux/fs.h  |   11 +-
>  include/trace/events/filelock.h |   16 +-
>  9 files changed, 173 insertions(+), 145 deletions(-)
> 
> --
> Signature


[PATCH 3.18 123/144] USB: hub: fix up early-exit pathway in hub_activate

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ca5cbc8b02f9b21cc8cd1ab36668763ec34f9ee8 ]

The early-exit pathway in hub_activate, added by commit e50293ef9775
("USB: fix invalid memory access in hub_activate()") needs
improvement.  It duplicates code that is already present at the end of
the subroutine, and it neglects to undo the effect of a
usb_autopm_get_interface_no_resume() call.

This patch fixes both problems by making the early-exit pathway jump
directly to the end of the subroutine.  It simplifies the code at the
end by merging two conditionals that actually test the same condition
although they appear different: If type < HUB_INIT3 then type must be
either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that
case the subroutine would have exited earlier.

Signed-off-by: Alan Stern 
CC:  #4.4+
Reviewed-by: Viresh Kumar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/core/hub.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 164fdeddfc05..9a47a9c8ebb4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1000,11 +1000,8 @@ static void hub_activate(struct usb_hub *hub, enum 
hub_activation_type type)
device_lock(hub->intfdev);
 
/* Was the hub disconnected while we were waiting? */
-   if (hub->disconnected) {
-   device_unlock(hub->intfdev);
-   kref_put(>kref, hub_release);
-   return;
-   }
+   if (hub->disconnected)
+   goto disconnected;
if (type == HUB_INIT2)
goto init2;
goto init3;
@@ -1230,12 +1227,12 @@ static void hub_activate(struct usb_hub *hub, enum 
hub_activation_type type)
/* Scan all ports that need attention */
kick_hub_wq(hub);
 
-   /* Allow autosuspend if it was suppressed */
-   if (type <= HUB_INIT3)
+   if (type == HUB_INIT2 || type == HUB_INIT3) {
+   /* Allow autosuspend if it was suppressed */
+ disconnected:
usb_autopm_put_interface_async(to_usb_interface(hub->intfdev));
-
-   if (type == HUB_INIT2 || type == HUB_INIT3)
device_unlock(hub->intfdev);
+   }
 
kref_put(>kref, hub_release);
 }
-- 
2.17.1





[PATCH 4.4 023/114] tracing: Skip more functions when doing stack tracing of events

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit be54f69c26193de31053190761e521903b89d098 ]

 # echo 1 > options/stacktrace
 # echo 1 > events/sched/sched_switch/enable
 # cat trace
  -0 [002] d..2  1982.525169: 
 => save_stack_trace
 => __ftrace_trace_stack
 => trace_buffer_unlock_commit_regs
 => event_trigger_unlock_commit
 => trace_event_buffer_commit
 => trace_event_raw_event_sched_switch
 => __schedule
 => schedule
 => schedule_preempt_disabled
 => cpu_startup_entry
 => start_secondary

The above shows that we are seeing 6 functions before ever making it to the
caller of the sched_switch event.

 # echo stacktrace > events/sched/sched_switch/trigger
 # cat trace
  -0 [002] d..3  2146.335208: 
 => trace_event_buffer_commit
 => trace_event_raw_event_sched_switch
 => __schedule
 => schedule
 => schedule_preempt_disabled
 => cpu_startup_entry
 => start_secondary

The stacktrace trigger isn't as bad, because it adds its own skip to the
stacktracing, but still has two events extra.

One issue is that if the stacktrace passes its own "regs" then there should
be no addition to the skip, as the regs will not include the functions being
called. This was an issue that was fixed by commit 7717c6be6999 ("tracing:
Fix stacktrace skip depth in trace_buffer_unlock_commit_regs()" as adding
the skip number for kprobes made the probes not have any stack at all.

But since this is only an issue when regs is being used, a skip should be
added if regs is NULL. Now we have:

 # echo 1 > options/stacktrace
 # echo 1 > events/sched/sched_switch/enable
 # cat trace
  -0 [000] d..2  1297.676333: 
 => __schedule
 => schedule
 => schedule_preempt_disabled
 => cpu_startup_entry
 => rest_init
 => start_kernel
 => x86_64_start_reservations
 => x86_64_start_kernel

 # echo stacktrace > events/sched/sched_switch/trigger
 # cat trace
  -0 [002] d..3  1370.759745: 
 => __schedule
 => schedule
 => schedule_preempt_disabled
 => cpu_startup_entry
 => start_secondary

And kprobes are not touched.

Reported-by: Peter Zijlstra 
Signed-off-by: Steven Rostedt 
Signed-off-by: Sasha Levin 
---
 kernel/trace/trace.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e409ddce8754..1a47a64d623f 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1757,7 +1757,17 @@ void trace_buffer_unlock_commit_regs(struct trace_array 
*tr,
 {
__buffer_unlock_commit(buffer, event);
 
-   ftrace_trace_stack(tr, buffer, flags, 0, pc, regs);
+   /*
+* If regs is not set, then skip the following callers:
+*   trace_buffer_unlock_commit_regs
+*   event_trigger_unlock_commit
+*   trace_event_buffer_commit
+*   trace_event_raw_event_sched_switch
+* Note, we can still get here via blktrace, wakeup tracer
+* and mmiotrace, but that's ok if they lose a function or
+* two. They are that meaningful.
+*/
+   ftrace_trace_stack(tr, buffer, flags, regs ? 0 : 4, pc, regs);
ftrace_trace_userstack(buffer, flags, pc);
 }
 EXPORT_SYMBOL_GPL(trace_buffer_unlock_commit_regs);
@@ -1815,6 +1825,13 @@ static void __ftrace_trace_stack(struct ring_buffer 
*buffer,
trace.nr_entries= 0;
trace.skip  = skip;
 
+   /*
+* Add two, for this function and the call to save_stack_trace()
+* If regs is set, then these functions will not be in the way.
+*/
+   if (!regs)
+   trace.skip += 2;
+
/*
 * Since events can happen in NMIs there's no safe way to
 * use the per cpu ftrace_stacks. We reserve it and if an interrupt
-- 
2.17.1





[PATCH 4.4 026/114] btrfs: cleaner_kthread() doesnt need explicit freeze

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 838fe1887765f4cc679febea60d87d2a06bd300e ]

cleaner_kthread() is not marked freezable, and therefore calling
try_to_freeze() in its context is a pointless no-op.

In addition to that, as has been clearly demonstrated by 80ad623edd2d
("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly
valid / legal for cleaner_kthread() to stay scheduled out in an arbitrary
place during suspend (in that particular example that was waiting for
reading of extent pages), so there is no need to leave any traces of
freezer in this kthread.

Fixes: 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()")
Fixes: 696249132158 ("btrfs: clear PF_NOFREEZE in cleaner_kthread()")
Signed-off-by: Jiri Kosina 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/disk-io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index ae6e3a30e61e..a2001abbe379 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1820,7 +1820,7 @@ static int cleaner_kthread(void *arg)
 */
btrfs_delete_unused_bgs(root->fs_info);
 sleep:
-   if (!try_to_freeze() && !again) {
+   if (!again) {
set_current_state(TASK_INTERRUPTIBLE);
if (!kthread_should_stop())
schedule();
-- 
2.17.1





[PATCH 4.4 025/114] x86/mm/pat: Prevent hang during boot when mapping pages

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e535ec0899d1fe52ec3a84c9bc03457ac67ad6f7 ]

There's a mixture of signed 32-bit and unsigned 32-bit and 64-bit data
types used for keeping track of how many pages have been mapped.

This leads to hangs during boot when mapping large numbers of pages
(multiple terabytes, as reported by Waiman) because those values are
interpreted as being negative.

commit 742563777e8d ("x86/mm/pat: Avoid truncation when converting
cpa->numpages to address") fixed one of those bugs, but there is
another lurking in __change_page_attr_set_clr().

Additionally, the return value type for the populate_*() functions can
return negative values when a large number of pages have been mapped,
triggering the error paths even though no error occurred.

Consistently use 64-bit types on 64-bit platforms when counting pages.
Even in the signed case this gives us room for regions 8PiB
(pebibytes) in size whilst still allowing the usual negative value
error checking idiom.

Reported-by: Waiman Long 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
CC: Theodore Ts'o 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Scott J Norton 
Cc: Douglas Hatch 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin 
---
 arch/x86/mm/pageattr.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 0e1dd7d47f05..26598e08666c 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -955,11 +955,11 @@ static void populate_pte(struct cpa_data *cpa,
}
 }
 
-static int populate_pmd(struct cpa_data *cpa,
-   unsigned long start, unsigned long end,
-   unsigned num_pages, pud_t *pud, pgprot_t pgprot)
+static long populate_pmd(struct cpa_data *cpa,
+unsigned long start, unsigned long end,
+unsigned num_pages, pud_t *pud, pgprot_t pgprot)
 {
-   unsigned int cur_pages = 0;
+   long cur_pages = 0;
pmd_t *pmd;
pgprot_t pmd_pgprot;
 
@@ -1029,12 +1029,12 @@ static int populate_pmd(struct cpa_data *cpa,
return num_pages;
 }
 
-static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
-   pgprot_t pgprot)
+static long populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
+pgprot_t pgprot)
 {
pud_t *pud;
unsigned long end;
-   int cur_pages = 0;
+   long cur_pages = 0;
pgprot_t pud_pgprot;
 
end = start + (cpa->numpages << PAGE_SHIFT);
@@ -1090,7 +1090,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned 
long start, pgd_t *pgd,
 
/* Map trailing leftover */
if (start < end) {
-   int tmp;
+   long tmp;
 
pud = pud_offset(pgd, start);
if (pud_none(*pud))
@@ -1116,7 +1116,7 @@ static int populate_pgd(struct cpa_data *cpa, unsigned 
long addr)
pgprot_t pgprot = __pgprot(_KERNPG_TABLE);
pud_t *pud = NULL;  /* shut up gcc */
pgd_t *pgd_entry;
-   int ret;
+   long ret;
 
pgd_entry = cpa->pgd + pgd_index(addr);
 
@@ -1351,7 +1351,8 @@ static int cpa_process_alias(struct cpa_data *cpa)
 
 static int __change_page_attr_set_clr(struct cpa_data *cpa, int checkalias)
 {
-   int ret, numpages = cpa->numpages;
+   unsigned long numpages = cpa->numpages;
+   int ret;
 
while (numpages) {
/*
-- 
2.17.1





[PATCH 4.4 008/114] Bluetooth: SMP: fix crash in unpairing

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit cb28c306b93b71f2741ce1a5a66289db26715f4d ]

In case unpair_device() was called through mgmt interface at the same time
when pairing was in progress, Bluetooth kernel module crash was seen.

[  600.351225] general protection fault:  [#1] SMP PTI
[  600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G   OE 
4.19.0-rc1+ #1
[  600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 
05/14/2017
[  600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[  600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 
ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 
48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[  600.351279] RSP: 0018:a9be839b3b50 EFLAGS: 00010246
[  600.351282] RAX: 9c999ac565a0 RBX: 9c9996e98c00 RCX: 9c999aa28b60
[  600.351285] RDX: dead0200 RSI: 0010 RDI: 9c999e403500
[  600.351287] RBP: a9be839b3b70 R08:  R09: 92a25c00
[  600.351290] R10: a9be839b3ae8 R11: 0001 R12: 9c995375b800
[  600.351292] R13:  R14: 9c99619a5000 R15: 9c9962a01c00
[  600.351295] FS:  7fb2be27c700() GS:9c999e88() 
knlGS:
[  600.351298] CS:  0010 DS:  ES:  CR0: 80050033
[  600.351300] CR2: 7fb2bdadbad0 CR3: 00041c328001 CR4: 001606e0
[  600.351302] Call Trace:
[  600.351325]  smp_failure+0x4f/0x70 [bluetooth]
[  600.351345]  smp_cancel_pairing+0x74/0x80 [bluetooth]
[  600.351370]  unpair_device+0x1c1/0x330 [bluetooth]
[  600.351399]  hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
[  600.351409]  ? apparmor_socket_sendmsg+0x1e/0x20
[  600.351417]  sock_sendmsg+0x3e/0x50
[  600.351422]  sock_write_iter+0x85/0xf0
[  600.351429]  do_iter_readv_writev+0x12b/0x1b0
[  600.351434]  do_iter_write+0x87/0x1a0
[  600.351439]  vfs_writev+0x98/0x110
[  600.351443]  ? ep_poll+0x16d/0x3d0
[  600.351447]  ? ep_modify+0x73/0x170
[  600.351451]  do_writev+0x61/0xf0
[  600.351455]  ? do_writev+0x61/0xf0
[  600.351460]  __x64_sys_writev+0x1c/0x20
[  600.351465]  do_syscall_64+0x5a/0x110
[  600.351471]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  600.351474] RIP: 0033:0x7fb2bdb62fe0
[  600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
[  600.351479] RSP: 002b:7ffe062cb8f8 EFLAGS: 0246 ORIG_RAX: 
0014
[  600.351484] RAX: ffda RBX: 0255b3d0 RCX: 7fb2bdb62fe0
[  600.351487] RDX: 0001 RSI: 7ffe062cb920 RDI: 0004
[  600.351490] RBP: 7ffe062cb920 R08: 0255bd80 R09: 
[  600.351494] R10: 0353 R11: 0246 R12: 0001
[  600.351497] R13: 7ffe062cbbe0 R14:  R15: 
[  600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac 
ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat 
nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp 
llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon 
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd 
glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch 
input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
[  600.351569]  snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel 
snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof 
dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi 
snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei 
dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic 
usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm 
irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt 
mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video 
wmi
[  600.351637] ---[ end trace e49e9f1df09c94fb ]---
[  600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[  600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 
ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 
48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[  600.351669] RSP: 0018:a9be839b3b50 EFLAGS: 00010246
[  600.351672] RAX: 9c999ac565a0 RBX: 9c9996e98c00 RCX: 

[PATCH 4.4 006/114] xfrm: validate template mode

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 32bf94fb5c2ec4ec842152d0e5937cd4bb6738fa ]

XFRM mode parameters passed as part of the user templates
in the IP_XFRM_POLICY are never properly validated. Passing
values other than valid XFRM modes can cause stack-out-of-bounds
reads to occur later in the XFRM processing:

[  140.535608] 
[  140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
[  140.550306] Read of size 4 at addr ffc0238a7a58 by task repro/5148
[  140.557369]
[  140.558927] Call trace:
[  140.558936] dump_backtrace+0x0/0x388
[  140.558940] show_stack+0x24/0x30
[  140.558946] __dump_stack+0x24/0x2c
[  140.558949] dump_stack+0x8c/0xd0
[  140.558956] print_address_description+0x74/0x234
[  140.558960] kasan_report+0x240/0x264
[  140.558963] __asan_report_load4_noabort+0x2c/0x38
[  140.558967] xfrm_state_find+0x17e4/0x1cc4
[  140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
[  140.558975] xfrm_lookup+0x238/0x1444
[  140.558977] xfrm_lookup_route+0x48/0x11c
[  140.558984] ip_route_output_flow+0x88/0xc4
[  140.558991] raw_sendmsg+0xa74/0x266c
[  140.558996] inet_sendmsg+0x258/0x3b0
[  140.559002] sock_sendmsg+0xbc/0xec
[  140.559005] SyS_sendto+0x3a8/0x5a8
[  140.559008] el0_svc_naked+0x34/0x38
[  140.559009]
[  140.592245] page dumped because: kasan: bad access detected
[  140.597981] page_owner info is not active (free page?)
[  140.603267]
[  140.653503] 

Signed-off-by: Sean Tranchetti 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index c2e98dcba9fe..476f1fc6d655 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1408,6 +1408,9 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl 
*ut, u16 family)
(ut[i].family != prev_family))
return -EINVAL;
 
+   if (ut[i].mode >= XFRM_MODE_MAX)
+   return -EINVAL;
+
prev_family = ut[i].family;
 
switch (ut[i].family) {
-- 
2.17.1





[PATCH 4.4 005/114] ARM: 8799/1: mm: fix pci_ioremap_io() offset check

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 3a58ac65e2d7969bcdf1b6acb70fa4d12a88e53e ]

IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e
something like 0xf (and not 0x10).

Therefore, when offset = 0xf is passed as argument, this function
fails even though the offset + SZ_64K fits below the
IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space
not usable as it cannot be mapped.

This patch fixes that by substracing 1 to offset + SZ_64K, so that we
compare the addrss of the last byte of the I/O space against
IO_SPACE_LIMIT instead of the address of the first byte of what is
after the I/O space.

Fixes: c2794437091a4 ("ARM: Add fixed PCI i/o mapping")
Signed-off-by: Thomas Petazzoni 
Acked-by: Nicolas Pitre 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
---
 arch/arm/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 0c81056c1dd7..2a3feb73de0b 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -460,7 +460,7 @@ void pci_ioremap_set_mem_type(int mem_type)
 
 int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
 {
-   BUG_ON(offset + SZ_64K > IO_SPACE_LIMIT);
+   BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
 
return ioremap_page_range(PCI_IO_VIRT_BASE + offset,
  PCI_IO_VIRT_BASE + offset + SZ_64K,
-- 
2.17.1





[PATCH 4.4 010/114] asix: Check for supported Wake-on-LAN modes

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit c4ce446e33d7a0e978256ac6fea4c80e59d9de5f ]

The driver currently silently accepts unsupported Wake-on-LAN modes
(other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user,
which is confusing.

Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet 
adapters")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/asix_common.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 7fbd8f044207..2092ef6431f2 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -449,6 +449,9 @@ int asix_set_wol(struct net_device *net, struct 
ethtool_wolinfo *wolinfo)
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
 
+   if (wolinfo->wolopts & ~(WAKE_PHY | WAKE_MAGIC))
+   return -EINVAL;
+
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_LINK;
if (wolinfo->wolopts & WAKE_MAGIC)
-- 
2.17.1





[PATCH 4.4 007/114] mac80211_hwsim: do not omit multicast announce of first added radio

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 28ef8b49a338dc1844e86b7954cfffc7dfa2660a ]

The allocation of hwsim radio identifiers uses a post-increment from 0,
so the first radio has idx 0. This idx is explicitly excluded from
multicast announcements ever since, but it is unclear why.

Drop that idx check and announce the first radio as well. This makes
userspace happy if it relies on these events.

Signed-off-by: Martin Willi 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/mac80211_hwsim.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index c98cb962b454..05413176a5d6 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2547,8 +2547,7 @@ static int mac80211_hwsim_new_radio(struct genl_info 
*info,
list_add_tail(>list, _radios);
spin_unlock_bh(_radio_lock);
 
-   if (idx > 0)
-   hwsim_mcast_new_radio(idx, info, param);
+   hwsim_mcast_new_radio(idx, info, param);
 
return idx;
 
-- 
2.17.1





[PATCH 4.4 003/114] mac80211: Always report TX status

2018-11-08 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8682250b3c1b75a45feb7452bc413d004cfe3778 ]

If a frame is dropped for any reason, mac80211 wouldn't report the TX
status back to user space.

As the user space may rely on the TX_STATUS to kick its state
machines, resends etc, it's better to just report this frame as not
acked instead.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/status.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 45fb1abdb265..2731cf5bf052 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -466,11 +466,6 @@ static void ieee80211_report_ack_skb(struct 
ieee80211_local *local,
if (!skb)
return;
 
-   if (dropped) {
-   dev_kfree_skb_any(skb);
-   return;
-   }
-
if (info->flags & IEEE80211_TX_INTFL_NL80211_FRAME_TX) {
u64 cookie = IEEE80211_SKB_CB(skb)->ack.cookie;
struct ieee80211_sub_if_data *sdata;
@@ -491,6 +486,8 @@ static void ieee80211_report_ack_skb(struct ieee80211_local 
*local,
}
rcu_read_unlock();
 
+   dev_kfree_skb_any(skb);
+   } else if (dropped) {
dev_kfree_skb_any(skb);
} else {
/* consumes skb */
-- 
2.17.1





[PATCH 3.18 129/144] /proc/iomem: only expose physical resource addresses to privileged users

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Linus Torvalds 

commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4 upstream.

In commit c4004b02f8e5b ("x86: remove the kernel code/data/bss resources
from /proc/iomem") I was hoping to remove the phyiscal kernel address
data from /proc/iomem entirely, but that had to be reverted because some
system programs actually use it.

This limits all the detailed resource information to properly
credentialed users instead.

Signed-off-by: Linus Torvalds 
Signed-off-by: Mark Salyzyn 
Signed-off-by: Greg Kroah-Hartman 
---
 kernel/resource.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -104,16 +104,25 @@ static int r_show(struct seq_file *m, vo
 {
struct resource *root = m->private;
struct resource *r = v, *p;
+   unsigned long long start, end;
int width = root->end < 0x1 ? 4 : 8;
int depth;
 
for (depth = 0, p = r; depth < MAX_IORES_LEVEL; depth++, p = p->parent)
if (p->parent == root)
break;
+
+   if (file_ns_capable(m->file, _user_ns, CAP_SYS_ADMIN)) {
+   start = r->start;
+   end = r->end;
+   } else {
+   start = end = 0;
+   }
+
seq_printf(m, "%*s%0*llx-%0*llx : %s\n",
depth * 2, "",
-   width, (unsigned long long) r->start,
-   width, (unsigned long long) r->end,
+   width, start,
+   width, end,
r->name ? r->name : "");
return 0;
 }




[PATCH 3.18 143/144] USB: fix the usbfs flag sanitization for control transfers

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Alan Stern 

commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream.

Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the
transfer flags for URBs submitted from userspace via usbfs.  However,
the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be
allowed for a control transfer was added in the wrong place, before
the code has properly determined the direction of the control
transfer.  (Control transfers are special because for them, the
direction is set by the bRequestType byte of the Setup packet rather
than direction bit of the endpoint address.)

This patch moves code which sets up the allow_short flag for control
transfers down after is_in has been set to the correct value.

Signed-off-by: Alan Stern 
Reported-and-tested-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more")
CC: Oliver Neukum 
CC: 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/core/devio.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1326,8 +1326,6 @@ static int proc_do_submiturb(struct usb_
u = 0;
switch(uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
-   if (is_in)
-   allow_short = true;
if (!usb_endpoint_xfer_control(>desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1357,6 +1355,8 @@ static int proc_do_submiturb(struct usb_
is_in = 0;
uurb->endpoint &= ~USB_DIR_IN;
}
+   if (is_in)
+   allow_short = true;
snoop(>dev->dev, "control urb: bRequestType=%02x "
"bRequest=%02x wValue=%04x "
"wIndex=%04x wLength=%04x\n",




[PATCH 3.18 128/144] perf tools: Disable parallelism for make clean

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit da15fc2fa9c07b23db8f5e479bd8a9f0d741ca07 ]

The Yocto build system does a 'make clean' when rebuilding due to
changed dependencies, and that consistently fails for me (causing the
whole BSP build to fail) with errors such as

| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: find: 
'[...]/perf/1.0-r9/perf-1.0/libtraceevent.a''[...]/perf/1.0-r9/perf-1.0/libtraceevent.a':
 No such file or directory: No such file or directory
|
[...]
| find: cannot delete 
'/mnt/xfs/devel/pil/yocto/tmp-glibc/work/wandboard-oe-linux-gnueabi/perf/1.0-r9/perf-1.0/util/.pstack.o.cmd':
 No such file or directory

Apparently (despite the comment), 'make clean' ends up launching
multiple sub-makes that all want to remove the same things - perhaps
this only happens in combination with a O=... parameter. In any case, we
don't lose much by explicitly disabling the parallelism for the clean
target, and it makes automated builds much more reliable.

Signed-off-by: Rasmus Villemoes 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180705131527.19749-1-li...@rasmusvillemoes.dk
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index cb2e5868c8e8..70b03103102d 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -69,10 +69,10 @@ all tags TAGS:
$(make)
 
 #
-# The clean target is not really parallel, don't print the jobs info:
+# Explicitly disable parallelism for the clean target.
 #
 clean:
-   $(make)
+   $(make) -j1
 
 #
 # The build-test target is not really parallel, don't print the jobs info:
-- 
2.17.1





[PATCH 4.18 25/34] tracing: Fix synthetic event to allow semicolon at end

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Masami Hiramatsu 

commit a360d9e4016c1fcf41553b37ad496870dc5723d0 upstream.

Fix synthetic event to allow independent semicolon at end.

The synthetic_events interface accepts a semicolon after the
last word if there is no space.

 # echo "myevent u64 var;" >> synthetic_events

But if there is a space, it returns an error.

 # echo "myevent u64 var ;" > synthetic_events
 sh: write error: Invalid argument

This behavior is difficult for users to understand. Let's
allow the last independent semicolon too.

Link: 
http://lkml.kernel.org/r/153986835420.18251.2191216690677025744.stgit@devbox

Cc: Shuah Khan 
Cc: Tom Zanussi 
Cc: sta...@vger.kernel.org
Fixes: commit 4b147936fa50 ("tracing: Add support for 'synthetic' events")
Signed-off-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/trace/trace_events_hist.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1097,7 +1097,7 @@ static int create_synth_event(int argc,
i += consumed - 1;
}
 
-   if (i < argc) {
+   if (i < argc && strcmp(argv[i], ";") != 0) {
ret = -EINVAL;
goto err;
}




[PATCH 4.18 00/34] 4.18.18-stable review

2018-11-08 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.18.18 release.
There are 34 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Nov 10 21:51:21 UTC 2018.
Anything received after that time might be too late.

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

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

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

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.18.18-rc1

Sebastian Andrzej Siewior 
x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on 
context switch if there is an FPU

Christoph Hellwig 
x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels

Nathan Chancellor 
x86/time: Correct the attribute on jiffies' definition

Peter Zijlstra 
x86/percpu: Fix this_cpu_read()

Zhimin Gu 
x86, hibernate: Fix nosave_regions setup for hibernation

Peter Zijlstra 
x86/tsc: Force inlining of cyc2ns bits

Phil Auld 
sched/fair: Fix throttle_list starvation with low CFS quota

Boris Brezillon 
drm/sun4i: Fix an ulong overflow in the dotclock driver

Mikhail Nikiforov 
Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM

Masami Hiramatsu 
tracing: Fix synthetic event to allow semicolon at end

Masami Hiramatsu 
tracing: Fix synthetic event to accept unsigned modifier

Ming Lei 
block: don't deal with discard limit in blkdev_issue_discard()

Alan Stern 
USB: fix the usbfs flag sanitization for control transfers

Heikki Krogerus 
usb: xhci: pci: Enable Intel USB role mux on Apollo Lake platforms

Wan Ahmad Zainie 
usb: roles: intel_xhci: Fix Unbalanced pm_runtime_enable

Gustavo A. R. Silva 
usb: gadget: storage: Fix Spectre v1 vulnerability

Shuah Khan (Samsung OSG) 
usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control()

Oliver Neukum 
cdc-acm: fix race between reset and control messaging

Tobias Herzog 
cdc-acm: correct counting of UART states in serial state notification

Tobias Herzog 
cdc-acm: do not reset notification buffer index upon urb unlinking

Gustavo A. R. Silva 
IB/ucm: Fix Spectre v1 vulnerability

Gustavo A. R. Silva 
RDMA/ucma: Fix Spectre v1 vulnerability

Eugeniy Paltsev 
drm: fb-helper: Reject all pixel format changing requests

Clint Taylor 
drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

Kai-Heng Feng 
drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

Gustavo A. R. Silva 
ptp: fix Spectre v1 vulnerability

Eric Sandeen 
fscache: Fix out of bound read in long cookie keys

Al Viro 
cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)

David Howells 
fscache: Fix incomplete initialisation of inline key space

Chen-Yu Tsai 
clk: sunxi-ng: sun4i: Set VCO and PLL bias current to lowest setting

Linus Walleij 
gpio: mxs: Get rid of external API call

Daniel Borkmann 
bpf: fix partial copy of map_ptr when dst is scalar

Amir Goldstein 
vfs: swap names of {do,vfs}_clone_file_range()

Alan Chiang 
eeprom: at24: Add support for address-width property


-

Diffstat:

 Makefile   |  4 +-
 arch/x86/include/asm/fpu/internal.h|  2 +-
 arch/x86/include/asm/percpu.h  |  8 +--
 arch/x86/kernel/pci-swiotlb.c  |  2 -
 arch/x86/kernel/setup.c|  2 +-
 arch/x86/kernel/time.c |  2 +-
 arch/x86/kernel/tsc.c  |  6 +-
 block/blk-lib.c| 28 +---
 drivers/clk/sunxi-ng/ccu-sun4i-a10.c   | 10 ++-
 drivers/gpio/gpio-mxs.c|  4 +-
 drivers/gpu/drm/drm_edid.c |  5 +-
 drivers/gpu/drm/drm_fb_helper.c| 91 --
 drivers/gpu/drm/sun4i/sun4i_dotclock.c | 12 +++-
 drivers/infiniband/core/ucm.c  |  3 +
 drivers/infiniband/core/ucma.c |  3 +
 drivers/input/mouse/elan_i2c_core.c|  1 +
 drivers/misc/eeprom/at24.c | 17 +
 drivers/ptp/ptp_chardev.c  |  4 ++
 drivers/usb/class/cdc-acm.c| 16 ++---
 drivers/usb/core/devio.c   |  4 +-
 drivers/usb/gadget/function/f_mass_storage.c   |  3 +
 drivers/usb/host/xhci-pci.c|  6 +-
 drivers/usb/roles/intel-xhci-usb-role-switch.c |  2 +
 drivers/usb/usbip/vhci_hcd.c   | 57 +++-
 fs/cachefiles/namei.c  |  2 +-
 fs/fscache/cookie.c| 31 +++--
 fs/fscache/internal.h  |  

[PATCH 4.18 31/34] x86/percpu: Fix this_cpu_read()

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Zijlstra 

commit b59167ac7bafd804c91e49ad53c6d33a7394d4c8 upstream.

Eric reported that a sequence count loop using this_cpu_read() got
optimized out. This is wrong, this_cpu_read() must imply READ_ONCE()
because the interface is IRQ-safe, therefore an interrupt can have
changed the per-cpu value.

Fixes: 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section")
Reported-by: Eric Dumazet 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Thomas Gleixner 
Acked-by: Eric Dumazet 
Cc: h...@zytor.com
Cc: eric.duma...@gmail.com
Cc: b...@alien8.de
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181011104019.748208...@infradead.org
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/percpu.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -185,22 +185,22 @@ do {  
\
typeof(var) pfo_ret__;  \
switch (sizeof(var)) {  \
case 1: \
-   asm(op "b "__percpu_arg(1)",%0" \
+   asm volatile(op "b "__percpu_arg(1)",%0"\
: "=q" (pfo_ret__)  \
: "m" (var));   \
break;  \
case 2: \
-   asm(op "w "__percpu_arg(1)",%0" \
+   asm volatile(op "w "__percpu_arg(1)",%0"\
: "=r" (pfo_ret__)  \
: "m" (var));   \
break;  \
case 4: \
-   asm(op "l "__percpu_arg(1)",%0" \
+   asm volatile(op "l "__percpu_arg(1)",%0"\
: "=r" (pfo_ret__)  \
: "m" (var));   \
break;  \
case 8: \
-   asm(op "q "__percpu_arg(1)",%0" \
+   asm volatile(op "q "__percpu_arg(1)",%0"\
: "=r" (pfo_ret__)  \
: "m" (var));   \
break;  \




[PATCH 4.18 09/34] ptp: fix Spectre v1 vulnerability

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Gustavo A. R. Silva 

commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba upstream.

pin_index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
'ops->pin_config' [r] (local cap)

Fix this by sanitizing pin_index before using it to index
ops->pin_config, and before passing it as an argument to
function ptp_set_pinfunc(), in which it is used to index
info->pin_config.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel=152449131114778=2

Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Acked-by: Richard Cochran 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/ptp/ptp_chardev.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 
+#include 
+
 #include "ptp_private.h"
 
 static int ptp_disable_pinfunc(struct ptp_clock_info *ops,
@@ -248,6 +250,7 @@ long ptp_ioctl(struct posix_clock *pc, u
err = -EINVAL;
break;
}
+   pin_index = array_index_nospec(pin_index, ops->n_pins);
if (mutex_lock_interruptible(>pincfg_mux))
return -ERESTARTSYS;
pd = ops->pin_config[pin_index];
@@ -266,6 +269,7 @@ long ptp_ioctl(struct posix_clock *pc, u
err = -EINVAL;
break;
}
+   pin_index = array_index_nospec(pin_index, ops->n_pins);
if (mutex_lock_interruptible(>pincfg_mux))
return -ERESTARTSYS;
err = ptp_set_pinfunc(ptp, pin_index, pd.func, pd.chan);




[PATCH 4.18 26/34] Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Mikhail Nikiforov 

commit 13c1c5e4d7f887cba36c5e3df3faa22071c1469f upstream.

Add ELAN061C to the ACPI table to support Elan touchpad found in Lenovo
IdeaPad 330-15IGM.

Signed-off-by: Mikhail Nikiforov 
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/mouse/elan_i2c_core.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1346,6 +1346,7 @@ static const struct acpi_device_id elan_
{ "ELAN0611", 0 },
{ "ELAN0612", 0 },
{ "ELAN0618", 0 },
+   { "ELAN061C", 0 },
{ "ELAN061D", 0 },
{ "ELAN0622", 0 },
{ "ELAN1000", 0 },




[PATCH 4.18 33/34] x86/swiotlb: Enable swiotlb for > 4GiG RAM on 32-bit kernels

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Christoph Hellwig 

commit 485734f3fc77c1eb77ffe138c027b9a4bf0178f3 upstream.

We already build the swiotlb code for 32-bit kernels with PAE support,
but the code to actually use swiotlb has only been enabled for 64-bit
kernels for an unknown reason.

Before Linux v4.18 we paper over this fact because the networking code,
the SCSI layer and some random block drivers implemented their own
bounce buffering scheme.

[ mingo: Changelog fixes. ]

Fixes: 21e07dba9fb1 ("scsi: reduce use of block bounce buffers")
Fixes: ab74cfebafa3 ("net: remove the PCI_DMA_BUS_IS_PHYS check in 
illegal_highdma")
Reported-by: Matthew Whitehead 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Thomas Gleixner 
Tested-by: Matthew Whitehead 
Cc: konrad.w...@oracle.com
Cc: io...@lists.linux-foundation.org
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181014075208.2715-1-...@lst.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/pci-swiotlb.c |2 --
 1 file changed, 2 deletions(-)

--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -42,10 +42,8 @@ IOMMU_INIT_FINISH(pci_swiotlb_detect_ove
 int __init pci_swiotlb_detect_4gb(void)
 {
/* don't initialize swiotlb if iommu=off (no_iommu=1) */
-#ifdef CONFIG_X86_64
if (!no_iommu && max_possible_pfn > MAX_DMA32_PFN)
swiotlb = 1;
-#endif
 
/*
 * If SME is active then swiotlb will be set to 1 so that bounce




[PATCH 4.18 29/34] x86/tsc: Force inlining of cyc2ns bits

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Peter Zijlstra 

commit 4907c68abd3f60f650f98d5a69d4ec77c0bde44f upstream.

Looking at the asm for native_sched_clock() I noticed we don't inline
enough. Mostly caused by sharing code with cyc2ns_read_begin(), which
we didn't used to do. So mark all that __force_inline to make it DTRT.

Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
Reported-by: Eric Dumazet 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Thomas Gleixner 
Cc: h...@zytor.com
Cc: eric.duma...@gmail.com
Cc: b...@alien8.de
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181011104019.695196...@infradead.org
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/tsc.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -60,7 +60,7 @@ struct cyc2ns {
 
 static DEFINE_PER_CPU_ALIGNED(struct cyc2ns, cyc2ns);
 
-void cyc2ns_read_begin(struct cyc2ns_data *data)
+void __always_inline cyc2ns_read_begin(struct cyc2ns_data *data)
 {
int seq, idx;
 
@@ -77,7 +77,7 @@ void cyc2ns_read_begin(struct cyc2ns_dat
} while (unlikely(seq != this_cpu_read(cyc2ns.seq.sequence)));
 }
 
-void cyc2ns_read_end(void)
+void __always_inline cyc2ns_read_end(void)
 {
preempt_enable_notrace();
 }
@@ -123,7 +123,7 @@ static void __init cyc2ns_init(int cpu)
seqcount_init(>seq);
 }
 
-static inline unsigned long long cycles_2_ns(unsigned long long cyc)
+static __always_inline unsigned long long cycles_2_ns(unsigned long long cyc)
 {
struct cyc2ns_data data;
unsigned long long ns;




[PATCH 4.18 30/34] x86, hibernate: Fix nosave_regions setup for hibernation

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Zhimin Gu 

commit cc55f7537db6af371e9c1c6a71161ee40f918824 upstream.

On 32bit systems, nosave_regions(non RAM areas) located between
max_low_pfn and max_pfn are not excluded from hibernation snapshot
currently, which may result in a machine check exception when
trying to access these unsafe regions during hibernation:

[  612.800453] Disabling lock debugging due to kernel taint
[  612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: 
fe801136
[  612.814344] mce: [Hardware Error]: RIP !INEXACT! 60: 
{swsusp_save+0x436/0x560}
[  612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd00 MISC 
30e086
[  612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 
0 APIC 0 microcode 24
[  612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[  612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt
[  612.853380] Kernel panic - not syncing: Fatal machine check
[  612.858978] Kernel Offset: 0x1800 from 0xc100 (relocation range: 
0xc000-0xf7ffdfff)

This is because on 32bit systems, pages above max_low_pfn are regarded
as high memeory, and accessing unsafe pages might cause expected MCE.
On the problematic 32bit system, there are reserved memory above low
memory, which triggered the MCE:

e820 memory mapping:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xd160cfff] usable
[0.00] BIOS-e820: [mem 0xd160d000-0xd1613fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xd1614000-0xd1a44fff] usable
[0.00] BIOS-e820: [mem 0xd1a45000-0xd1ec] reserved
[0.00] BIOS-e820: [mem 0xd1ed-0xd7eeafff] usable
[0.00] BIOS-e820: [mem 0xd7eeb000-0xd7ff] reserved
[0.00] BIOS-e820: [mem 0xd800-0xd875] usable
[0.00] BIOS-e820: [mem 0xd876-0xd87f] reserved
[0.00] BIOS-e820: [mem 0xd880-0xd8fadfff] usable
[0.00] BIOS-e820: [mem 0xd8fae000-0xd8ff] ACPI data
[0.00] BIOS-e820: [mem 0xd900-0xda71bfff] usable
[0.00] BIOS-e820: [mem 0xda71c000-0xda7f] ACPI NVS
[0.00] BIOS-e820: [mem 0xda80-0xdbb8bfff] usable
[0.00] BIOS-e820: [mem 0xdbb8c000-0xdbff] reserved
[0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041edf] usable

Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
This fix does not impact 64bit system because on 64bit max_low_pfn
is the same as max_pfn.

Signed-off-by: Zhimin Gu 
Acked-by: Pavel Machek 
Signed-off-by: Chen Yu 
Acked-by: Thomas Gleixner 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/setup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1258,7 +1258,7 @@ void __init setup_arch(char **cmdline_p)
x86_init.hyper.guest_late_init();
 
e820__reserve_resources();
-   e820__register_nosave_regions(max_low_pfn);
+   e820__register_nosave_regions(max_pfn);
 
x86_init.resources.reserve_resources();
 




[PATCH 4.18 32/34] x86/time: Correct the attribute on jiffies definition

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Nathan Chancellor 

commit 53c13ba8ed39e89f21a0b98f4c8a241bb44e483d upstream.

Clang warns that the declaration of jiffies in include/linux/jiffies.h
doesn't match the definition in arch/x86/time/kernel.c:

arch/x86/kernel/time.c:29:42: warning: section does not match previous 
declaration [-Wsection]
__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
 ^
./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
 __section__(".data..cacheline_aligned")))
 ^
./include/linux/jiffies.h:81:31: note: previous attribute is here
extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data 
jiffies;
  ^
./arch/x86/include/asm/cache.h:20:2: note: expanded from macro 
'__cacheline_aligned_in_smp'
__page_aligned_data
^
./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
#define __page_aligned_data __section(.data..page_aligned) 
__aligned(PAGE_SIZE)
^
./include/linux/compiler_attributes.h:233:56: note: expanded from macro 
'__section'
#define __section(S)__attribute__((__section__(#S)))
   ^
1 warning generated.

The declaration was changed in commit 7c30f352c852 ("jiffies.h: declare
jiffies and jiffies_64 with cacheline_aligned_in_smp") but wasn't
updated here. Make them match so Clang no longer warns.

Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with 
cacheline_aligned_in_smp")
Signed-off-by: Nathan Chancellor 
Signed-off-by: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Nick Desaulniers 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20181013005311.28617-1-natechancel...@gmail.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/time.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -25,7 +25,7 @@
 #include 
 
 #ifdef CONFIG_X86_64
-__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
+__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = 
INITIAL_JIFFIES;
 #endif
 
 unsigned long profile_pc(struct pt_regs *regs)




[PATCH 4.18 07/34] cachefiles: fix the race between cachefiles_bury_object() and rmdir(2)

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Al Viro 

commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream.

the victim might've been rmdir'ed just before the lock_rename();
unlike the normal callers, we do not look the source up after the
parents are locked - we know it beforehand and just recheck that it's
still the child of what used to be its parent.  Unfortunately,
the check is too weak - we don't spot a dead directory since its
->d_parent is unchanged, dentry is positive, etc.  So we sail all
the way to ->rename(), with hosting filesystems _not_ expecting
to be asked renaming an rmdir'ed subdirectory.

The fix is easy, fortunately - the lock on parent is sufficient for
making IS_DEADDIR() on child safe.

Cc: sta...@vger.kernel.org
Fixes: 9ae326a69004 (CacheFiles: A cache that backs onto a mounted filesystem)
Signed-off-by: Al Viro 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/cachefiles/namei.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/cachefiles/namei.c
+++ b/fs/cachefiles/namei.c
@@ -343,7 +343,7 @@ try_again:
trap = lock_rename(cache->graveyard, dir);
 
/* do some checks before getting the grave dentry */
-   if (rep->d_parent != dir) {
+   if (rep->d_parent != dir || IS_DEADDIR(d_inode(rep))) {
/* the entry was probably culled when we dropped the parent dir
 * lock */
unlock_rename(cache->graveyard, dir);




[PATCH 4.18 06/34] fscache: Fix incomplete initialisation of inline key space

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: David Howells 

commit 1ff22883b0b2f7a73eb2609ffe879c9fd96f6328 upstream.

The inline key in struct rxrpc_cookie is insufficiently initialized,
zeroing only 3 of the 4 slots, therefore an index_key_len between 13 and 15
bytes will end up hashing uninitialized memory because the memcpy only
partially fills the last buf[] element.

Fix this by clearing fscache_cookie objects on allocation rather than using
the slab constructor to initialise them.  We're going to pretty much fill
in the entire struct anyway, so bringing it into our dcache writably
shouldn't incur much overhead.

This removes the need to do clearance in fscache_set_key() (where we aren't
doing it correctly anyway).

Also, we don't need to set cookie->key_len in fscache_set_key() as we
already did it in the only caller, so remove that.

Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies")
Reported-by: syzbot+a95b989b2dde8e806...@syzkaller.appspotmail.com
Reported-by: Eric Sandeen 
Cc: stable 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fscache/cookie.c   |   23 ---
 fs/fscache/internal.h |1 -
 fs/fscache/main.c |4 +---
 3 files changed, 5 insertions(+), 23 deletions(-)

--- a/fs/fscache/cookie.c
+++ b/fs/fscache/cookie.c
@@ -70,19 +70,6 @@ void fscache_free_cookie(struct fscache_
 }
 
 /*
- * initialise an cookie jar slab element prior to any use
- */
-void fscache_cookie_init_once(void *_cookie)
-{
-   struct fscache_cookie *cookie = _cookie;
-
-   memset(cookie, 0, sizeof(*cookie));
-   spin_lock_init(>lock);
-   spin_lock_init(>stores_lock);
-   INIT_HLIST_HEAD(>backing_objects);
-}
-
-/*
  * Set the index key in a cookie.  The cookie struct has space for a 12-byte
  * key plus length and hash, but if that's not big enough, it's instead a
  * pointer to a buffer containing 3 bytes of hash, 1 byte of length and then
@@ -95,8 +82,6 @@ static int fscache_set_key(struct fscach
u32 *buf;
int i;
 
-   cookie->key_len = index_key_len;
-
if (index_key_len > sizeof(cookie->inline_key)) {
buf = kzalloc(index_key_len, GFP_KERNEL);
if (!buf)
@@ -104,9 +89,6 @@ static int fscache_set_key(struct fscach
cookie->key = buf;
} else {
buf = (u32 *)cookie->inline_key;
-   buf[0] = 0;
-   buf[1] = 0;
-   buf[2] = 0;
}
 
memcpy(buf, index_key, index_key_len);
@@ -161,7 +143,7 @@ struct fscache_cookie *fscache_alloc_coo
struct fscache_cookie *cookie;
 
/* allocate and initialise a cookie */
-   cookie = kmem_cache_alloc(fscache_cookie_jar, GFP_KERNEL);
+   cookie = kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL);
if (!cookie)
return NULL;
 
@@ -192,6 +174,9 @@ struct fscache_cookie *fscache_alloc_coo
cookie->netfs_data  = netfs_data;
cookie->flags   = (1 << FSCACHE_COOKIE_NO_DATA_YET);
cookie->type= def->type;
+   spin_lock_init(>lock);
+   spin_lock_init(>stores_lock);
+   INIT_HLIST_HEAD(>backing_objects);
 
/* radix tree insertion won't use the preallocation pool unless it's
 * told it may not wait */
--- a/fs/fscache/internal.h
+++ b/fs/fscache/internal.h
@@ -51,7 +51,6 @@ extern struct fscache_cache *fscache_sel
 extern struct kmem_cache *fscache_cookie_jar;
 
 extern void fscache_free_cookie(struct fscache_cookie *);
-extern void fscache_cookie_init_once(void *);
 extern struct fscache_cookie *fscache_alloc_cookie(struct fscache_cookie *,
   const struct 
fscache_cookie_def *,
   const void *, size_t,
--- a/fs/fscache/main.c
+++ b/fs/fscache/main.c
@@ -143,9 +143,7 @@ static int __init fscache_init(void)
 
fscache_cookie_jar = kmem_cache_create("fscache_cookie_jar",
   sizeof(struct fscache_cookie),
-  0,
-  0,
-  fscache_cookie_init_once);
+  0, 0, NULL);
if (!fscache_cookie_jar) {
pr_notice("Failed to allocate a cookie jar\n");
ret = -ENOMEM;




[PATCH 4.18 28/34] sched/fair: Fix throttle_list starvation with low CFS quota

2018-11-08 Thread Greg Kroah-Hartman
4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Phil Auld 

commit baa9be4ffb55876923dc9716abc0a448e510ba30 upstream.

With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve.  Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.

Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list.  The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.

This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:

  crash> list cfs_rq.throttled_list -H 0x90b54f6ade40 -s 
cfs_rq.runtime_remaining | paste - - | awk '{print $1"  "$4}' | pr -t -n3
1 90b56cb2d200  -976050
2 90b56cb2cc00  -484925
3 90b56cb2bc00  -658814
4 90b56cb2ba00  -275365
5 90b166a45600  -135138
6 90b56cb2da00  -282505
7 90b56cb2e000  -148065
8 90b56cb2fa00  -872591
9 90b56cb2c000  -84687
   10 90b56cb2f000  -87237
   11 90b166a40a00  -164582

  crash> list cfs_rq.throttled_list -H 0x90b54f6ade40 -s 
cfs_rq.runtime_remaining | paste - - | awk '{print $1"  "$4}' | pr -t -n3
1 90b56cb2d200  -994147
2 90b56cb2cc00  -306051
3 90b56cb2bc00  -961321
4 90b56cb2ba00  -24490
5 90b166a45600  -135138
6 90b56cb2da00  -282505
7 90b56cb2e000  -148065
8 90b56cb2fa00  -872591
9 90b56cb2c000  -84687
   10 90b56cb2f000  -87237
   11 90b166a40a00  -164582

Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:

  crash> task 8eb765994500 sched_info
  PID: 7800   TASK: 8eb765994500  CPU: 16  COMMAND: "cputest"
sched_info = {
  pcount = 8,
  run_delay = 697094208,
  last_arrival = 240260125039,
  last_queued = 240260327513
},
  crash> task 8eb765994500 sched_info
  PID: 7800   TASK: 8eb765994500  CPU: 16  COMMAND: "cputest"
sched_info = {
  pcount = 8,
  run_delay = 697094208,
  last_arrival = 240260125039,
  last_queued = 240260327513
},

Signed-off-by: Phil Auld 
Reviewed-by: Ben Segall 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite 
distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.ga4...@pauld.bos.csb
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/sched/fair.c  |   22 +++---
 kernel/sched/sched.h |2 ++
 2 files changed, 21 insertions(+), 3 deletions(-)

--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4797,9 +4797,13 @@ static void throttle_cfs_rq(struct cfs_r
 
/*
 * Add to the _head_ of the list, so that an already-started
-* distribute_cfs_runtime will not see us
+* distribute_cfs_runtime will not see us. If disribute_cfs_runtime is
+* not running add to the tail so that later runqueues don't get 
starved.
 */
-   list_add_rcu(_rq->throttled_list, _b->throttled_cfs_rq);
+   if (cfs_b->distribute_running)
+   list_add_rcu(_rq->throttled_list, _b->throttled_cfs_rq);
+   else
+   list_add_tail_rcu(_rq->throttled_list, 
_b->throttled_cfs_rq);
 
/*
 * If we're the first throttled task, make sure the bandwidth
@@ -4943,14 +4947,16 @@ static int do_sched_cfs_period_timer(str
 * in us over-using our runtime if it is all used during this loop, but
 * only by limited amounts in that extreme case.
 */
-   while (throttled && cfs_b->runtime > 0) {
+   while (throttled && cfs_b->runtime > 0 && !cfs_b->distribute_running) {
runtime = cfs_b->runtime;
+   cfs_b->distribute_running = 1;
raw_spin_unlock(_b->lock);
/* we can't nest cfs_b->lock while distributing bandwidth */
runtime = distribute_cfs_runtime(cfs_b, runtime,
 runtime_expires);
raw_spin_lock(_b->lock);
 
+   cfs_b->distribute_running = 0;
throttled = !list_empty(_b->throttled_cfs_rq);
 
  

[PATCH 4.9 054/171] bnxt_en: Dont use rtnl lock to protect link change logic in workqueue.

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e2dc9b6e38fa3919e63d6d7905da70ca41cbf908 ]

As a further improvement to the PF/VF link change logic, use a private
mutex instead of the rtnl lock to protect link change logic.  With the
new mutex, we don't have to take the rtnl lock in the workqueue when
we have to handle link related functions.  If the VF and PF drivers
are running on the same host and both take the rtnl lock and one is
waiting for the other, it will cause timeout.  This patch fixes these
timeouts.

Fixes: 90c694bb7181 ("bnxt_en: Fix RTNL lock usage on bnxt_update_link().")
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 25 ++-
 drivers/net/ethernet/broadcom/bnxt/bnxt.h |  4 +++
 .../net/ethernet/broadcom/bnxt/bnxt_ethtool.c |  4 +++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 208e9dacfd34..a036f7039d76 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5580,7 +5580,9 @@ static int __bnxt_open_nic(struct bnxt *bp, bool 
irq_re_init, bool link_re_init)
}
 
if (link_re_init) {
+   mutex_lock(>link_lock);
rc = bnxt_update_phy_setting(bp);
+   mutex_unlock(>link_lock);
if (rc)
netdev_warn(bp->dev, "failed to update phy settings\n");
}
@@ -6230,30 +6232,28 @@ static void bnxt_sp_task(struct work_struct *work)
if (test_and_clear_bit(BNXT_PERIODIC_STATS_SP_EVENT, >sp_event))
bnxt_hwrm_port_qstats(bp);
 
-   /* These functions below will clear BNXT_STATE_IN_SP_TASK.  They
-* must be the last functions to be called before exiting.
-*/
if (test_and_clear_bit(BNXT_LINK_CHNG_SP_EVENT, >sp_event)) {
-   int rc = 0;
+   int rc;
 
+   mutex_lock(>link_lock);
if (test_and_clear_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT,
   >sp_event))
bnxt_hwrm_phy_qcaps(bp);
 
-   bnxt_rtnl_lock_sp(bp);
-   if (test_bit(BNXT_STATE_OPEN, >state))
-   rc = bnxt_update_link(bp, true);
-   bnxt_rtnl_unlock_sp(bp);
+   rc = bnxt_update_link(bp, true);
+   mutex_unlock(>link_lock);
if (rc)
netdev_err(bp->dev, "SP task can't update link (rc: 
%x)\n",
   rc);
}
if (test_and_clear_bit(BNXT_HWRM_PORT_MODULE_SP_EVENT, >sp_event)) {
-   bnxt_rtnl_lock_sp(bp);
-   if (test_bit(BNXT_STATE_OPEN, >state))
-   bnxt_get_port_module_status(bp);
-   bnxt_rtnl_unlock_sp(bp);
+   mutex_lock(>link_lock);
+   bnxt_get_port_module_status(bp);
+   mutex_unlock(>link_lock);
}
+   /* These functions below will clear BNXT_STATE_IN_SP_TASK.  They
+* must be the last functions to be called before exiting.
+*/
if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, >sp_event))
bnxt_reset(bp, false);
 
@@ -6788,6 +6788,7 @@ static int bnxt_probe_phy(struct bnxt *bp)
   rc);
return rc;
}
+   mutex_init(>link_lock);
 
rc = bnxt_update_link(bp, false);
if (rc) {
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 666bc0608ed7..017c10c53715 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1109,6 +1109,10 @@ struct bnxt {
unsigned long   *ntp_fltr_bmap;
int ntp_fltr_count;
 
+   /* To protect link related settings during link changes and
+* ethtool settings changes.
+*/
+   struct mutexlink_lock;
struct bnxt_link_info   link_info;
struct ethtool_eee  eee;
u32 lpi_tmr_lo;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index cde4b96f3153..3a352f76e633 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -793,6 +793,7 @@ static int bnxt_get_link_ksettings(struct net_device *dev,
u32 ethtool_speed;
 
ethtool_link_ksettings_zero_link_mode(lk_ksettings, supported);
+   mutex_lock(>link_lock);
bnxt_fw_to_ethtool_support_spds(link_info, lk_ksettings);
 
ethtool_link_ksettings_zero_link_mode(lk_ksettings, advertising);
@@ -840,6 +841,7 @@ static int bnxt_get_link_ksettings(struct net_device *dev,

[PATCH 4.9 051/171] net/mlx5: Fix command completion after timeout access invalid structure

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 061870800efb4e3d1ad4082a2569363629bdfcfc ]

Completion on timeout should not free the driver command entry structure
as it will need to access it again once real completion event from FW
will occur.

Fixes: 73dd3a4839c1 ('net/mlx5: Avoid using pending command interface slots')
Signed-off-by: Moshe Shemesh 
Cc: kernel-t...@fb.com
Signed-off-by: Saeed Mahameed 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c 
b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 9680c8805178..1d5263c46eee 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -965,7 +965,7 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, 
struct mlx5_cmd_msg *in,
 
err = wait_func(dev, ent);
if (err == -ETIMEDOUT)
-   goto out_free;
+   goto out;
 
ds = ent->ts2 - ent->ts1;
op = MLX5_GET(mbox_in, in->first.data, opcode);
@@ -1428,6 +1428,7 @@ void mlx5_cmd_comp_handler(struct mlx5_core_dev *dev, u64 
vec, bool forced)
mlx5_core_err(dev, "Command completion 
arrived after timeout (entry idx = %d).\n",
  ent->idx);
free_ent(cmd, ent->idx);
+   free_cmd(ent);
}
continue;
}
@@ -1486,7 +1487,8 @@ void mlx5_cmd_comp_handler(struct mlx5_core_dev *dev, u64 
vec, bool forced)
free_msg(dev, ent->in);
 
err = err ? err : ent->status;
-   free_cmd(ent);
+   if (!forced)
+   free_cmd(ent);
callback(err, context);
} else {
complete(>done);
-- 
2.17.1





x86_64 INIT/SIPI Bug

2018-11-08 Thread Rian Quinn
I apologize upfront if this is the wrong place to post this, pretty new to this.

We are working on the Bareflank Hypervisor (www.bareflank.org), and we
are passing through the INIT/SIPI process (similar to how a VMX
rootkit from EFI might boot the OS) and we noticed that on Arch Linux,
the INIT/SIPI process stalls, something we are not seeing on Ubuntu.

Turns out, to fix the issue, we had to turn on cpu_init_udelay=1.
The problem is, once a hypervisor is turned on, even one that is doing
nothing but passing through the instructions, the "quick" that is
detailed below fails as the kernel is not giving the CPU enough time
to perform a VMExit/VMEntry (even through the VMExit is not doing
anything).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/smpboot.c?h=v4.20-rc1#n650

You can see our INIT/SIPI code here if you are interested:
https://github.com/rianquinn/extended_apis/blob/hyperkernel_1/bfvmm/src/hve/arch/intel_x64/vmexit/init_signal.cpp

The reason I suggest this is a bug is the manual clearly states that a
wait is required and the "quirk" that turns off this delay prevents
code like this from working. Would it be possible to either:
- Turn this off by default, but still allow someone to turn it on if
they are confident the delay is not needed?
- Provide a generic way to turn this off (maybe if a hypervisor is
detected, it defaults to off)?

I'd be more than happy to provide a patch and test, but I'm not sure
if there is any interest in changing this code.

Thanks,
- Rian Quinn


[PATCH 4.9 067/171] ARM: 8677/1: boot/compressed: fix decompressor header layout for v7-M

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 06a4b6d009a1b74a6ec46c5418b46cc53a79fcb8 ]

As reported by Patrice, the header layout of the decompressor is
incorrect when building for v7-M. In this case, the __nop macro
resolves to 'mov r0, r0', which is emitted as a narrow encoding,
resulting in the header data fields to end up at lower offsets than
required.

Given the variety of targets we need to support with the same code,
the startup sequence is a bit of a jumble, and uses instructions
and macros whose encoding widths cannot be specified (badr), or only
exist in a narrow encoding (bx)

So force the use of a wide encoding in __nop, and replace the start
sequence with a simple jump to the label marking the start of code,
preceded by a Thumb2 mode switch if required (using explicit wide
encodings where appropriate). The label itself can be moved to the
start of code [where it belongs] due to the larger range of branch
instructions as compared to adr instructions.

Reported-by: Patrice CHOTARD 
Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/compressed/efi-header.S |  4 +---
 arch/arm/boot/compressed/head.S   | 17 ++---
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/compressed/efi-header.S 
b/arch/arm/boot/compressed/efi-header.S
index 9d5dc4fda3c1..3f7d1b74c5e0 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -17,14 +17,12 @@
@ there.
.inst   'M' | ('Z' << 8) | (0x1310 << 16)   @ tstne r0, #0x4d000
 #else
-   mov r0, r0
+   W(mov)  r0, r0
 #endif
.endm
 
.macro  __EFI_HEADER
 #ifdef CONFIG_EFI_STUB
-   b   __efi_start
-
.setstart_offset, __efi_start - start
.orgstart + 0x3c
@
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fc6d541549a2..2d7f2bb0d66a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -130,19 +130,22 @@ start:
.rept   7
__nop
.endr
-   ARM(mov r0, r0  )
-   ARM(b   1f  )
- THUMB(badrr12, 1f )
- THUMB(bx  r12 )
+#ifndef CONFIG_THUMB2_KERNEL
+   mov r0, r0
+#else
+ AR_CLASS( sub pc, pc, #3  )   @ A/R: switch to Thumb2 mode
+  M_CLASS( nop.w   )   @ M: already in Thumb2 mode
+   .thumb
+#endif
+   W(b)1f
 
.word   _magic_sig  @ Magic numbers to help the loader
.word   _magic_start@ absolute load/run zImage address
.word   _magic_end  @ zImage end address
.word   0x04030201  @ endianness flag
 
- THUMB(.thumb  )
-1: __EFI_HEADER
-
+   __EFI_HEADER
+1:
  ARM_BE8(  setend  be  )   @ go BE8 if compiled for BE8
  AR_CLASS( mrs r9, cpsr)
 #ifdef CONFIG_ARM_VIRT_EXT
-- 
2.17.1





[PATCH 4.9 052/171] tipc: Fix tipc_sk_reinit handling of -EAGAIN

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 6c7e983b220f89e03286dc70a41c7ef3a8b409df ]

In 9dbbfb0ab6680c6a85609041011484e6658e7d3c function tipc_sk_reinit
had additional logic added to loop in the event that function
rhashtable_walk_next() returned -EAGAIN. No worries.

However, if rhashtable_walk_start returns -EAGAIN, it does "continue",
and therefore skips the call to rhashtable_walk_stop(). That has
the effect of calling rcu_read_lock() without its paired call to
rcu_read_unlock(). Since rcu_read_lock() may be nested, the problem
may not be apparent for a while, especially since resize events may
be rare. But the comments to rhashtable_walk_start() state:

 * ...Note that we take the RCU lock in all
 * cases including when we return an error.  So you must always call
 * rhashtable_walk_stop to clean up.

This patch replaces the continue with a goto and label to ensure a
matching call to rhashtable_walk_stop().

Signed-off-by: Bob Peterson 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/tipc/socket.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 25bc5c30d7fb..9d3f047305ce 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2277,8 +2277,8 @@ void tipc_sk_reinit(struct net *net)
 
do {
tsk = ERR_PTR(rhashtable_walk_start());
-   if (tsk)
-   continue;
+   if (IS_ERR(tsk))
+   goto walk_stop;
 
while ((tsk = rhashtable_walk_next()) && !IS_ERR(tsk)) {
spin_lock_bh(>sk.sk_lock.slock);
@@ -2287,7 +2287,7 @@ void tipc_sk_reinit(struct net *net)
msg_set_orignode(msg, tn->own_addr);
spin_unlock_bh(>sk.sk_lock.slock);
}
-
+walk_stop:
rhashtable_walk_stop();
} while (tsk == ERR_PTR(-EAGAIN));
 }
-- 
2.17.1





[PATCH 4.9 048/171] rxe: Fix a sleep-in-atomic bug in post_one_send

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 07d432bb97f19dd5e784175152f9fce3b2646133 ]

The driver may sleep under a spin lock, and the function call path is:
post_one_send (acquire the lock by spin_lock_irqsave)
  init_send_wqe
copy_from_user --> may sleep

There is no flow that makes "qp->is_user" true, and copy_from_user may
cause bug when a non-user pointer is used. So the lines of copy_from_user
and check of "qp->is_user" are removed.

Signed-off-by: Jia-Ju Bai 
Reviewed-by: Leon Romanovsky 
Acked-by: Moni Shoua 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/sw/rxe/rxe_verbs.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c 
b/drivers/infiniband/sw/rxe/rxe_verbs.c
index ced416f5dffb..ef13082d6ca1 100644
--- a/drivers/infiniband/sw/rxe/rxe_verbs.c
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.c
@@ -729,13 +729,8 @@ static int init_send_wqe(struct rxe_qp *qp, struct 
ib_send_wr *ibwr,
 
sge = ibwr->sg_list;
for (i = 0; i < num_sge; i++, sge++) {
-   if (qp->is_user && copy_from_user(p, (__user void *)
-   (uintptr_t)sge->addr, sge->length))
-   return -EFAULT;
-
-   else if (!qp->is_user)
-   memcpy(p, (void *)(uintptr_t)sge->addr,
-  sge->length);
+   memcpy(p, (void *)(uintptr_t)sge->addr,
+   sge->length);
 
p += sge->length;
}
-- 
2.17.1





[PATCH 4.9 069/171] elevator: fix truncation of icq_cache_name

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 9bd2bbc01d17ddd567cc0f81f77fe1163e497462 ]

gcc 7.1 reports the following warning:

block/elevator.c: In function ‘elv_register’:
block/elevator.c:898:5: warning: ‘snprintf’ output may be truncated before 
the last format character [-Wformat-truncation=]
 "%s_io_cq", e->elevator_name);
 ^~
block/elevator.c:897:3: note: ‘snprintf’ output between 7 and 22 bytes into 
a destination of size 21
   snprintf(e->icq_cache_name, sizeof(e->icq_cache_name),
   ^~
 "%s_io_cq", e->elevator_name);
 ~

The bug is that the name of the icq_cache is 6 characters longer than
the elevator name, but only ELV_NAME_MAX + 5 characters were reserved
for it --- so in the case of a maximum-length elevator name, the 'q'
character in "_io_cq" would be truncated by snprintf().  Fix it by
reserving ELV_NAME_MAX + 6 characters instead.

Signed-off-by: Eric Biggers 
Reviewed-by: Bart Van Assche 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 include/linux/elevator.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/elevator.h b/include/linux/elevator.h
index e7f358d2e5fc..eaa58c0f894b 100644
--- a/include/linux/elevator.h
+++ b/include/linux/elevator.h
@@ -102,7 +102,7 @@ struct elevator_type
struct module *elevator_owner;
 
/* managed by elevator core */
-   char icq_cache_name[ELV_NAME_MAX + 5];  /* elvname + "_io_cq" */
+   char icq_cache_name[ELV_NAME_MAX + 6];  /* elvname + "_io_cq" */
struct list_head list;
 };
 
-- 
2.17.1





Re: [PATCH] z3fold: fix wrong handling of headless pages

2018-11-08 Thread Andrew Morton
On Thu,  8 Nov 2018 22:45:40 +0900 Jongseok Kim  wrote:

> Yes, you are right.
> I think that's the best way to deal it.
> Thank you.


I did this:

Link: http://lkml.kernel.org/r/20181105162225.74e8837d03583a9b707cf...@gmail.com
Signed-off-by: Vitaly Wool 
Signed-off-by: Jongseok Kim 
Reported-by-by: Jongseok Kim 
Reviewed-by: Snild Dolkow 


[PATCH 4.9 091/171] ALSA: hda - No loopback on ALC299 codec

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit fa16b69f1299004b60b625f181143500a246e5cb ]

ALC299 has no loopback mixer, but the driver still tries to add a beep
control over the mixer NID which leads to the error at accessing it.
This patch fixes it by properly declaring mixer_nid=0 for this codec.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195775
Fixes: 28f1f9b26cee ("ALSA: hda/realtek - Add new codec ID ALC299")
Cc: sta...@vger.kernel.org
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/pci/hda/patch_realtek.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ca2945711dbe..0eee308365c4 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6392,8 +6392,11 @@ static int patch_alc269(struct hda_codec *codec)
break;
case 0x10ec0225:
case 0x10ec0295:
+   spec->codec_variant = ALC269_TYPE_ALC225;
+   break;
case 0x10ec0299:
spec->codec_variant = ALC269_TYPE_ALC225;
+   spec->gen.mixer_nid = 0; /* no loopback on ALC299 */
break;
case 0x10ec0234:
case 0x10ec0274:
-- 
2.17.1





[PATCH 4.9 053/171] tipc: fix a race condition of releasing subscriber object

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit fd849b7c41f0fabfe783d0691a63c5518e8ebc99 ]

No matter whether a request is inserted into workqueue as a work item
to cancel a subscription or to delete a subscription's subscriber
asynchronously, the work items may be executed in different workers.
As a result, it doesn't mean that one request which is raised prior to
another request is definitely handled before the latter. By contrast,
if the latter request is executed before the former request, below
error may happen:

[  656.183644] BUG: spinlock bad magic on CPU#0, kworker/u8:0/12117
[  656.184487] general protection fault:  [#1] SMP
[  656.185160] Modules linked in: tipc ip6_udp_tunnel udp_tunnel 9pnet_virtio 
9p 9pnet virtio_net virtio_pci virtio_ring virtio [last unloaded: 
ip6_udp_tunnel]
[  656.187003] CPU: 0 PID: 12117 Comm: kworker/u8:0 Not tainted 4.11.0-rc7+ #6
[  656.187920] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  656.188690] Workqueue: tipc_rcv tipc_recv_work [tipc]
[  656.189371] task: 88003f5cec40 task.stack: c90004448000
[  656.190157] RIP: 0010:spin_bug+0xdd/0xf0
[  656.190678] RSP: 0018:c9000444bcb8 EFLAGS: 00010202
[  656.191375] RAX: 0034 RBX: 88003f8d1388 RCX: 
[  656.192321] RDX: 88003ba13708 RSI: 88003ba0cd08 RDI: 88003ba0cd08
[  656.193265] RBP: c9000444bcd0 R08: 0030 R09: 6b6b6b6b
[  656.194208] R10: 8800bde3e000 R11: 01b4 R12: 6b6b6b6b6b6b6b6b
[  656.195157] R13: 81a3ca64 R14: 88003f8d1388 R15: 88003f8d13a0
[  656.196101] FS:  () GS:88003ba0() 
knlGS:
[  656.197172] CS:  0010 DS:  ES:  CR0: 80050033
[  656.197935] CR2: 7f0b3d2e6000 CR3: 3ef9e000 CR4: 06f0
[  656.198873] Call Trace:
[  656.199210]  do_raw_spin_lock+0x66/0xa0
[  656.199735]  _raw_spin_lock_bh+0x19/0x20
[  656.200258]  tipc_subscrb_subscrp_delete+0x28/0xf0 [tipc]
[  656.200990]  tipc_subscrb_rcv_cb+0x45/0x260 [tipc]
[  656.201632]  tipc_receive_from_sock+0xaf/0x100 [tipc]
[  656.202299]  tipc_recv_work+0x2b/0x60 [tipc]
[  656.202872]  process_one_work+0x157/0x420
[  656.203404]  worker_thread+0x69/0x4c0
[  656.203898]  kthread+0x138/0x170
[  656.204328]  ? process_one_work+0x420/0x420
[  656.204889]  ? kthread_create_on_node+0x40/0x40
[  656.205527]  ret_from_fork+0x29/0x40
[  656.206012] Code: 48 8b 0c 25 00 c5 00 00 48 c7 c7 f0 24 a3 81 48 81 c1 f0 
05 00 00 65 8b 15 61 ef f5 7e e8 9a 4c 09 00 4d 85 e4 44 8b 4b 08 74 92 <45> 8b 
84 24 40 04 00 00 49 8d 8c 24 f0 05 00 00 eb 8d 90 0f 1f
[  656.208504] RIP: spin_bug+0xdd/0xf0 RSP: c9000444bcb8
[  656.209798] ---[ end trace e2a800e6eb0770be ]---

In above scenario, the request of deleting subscriber was performed
earlier than the request of canceling a subscription although the
latter was issued before the former, which means tipc_subscrb_delete()
was called before tipc_subscrp_cancel(). As a result, when
tipc_subscrb_subscrp_delete() called by tipc_subscrp_cancel() was
executed to cancel a subscription, the subscription's subscriber
refcnt had been decreased to 1. After tipc_subscrp_delete() where
the subscriber was freed because its refcnt was decremented to zero,
but the subscriber's lock had to be released, as a consequence, panic
happened.

By contrast, if we increase subscriber's refcnt before
tipc_subscrb_subscrp_delete() is called in tipc_subscrp_cancel(),
the panic issue can be avoided.

Fixes: d094c4d5f5c7 ("tipc: add subscription refcount to avoid invalid delete")
Reported-by: Parthasarathy Bhuvaragan 
Signed-off-by: Ying Xue 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/tipc/subscr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index 271cd66e4b3b..c2646446e157 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -256,7 +256,9 @@ static void tipc_subscrp_delete(struct tipc_subscription 
*sub)
 static void tipc_subscrp_cancel(struct tipc_subscr *s,
struct tipc_subscriber *subscriber)
 {
+   tipc_subscrb_get(subscriber);
tipc_subscrb_subscrp_delete(subscriber, s);
+   tipc_subscrb_put(subscriber);
 }
 
 static struct tipc_subscription *tipc_subscrp_create(struct net *net,
-- 
2.17.1





[PATCH 4.9 045/171] IB/ipoib: Do not warn if IPoIB debugfs doesnt exist

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 14fa91e0fef8e4d6feb8b1fa2a807828e0abe815 ]

netdev_wait_allrefs() could rebroadcast NETDEV_UNREGISTER event
multiple times until all refs are gone, which will result in calling
ipoib_delete_debug_files multiple times and printing a warning.

Remove the WARN_ONCE since checks of NULL pointers before calling
debugfs_remove are not needed.

Fixes: 771a52584096 ("IB/IPoIB: ibX: failed to create mcg debug file")
Signed-off-by: Alaa Hleihel 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Dennis Dalessandro 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_fs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_fs.c 
b/drivers/infiniband/ulp/ipoib/ipoib_fs.c
index 09396bd7b02d..63be3bcdc0e3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_fs.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_fs.c
@@ -281,8 +281,6 @@ void ipoib_delete_debug_files(struct net_device *dev)
 {
struct ipoib_dev_priv *priv = netdev_priv(dev);
 
-   WARN_ONCE(!priv->mcg_dentry, "null mcg debug file\n");
-   WARN_ONCE(!priv->path_dentry, "null path debug file\n");
debugfs_remove(priv->mcg_dentry);
debugfs_remove(priv->path_dentry);
priv->mcg_dentry = priv->path_dentry = NULL;
-- 
2.17.1





[PATCH 4.9 088/171] ocfs2: fix deadlock caused by recursive locking in xattr

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 8818efaaacb78c60a9d90c5705b6c99b75d7d442 ]

Another deadlock path caused by recursive locking is reported.  This
kind of issue was introduced since commit 743b5f1434f5 ("ocfs2: take
inode lock in ocfs2_iop_set/get_acl()").  Two deadlock paths have been
fixed by commit b891fa5024a9 ("ocfs2: fix deadlock issue when taking
inode lock at vfs entry points").  Yes, we intend to fix this kind of
case in incremental way, because it's hard to find out all possible
paths at once.

This one can be reproduced like this.  On node1, cp a large file from
home directory to ocfs2 mountpoint.  While on node2, run
setfacl/getfacl.  Both nodes will hang up there.  The backtraces:

On node1:
  __ocfs2_cluster_lock.isra.39+0x357/0x740 [ocfs2]
  ocfs2_inode_lock_full_nested+0x17d/0x840 [ocfs2]
  ocfs2_write_begin+0x43/0x1a0 [ocfs2]
  generic_perform_write+0xa9/0x180
  __generic_file_write_iter+0x1aa/0x1d0
  ocfs2_file_write_iter+0x4f4/0xb40 [ocfs2]
  __vfs_write+0xc3/0x130
  vfs_write+0xb1/0x1a0
  SyS_write+0x46/0xa0

On node2:
  __ocfs2_cluster_lock.isra.39+0x357/0x740 [ocfs2]
  ocfs2_inode_lock_full_nested+0x17d/0x840 [ocfs2]
  ocfs2_xattr_set+0x12e/0xe80 [ocfs2]
  ocfs2_set_acl+0x22d/0x260 [ocfs2]
  ocfs2_iop_set_acl+0x65/0xb0 [ocfs2]
  set_posix_acl+0x75/0xb0
  posix_acl_xattr_set+0x49/0xa0
  __vfs_setxattr+0x69/0x80
  __vfs_setxattr_noperm+0x72/0x1a0
  vfs_setxattr+0xa7/0xb0
  setxattr+0x12d/0x190
  path_setxattr+0x9f/0xb0
  SyS_setxattr+0x14/0x20

Fix this one by using ocfs2_inode_{lock|unlock}_tracker, which is
exported by commit 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking logic
to avoid recursive cluster lock").

Link: http://lkml.kernel.org/r/20170622014746.5815-1-z...@suse.com
Fixes: 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
Signed-off-by: Eric Ren 
Reported-by: Thomas Voegtle 
Tested-by: Thomas Voegtle 
Reviewed-by: Joseph Qi 
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/dlmglue.c |  4 
 fs/ocfs2/xattr.c   | 23 +--
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 785fcc29d85d..5729d55da67d 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -2599,6 +2599,10 @@ void ocfs2_inode_unlock_tracker(struct inode *inode,
struct ocfs2_lock_res *lockres;
 
lockres = _I(inode)->ip_inode_lockres;
+   /* had_lock means that the currect process already takes the cluster
+* lock previously. If had_lock is 1, we have nothing to do here, and
+* it will get unlocked where we got the lock.
+*/
if (!had_lock) {
ocfs2_remove_holder(lockres, oh);
ocfs2_inode_unlock(inode, ex);
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 03f6ff249edb..01932763b4d1 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -1330,20 +1330,21 @@ static int ocfs2_xattr_get(struct inode *inode,
   void *buffer,
   size_t buffer_size)
 {
-   int ret;
+   int ret, had_lock;
struct buffer_head *di_bh = NULL;
+   struct ocfs2_lock_holder oh;
 
-   ret = ocfs2_inode_lock(inode, _bh, 0);
-   if (ret < 0) {
-   mlog_errno(ret);
-   return ret;
+   had_lock = ocfs2_inode_lock_tracker(inode, _bh, 0, );
+   if (had_lock < 0) {
+   mlog_errno(had_lock);
+   return had_lock;
}
down_read(_I(inode)->ip_xattr_sem);
ret = ocfs2_xattr_get_nolock(inode, di_bh, name_index,
 name, buffer, buffer_size);
up_read(_I(inode)->ip_xattr_sem);
 
-   ocfs2_inode_unlock(inode, 0);
+   ocfs2_inode_unlock_tracker(inode, 0, , had_lock);
 
brelse(di_bh);
 
@@ -3539,11 +3540,12 @@ int ocfs2_xattr_set(struct inode *inode,
 {
struct buffer_head *di_bh = NULL;
struct ocfs2_dinode *di;
-   int ret, credits, ref_meta = 0, ref_credits = 0;
+   int ret, credits, had_lock, ref_meta = 0, ref_credits = 0;
struct ocfs2_super *osb = OCFS2_SB(inode->i_sb);
struct inode *tl_inode = osb->osb_tl_inode;
struct ocfs2_xattr_set_ctxt ctxt = { NULL, NULL, NULL, };
struct ocfs2_refcount_tree *ref_tree = NULL;
+   struct ocfs2_lock_holder oh;
 
struct ocfs2_xattr_info xi = {
.xi_name_index = name_index,
@@ -3574,8 +3576,9 @@ int ocfs2_xattr_set(struct inode *inode,
return -ENOMEM;
}
 
-   ret = ocfs2_inode_lock(inode, _bh, 1);
-   if (ret < 0) {
+   had_lock = ocfs2_inode_lock_tracker(inode, _bh, 1, );
+   if (had_lock < 0) {
+   ret = had_lock;
mlog_errno(ret);
goto cleanup_nolock;
}
@@ -3672,7 +3675,7 

[PATCH 4.9 080/171] usb: renesas_usbhs: gadget: fix unused-but-set-variable warning

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit b7d44c36a6f6d956e1539e0dd42f98b26e5a4684 ]

The commit b8b9c974afee ("usb: renesas_usbhs: gadget: disable all eps
when the driver stops") causes the unused-but-set-variable warning.
But, if the usbhsg_ep_disable() will return non-zero value, udc/core.c
doesn't clear the ep->enabled flag. So, this driver should not return
non-zero value, if the pipe is zero because this means the pipe is
already disabled. Otherwise, the ep->enabled flag is never cleared
when the usbhsg_ep_disable() is called by the renesas_usbhs driver first.

Fixes: b8b9c974afee ("usb: renesas_usbhs: gadget: disable all eps when the 
driver stops")
Fixes: 11432050f070 ("usb: renesas_usbhs: gadget: fix NULL pointer dereference 
in ep_disable()")
Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/renesas_usbhs/mod_gadget.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
b/drivers/usb/renesas_usbhs/mod_gadget.c
index 54a3237aac08..5984fb134cf4 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -639,14 +639,11 @@ static int usbhsg_ep_disable(struct usb_ep *ep)
struct usbhsg_uep *uep = usbhsg_ep_to_uep(ep);
struct usbhs_pipe *pipe;
unsigned long flags;
-   int ret = 0;
 
spin_lock_irqsave(>lock, flags);
pipe = usbhsg_uep_to_pipe(uep);
-   if (!pipe) {
-   ret = -EINVAL;
+   if (!pipe)
goto out;
-   }
 
usbhsg_pipe_disable(uep);
usbhs_pipe_free(pipe);
-- 
2.17.1





[PATCH 4.9 050/171] net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.

2018-11-08 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit c505873eaece2b4aefd07d339dc7e1400e0235ac ]

88E1145 also need this autoneg errata.

Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/marvell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c60c147708c4..520352327104 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1610,7 +1610,7 @@ static struct phy_driver marvell_drivers[] = {
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
.config_init = _config_init,
-   .config_aneg = _config_aneg,
+   .config_aneg = _config_aneg,
.read_status = _read_status,
.ack_interrupt = _ack_interrupt,
.config_intr = _config_intr,
-- 
2.17.1





[PATCH 3.18 074/144] perf machine: Fix __machine__findnew_thread() error path

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 260d819e3abdbdaa2b88fb983d1314f1b263f9e2 ]

When thread__init_map_groups() fails, a new thread should be removed
from the rbtree since it's gonna be freed.  Also update last match cache
only if the function succeeded.

Reported-by: David Ahern 
Signed-off-by: Namhyung Kim 
Acked-by: Jiri Olsa 
Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/util/machine.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 34fc7c8672e4..84238a10c34b 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -389,7 +389,6 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine,
if (th != NULL) {
rb_link_node(>rb_node, parent, p);
rb_insert_color(>rb_node, >threads);
-   machine->last_match = th;
 
/*
 * We have to initialize map_groups separately
@@ -400,9 +399,12 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine,
 * leader and that would screwed the rb tree.
 */
if (thread__init_map_groups(th, machine)) {
+   rb_erase(>rb_node, >threads);
thread__delete(th);
return NULL;
}
+
+   machine->last_match = th;
}
 
return th;
-- 
2.17.1





[PATCH 3.18 073/144] perf/x86/intel: Fix bug for "cycles:p" and "cycles:pp" on SLM

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 33636732dcd7cc738a5913bb730d663c6b03c8fb ]

cycles:p and cycles:pp do not work on SLM since commit:

   86a04461a99f ("perf/x86: Revamp PEBS event selection")

UOPS_RETIRED.ALL is not a PEBS capable event, so it should not be used
to count cycle number.

Actually SLM calls intel_pebs_aliases_core2() which uses INST_RETIRED.ANY_P
to count the number of cycles. It's a PEBS capable event. But inv and
cmask must be set to count cycles.

Considering SLM allows all events as PEBS with no flags, only
INST_RETIRED.ANY_P, inv=1, cmask=16 needs to handled specially.

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: 
http://lkml.kernel.org/r/1421084541-31639-1-git-send-email-kan.li...@intel.com
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 46211bcc813e..423cbd9bea3e 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -568,8 +568,8 @@ struct event_constraint intel_atom_pebs_event_constraints[] 
= {
 };
 
 struct event_constraint intel_slm_pebs_event_constraints[] = {
-   /* UOPS_RETIRED.ALL, inv=1, cmask=16 (cycles:p). */
-   INTEL_FLAGS_EVENT_CONSTRAINT(0x108001c2, 0xf),
+   /* INST_RETIRED.ANY_P, inv=1, cmask=16 (cycles:p). */
+   INTEL_FLAGS_EVENT_CONSTRAINT(0x108000c0, 0x1),
/* Allow all events as PEBS with no flags */
INTEL_ALL_EVENT_CONSTRAINT(0, 0x1),
EVENT_CONSTRAINT_END
-- 
2.17.1





Re: [driver-core PATCH v6 3/9] device core: Consolidate locking and unlocking of parent and device

2018-11-08 Thread jane . chu

Hi, Alex,


On 11/08/2018 10:06 AM, Alexander Duyck wrote:

+/*
+ * __device_driver_lock - release locks needed to manipulate dev->drv


You meant to say __device_driver_unlock, right?


+ * @dev: Device we will update driver info for
+ * @parent: Parent device. Needed if the bus requires parent lock
+ *
+ * This function will release the required locks for manipulating dev->drv.
+ * Normally this will just be the the @dev lock, but when called for a
+ * USB interface, @parent lock will be released as well.
+ */
+static void __device_driver_unlock(struct device *dev, struct device *parent)
+{
+   device_unlock(dev);
+   if (parent && dev->bus->need_parent_lock)
+   device_unlock(parent);
+}


-jane


[PATCH 3.18 075/144] perf tools: Fix statfs.f_type data type mismatch build error with uclibc

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit db1806edcfef007d9594435a331dcf7e7f1b8fac ]

ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers
statfs defines f_type to be U32 which causes perf build breakage

http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h

  --->8---
CC   fs/fs.o
  fs/fs.c: In function 'fs__valid_mount':
  fs/fs.c:82:24: error: comparison between signed and unsigned integer
  expressions [-Werror=sign-compare]
else if (st_fs.f_type != magic)
  ^
  cc1: all warnings being treated as errors
  --->8---

Signed-off-by: Alexey Brodkin 
Acked-by: Jiri Olsa 
Cc: Borislav Petkov 
Cc: Cody P Schafer 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Vineet Gupta 
Link: 
http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgu...@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/lib/api/fs/debugfs.c | 2 +-
 tools/lib/api/fs/fs.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
index a74fba6d7743..86ea2d7b8845 100644
--- a/tools/lib/api/fs/debugfs.c
+++ b/tools/lib/api/fs/debugfs.c
@@ -67,7 +67,7 @@ int debugfs_valid_mountpoint(const char *debugfs)
 
if (statfs(debugfs, _fs) < 0)
return -ENOENT;
-   else if (st_fs.f_type != (long) DEBUGFS_MAGIC)
+   else if ((long)st_fs.f_type != (long)DEBUGFS_MAGIC)
return -ENOENT;
 
return 0;
diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c
index c1b49c36a951..4b2fa7bcbb84 100644
--- a/tools/lib/api/fs/fs.c
+++ b/tools/lib/api/fs/fs.c
@@ -75,7 +75,7 @@ static int fs__valid_mount(const char *fs, long magic)
 
if (statfs(fs, _fs) < 0)
return -ENOENT;
-   else if (st_fs.f_type != magic)
+   else if ((long)st_fs.f_type != magic)
return -ENOENT;
 
return 0;
-- 
2.17.1





[PATCH 3.18 058/144] arm: dts: Use pmu_system_controller phandle for dp phy

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit e93e54544adf3aa6908b821e896cb17a562cb683 ]

DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.

Signed-off-by: Vivek Gautam 
Reviewed-by: Jingoo Han 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Kukjin Kim 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/exynos5250.dtsi | 2 +-
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index d55c1a2eb798..251226eefad7 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
 
dp_phy: video-phy@10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040720 4>;
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a031cbc0..1353a092134f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
 
dp_phy: video-phy@10040728 {
-   compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040728 4>;
+   compatible = "samsung,exynos5420-dp-video-phy";
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};
 
-- 
2.17.1





[PATCH 3.18 087/144] Btrfs: avoid syncing log in the fast fsync path when not necessary

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit b659ef027792219b590d67a2baf1643a93727d29 ]

Commit 3a8b36f37806 ("Btrfs: fix data loss in the fast fsync path") added
a performance regression for that causes an unnecessary sync of the log
trees (fs/subvol and root log trees) when 2 consecutive fsyncs are done
against a file, without no writes or any metadata updates to the inode in
between them and if a transaction is committed before the second fsync is
called.

Huang Ying reported this to lkml (https://lkml.org/lkml/2015/3/18/99)
after a test sysbench test that measured a -62% decrease of file io
requests per second for that tests' workload.

The test is:

  echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
  echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
  echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
  mkfs -t btrfs /dev/sda2
  mount -t btrfs /dev/sda2 /fs/sda2
  cd /fs/sda2
  for ((i = 0; i < 1024; i++)); do fallocate -l 67108864 testfile.$i; done
  sysbench --test=fileio --max-requests=0 --num-threads=4 --max-time=600 \
--file-test-mode=rndwr --file-total-size=68719476736 --file-io-mode=sync \
--file-num=1024 run

A test on kvm guest, running a debug kernel gave me the following results:

Without 3a8b36f378060d: 16.01 reqs/sec
With 3a8b36f378060d: 3.39 reqs/sec
With 3a8b36f378060d and this patch: 16.04 reqs/sec

Reported-by: Huang Ying 
Tested-by: Huang, Ying 
Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/file.c |  9 ++---
 fs/btrfs/ordered-data.c | 14 ++
 fs/btrfs/ordered-data.h |  3 +++
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 2ad4cb3da8f6..ba37ec6263ca 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1879,6 +1879,7 @@ int btrfs_sync_file(struct file *file, loff_t start, 
loff_t end, int datasync)
struct btrfs_log_ctx ctx;
int ret = 0;
bool full_sync = 0;
+   const u64 len = end - start + 1;
 
trace_btrfs_sync_file(file, datasync);
 
@@ -1907,7 +1908,7 @@ int btrfs_sync_file(struct file *file, loff_t start, 
loff_t end, int datasync)
 * all extents are persisted and the respective file extent
 * items are in the fs/subvol btree.
 */
-   ret = btrfs_wait_ordered_range(inode, start, end - start + 1);
+   ret = btrfs_wait_ordered_range(inode, start, len);
} else {
/*
 * Start any new ordered operations before starting to log the
@@ -1979,8 +1980,10 @@ int btrfs_sync_file(struct file *file, loff_t start, 
loff_t end, int datasync)
 */
smp_mb();
if (btrfs_inode_in_log(inode, root->fs_info->generation) ||
-   (full_sync && BTRFS_I(inode)->last_trans <=
-root->fs_info->last_trans_committed)) {
+   (BTRFS_I(inode)->last_trans <=
+root->fs_info->last_trans_committed &&
+(full_sync ||
+ !btrfs_have_ordered_extents_in_range(inode, start, len {
/*
 * We'v had everything committed since the last time we were
 * modified so clear this flag in case it was set for whatever
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index b23d024c0234..4c20199cef62 100644
--- a/fs/btrfs/ordered-data.c
+++ b/fs/btrfs/ordered-data.c
@@ -848,6 +848,20 @@ out:
return entry;
 }
 
+bool btrfs_have_ordered_extents_in_range(struct inode *inode,
+u64 file_offset,
+u64 len)
+{
+   struct btrfs_ordered_extent *oe;
+
+   oe = btrfs_lookup_ordered_range(inode, file_offset, len);
+   if (oe) {
+   btrfs_put_ordered_extent(oe);
+   return true;
+   }
+   return false;
+}
+
 /*
  * lookup and return any extent before 'file_offset'.  NULL is returned
  * if none is found
diff --git a/fs/btrfs/ordered-data.h b/fs/btrfs/ordered-data.h
index 0124bffc775f..a1bce0a5 100644
--- a/fs/btrfs/ordered-data.h
+++ b/fs/btrfs/ordered-data.h
@@ -191,6 +191,9 @@ btrfs_lookup_first_ordered_extent(struct inode * inode, u64 
file_offset);
 struct btrfs_ordered_extent *btrfs_lookup_ordered_range(struct inode *inode,
u64 file_offset,
u64 len);
+bool btrfs_have_ordered_extents_in_range(struct inode *inode,
+u64 file_offset,
+u64 len);
 int btrfs_ordered_update_i_size(struct inode *inode, u64 offset,
struct 

[PATCH 3.18 059/144] scsi: ->queue_rq cant sleep

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit 70a0f2c1898c6abf53670e55642b6e840b003892 ]

The blk-mq ->queue_rq method is always called from process context,
but might have preemption disabled.  This means we still always
have to use GFP_ATOMIC for memory allocations, and thus need to
revert part of commit 3c356bde1 ("scsi: stop passing a gfp_mask
argument down the command setup path").

Signed-off-by: Christoph Hellwig 
Reported-by: Sasha Levin 
Reviewed-by: Bart Van Assche 
Tested-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/scsi_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index a11837054d6c..0d5c218b7ad1 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -616,7 +616,7 @@ static int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, 
int nents,
}
 
ret = __sg_alloc_table(>table, nents, SCSI_MAX_SG_SEGMENTS,
-  first_chunk, gfp_mask, scsi_sg_alloc);
+  first_chunk, GFP_ATOMIC, scsi_sg_alloc);
if (unlikely(ret))
scsi_free_sgtable(sdb, mq);
return ret;
-- 
2.17.1





[PATCH 3.18 054/144] NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ceb3a16c070c403f5f9ca46b46cf2bb79ea11750 ]

Ensure that we cache the NFSv4/v4.1 client owner_id so that we can
verify it when we're doing trunking detection.

Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs4client.c   |  1 +
 fs/nfs/nfs4proc.c | 19 +++
 include/linux/nfs_fs_sb.h |  3 +++
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 723c656ebd28..d748d403bab1 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -228,6 +228,7 @@ static void nfs4_shutdown_client(struct nfs_client *clp)
kfree(clp->cl_serverowner);
kfree(clp->cl_serverscope);
kfree(clp->cl_implid);
+   kfree(clp->cl_owner_id);
 }
 
 void nfs4_free_client(struct nfs_client *clp)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 321044c183f5..db8456b4ecb8 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -4913,11 +4913,14 @@ static void nfs4_init_boot_verifier(const struct 
nfs_client *clp,
 }
 
 static unsigned int
-nfs4_init_nonuniform_client_string(const struct nfs_client *clp,
+nfs4_init_nonuniform_client_string(struct nfs_client *clp,
   char *buf, size_t len)
 {
unsigned int result;
 
+   if (clp->cl_owner_id != NULL)
+   return strlcpy(buf, clp->cl_owner_id, len);
+
rcu_read_lock();
result = scnprintf(buf, len, "Linux NFSv4.0 %s/%s %s",
clp->cl_ipaddr,
@@ -4926,24 +4929,32 @@ nfs4_init_nonuniform_client_string(const struct 
nfs_client *clp,
rpc_peeraddr2str(clp->cl_rpcclient,
RPC_DISPLAY_PROTO));
rcu_read_unlock();
+   clp->cl_owner_id = kstrdup(buf, GFP_KERNEL);
return result;
 }
 
 static unsigned int
-nfs4_init_uniform_client_string(const struct nfs_client *clp,
+nfs4_init_uniform_client_string(struct nfs_client *clp,
char *buf, size_t len)
 {
const char *nodename = clp->cl_rpcclient->cl_nodename;
+   unsigned int result;
+
+   if (clp->cl_owner_id != NULL)
+   return strlcpy(buf, clp->cl_owner_id, len);
 
if (nfs4_client_id_uniquifier[0] != '\0')
-   return scnprintf(buf, len, "Linux NFSv%u.%u %s/%s",
+   result = scnprintf(buf, len, "Linux NFSv%u.%u %s/%s",
clp->rpc_ops->version,
clp->cl_minorversion,
nfs4_client_id_uniquifier,
nodename);
-   return scnprintf(buf, len, "Linux NFSv%u.%u %s",
+   else
+   result = scnprintf(buf, len, "Linux NFSv%u.%u %s",
clp->rpc_ops->version, clp->cl_minorversion,
nodename);
+   clp->cl_owner_id = kstrdup(buf, GFP_KERNEL);
+   return result;
 }
 
 /*
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index fd249ab2718f..4ac99c07406a 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -74,6 +74,9 @@ struct nfs_client {
/* idmapper */
struct idmap *  cl_idmap;
 
+   /* Client owner identifier */
+   const char *cl_owner_id;
+
/* Our own IP address, as a null-terminated string.
 * This is used to generate the mv0 callback address.
 */
-- 
2.17.1





[PATCH 3.18 070/144] fbdev/broadsheetfb: fix memory leak

2018-11-08 Thread Greg Kroah-Hartman
3.18-stable review patch.  If anyone has any objections, please let me know.

--

[ Upstream commit ef6899cdc8608e2f018e590683f04bb04a069704 ]

static code analysis from cppcheck reports:

[drivers/video/fbdev/broadsheetfb.c:673]:
  (error) Memory leak: sector_buffer

sector_buffer is not being kfree'd on each call to
broadsheet_spiflash_rewrite_sector(), so free it.

Signed-off-by: Colin Ian King 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/broadsheetfb.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/broadsheetfb.c 
b/drivers/video/fbdev/broadsheetfb.c
index 8556264b16b7..235542f42da9 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -636,7 +636,7 @@ static int broadsheet_spiflash_rewrite_sector(struct 
broadsheetfb_par *par,
err = broadsheet_spiflash_read_range(par, start_sector_addr,
data_start_addr, sector_buffer);
if (err)
-   return err;
+   goto out;
}
 
/* now we copy our data into the right place in the sector buffer */
@@ -657,7 +657,7 @@ static int broadsheet_spiflash_rewrite_sector(struct 
broadsheetfb_par *par,
err = broadsheet_spiflash_read_range(par, tail_start_addr,
tail_len, sector_buffer + tail_start_addr);
if (err)
-   return err;
+   goto out;
}
 
/* if we got here we have the full sector that we want to rewrite. */
@@ -665,11 +665,13 @@ static int broadsheet_spiflash_rewrite_sector(struct 
broadsheetfb_par *par,
/* first erase the sector */
err = broadsheet_spiflash_erase_sector(par, start_sector_addr);
if (err)
-   return err;
+   goto out;
 
/* now write it */
err = broadsheet_spiflash_write_sector(par, start_sector_addr,
sector_buffer, sector_size);
+out:
+   kfree(sector_buffer);
return err;
 }
 
-- 
2.17.1





<    3   4   5   6   7   8   9   10   11   12   >