New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Wpointer-bool-conversion in drivers/net/ethernet/mellanox/mlx4/eq.c #86

Closed
shenki opened this Issue Sep 17, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@shenki
Member

shenki commented Sep 17, 2018

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of array 'eq->affinity_mask' will always
      evaluate to 'true' [-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
@nathanchance

This comment has been minimized.

Member

nathanchance commented Sep 21, 2018

Requires # CONFIG_CPUMASK_OFFSTACK is not set to be triggered.

Patch sent: https://lore.kernel.org/lkml/20180921094412.15547-1-natechancellor@gmail.com/

fengguang pushed a commit to 0day-ci/linux that referenced this issue Sep 22, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

fengguang pushed a commit to 0day-ci/linux that referenced this issue Sep 23, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
@nathanchance

This comment has been minimized.

@tpimh tpimh removed the low priority label Sep 25, 2018

Whissi pushed a commit to Whissi/linux-stable that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Whissi pushed a commit to Whissi/linux-stable that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Whissi pushed a commit to Whissi/linux-stable that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Whissi pushed a commit to Whissi/linux-stable that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dndrmwn added a commit to dndrmwn/sagit that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

psndna88 added a commit to psndna88/AGNi_pureMIUI that referenced this issue Oct 20, 2018

Merge kernel.org 4.4.162
ASoC: wm8804: Add ACPI support

[ Upstream commit 960cdd50ca9fdfeb82c2757107bcb7f93c8d7d41 ]

HID made of either Wolfson/CirrusLogic PCI ID + 8804 identifier.

This helps enumerate the HifiBerry Digi+ HAT boards on the Up2 platform.

The scripts at https://github.com/thesofproject/acpi-scripts can be
used to add the ACPI initrd overlays.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ASoC: sigmadsp: safeload should not have lower byte limit

[ Upstream commit 5ea752c6efdf5aa8a57aed816d453a8f479f1b0a ]

Fixed range in safeload conditional to allow safeload to up to 20 bytes,
without a lower limit.

Signed-off-by: Danny Smith <dannys@axis.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
selftests/efivarfs: add required kernel configs

[ Upstream commit 53cf59d6c0ad3edc4f4449098706a8f8986258b6 ]

add config file

Signed-off-by: Lei Yang <Lei.Yang@windriver.com>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mfd: omap-usb-host: Fix dts probe of children

[ Upstream commit 10492ee8ed9188d6d420e1f79b2b9bdbc0624e65 ]

It currently only works if the parent bus uses "simple-bus". We
currently try to probe children with non-existing compatible values.
And we're missing .probe.

I noticed this while testing devices configured to probe using ti-sysc
interconnect target module driver. For that we also may want to rebind
the driver, so let's remove __init and __exit.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sound: enable interrupt after dma buffer initialization

[ Upstream commit b61749a89f826eb61fc59794d9e4697bd246eb61 ]

In snd_hdac_bus_init_chip(), we enable interrupt before
snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
been acquired and irq handler uses the dma buffer, kernel may crash
when interrupt comes in.

Fix the problem by postponing enabling irq after dma buffer
initialization. And warn once on null dma buffer pointer during the
initialization.

Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Yu Zhao <yuzhao@google.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stmmac: fix valid numbers of unicast filter entries

[ 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 <neidhard.kim@lge.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: macb: disable scatter-gather for macb on sama5d3

[ Upstream commit eb4ed8e2d7fecb5f40db38e4498b9ee23cddf196 ]

Create a new configuration for the sama5d3-macb new compatibility string.
This configuration disables scatter-gather because we experienced lock down
of the macb interface of this particular SoC under very high load.

Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: at91: add new compatibility string for macb on sama5d3

[ Upstream commit 321cc359d899a8e988f3725d87c18a628e1cc624 ]

We need this new compatibility string as we experienced different behavior
for this 10/100Mbits/s macb interface on this particular SoC.
Backward compatibility is preserved as we keep the alternative strings.

Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7

[ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]

A wrong register bit was examinated for checking SDMA status so it reports
false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
bit.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Amber Lin <Amber.Lin@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ext4: add corruption check in ext4_xattr_set_entry()

commit 5369a762c882c0b6e9599e4ebbb3a9ba9eee7e2d upstream.

In theory this should have been caught earlier when the xattr list was
verified, but in case it got missed, it's simple enough to add check
to make sure we don't overrun the xattr buffer.

This addresses CVE-2018-10879.

https://bugzilla.kernel.org/show_bug.cgi?id=200001

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
[bwh: Backported to 3.16:
 - Add inode parameter to ext4_xattr_set_entry() and update callers
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[adjusted for 4.4 context]
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm/vmstat.c: fix outdated vmstat_text

commit 28e2c4bb99aa40f9d5f07ac130cbc4da0ea93079 upstream.

7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely") removed the
VMACACHE_FULL_FLUSHES statistics, but didn't remove the corresponding
entry in vmstat_text.  This causes an out-of-bounds access in
vmstat_show().

Luckily this only affects kernels with CONFIG_DEBUG_VM_VMACACHE=y, which
is probably very rare.

Link: http://lkml.kernel.org/r/20181001143138.95119-1-jannh@google.com
Fixes: 7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely")
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Roman Gushchin <guro@fb.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Kemi Wang <kemi.wang@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mach64: detect the dot clock divider correctly on sparc

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 <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf script python: Fix export-to-postgresql.py occasional failure

commit 25e11700b54c7b6b5ebfc4361981dae12299557b upstream.

Occasional export failures were found to be caused by truncating 64-bit
pointers to 32-bits. Fix by explicitly setting types for all ctype
arguments and results.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180911114504.28516-2-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: i2c-scmi: fix for i2c_smbus_write_block_data

commit 08d9db00fe0e300d6df976e6c294f974988226dd upstream.

The i2c-scmi driver crashes when the SMBus Write Block transaction is
executed:

WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0
 Call Trace:
  ? get_page_from_freelist+0x49d/0x11f0
  ? alloc_pages_current+0x6a/0xe0
  ? new_slab+0x499/0x690
  __alloc_pages_nodemask+0x265/0x280
  alloc_pages_current+0x6a/0xe0
  kmalloc_order+0x18/0x40
  kmalloc_order_trace+0x24/0xb0
  ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c
  __kmalloc+0x203/0x220
  acpi_os_allocate_zeroed+0x34/0x36
  acpi_ut_copy_eobject_to_iobject+0x266/0x31e
  acpi_evaluate_object+0x166/0x3b2
  acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi]
  i2c_smbus_xfer+0xda/0x370
  i2cdev_ioctl_smbus+0x1bd/0x270
  i2cdev_ioctl+0xaa/0x250
  do_vfs_ioctl+0xa4/0x600
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x73/0x130
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)

This problem occurs because the length of ACPI Buffer object is not
defined/initialized in the code before a corresponding ACPI method is
called. The obvious patch below fixes this issue.

Signed-off-by: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
Acked-by: Viktor Krasnov <vkrasnov@dev.rtsoft.ru>
Acked-by: Michael Brunner <Michael.Brunner@kontron.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Don't print a warning when setting link state for disabled ports

commit 1208d8a84fdcae6b395c57911cdf907450d30e70 upstream.

When disabling a USB3 port the hub driver will set the port link state to
U3 to prevent "ejected" or "safely removed" devices that are still
physically connected from immediately re-enumerating.

If the device was really unplugged, then error messages were printed
as the hub tries to set the U3 link state for a port that is no longer
enabled.

xhci-hcd ee000000.usb: Cannot set link state.
usb usb8-port1: cannot disable (err = -32)

Don't print error message in xhci-hub if hub tries to set port link state
for a disabled port. Return -ENODEV instead which also silences hub driver.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Ross Zwisler <zwisler@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jffs2: return -ERANGE when xattr buffer is too small

When a file have multiple xattrs and the passed buffer is
smaller than the required size, jffs2_listxattr() should
return -ERANGE instead of continue, else Oops may occur
due to memory corruption.

Also remove the unnecessary check ("rc < 0"), because
xhandle->list(...) will not return an error number.

Spotted by generic/377 in xfstests-dev.

NB: The problem had been fixed by commit 764a5c6b1fa4 ("xattr
handlers: Simplify list operation") in v4.5-rc1, but the
modification in that commit may be too much because it modifies
all file-systems which implement xattr, so I create a single
patch for jffs2 to fix the problem.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bnxt_en: Fix TX timeout during netpoll.

[ Upstream commit 73f21c653f930f438d53eed29b5e4c65c8a0f906 ]

The current netpoll implementation in the bnxt_en driver has problems
that may miss TX completion events.  bnxt_poll_work() in effect is
only handling at most 1 TX packet before exiting.  In addition,
there may be in flight TX completions that ->poll() may miss even
after we fix bnxt_poll_work() to handle all visible TX completions.
netpoll may not call ->poll() again and HW may not generate IRQ
because the driver does not ARM the IRQ when the budget (0 for netpoll)
is reached.

We fix it by handling all TX completions and to always ARM the IRQ
when we exit ->poll() with 0 budget.

Also, the logic to ACK the completion ring in case it is almost filled
with TX completions need to be adjusted to take care of the 0 budget
case, as discussed with Eric Dumazet <edumazet@google.com>

Reported-by: Song Liu <songliubraving@fb.com>
Reviewed-by: Song Liu <songliubraving@fb.com>
Tested-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bonding: avoid possible dead-lock

[ Upstream commit d4859d749aa7090ffb743d15648adb962a1baeae ]

Syzkaller reported this on a slightly older kernel but it's still
applicable to the current kernel -

======================================================
WARNING: possible circular locking dependency detected
4.18.0-next-20180823+ #46 Not tainted
------------------------------------------------------
syz-executor4/26841 is trying to acquire lock:
00000000dd41ef48 ((wq_completion)bond_dev->name){+.+.}, at: flush_workqueue+0x2db/0x1e10 kernel/workqueue.c:2652

but task is already holding lock:
00000000768ab431 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
00000000768ab431 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4708

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (rtnl_mutex){+.+.}:
       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
       rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
       bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
       bond_netdev_notify_work+0x44/0xd0 drivers/net/bonding/bond_main.c:1320
       process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
       worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
       kthread+0x35a/0x420 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

-> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
       process_one_work+0xc0b/0x1aa0 kernel/workqueue.c:2129
       worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
       kthread+0x35a/0x420 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

-> #0 ((wq_completion)bond_dev->name){+.+.}:
       lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
       flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
       drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
       destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
       __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
       bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
       register_netdevice+0x337/0x1100 net/core/dev.c:8410
       bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
       rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:632
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
       __sys_sendmsg+0x11d/0x290 net/socket.c:2153
       __do_sys_sendmsg net/socket.c:2162 [inline]
       __se_sys_sendmsg net/socket.c:2160 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

Chain exists of:
  (wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work) --> rtnl_mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(rtnl_mutex);
                               lock((work_completion)(&(&nnw->work)->work));
                               lock(rtnl_mutex);
  lock((wq_completion)bond_dev->name);

 *** DEADLOCK ***

1 lock held by syz-executor4/26841:

stack backtrace:
CPU: 1 PID: 26841 Comm: syz-executor4 Not tainted 4.18.0-next-20180823+ #46
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_circular_bug.isra.34.cold.55+0x1bd/0x27d kernel/locking/lockdep.c:1222
 check_prev_add kernel/locking/lockdep.c:1862 [inline]
 check_prevs_add kernel/locking/lockdep.c:1975 [inline]
 validate_chain kernel/locking/lockdep.c:2416 [inline]
 __lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3412
 lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
 flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
 drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
 destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
 __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
 bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
 register_netdevice+0x337/0x1100 net/core/dev.c:8410
 bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
 rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
 rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
 netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
 netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
 sock_sendmsg_nosec net/socket.c:622 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:632
 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
 __sys_sendmsg+0x11d/0x290 net/socket.c:2153
 __do_sys_sendmsg net/socket.c:2162 [inline]
 __se_sys_sendmsg net/socket.c:2160 [inline]
 __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
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:00007f2df20a5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2df20a66d4 RCX: 0000000000457089
RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
RBP: 0000000000930140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d40b8 R14: 00000000004c8ad8 R15: 0000000000000001

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ip6_tunnel: be careful when accessing the inner header

[ Upstream commit 76c0ddd8c3a683f6e2c6e60e11dc1a1558caf4bc ]

the ip6 tunnel xmit ndo assumes that the processed skb always
contains an ip[v6] header, but syzbot has found a way to send
frames that fall short of this assumption, leading to the following splat:

BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307
[inline]
BUG: KMSAN: uninit-value in ip6_tnl_start_xmit+0x7d2/0x1ef0
net/ipv6/ip6_tunnel.c:1390
CPU: 0 PID: 4504 Comm: syz-executor558 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
  kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
  ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline]
  ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390
  __netdev_start_xmit include/linux/netdevice.h:4066 [inline]
  netdev_start_xmit include/linux/netdevice.h:4075 [inline]
  xmit_one net/core/dev.c:3026 [inline]
  dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042
  __dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557
  dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
  packet_snd net/packet/af_packet.c:2944 [inline]
  packet_sendmsg+0x7c70/0x8a30 net/packet/af_packet.c:2969
  sock_sendmsg_nosec net/socket.c:630 [inline]
  sock_sendmsg net/socket.c:640 [inline]
  ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
  __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
  SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
  SyS_sendmmsg+0x63/0x90 net/socket.c:2162
  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x441819
RSP: 002b:00007ffe58ee8268 EFLAGS: 00000213 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441819
RDX: 0000000000000002 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000402510
R13: 00000000004025a0 R14: 0000000000000000 R15: 0000000000000000

Uninit was created at:
  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
  kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
  kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
  kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
  slab_post_alloc_hook mm/slab.h:445 [inline]
  slab_alloc_node mm/slub.c:2737 [inline]
  __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
  __kmalloc_reserve net/core/skbuff.c:138 [inline]
  __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
  alloc_skb include/linux/skbuff.h:984 [inline]
  alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
  sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
  packet_alloc_skb net/packet/af_packet.c:2803 [inline]
  packet_snd net/packet/af_packet.c:2894 [inline]
  packet_sendmsg+0x6454/0x8a30 net/packet/af_packet.c:2969
  sock_sendmsg_nosec net/socket.c:630 [inline]
  sock_sendmsg net/socket.c:640 [inline]
  ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
  __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
  SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
  SyS_sendmmsg+0x63/0x90 net/socket.c:2162
  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

This change addresses the issue adding the needed check before
accessing the inner header.

The ipv4 side of the issue is apparently there since the ipv4 over ipv6
initial support, and the ipv6 side predates git history.

Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com
Tested-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ip_tunnel: be careful when accessing the inner header

[ 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 <xiyou.wangcong@gmail.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()

[ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]

Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
do not do it.

Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: ipv4: update fnhe_pmtu when first hop's MTU changes

[ Upstream commit af7d6cce53694a88d6a1bb60c9a239a6a5144459 ]

Since commit 5aad1de5ea2c ("ipv4: use separate genid for next hop
exceptions"), exceptions get deprecated separately from cached
routes. In particular, administrative changes don't clear PMTU anymore.

As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes
on PMTU of exceptions for MTU-less routes"), the PMTU discovered before
the local MTU change can become stale:
 - if the local MTU is now lower than the PMTU, that PMTU is now
   incorrect
 - if the local MTU was the lowest value in the path, and is increased,
   we might discover a higher PMTU

Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those
cases.

If the exception was locked, the discovered PMTU was smaller than the
minimal accepted PMTU. In that case, if the new local MTU is smaller
than the current PMTU, let PMTU discovery figure out if locking of the
exception is still needed.

To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU
notifier. By the time the notifier is called, dev->mtu has been
changed. This patch adds the old MTU as additional information in the
notifier structure, and a new call_netdevice_notifiers_u32() function.

Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/ipv6: Display all addresses in output of /proc/net/if_inet6

[ Upstream commit 86f9bd1ff61c413a2a251fa736463295e4e24733 ]

The backend handling for /proc/net/if_inet6 in addrconf.c doesn't properly
handle starting/stopping the iteration.  The problem is that at some point
during the iteration, an overflow is detected and the process is
subsequently stopped.  The item being shown via seq_printf() when the
overflow occurs is not actually shown, though.  When start() is
subsequently called to resume iterating, it returns the next item, and
thus the item that was being processed when the overflow occurred never
gets printed.

Alter the meaning of the private data member "offset".  Currently, when it
is not 0 (which only happens at the very beginning), "offset" represents
the next hlist item to be printed.  After this change, "offset" always
represents the current item.

This is also consistent with the private data member "bucket", which
represents the current bucket, and also the use of "pos" as defined in
seq_file.txt:
    The pos passed to start() will always be either zero, or the most
    recent pos used in the previous session.

Signed-off-by: Jeff Barnhill <0xeffeff@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
netlabel: check for IPV4MASK in addrinfo_get

[ Upstream commit f88b4c01b97e09535505cf3c327fdbce55c27f00 ]

netlbl_unlabel_addrinfo_get() assumes that if it finds the
NLBL_UNLABEL_A_IPV4ADDR attribute, it must also have the
NLBL_UNLABEL_A_IPV4MASK attribute as well. However, this is
not necessarily the case as the current checks in
netlbl_unlabel_staticadd() and friends are not sufficent to
enforce this.

If passed a netlink message with NLBL_UNLABEL_A_IPV4ADDR,
NLBL_UNLABEL_A_IPV6ADDR, and NLBL_UNLABEL_A_IPV6MASK attributes,
these functions will all call netlbl_unlabel_addrinfo_get() which
will then attempt dereference NULL when fetching the non-existent
NLBL_UNLABEL_A_IPV4MASK attribute:

Unable to handle kernel NULL pointer dereference at virtual address 0
Process unlab (pid: 31762, stack limit = 0xffffff80502d8000)
Call trace:
	netlbl_unlabel_addrinfo_get+0x44/0xd8
	netlbl_unlabel_staticremovedef+0x98/0xe0
	genl_rcv_msg+0x354/0x388
	netlink_rcv_skb+0xac/0x118
	genl_rcv+0x34/0x48
	netlink_unicast+0x158/0x1f0
	netlink_sendmsg+0x32c/0x338
	sock_sendmsg+0x44/0x60
	___sys_sendmsg+0x1d0/0x2a8
	__sys_sendmsg+0x64/0xb4
	SyS_sendmsg+0x34/0x4c
	el0_svc_naked+0x34/0x38
Code: 51001149 7100113f 540000a0 f9401508 (79400108)
---[ end trace f6438a488e737143 ]---
Kernel panic - not syncing: Fatal exception

Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/usb: cancel pending work when unbinding smsc75xx

[ Upstream commit f7b2a56e1f3dcbdb4cf09b2b63e859ffe0e09df8 ]

Cancel pending work before freeing smsc75xx private data structure
during binding. This fixes the following crash in the driver:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
IP: mutex_lock+0x2b/0x3f
<snipped>
Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
task: ffff8caa83e85700 task.stack: ffff948b80518000
RIP: 0010:mutex_lock+0x2b/0x3f
<snipped>
Call Trace:
 smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
 process_one_work+0x18d/0x2fc
 worker_thread+0x1a2/0x269
 ? pr_cont_work+0x58/0x58
 kthread+0xfa/0x10a
 ? pr_cont_work+0x58/0x58
 ? rcu_read_unlock_sched_notrace+0x48/0x48
 ret_from_fork+0x22/0x40

Signed-off-by: Yu Zhao <yuzhao@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qlcnic: fix Tx descriptor corruption on 82xx devices

[ Upstream commit c333fa0c4f220f8f7ea5acd6b0ebf3bf13fd684d ]

In regular NIC transmission flow, driver always configures MAC using
Tx queue zero descriptor as a part of MAC learning flow.
But with multi Tx queue supported NIC, regular transmission can occur on
any non-zero Tx queue and from that context it uses
Tx queue zero descriptor to configure MAC, at the same time TX queue
zero could be used by another CPU for regular transmission
which could lead to Tx queue zero descriptor corruption and cause FW
abort.

This patch fixes this in such a way that driver always configures
learned MAC address from the same Tx queue which is used for
regular transmission.

Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
team: Forbid enslaving team device to itself

[ 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____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868

but task is already holding lock:
(____ptrval____) (&team->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(&team->lock);
  lock(&team->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____) (&team->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:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000

Fixes: 87002b03baab ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: mvpp2: Extract the correct ethtype from the skb for tx csum offload

[ Upstream commit 35f3625c21852ad839f20c91c7d81c4c1101e207 ]

When offloading the L3 and L4 csum computation on TX, we need to extract
the l3_proto from the ethtype, independently of the presence of a vlan
tag.

The actual driver uses skb->protocol as-is, resulting in packets with
the wrong L4 checksum being sent when there's a vlan tag in the packet
header and checksum offloading is enabled.

This commit makes use of vlan_protocol_get() to get the correct ethtype
regardless the presence of a vlan tag.

Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: systemport: Fix wake-up interrupt race during resume

[ Upstream commit 45ec318578c0c22a11f5b9927d064418e1ab1905 ]

The AON_PM_L2 is normally used to trigger and identify the source of a
wake-up event. Since the RX_SYS clock is no longer turned off, we also
have an interrupt being sent to the SYSTEMPORT INTRL_2_0 controller, and
that interrupt remains active up until the magic packet detector is
disabled which happens much later during the driver resumption.

The race happens if we have a CPU that is entering the SYSTEMPORT
INTRL2_0 handler during resume, and another CPU has managed to clear the
wake-up interrupt during bcm_sysport_resume_from_wol(). In that case, we
have the first CPU stuck in the interrupt handler with an interrupt
cause that has been cleared under its feet, and so we keep returning
IRQ_NONE and we never make any progress.

This was not a problem before because we would always turn off the
RX_SYS clock during WoL, so the SYSTEMPORT INTRL2_0 would also be turned
off as well, thus not latching the interrupt.

The fix is to make sure we do not enable either the MPD or
BRCM_TAG_MATCH interrupts since those are redundant with what the
AON_PM_L2 interrupt controller already processes and they would cause
such a race to occur.

Fixes: bb9051a2b230 ("net: systemport: Add support for WAKE_FILTER")
Fixes: 83e82f4c706b ("net: systemport: add Wake-on-LAN support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096

[ Upstream commit 0e1d6eca5113858ed2caea61a5adc03c595f6096 ]

We have an impressive number of syzkaller bugs that are linked
to the fact that syzbot was able to create a networking device
with millions of TX (or RX) queues.

Let's limit the number of RX/TX queues to 4096, this really should
cover all known cases.

A separate patch will add various cond_resched() in the loops
handling sysfs entries at device creation and dismantle.

Tested:

lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap
RTNETLINK answers: Invalid argument

lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap

real	0m0.180s
user	0m0.000s
sys	0m0.107s

Fixes: 76ff5cc91935 ("rtnl: allow to specify number of rx and tx queues on device creation")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch

commit 5a5fbdc0e3f1159a734f1890da60fce70e98271d upstream.

It is now equal to use_eager_fpu(), which simply tests a cpufeature bit.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/fpu: Remove use_eager_fpu()

commit c592b57347069abfc0dcad3b3a302cf882602597 upstream.

This removes all the obvious code paths that depend on lazy FPU mode.
It shouldn't change the generated code at all.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: pbonzini@redhat.com
Link: http://lkml.kernel.org/r/1475627678-20788-5-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/fpu: Remove struct fpu::counter

commit 3913cc3507575273beb165a5e027a081913ed507 upstream.

With the lazy FPU code gone, we no longer use the counter field
in struct fpu for anything. Get rid it.

Signed-off-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: pbonzini@redhat.com
Link: http://lkml.kernel.org/r/1475627678-20788-6-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/fpu: Finish excising 'eagerfpu'

commit e63650840e8b053aa09ad934877e87e9941ed135 upstream.

Now that eagerfpu= is gone, remove it from the docs and some
comments.  Also sync the changes to tools/.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/cf430dd4481d41280e93ac6cf0def1007a67fc8e.1476740397.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: af9035: prevent buffer overflow on write

[ Upstream commit 312f73b648626a0526a3aceebb0a3192aaba05ce ]

When less than 3 bytes are written to the device, memcpy is called with
negative array size which leads to buffer overflow and kernel panic. This
patch adds a condition and returns -EOPNOTSUPP instead.
Fixes bugzilla issue 64871

[mchehab+samsung@kernel.org: fix a merge conflict and changed the
 condition to match the patch's comment, e. g. len == 3 could
 also be valid]
Signed-off-by: Jozef Balga <jozef.balga@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs

[ Upstream commit 3b7d96a0dbb6b630878597a1838fc39f808b761b ]

The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
add the flag for all the other SoCs.

Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: atakbd - fix Atari keymap

[ Upstream commit 9e62df51be993035c577371ffee5477697a56aad ]

Fix errors in Atari keymap (mostly in keypad, help and undo keys).

Patch provided on debian-68k ML by Andreas Schwab <schwab@linux-m68k.org>,
keymap array size and unhandled scancode limit adjusted to 0x73 by me.

Tested-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: atakbd - fix Atari CapsLock behaviour

[ Upstream commit 52d2c7bf7c90217fbe875d2d76f310979c48eb83 ]

The CapsLock key on Atari keyboards is not a toggle, it does send the
normal make and break scancodes.

Drop the CapsLock toggle handling code, which did cause the CapsLock
key to merely act as a Shift key.

Tested-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/mlx4: Use cpumask_available for eq->affinity_mask

[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: https://github.com/ClangBuiltLinux/linux/issues/86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
powerpc/tm: Fix userspace r13 corruption

[ Upstream commit cf13435b730a502e814c63c84d93db131e563f5f ]

When we treclaim we store the userspace checkpointed r13 to a scratch
SPR and then later save the scratch SPR to the user thread struct.

Unfortunately, this doesn't work as accessing the user thread struct
can take an SLB fault and the SLB fault handler will write the same
scratch SPRG that now contains the userspace r13.

To fix this, we store r13 to the kernel stack (which can't fault)
before we access the user thread struct.

Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen
as a random userspace segfault with r13 looking like a kernel address.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
powerpc/tm: Avoid possible userspace r1 corruption on reclaim

[ Upstream commit 96dc89d526ef77604376f06220e3d2931a0bfd58 ]

Current we store the userspace r1 to PACATMSCRATCH before finally
saving it to the thread struct.

In theory an exception could be taken here (like a machine check or
SLB miss) that could write PACATMSCRATCH and hence corrupt the
userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but
others do.

We've never actually seen this happen but it's theoretically
possible. Either way, the code is fragile as it is.

This patch saves r1 to the kernel stack (which can't fault) before we
turn MSR[RI] back on. PACATMSCRATCH is still used but only with
MSR[RI] off. We then copy r1 from the kernel stack to the thread
struct once we have MSR[RI] back on.

Suggested-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARC: build: Get rid of toolchain check

commit 615f64458ad890ef94abc879a66d8b27236e733a upstream.

This check is very naive: we simply test if GCC invoked without
"-mcpu=XXX" has ARC700 define set. In that case we think that GCC
was built with "--with-cpu=arc700" and has libgcc built for ARC700.

Otherwise if ARC700 is not defined we think that everythng was built
for ARCv2.

But in reality our life is much more interesting.

1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
   it may generate code for any ARC core).

2. libgcc might be built with explicitly specified "--mcpu=YYY"

That's exactly what happens in case of multilibbed toolchains:
 - GCC is configured with default settings
 - All the libs built for many different CPU flavors

I.e. that check gets in the way of usage of multilibbed
toolchains. And even non-multilibbed toolchains are affected.
OpenEmbedded also builds GCC without "--with-cpu" because
each and every target component later is compiled with explicitly
set "-mcpu=ZZZ".

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: gadget: serial: fix oops when data rx'd after close

commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream.

When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack of
gadget serial device to TTY association (i.e. a NULL pointer dereference).

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers: hv: utils: Invoke the poll function after handshake

commit 2d0c3b5ad739697a68dc8a444f5b9f4817cf8f8f upstream.

When the handshake with daemon is complete, we should poll the channel since
during the handshake, we will not be processing any messages. This is a
potential bug if the host is waiting for a response from the guest.
I would like to thank Dexuan for pointing this out.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers: hv: util: Pass the channel information during the init call

commit b9830d120cbe155863399f25eaef6aa8353e767f upstream.

Pass the channel information to the util drivers that need to defer
reading the channel while they are processing a request. This would address
the following issue reported by Vitaly:

Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
interrupt context") removed direct *_transaction.state = HVUTIL_READY
assignments from *_handle_handshake() functions introducing the following
race: if a userspace daemon connects before we get first non-negotiation
request from the server hv_poll_channel() won't set transaction state to
HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
the first real request from the server.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers: hv: kvp: fix IP Failover

commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc upstream.

Hyper-V VMs can be replicated to another hosts and there is a feature to
set different IP for replicas, it is called 'Failover TCP/IP'. When
such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
as we finish negotiation procedure. The problem is that it can happen (and
it actually happens) before userspace daemon connects and we reply with
HV_E_FAIL to the message. As there are no repetitions we fail to set the
requested IP.

Solve the issue by postponing our reply to the negotiation message till
userspace daemon is connected. We can't wait too long as there is a
host-side timeout (cca. 75 seconds) and if we fail to reply in this time
frame the whole KVP service will become inactive. The solution is not
ideal - if it takes userspace daemon more than 60 seconds to connect
IP Failover will still fail but I don't see a solution with our current
separation between kernel and userspace parts.

Other two modules (VSS and FCOPY) don't require such delay, leave them
untouched.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
HV: properly delay KVP packets when negotiation is in progress

commit a3ade8cc474d848676278660e65f5af1e9e094d9 upstream.

The host may send multiple negotiation packets
(due to timeout) before the KVP user-mode daemon
is connected. KVP user-mode daemon is connected.
We need to defer processing those packets
until the daemon is negotiated and connected.
It's okay for guest to respond
to all negotiation packets.

In addition, the host may send multiple staged
KVP requests as soon as negotiation is done.
We need to properly process those packets using one
tasklet for exclusive access to ring buffer.

This patch is based on the work of
Nick Meier <Nick.Meier@microsoft.com>.

The above is the original changelog of
a3ade8cc474d ("HV: properly delay KVP packets when negotiation is in progress"

Here I re-worked the original patch because the mainline version
can't work for the linux-4.4.y branch, on which channel->callback_event
doesn't exist yet. In the mainline, channel->callback_event was added by:
631e63a9f346 ("vmbus: change to per channel tasklet"). Here we don't want
to backport it to v4.4, as it requires extra supporting changes and fixes,
which are unnecessary as to the KVP bug we're trying to resolve.

NOTE: before this patch is used, we should cherry-pick the other related
3 patches from the mainline first:

The background of this backport request is that: recently Wang Jian reported
some KVP issues: https://github.com/LIS/lis-next/issues/593:
e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes
if the hv_kvp_daemon doesn't timely start, the host may not be able to query
the VM's IP address via KVP.

Reported-by: Wang Jian <jianjian.wang1@gmail.com>
Tested-by: Wang Jian <jianjian.wang1@gmail.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 4.4.162

Signed-off-by: Parvinder Singh <psndna88@gmail.com>

rajadeja added a commit to ArrowOS-Devices/android_kernel_xiaomi_whyred that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

freeza-inc added a commit to freeza-inc/bm-galaxy-note9-exynos that referenced this issue Oct 20, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rahulsnair added a commit to moto-SDM660/android_kernel_motorola_sdm660 that referenced this issue Oct 21, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Alucard24 added a commit to Alucard24/Alucard-Kernel-cheeseburger that referenced this issue Oct 23, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

archie9211 added a commit to archie9211/android_kernel_asus_sdm660 that referenced this issue Oct 23, 2018

Linux Stable Upstream to 4.4.162
commit 94d5e769ac932b000e605e78819131d0301e1690
Merge: 7484d008b46e 24c2342b8e51
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sat Oct 20 08:46:10 2018 -0700

    Merge 4.4.162 into kernel.lnx.4.4.r27-rel

    Changes in 4.4.162: (48 commits)
            ASoC: wm8804: Add ACPI support
            ASoC: sigmadsp: safeload should not have lower byte limit
            selftests/efivarfs: add required kernel configs
            mfd: omap-usb-host: Fix dts probe of children
            sound: enable interrupt after dma buffer initialization
            stmmac: fix valid numbers of unicast filter entries
            net: macb: disable scatter-gather for macb on sama5d3
            ARM: dts: at91: add new compatibility string for macb on sama5d3
            drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
            ext4: add corruption check in ext4_xattr_set_entry()
            mm/vmstat.c: fix outdated vmstat_text
            mach64: detect the dot clock divider correctly on sparc
            perf script python: Fix export-to-postgresql.py occasional failure
            i2c: i2c-scmi: fix for i2c_smbus_write_block_data
            xhci: Don't print a warning when setting link state for disabled ports
            jffs2: return -ERANGE when xattr buffer is too small
            bnxt_en: Fix TX timeout during netpoll.
            bonding: avoid possible dead-lock
            ip6_tunnel: be careful when accessing the inner header
            ip_tunnel: be careful when accessing the inner header
            ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()
            net: ipv4: update fnhe_pmtu when first hop's MTU changes
            net/ipv6: Display all addresses in output of /proc/net/if_inet6
            netlabel: check for IPV4MASK in addrinfo_get
            net/usb: cancel pending work when unbinding smsc75xx
            qlcnic: fix Tx descriptor corruption on 82xx devices
            team: Forbid enslaving team device to itself
            net: mvpp2: Extract the correct ethtype from the skb for tx csum offload
            net: systemport: Fix wake-up interrupt race during resume
            rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096
            KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch
            x86/fpu: Remove use_eager_fpu()
            x86/fpu: Remove struct fpu::counter
            x86/fpu: Finish excising 'eagerfpu'
            media: af9035: prevent buffer overflow on write
            clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs
            Input: atakbd - fix Atari keymap
            Input: atakbd - fix Atari CapsLock behaviour
            net/mlx4: Use cpumask_available for eq->affinity_mask
            powerpc/tm: Fix userspace r13 corruption
            powerpc/tm: Avoid possible userspace r1 corruption on reclaim
            ARC: build: Get rid of toolchain check
            usb: gadget: serial: fix oops when data rx'd after close
            Drivers: hv: utils: Invoke the poll function after handshake
            Drivers: hv: util: Pass the channel information during the init call
            Drivers: hv: kvp: fix IP Failover
            HV: properly delay KVP packets when negotiation is in progress
            Linux 4.4.162

    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

commit 24c2342b8e51ab3185e68470709904150a1e3ee0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 20 09:52:38 2018 +0200

    Linux 4.4.162

commit e34c69f2094a07b0565feb444dff58a53ccf0958
Author: Long Li <longli@microsoft.com>
Date:   Sun Apr 30 16:21:19 2017 -0700

    HV: properly delay KVP packets when negotiation is in progress

    commit a3ade8cc474d848676278660e65f5af1e9e094d9 upstream.

    The host may send multiple negotiation packets
    (due to timeout) before the KVP user-mode daemon
    is connected. KVP user-mode daemon is connected.
    We need to defer processing those packets
    until the daemon is negotiated and connected.
    It's okay for guest to respond
    to all negotiation packets.

    In addition, the host may send multiple staged
    KVP requests as soon as negotiation is done.
    We need to properly process those packets using one
    tasklet for exclusive access to ring buffer.

    This patch is based on the work of
    Nick Meier <Nick.Meier@microsoft.com>.

    The above is the original changelog of
    a3ade8cc474d ("HV: properly delay KVP packets when negotiation is in progress"

    Here I re-worked the original patch because the mainline version
    can't work for the linux-4.4.y branch, on which channel->callback_event
    doesn't exist yet. In the mainline, channel->callback_event was added by:
    631e63a9f346 ("vmbus: change to per channel tasklet"). Here we don't want
    to backport it to v4.4, as it requires extra supporting changes and fixes,
    which are unnecessary as to the KVP bug we're trying to resolve.

    NOTE: before this patch is used, we should cherry-pick the other related
    3 patches from the mainline first:

    The background of this backport request is that: recently Wang Jian reported
    some KVP issues: https://github.com/LIS/lis-next/issues/593:
    e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes
    if the hv_kvp_daemon doesn't timely start, the host may not be able to query
    the VM's IP address via KVP.

    Reported-by: Wang Jian <jianjian.wang1@gmail.com>
    Tested-by: Wang Jian <jianjian.wang1@gmail.com>
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Long Li <longli@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43fea648af714b0578f20bfadfec18858e67430d
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Sat Apr 30 19:21:33 2016 -0700

    Drivers: hv: kvp: fix IP Failover

    commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc upstream.

    Hyper-V VMs can be replicated to another hosts and there is a feature to
    set different IP for replicas, it is called 'Failover TCP/IP'. When
    such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
    as we finish negotiation procedure. The problem is that it can happen (and
    it actually happens) before userspace daemon connects and we reply with
    HV_E_FAIL to the message. As there are no repetitions we fail to set the
    requested IP.

    Solve the issue by postponing our reply to the negotiation message till
    userspace daemon is connected. We can't wait too long as there is a
    host-side timeout (cca. 75 seconds) and if we fail to reply in this time
    frame the whole KVP service will become inactive. The solution is not
    ideal - if it takes userspace daemon more than 60 seconds to connect
    IP Failover will still fail but I don't see a solution with our current
    separation between kernel and userspace parts.

    Other two modules (VSS and FCOPY) don't require such delay, leave them
    untouched.

    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaee7976cf2af79c294ab41d651c0e52488ca868
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Fri Feb 26 15:13:19 2016 -0800

    Drivers: hv: util: Pass the channel information during the init call

    commit b9830d120cbe155863399f25eaef6aa8353e767f upstream.

    Pass the channel information to the util drivers that need to defer
    reading the channel while they are processing a request. This would address
    the following issue reported by Vitaly:

    Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
    interrupt context") removed direct *_transaction.state = HVUTIL_READY
    assignments from *_handle_handshake() functions introducing the following
    race: if a userspace daemon connects before we get first non-negotiation
    request from the server hv_poll_channel() won't set transaction state to
    HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
    the first real request from the server.

    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f91b8b1fd69c57764ffd404e33f565aa75357a1e
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Mon Dec 14 16:01:57 2015 -0800

    Drivers: hv: utils: Invoke the poll function after handshake

    commit 2d0c3b5ad739697a68dc8a444f5b9f4817cf8f8f upstream.

    When the handshake with daemon is complete, we should poll the channel since
    during the handshake, we will not be processing any messages. This is a
    potential bug if the host is waiting for a response from the guest.
    I would like to thank Dexuan for pointing this out.

    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68a318670c663cac76ac359784d2f58d8d19cfc7
Author: Stephen Warren <swarren@nvidia.com>
Date:   Wed Aug 16 14:30:10 2017 -0600

    usb: gadget: serial: fix oops when data rx'd after close

    commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream.

    When the gadget serial device has no associated TTY, do not pass any
    received data into the TTY layer for processing; simply drop it instead.
    This prevents the TTY layer from calling back into the gadget serial
    driver, which will then crash in e.g. gs_write_room() due to lack of
    gadget serial device to TTY association (i.e. a NULL pointer dereference).

    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 466dda64e443101da297bd26e911df8e0aa6576c
Author: Alexey Brodkin <abrodkin@synopsys.com>
Date:   Thu Sep 13 23:24:28 2018 +0300

    ARC: build: Get rid of toolchain check

    commit 615f64458ad890ef94abc879a66d8b27236e733a upstream.

    This check is very naive: we simply test if GCC invoked without
    "-mcpu=XXX" has ARC700 define set. In that case we think that GCC
    was built with "--with-cpu=arc700" and has libgcc built for ARC700.

    Otherwise if ARC700 is not defined we think that everythng was built
    for ARCv2.

    But in reality our life is much more interesting.

    1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
       it may generate code for any ARC core).

    2. libgcc might be built with explicitly specified "--mcpu=YYY"

    That's exactly what happens in case of multilibbed toolchains:
     - GCC is configured with default settings
     - All the libs built for many different CPU flavors

    I.e. that check gets in the way of usage of multilibbed
    toolchains. And even non-multilibbed toolchains are affected.
    OpenEmbedded also builds GCC without "--with-cpu" because
    each and every target component later is compiled with explicitly
    set "-mcpu=ZZZ".

    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a51c55493c039e5579d9d87bc7601ae119b6efb
Author: Michael Neuling <mikey@neuling.org>
Date:   Tue Sep 25 19:36:47 2018 +1000

    powerpc/tm: Avoid possible userspace r1 corruption on reclaim

    [ Upstream commit 96dc89d526ef77604376f06220e3d2931a0bfd58 ]

    Current we store the userspace r1 to PACATMSCRATCH before finally
    saving it to the thread struct.

    In theory an exception could be taken here (like a machine check or
    SLB miss) that could write PACATMSCRATCH and hence corrupt the
    userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but
    others do.

    We've never actually seen this happen but it's theoretically
    possible. Either way, the code is fragile as it is.

    This patch saves r1 to the kernel stack (which can't fault) before we
    turn MSR[RI] back on. PACATMSCRATCH is still used but only with
    MSR[RI] off. We then copy r1 from the kernel stack to the thread
    struct once we have MSR[RI] back on.

    Suggested-by: Breno Leitao <leitao@debian.org>
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6939b3b00c124d1b88c3e1c57d1f18e426df2fa3
Author: Michael Neuling <mikey@neuling.org>
Date:   Mon Sep 24 17:27:04 2018 +1000

    powerpc/tm: Fix userspace r13 corruption

    [ Upstream commit cf13435b730a502e814c63c84d93db131e563f5f ]

    When we treclaim we store the userspace checkpointed r13 to a scratch
    SPR and then later save the scratch SPR to the user thread struct.

    Unfortunately, this doesn't work as accessing the user thread struct
    can take an SLB fault and the SLB fault handler will write the same
    scratch SPRG that now contains the userspace r13.

    To fix this, we store r13 to the kernel stack (which can't fault)
    before we access the user thread struct.

    Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen
    as a random userspace segfault with r13 looking like a kernel address.

    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Reviewed-by: Breno Leitao <leitao@debian.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d02fdd080d2435101f09d02e843eae17606fb59
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Sep 21 02:44:12 2018 -0700

    net/mlx4: Use cpumask_available for eq->affinity_mask

    [ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

    Clang warns that the address of a pointer will always evaluated as true
    in a boolean context:

    drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
    array 'eq->affinity_mask' will always evaluate to 'true'
    [-Wpointer-bool-conversion]
            if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
                ~~~~~^~~~~~~~~~~~~
    1 warning generated.

    Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
    helper cpumask_available()"), which does the proper checking and avoids
    this warning.

    Link: https://github.com/ClangBuiltLinux/linux/issues/86
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6df8eb6ae2295ad0fa830d943585d9eb69785074
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Mon Sep 17 15:27:49 2018 -0700

    Input: atakbd - fix Atari CapsLock behaviour

    [ Upstream commit 52d2c7bf7c90217fbe875d2d76f310979c48eb83 ]

    The CapsLock key on Atari keyboards is not a toggle, it does send the
    normal make and break scancodes.

    Drop the CapsLock toggle handling code, which did cause the CapsLock
    key to merely act as a Shift key.

    Tested-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d200ea29009ebd4eb8e932e364d565c4c1a5b837
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Mon Sep 17 12:43:34 2018 -0700

    Input: atakbd - fix Atari keymap

    [ Upstream commit 9e62df51be993035c577371ffee5477697a56aad ]

    Fix errors in Atari keymap (mostly in keypad, help and undo keys).

    Patch provided on debian-68k ML by Andreas Schwab <schwab@linux-m68k.org>,
    keymap array size and unhandled scancode limit adjusted to 0x73 by me.

    Tested-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be7e497bf0908851c8744d30c513655b47e386bf
Author: Keerthy <j-keerthy@ti.com>
Date:   Wed Aug 8 18:44:59 2018 +0530

    clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs

    [ Upstream commit 3b7d96a0dbb6b630878597a1838fc39f808b761b ]

    The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
    add the flag for all the other SoCs.

    Reported-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a585d445050f16030b372ada1f4ce076de27833
Author: Jozef Balga <jozef.balga@gmail.com>
Date:   Tue Aug 21 05:01:04 2018 -0400

    media: af9035: prevent buffer overflow on write

    [ Upstream commit 312f73b648626a0526a3aceebb0a3192aaba05ce ]

    When less than 3 bytes are written to the device, memcpy is called with
    negative array size which leads to buffer overflow and kernel panic. This
    patch adds a condition and returns -EOPNOTSUPP instead.
    Fixes bugzilla issue 64871

    [mchehab+samsung@kernel.org: fix a merge conflict and changed the
     condition to match the patch's comment, e. g. len == 3 could
     also be valid]
    Signed-off-by: Jozef Balga <jozef.balga@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e7ef8fc8001589339083872f3b6260734cc0e76
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Oct 17 14:40:11 2016 -0700

    x86/fpu: Finish excising 'eagerfpu'

    commit e63650840e8b053aa09ad934877e87e9941ed135 upstream.

    Now that eagerfpu= is gone, remove it from the docs and some
    comments.  Also sync the changes to tools/.

    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/cf430dd4481d41280e93ac6cf0def1007a67fc8e.1476740397.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e7d7bea15e866838110b7e12dcea9f4ca414b05
Author: Rik van Riel <riel@redhat.com>
Date:   Tue Oct 4 20:34:34 2016 -0400

    x86/fpu: Remove struct fpu::counter

    commit 3913cc3507575273beb165a5e027a081913ed507 upstream.

    With the lazy FPU code gone, we no longer use the counter field
    in struct fpu for anything. Get rid it.

    Signed-off-by: Rik van Riel <riel@redhat.com>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: pbonzini@redhat.com
    Link: http://lkml.kernel.org/r/1475627678-20788-6-git-send-email-riel@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6b69cf4bd3e1f4a35d5e8ab2b4c428fcff348f
Author: Andy Lutomirski <luto@kernel.org>
Date:   Tue Oct 4 20:34:33 2016 -0400

    x86/fpu: Remove use_eager_fpu()

    commit c592b57347069abfc0dcad3b3a302cf882602597 upstream.

    This removes all the obvious code paths that depend on lazy FPU mode.
    It shouldn't change the generated code at all.

    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: pbonzini@redhat.com
    Link: http://lkml.kernel.org/r/1475627678-20788-5-git-send-email-riel@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84037eebce3a51a135149bcb16fe01bcdf6d7711
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Mar 8 10:00:11 2016 +0100

    KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch

    commit 5a5fbdc0e3f1159a734f1890da60fce70e98271d upstream.

    It is now equal to use_eager_fpu(), which simply tests a cpufeature bit.

    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcea9310efa8d0f790509770341be4ea5bfc63b3
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 2 15:47:35 2018 -0700

    rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096

    [ Upstream commit 0e1d6eca5113858ed2caea61a5adc03c595f6096 ]

    We have an impressive number of syzkaller bugs that are linked
    to the fact that syzbot was able to create a networking device
    with millions of TX (or RX) queues.

    Let's limit the number of RX/TX queues to 4096, this really should
    cover all known cases.

    A separate patch will add various cond_resched() in the loops
    handling sysfs entries at device creation and dismantle.

    Tested:

    lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap
    RTNETLINK answers: Invalid argument

    lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap

    real	0m0.180s
    user	0m0.000s
    sys	0m0.107s

    Fixes: 76ff5cc91935 ("rtnl: allow to specify number of rx and tx queues on device creation")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59b6d2e59b290ebd597c3e249477d6866d275ce2
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Oct 2 16:52:03 2018 -0700

    net: systemport: Fix wake-up interrupt race during resume

    [ Upstream commit 45ec318578c0c22a11f5b9927d064418e1ab1905 ]

    The AON_PM_L2 is normally used to trigger and identify the source of a
    wake-up event. Since the RX_SYS clock is no longer turned off, we also
    have an interrupt being sent to the SYSTEMPORT INTRL_2_0 controller, and
    that interrupt remains active up until the magic packet detector is
    disabled which happens much later during the driver resumption.

    The race happens if we have a CPU that is entering the SYSTEMPORT
    INTRL2_0 handler during resume, and another CPU has managed to clear the
    wake-up interrupt during bcm_sysport_resume_from_wol(). In that case, we
    have the first CPU stuck in the interrupt handler with an interrupt
    cause that has been cleared under its feet, and so we keep returning
    IRQ_NONE and we never make any progress.

    This was not a problem before because we would always turn off the
    RX_SYS clock during WoL, so the SYSTEMPORT INTRL2_0 would also be turned
    off as well, thus not latching the interrupt.

    The fix is to make sure we do not enable either the MPD or
    BRCM_TAG_MATCH interrupts since those are redundant with what the
    AON_PM_L2 interrupt controller already processes and they would cause
    such a race to occur.

    Fixes: bb9051a2b230 ("net: systemport: Add support for WAKE_FILTER")
    Fixes: 83e82f4c706b ("net: systemport: add Wake-on-LAN support")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b2c9306e3cd90d508384a3d94dabf59d24824e6
Author: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date:   Fri Oct 5 09:04:40 2018 +0200

    net: mvpp2: Extract the correct ethtype from the skb for tx csum offload

    [ Upstream commit 35f3625c21852ad839f20c91c7d81c4c1101e207 ]

    When offloading the L3 and L4 csum computation on TX, we need to extract
    the l3_proto from the ethtype, independently of the presence of a vlan
    tag.

    The actual driver uses skb->protocol as-is, resulting in packets with
    the wrong L4 checksum being sent when there's a vlan tag in the packet
    header and checksum offloading is enabled.

    This commit makes use of vlan_protocol_get() to get the correct ethtype
    regardless the presence of a vlan tag.

    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0fff89962d3d30cf677b3c0e7a2f379d7ef0f3a
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Mon Oct 1 12:21:59 2018 +0300

    team: Forbid enslaving team device to itself

    [ 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____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868

    but task is already holding lock:
    (____ptrval____) (&team->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(&team->lock);
      lock(&team->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____) (&team->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:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
    RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
    RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000

    Fixes: 87002b03baab ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f04cacdcd5bc4227d0d4ed6be08da6f959168c8
Author: Shahed Shaikh <shahed.shaikh@cavium.com>
Date:   Wed Sep 26 12:41:10 2018 -0700

    qlcnic: fix Tx descriptor corruption on 82xx devices

    [ Upstream commit c333fa0c4f220f8f7ea5acd6b0ebf3bf13fd684d ]

    In regular NIC transmission flow, driver always configures MAC using
    Tx queue zero descriptor as a part of MAC learning flow.
    But with multi Tx queue supported NIC, regular transmission can occur on
    any non-zero Tx queue and from that context it uses
    Tx queue zero descriptor to configure MAC, at the same time TX queue
    zero could be used by another CPU for regular transmission
    which could lead to Tx queue zero descriptor corruption and cause FW
    abort.

    This patch fixes this in such a way that driver always configures
    learned MAC address from the same Tx queue which is used for
    regular transmission.

    Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
    Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0aa059ea2dacc7383052f9b2380edd3964f23033
Author: Yu Zhao <yuzhao@google.com>
Date:   Fri Sep 28 17:04:30 2018 -0600

    net/usb: cancel pending work when unbinding smsc75xx

    [ Upstream commit f7b2a56e1f3dcbdb4cf09b2b63e859ffe0e09df8 ]

    Cancel pending work before freeing smsc75xx private data structure
    during binding. This fixes the following crash in the driver:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
    IP: mutex_lock+0x2b/0x3f
    <snipped>
    Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
    task: ffff8caa83e85700 task.stack: ffff948b80518000
    RIP: 0010:mutex_lock+0x2b/0x3f
    <snipped>
    Call Trace:
     smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
     process_one_work+0x18d/0x2fc
     worker_thread+0x1a2/0x269
     ? pr_cont_work+0x58/0x58
     kthread+0xfa/0x10a
     ? pr_cont_work+0x58/0x58
     ? rcu_read_unlock_sched_notrace+0x48/0x48
     ret_from_fork+0x22/0x40

    Signed-off-by: Yu Zhao <yuzhao@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f3a2366922b3e0e1af3df011dae20929d3a8204
Author: Sean Tranchetti <stranche@codeaurora.org>
Date:   Thu Sep 20 14:29:45 2018 -0600

    netlabel: check for IPV4MASK in addrinfo_get

    [ Upstream commit f88b4c01b97e09535505cf3c327fdbce55c27f00 ]

    netlbl_unlabel_addrinfo_get() assumes that if it finds the
    NLBL_UNLABEL_A_IPV4ADDR attribute, it must also have the
    NLBL_UNLABEL_A_IPV4MASK attribute as well. However, this is
    not necessarily the case as the current checks in
    netlbl_unlabel_staticadd() and friends are not sufficent to
    enforce this.

    If passed a netlink message with NLBL_UNLABEL_A_IPV4ADDR,
    NLBL_UNLABEL_A_IPV6ADDR, and NLBL_UNLABEL_A_IPV6MASK attributes,
    these functions will all call netlbl_unlabel_addrinfo_get() which
    will then attempt dereference NULL when fetching the non-existent
    NLBL_UNLABEL_A_IPV4MASK attribute:

    Unable to handle kernel NULL pointer dereference at virtual address 0
    Process unlab (pid: 31762, stack limit = 0xffffff80502d8000)
    Call trace:
    	netlbl_unlabel_addrinfo_get+0x44/0xd8
    	netlbl_unlabel_staticremovedef+0x98/0xe0
    	genl_rcv_msg+0x354/0x388
    	netlink_rcv_skb+0xac/0x118
    	genl_rcv+0x34/0x48
    	netlink_unicast+0x158/0x1f0
    	netlink_sendmsg+0x32c/0x338
    	sock_sendmsg+0x44/0x60
    	___sys_sendmsg+0x1d0/0x2a8
    	__sys_sendmsg+0x64/0xb4
    	SyS_sendmsg+0x34/0x4c
    	el0_svc_naked+0x34/0x38
    Code: 51001149 7100113f 540000a0 f9401508 (79400108)
    ---[ end trace f6438a488e737143 ]---
    Kernel panic - not syncing: Fatal exception

    Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>

    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ee4a60d618e8cf9ba6228139fae35c4ba3d4df0
Author: Jeff Barnhill <0xeffeff@gmail.com>
Date:   Fri Sep 21 00:45:27 2018 +0000

    net/ipv6: Display all addresses in output of /proc/net/if_inet6

    [ Upstream commit 86f9bd1ff61c413a2a251fa736463295e4e24733 ]

    The backend handling for /proc/net/if_inet6 in addrconf.c doesn't properly
    handle starting/stopping the iteration.  The problem is that at some point
    during the iteration, an overflow is detected and the process is
    subsequently stopped.  The item being shown via seq_printf() when the
    overflow occurs is not actually shown, though.  When start() is
    subsequently called to resume iterating, it returns the next item, and
    thus the item that was being processed when the overflow occurred never
    gets printed.

    Alter the meaning of the private data member "offset".  Currently, when it
    is not 0 (which only happens at the very beginning), "offset" represents
    the next hlist item to be printed.  After this change, "offset" always
    represents the current item.

    This is also consistent with the private data member "bucket", which
    represents the current bucket, and also the use of "pos" as defined in
    seq_file.txt:
        The pos passed to start() will always be either zero, or the most
        recent pos used in the previous session.

    Signed-off-by: Jeff Barnhill <0xeffeff@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b7e4c735933be79882aba2bed9afa789e03c62f
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Oct 9 17:48:14 2018 +0200

    net: ipv4: update fnhe_pmtu when first hop's MTU changes

    [ Upstream commit af7d6cce53694a88d6a1bb60c9a239a6a5144459 ]

    Since commit 5aad1de5ea2c ("ipv4: use separate genid for next hop
    exceptions"), exceptions get deprecated separately from cached
    routes. In particular, administrative changes don't clear PMTU anymore.

    As Stefano described in commit e9fa1495d738 ("ipv6: Reflect MTU changes
    on PMTU of exceptions for MTU-less routes"), the PMTU discovered before
    the local MTU change can become stale:
     - if the local MTU is now lower than the PMTU, that PMTU is now
       incorrect
     - if the local MTU was the lowest value in the path, and is increased,
       we might discover a higher PMTU

    Similarly to what commit e9fa1495d738 did for IPv6, update PMTU in those
    cases.

    If the exception was locked, the discovered PMTU was smaller than the
    minimal accepted PMTU. In that case, if the new local MTU is smaller
    than the current PMTU, let PMTU discovery figure out if locking of the
    exception is still needed.

    To do this, we need to know the old link MTU in the NETDEV_CHANGEMTU
    notifier. By the time the notifier is called, dev->mtu has been
    changed. This patch adds the old MTU as additional information in the
    notifier structure, and a new call_netdevice_notifiers_u32() function.

    Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7148eeb647fd55909f985ad14b0176ff1fae335
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Sep 30 11:33:39 2018 -0700

    ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()

    [ Upstream commit 64199fc0a46ba211362472f7f942f900af9492fd ]

    Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
    do not do it.

    Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9d3572816ba724129da0ec2ecd590d5c899e86e
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Sep 24 15:48:19 2018 +0200

    ip_tunnel: be careful when accessing the inner header

    [ 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 <xiyou.wangcong@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20f16d1a3817523350e9c5b5a231c4cb2cf0ab3f
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Sep 19 15:02:07 2018 +0200

    ip6_tunnel: be careful when accessing the inner header

    [ Upstream commit 76c0ddd8c3a683f6e2c6e60e11dc1a1558caf4bc ]

    the ip6 tunnel xmit ndo assumes that the processed skb always
    contains an ip[v6] header, but syzbot has found a way to send
    frames that fall short of this assumption, leading to the following splat:

    BUG: KMSAN: uninit-value in ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307
    [inline]
    BUG: KMSAN: uninit-value in ip6_tnl_start_xmit+0x7d2/0x1ef0
    net/ipv6/ip6_tunnel.c:1390
    CPU: 0 PID: 4504 Comm: syz-executor558 Not tainted 4.16.0+ #87
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x185/0x1d0 lib/dump_stack.c:53
      kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
      __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
      ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1307 [inline]
      ip6_tnl_start_xmit+0x7d2/0x1ef0 net/ipv6/ip6_tunnel.c:1390
      __netdev_start_xmit include/linux/netdevice.h:4066 [inline]
      netdev_start_xmit include/linux/netdevice.h:4075 [inline]
      xmit_one net/core/dev.c:3026 [inline]
      dev_hard_start_xmit+0x5f1/0xc70 net/core/dev.c:3042
      __dev_queue_xmit+0x27ee/0x3520 net/core/dev.c:3557
      dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
      packet_snd net/packet/af_packet.c:2944 [inline]
      packet_sendmsg+0x7c70/0x8a30 net/packet/af_packet.c:2969
      sock_sendmsg_nosec net/socket.c:630 [inline]
      sock_sendmsg net/socket.c:640 [inline]
      ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
      __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
      SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
      SyS_sendmmsg+0x63/0x90 net/socket.c:2162
      do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
      entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x441819
    RSP: 002b:00007ffe58ee8268 EFLAGS: 00000213 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441819
    RDX: 0000000000000002 RSI: 0000000020000100 RDI: 0000000000000003
    RBP: 00000000006cd018 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000402510
    R13: 00000000004025a0 R14: 0000000000000000 R15: 0000000000000000

    Uninit was created at:
      kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
      kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
      kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
      kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
      slab_post_alloc_hook mm/slab.h:445 [inline]
      slab_alloc_node mm/slub.c:2737 [inline]
      __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
      __kmalloc_reserve net/core/skbuff.c:138 [inline]
      __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
      alloc_skb include/linux/skbuff.h:984 [inline]
      alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
      sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
      packet_alloc_skb net/packet/af_packet.c:2803 [inline]
      packet_snd net/packet/af_packet.c:2894 [inline]
      packet_sendmsg+0x6454/0x8a30 net/packet/af_packet.c:2969
      sock_sendmsg_nosec net/socket.c:630 [inline]
      sock_sendmsg net/socket.c:640 [inline]
      ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
      __sys_sendmmsg+0x42d/0x800 net/socket.c:2136
      SYSC_sendmmsg+0xc4/0x110 net/socket.c:2167
      SyS_sendmmsg+0x63/0x90 net/socket.c:2162
      do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
      entry_SYSCALL_64_after_hwframe+0x3d/0xa2

    This change addresses the issue adding the needed check before
    accessing the inner header.

    The ipv4 side of the issue is apparently there since the ipv4 over ipv6
    initial support, and the ipv6 side predates git history.

    Fixes: c4d3efafcc93 ("[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+3fde91d4d394747d6db4@syzkaller.appspotmail.com
    Tested-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2691921c7d26efc18400162b77c794d6a921afe5
Author: Mahesh Bandewar <maheshb@google.com>
Date:   Mon Sep 24 14:40:11 2018 -0700

    bonding: avoid possible dead-lock

    [ Upstream commit d4859d749aa7090ffb743d15648adb962a1baeae ]

    Syzkaller reported this on a slightly older kernel but it's still
    applicable to the current kernel -

    ======================================================
    WARNING: possible circular locking dependency detected
    4.18.0-next-20180823+ #46 Not tainted
    ------------------------------------------------------
    syz-executor4/26841 is trying to acquire lock:
    00000000dd41ef48 ((wq_completion)bond_dev->name){+.+.}, at: flush_workqueue+0x2db/0x1e10 kernel/workqueue.c:2652

    but task is already holding lock:
    00000000768ab431 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
    00000000768ab431 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4708

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #2 (rtnl_mutex){+.+.}:
           __mutex_lock_common kernel/locking/mutex.c:925 [inline]
           __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
           mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
           rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
           bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
           bond_netdev_notify_work+0x44/0xd0 drivers/net/bonding/bond_main.c:1320
           process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
           worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
           kthread+0x35a/0x420 kernel/kthread.c:246
           ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

    -> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
           process_one_work+0xc0b/0x1aa0 kernel/workqueue.c:2129
           worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
           kthread+0x35a/0x420 kernel/kthread.c:246
           ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

    -> #0 ((wq_completion)bond_dev->name){+.+.}:
           lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
           flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
           drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
           destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
           __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
           bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
           register_netdevice+0x337/0x1100 net/core/dev.c:8410
           bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
           rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
           rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
           netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
           rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
           netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
           netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
           netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
           sock_sendmsg_nosec net/socket.c:622 [inline]
           sock_sendmsg+0xd5/0x120 net/socket.c:632
           ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
           __sys_sendmsg+0x11d/0x290 net/socket.c:2153
           __do_sys_sendmsg net/socket.c:2162 [inline]
           __se_sys_sendmsg net/socket.c:2160 [inline]
           __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
           do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
           entry_SYSCALL_64_after_hwframe+0x49/0xbe

    other info that might help us debug this:

    Chain exists of:
      (wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work) --> rtnl_mutex

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(rtnl_mutex);
                                   lock((work_completion)(&(&nnw->work)->work));
                                   lock(rtnl_mutex);
      lock((wq_completion)bond_dev->name);

     *** DEADLOCK ***

    1 lock held by syz-executor4/26841:

    stack backtrace:
    CPU: 1 PID: 26841 Comm: syz-executor4 Not tainted 4.18.0-next-20180823+ #46
    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_circular_bug.isra.34.cold.55+0x1bd/0x27d kernel/locking/lockdep.c:1222
     check_prev_add kernel/locking/lockdep.c:1862 [inline]
     check_prevs_add kernel/locking/lockdep.c:1975 [inline]
     validate_chain kernel/locking/lockdep.c:2416 [inline]
     __lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3412
     lock_acquire+0x1e4/0x4f0 kernel/locking/lockdep.c:3901
     flush_workqueue+0x30a/0x1e10 kernel/workqueue.c:2655
     drain_workqueue+0x2a9/0x640 kernel/workqueue.c:2820
     destroy_workqueue+0xc6/0x9d0 kernel/workqueue.c:4155
     __alloc_workqueue_key+0xef9/0x1190 kernel/workqueue.c:4138
     bond_init+0x269/0x940 drivers/net/bonding/bond_main.c:4734
     register_netdevice+0x337/0x1100 net/core/dev.c:8410
     bond_newlink+0x49/0xa0 drivers/net/bonding/bond_netlink.c:453
     rtnl_newlink+0xef4/0x1d50 net/core/rtnetlink.c:3099
     rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4711
     netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
     rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4729
     netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
     netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
     netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
     sock_sendmsg_nosec net/socket.c:622 [inline]
     sock_sendmsg+0xd5/0x120 net/socket.c:632
     ___sys_sendmsg+0x7fd/0x930 net/socket.c:2115
     __sys_sendmsg+0x11d/0x290 net/socket.c:2153
     __do_sys_sendmsg net/socket.c:2162 [inline]
     __se_sys_sendmsg net/socket.c:2160 [inline]
     __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2160
     do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457089
    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:00007f2df20a5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f2df20a66d4 RCX: 0000000000457089
    RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
    RBP: 0000000000930140 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 00000000004d40b8 R14: 00000000004c8ad8 R15: 0000000000000001

    Signed-off-by: Mahesh Bandewar <maheshb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4348b96650bb03e0fa6cf5704ffc1a6517db4970
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed Sep 26 00:41:04 2018 -0400

    bnxt_en: Fix TX timeout during netpoll.

    [ Upstream commit 73f21c653f930f438d53eed29b5e4c65c8a0f906 ]

    The current netpoll implementation in the bnxt_en driver has problems
    that may miss TX completion events.  bnxt_poll_work() in effect is
    only handling at most 1 TX packet before exiting.  In addition,
    there may be in flight TX completions that ->poll() may miss even
    after we fix bnxt_poll_work() to handle all visible TX completions.
    netpoll may not call ->poll() again and HW may not generate IRQ
    because the driver does not ARM the IRQ when the budget (0 for netpoll)
    is reached.

    We fix it by handling all TX completions and to always ARM the IRQ
    when we exit ->poll() with 0 budget.

    Also, the logic to ACK the completion ring in case it is almost filled
    with TX completions need to be adjusted to take care of the 0 budget
    case, as discussed with Eric Dumazet <edumazet@google.com>

    Reported-by: Song Liu <songliubraving@fb.com>
    Reviewed-by: Song Liu <songliubraving@fb.com>
    Tested-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ac147ebfa1c50cc0f25e3c7f42862cfe6b40d0d
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Oct 12 14:01:26 2018 +0800

    jffs2: return -ERANGE when xattr buffer is too small

    When a file have multiple xattrs and the passed buffer is
    smaller than the required size, jffs2_listxattr() should
    return -ERANGE instead of continue, else Oops may occur
    due to memory corruption.

    Also remove the unnecessary check ("rc < 0"), because
    xhandle->list(...) will not return an error number.

    Spotted by generic/377 in xfstests-dev.

    NB: The problem had been fixed by commit 764a5c6b1fa4 ("xattr
    handlers: Simplify list operation") in v4.5-rc1, but the
    modification in that commit may be too much because it modifies
    all file-systems which implement xattr, so I create a single
    patch for jffs2 to fix the problem.

    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f37a3ff6e4c7cb93eb65c6fc6c549fafa2673863
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Feb 12 14:24:47 2018 +0200

    xhci: Don't print a warning when setting link state for disabled ports

    commit 1208d8a84fdcae6b395c57911cdf907450d30e70 upstream.

    When disabling a USB3 port the hub driver will set the port link state to
    U3 to prevent "ejected" or "safely removed" devices that are still
    physically connected from immediately re-enumerating.

    If the device was really unplugged, then error messages were printed
    as the hub tries to set the U3 link state for a port that is no longer
    enabled.

    xhci-hcd ee000000.usb: Cannot set link state.
    usb usb8-port1: cannot disable (err = -32)

    Don't print error message in xhci-hub if hub tries to set port link state
    for a disabled port. Return -ENODEV instead which also silences hub driver.

    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Ross Zwisler <zwisler@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 863334098b60d163d39fde83d6044c54ca60d53e
Author: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
Date:   Thu Sep 27 11:56:03 2018 +0300

    i2c: i2c-scmi: fix for i2c_smbus_write_block_data

    commit 08d9db00fe0e300d6df976e6c294f974988226dd upstream.

    The i2c-scmi driver crashes when the SMBus Write Block transaction is
    executed:

    WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0
     Call Trace:
      ? get_page_from_freelist+0x49d/0x11f0
      ? alloc_pages_current+0x6a/0xe0
      ? new_slab+0x499/0x690
      __alloc_pages_nodemask+0x265/0x280
      alloc_pages_current+0x6a/0xe0
      kmalloc_order+0x18/0x40
      kmalloc_order_trace+0x24/0xb0
      ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c
      __kmalloc+0x203/0x220
      acpi_os_allocate_zeroed+0x34/0x36
      acpi_ut_copy_eobject_to_iobject+0x266/0x31e
      acpi_evaluate_object+0x166/0x3b2
      acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi]
      i2c_smbus_xfer+0xda/0x370
      i2cdev_ioctl_smbus+0x1bd/0x270
      i2cdev_ioctl+0xaa/0x250
      do_vfs_ioctl+0xa4/0x600
      SyS_ioctl+0x79/0x90
      do_syscall_64+0x73/0x130
      entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)

    This problem occurs because the length of ACPI Buffer object is not
    defined/initialized in the code before a corresponding ACPI method is
    called. The obvious patch below fixes this issue.

    Signed-off-by: Edgar Cherkasov <echerkasov@dev.rtsoft.ru>
    Acked-by: Viktor Krasnov <vkrasnov@dev.rtsoft.ru>
    Acked-by: Michael Brunner <Michael.Brunner@kontron.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49f80e6ef438982c42d9acb9175ead40d64074c1
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Sep 11 14:45:03 2018 +0300

    perf script python: Fix export-to-postgresql.py occasional failure

    commit 25e11700b54c7b6b5ebfc4361981dae12299557b upstream.

    Occasional export failures were found to be caused by truncating 64-bit
    pointers to 32-bits. Fix by explicitly setting types for all ctype
    arguments and results.

    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20180911114504.28516-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f41f387b0f44fd5ba325d893edead8b52314437
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Aug 17 15:19:37 2018 -0400

    mach64: detect the dot clock divider correctly on sparc

    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 <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Acked-by: David S. Miller <davem@davemloft.net>
    Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f0ad8d548588419b5f1b8ca36673af32d3dafdf
Author: Jann Horn <jannh@google.com>
Date:   Fri Oct 5 15:52:03 2018 -0700

    mm/vmstat.c: fix outdated vmstat_text

    commit 28e2c4bb99aa40f9d5f07ac130cbc4da0ea93079 upstream.

    7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely") removed the
    VMACACHE_FULL_FLUSHES statistics, but didn't remove the corresponding
    entry in vmstat_text.  This causes an out-of-bounds access in
    vmstat_show().

    Luckily this only affects kernels with CONFIG_DEBUG_VM_VMACACHE=y, which
    is probably very rare.

    Link: http://lkml.kernel.org/r/20181001143138.95119-1-jannh@google.com
    Fixes: 7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely")
    Signed-off-by: Jann Horn <jannh@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Roman Gushchin <guro@fb.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Christoph Lameter <clameter@sgi.com>
    Cc: Kemi Wang <kemi.wang@intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a3d844f83d47c432fba7d28570bc68b5015ecd0
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Jun 13 00:23:11 2018 -0400

    ext4: add corruption check in ext4_xattr_set_entry()

    commit 5369a762c882c0b6e9599e4ebbb3a9ba9eee7e2d upstream.

    In theory this should have been caught earlier when the xattr list was
    verified, but in case it got missed, it's simple enough to add check
    to make sure we don't overrun the xattr buffer.

    This addresses CVE-2018-10879.

    https://bugzilla.kernel.org/show_bug.cgi?id=200001

    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    [bwh: Backported to 3.16:
     - Add inode parameter to ext4_xattr_set_entry() and update callers
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [adjusted for 4.4 context]
    Signed-off-by: Daniel Rosenberg <drosen@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a6d4e4f784be0a6957043779e85bd6a410fd4d
Author: Amber Lin <Amber.Lin@amd.com>
Date:   Wed Sep 12 21:42:18 2018 -0400

    drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7

    [ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]

    A wrong register bit was examinated for checking SDMA status so it reports
    false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
    bit.

    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Amber Lin <Amber.Lin@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51b6ff44c6d4c06489c15955ed52ba67cf20eecf
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Fri Sep 14 17:48:11 2018 +0200

    ARM: dts: at91: add new compatibility string for macb on sama5d3

    [ Upstream commit 321cc359d899a8e988f3725d87c18a628e1cc624 ]

    We need this new compatibility string as we experienced different behavior
    for this 10/100Mbits/s macb interface on this particular SoC.
    Backward compatibility is preserved as we keep the alternative strings.

    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f74eda8ed5d90d40ed3e0f46ddfbfe57bc6786f2
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Fri Sep 14 17:48:10 2018 +0200

    net: macb: disable scatter-gather for macb on sama5d3

    [ Upstream commit eb4ed8e2d7fecb5f40db38e4498b9ee23cddf196 ]

    Create a new configuration for the sama5d3-macb new compatibility string.
    This configuration disables scatter-gather because we experienced lock down
    of the macb interface of this particular SoC under very high load.

    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd66767a8c0ecbd3f5eb0ad58da9b7fb975ee444
Author: Jongsung Kim <neidhard.kim@lge.com>
Date:   Thu Sep 13 18:32:21 2018 +0900

    stmmac: fix valid numbers of unicast filter entries
…

freak07 added a commit to freak07/Kirisakura_Taimen_8.1.0 that referenced this issue Oct 24, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0d02fdd080d2435101f09d02e843eae17606fb59)
(cherry picked from commit 291d1aaff8384ea6135a66b67ec3125b3d1d638f)

NeonDragon1909 added a commit to Dil3mm4/labyrinth_kernel_prague that referenced this issue Oct 25, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

EviraKernel added a commit to EviraKernel/aospkernel that referenced this issue Oct 27, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

EviraKernel added a commit to EviraKernel/evirarework that referenced this issue Oct 29, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

milouk added a commit to milouk/Sphinx-Dipper that referenced this issue Oct 29, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Jerry981028 added a commit to Jerry981028/Amlogic_s905-kernel that referenced this issue Oct 30, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f0 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

limoniumstatice added a commit to limoniumstatice/luna_kernel_mata that referenced this issue Nov 3, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

limoniumstatice added a commit to limoniumstatice/luna_kernel_mata that referenced this issue Nov 5, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

neonkat added a commit to neonkat/beryllium_kernel that referenced this issue Nov 5, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

jollaman999 added a commit to jollaman999/jolla-kernel_joan that referenced this issue Nov 8, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

limoniumstatice added a commit to limoniumstatice/luna_kernel_mata that referenced this issue Nov 11, 2018

net/mlx4: Use cpumask_available for eq->affinity_mask
[ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context:

drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
array 'eq->affinity_mask' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
            ~~~~~^~~~~~~~~~~~~
1 warning generated.

Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
helper cpumask_available()"), which does the proper checking and avoids
this warning.

Link: ClangBuiltLinux/linux#86
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment