Function dmi_matches can me made a bit faster:

* The documented purpose of dmi_initialized is to catch too early
  calls to dmi_check_system(). I'm not fully convinced it justifies
  slowing down the initialization of all systems out there, but at
  least the check should not have been moved from dmi_check_system()
  to dmi_matches(). dmi_matches() is being called for every entry of
  the table passed to dmi_check_system(), causing the same redundant
  check to be performed again and again. So move it back to
  dmi_check_system(), reverting this specific portion of commit
  d7b1956f ("DMI: Introduce dmi_first_match to make the interface
  more flexible").

* Don't check for the exact_match flag again when we already know its
  value.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Fixes: d7b1956f ("DMI: Introduce dmi_first_match to make the interface more flexible")
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Jeff Garzik <jgarzik@redhat.com>

Sukumar reported that sends to the local broadcast address
(255.255.255.255) are broken. Check for the address in vrf driver
and do not redirect to the VRF device - similar to multicast
packets.

With this change sockets can use SO_BINDTODEVICE to specify an
egress interface and receive responses. Note: the egress interface
can not be a VRF device but needs to be the enslaved device.

https://bugzilla.kernel.org/show_bug.cgi?id=198521Reported-by: NSukumar Gopalakrishnan <sukumarg1973@gmail.com>
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hardware statistics retrieval hurts in tight invocation loops.

Avoid extraneous write and enforce strict ordering of writes targeted to
the tally counters dump area address registers.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Tested-by: NOliver Freyermuth <o.freyermuth@googlemail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.

This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:

        a0c9259d (irq/matrix: Spread interrupts on allocation)

After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.

For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.

So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.

As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <efault@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
"BUG: unable to handle kernel NULL pointer dereference at           (null)"

Let's add a helper to check if update_pmtu is available before calling it.

Fixes: 52a589d5 ("geneve: update skb dst pmtu on tx path")
Fixes: a93bf0ff ("vxlan: update skb dst pmtu on tx path")
CC: Roman Kapl <code@rkapl.cz>
CC: Xin Long <lucien.xin@gmail.com>
Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

STA control register has areas of mode and opcodes for opeations. 18 bit is
using for mode selection, where 0 is old MIO/MDIO access method and 1 is
indirect access mode. 19-20 bits are using for setting up read/write
operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode
with 19 bit and write operation is set into 18 bit which is mode selection,
not a write operation. To correlate write with read we set it into 20 bit.
All those bit operations are MSB 0 based.
Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes,
in current state if we set it up in dts 8192 as example, we will get
only 2048 which may impact on network speed.
Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the sysfs attribute hangs off the RMI bus, which doesn't go away during
firmware flash, it needs to be explicitly removed, otherwise we would try and
register the same attribute twice.

This reverts commit 36a44af5.
Signed-off-by: NNick Dyer <nick@shmanahar.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The code will try to access dev->iotlb when processing
VHOST_IOTLB_INVALIDATE even if it was not initialized which may lead
to NULL pointer dereference. Fixes this by check dev->iotlb before.

Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
hold mutexes of all virtqueues. This may confuse lockdep to report a
possible deadlock because of trying to hold locks belong to same
class. Switch to use mutex_lock_nested() to avoid false positive.

Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since TC block changes drivers are required to check if
the TC hw offload flag is set on the interface themselves.

Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower")
Fixes: 44ae12a7 ("net: sched: move the can_offload check from binding phase to rule insertion phase")
Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: NSimon Horman <simon.horman@netronome.com>
Acked-by: NJiri Pirko <jiri@mellanox.com>
Acked-by: NAmritha Nambiar <amritha.nambiar@intel.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A tid was allocated for reserved MR during initialization but
not freed. This lead to an annoying output message during
rdma unload flow.
Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: NAriel Elior <Ariel.Elior@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Double reservation for kernel dedicated dpi was performed.
Once in the core module and once in qedr.
Remove the reservation from core.
Signed-off-by: NMichal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: NAriel Elior <Ariel.Elior@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Driver periodically samples all neighbors configured in device
in order to update the kernel regarding their state. When finding
an entry configured in HW that doesn't show in neigh_lookup()
driver logs an error message.
This introduces a race when removing multiple neighbors -
it's possible that a given entry would still be configured in HW
as its removal is still being processed but is already removed
from the kernel's neighbor tables.

Simply remove the error message and gracefully accept such events.

Fixes: c723c735 ("mlxsw: spectrum_router: Periodically update the kernel's neigh table")
Fixes: 60f040ca ("mlxsw: spectrum_router: Periodically dump active IPv6 neighbours")
Signed-off-by: NYuval Mintz <yuvalm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

with the introduction of commit
b0eb57cb, it appears that rq->buf_info
is improperly handled.  While it is heap allocated when an rx queue is
setup, and freed when torn down, an old line of code in
vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0]
being set to NULL prior to its being freed, causing a memory leak, which
eventually exhausts the system on repeated create/destroy operations
(for example, when  the mtu of a vmxnet3 interface is changed
frequently.

Fix is pretty straight forward, just move the NULL set to after the
free.

Tested by myself with successful results

Applies to net, and should likely be queued for stable, please
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Reported-By: boyang@redhat.com
CC: boyang@redhat.com
CC: Shrikrishna Khare <skhare@vmware.com>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: David S. Miller <davem@davemloft.net>
Acked-by: NShrikrishna Khare <skhare@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In pppoe_sendmsg(), reserving dev->hard_header_len bytes of headroom
was probably fine before the introduction of ->needed_headroom in
commit f5184d26 ("net: Allow netdevices to specify needed head/tailroom").

But now, virtual devices typically advertise the size of their overhead
in dev->needed_headroom, so we must also take it into account in
skb_reserve().
Allocation size of skb is also updated to take dev->needed_tailroom
into account and replace the arbitrary 32 bytes with the real size of
a PPPoE header.

This issue was discovered by syzbot, who connected a pppoe socket to a
gre device which had dev->header_ops->create == ipgre_header and
dev->hard_header_len == 0. Therefore, PPPoE didn't reserve any
headroom, and dev_hard_header() crashed when ipgre_header() tried to
prepend its header to skb->data.

skbuff: skb_under_panic: text:000000001d390b3a len:31 put:24
head:00000000d8ed776f data:000000008150e823 tail:0x7 end:0xc0 dev:gre0
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:104!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
    (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 3670 Comm: syzkaller801466 Not tainted
4.15.0-rc7-next-20180115+ #97
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100
RSP: 0018:ffff8801d9bd7840 EFLAGS: 00010282
RAX: 0000000000000083 RBX: ffff8801d4f083c0 RCX: 0000000000000000
RDX: 0000000000000083 RSI: 1ffff1003b37ae92 RDI: ffffed003b37aefc
RBP: ffff8801d9bd78a8 R08: 1ffff1003b37ae8a R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff86200de0
R13: ffffffff84a981ad R14: 0000000000000018 R15: ffff8801d2d34180
FS:  00000000019c4880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208bc000 CR3: 00000001d9111001 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  skb_under_panic net/core/skbuff.c:114 [inline]
  skb_push+0xce/0xf0 net/core/skbuff.c:1714
  ipgre_header+0x6d/0x4e0 net/ipv4/ip_gre.c:879
  dev_hard_header include/linux/netdevice.h:2723 [inline]
  pppoe_sendmsg+0x58e/0x8b0 drivers/net/ppp/pppoe.c:890
  sock_sendmsg_nosec net/socket.c:630 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:640
  sock_write_iter+0x31a/0x5d0 net/socket.c:909
  call_write_iter include/linux/fs.h:1775 [inline]
  do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653
  do_iter_write+0x154/0x540 fs/read_write.c:932
  vfs_writev+0x18a/0x340 fs/read_write.c:977
  do_writev+0xfc/0x2a0 fs/read_write.c:1012
  SYSC_writev fs/read_write.c:1085 [inline]
  SyS_writev+0x27/0x30 fs/read_write.c:1082
  entry_SYSCALL_64_fastpath+0x29/0xa0

Admittedly PPPoE shouldn't be allowed to run on non Ethernet-like
interfaces, but reserving space for ->needed_headroom is a more
fundamental issue that needs to be addressed first.

Same problem exists for __pppoe_xmit(), which also needs to take
dev->needed_headroom into account in skb_cow_head().

Fixes: f5184d26 ("net: Allow netdevices to specify needed head/tailroom")
Reported-by: syzbot+ed0838d0fa4c4f2b528e20286e6dc63effc7c14d@syzkaller.appspotmail.com
Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
Reviewed-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The newer trackpoints from ALPS, Elan and NXP implement a very limited
subset of extended commands and controls that the original trackpoints
implemented, so we should not be exposing not working controls in sysfs.
The newer trackpoints also do not implement "Power On Reset" or "Read
Extended Button Status", so we should not be using these commands during
initialization.

While we are at it, let's change "unsigned char" to u8 for byte data or
bool for booleans and use better suited error codes instead of -1.

Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands.
They supposed to reply with 0x02, 0x03, or 0x04 in response to the
"Read Extended ID" command, so we would know not to try certain extended
commands. Unfortunately even some trackpoints reporting the original IBM
version (0x01 firmware 0x0e) now respond with incorrect data to the "Get
Extended Buttons" command:

 thinkpad_acpi: ThinkPad BIOS R0DET87W (1.87 ), EC unknown
 thinkpad_acpi: Lenovo ThinkPad E470, model 20H1004SGE

 psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 0/0

Since there are no trackpoints without buttons, let's assume the trackpoint
has 3 buttons when we get 0 response to the extended buttons query.
Signed-off-by: NAaron Ma <aaron.ma@canonical.com>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196253
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The commit 62219066 ("be2net: Request RSS capability of Rx interface
depending on number of Rx rings") modified be_update_queues() so the
IFACE (HW representation of the netdevice) is destroyed and then
re-created. This causes a regression because potential promiscuous mode
is not restored properly during be_open() because the driver thinks
that the HW has promiscuous mode already enabled.

Note that Lancer is not affected by this bug because RX-filter flags are
disabled during be_close() for this chipset.

Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>

Fixes: 62219066 ("be2net: Request RSS capability of Rx interface depending on number of Rx rings")
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In reset events in which our memory allocations need to be reallocated,
VPD data is being freed, but never reallocated. This can cause issues if
we later attempt to access that memory or reset and attempt to free the
memory. This patch moves the allocation of the VPD data to init_resources
so that it will be symmetrically freed during release resources.
Signed-off-by: NJohn Allen <jallen@linux.vnet.ibm.com>
Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we request an unsupported mtu value, the vnic server will suggest a
different value. Currently we take the suggested value without question
and login with that value. However, the behavior doesn't seem completely
sane as attempting to change the mtu to some specific value will change
the mtu to some completely different value most of the time. This patch
fixes the issue by logging in with the previously used mtu value and
printing an error message saying that the given mtu is unsupported.
Signed-off-by: NJohn Allen <jallen@linux.vnet.ibm.com>
Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Using newer backing devices can cause the required padding at the end of
buffer as well as the number of queues to change after a failover.
Since we currently assume that these values never change, after a
failover to a backing device with different capabilities, we can get
errors from the vnic server, attempt to free long term buffers that are
no longer there, or not free long term buffers that should be freed.

This patch resolves the issue by checking whether any of these values
change, and if so perform the necessary re-allocations.
Signed-off-by: NJohn Allen <jallen@linux.vnet.ibm.com>
Reviewed-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

That a kevent could not be scheduled is not an error.
Such handlers must be able to deal with multiple events anyway.
As the successful scheduling of a work is a debug event, make
the failure debug priority, too.

V2: coding style
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Reported-by: NCristian Caravena <caravena@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't change endianness when assigning vlan value in cxgb4_tc_flower
code when processing flow match parameters. The value gets converted
to network order as part of filtering code in set_filter_wr.
Signed-off-by: NKumar Sanghvi <kumaras@chelsio.com>
Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For ethtype_key = ETH_P_IPV6, set filter type as 1 in cxgb4_tc_flower
code when processing flow match parameters.
Signed-off-by: NKumar Sanghvi <kumaras@chelsio.com>
Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adds support for the current lineup of Xbox One controllers from PDP
(Performance Designed Products). These controllers are very picky with
their initialization sequence and require an additional 2 packets before
they send any input reports.
Signed-off-by: NMark Furneaux <mark@furneaux.ca>
Reviewed-by: NCameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Replace the original license statement with the SPDX identifier.

Update also the copyright owner adding myself as co-owner of the
copyright.
Signed-off-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Helmut reported a bug about division by zero while
running traffic and doing physical cable pull test.

When the cable unplugged the ppms become zero, so when
dividing the current ppms by the previous ppms in the
next dim iteration there is division by zero.

This patch prevent this division for both ppms and epms.

Fixes: c3164d2f ("net/mlx5e: Added BW check for DIM decision mechanism")
Reported-by: NHelmut Grauer <helmut.grauer@de.ibm.com>
Signed-off-by: NTalat Batheesh <talatb@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt

This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.

However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.

I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).

To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.

Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.

Fixes: 014d6da6 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f5 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f2 ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: stable@vger.kernel.org
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Acked-by: NRob Herring <robh@kernel.org>
Tested-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Packet descriptor generation for IPv6 is broken.
Properly set L3 and L4 protocol flags for IPv6 descriptors.
Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Set some missing fields in the IP control offload buffer. This buffer is
used to enable checksum and TCP segmentation offload in the VNIC server.
The buffer length field and the checksum offloading bits were not set
properly, so fix that here.
Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a new LPM tree is created, we try to replace the trees in the
existing virtual routers with it. If we fail, the tree needs to be
freed.

Currently, this does not happen in the unlikely case where we fail to
bind the tree to the first virtual router, since its reference count
never transitions from 1 to 0.

Fix that by taking a reference before binding the tree.

Fixes: fc922bb0 ("mlxsw: spectrum_router: Use one LPM tree for all virtual routers")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- Fixes addition of stolen memory base address to PTEs.
- Removes support for compression.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>

Commit bbb163e1 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.

This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.

Fixes: bbb163e1 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: NGuillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.
Suggested-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A cleanup of the PM code left an incorrect #ifdef in place, leading
to a harmless build warning:

drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2502:12: error: 'fm10k_suspend' defined but not used [-Werror=unused-function]
drivers/net/ethernet/intel/fm10k/fm10k_pci.c:2475:12: error: 'fm10k_resume' defined but not used [-Werror=unused-function]

It's easier to use __maybe_unused attributes here, since you
can't pick the wrong one.

Fixes: 8249c47c ("fm10k: use generic PM hooks instead of legacy PCIe power hooks")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When saving BOs in the hang state we skip one entry of the
kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
pointer dereference when, later in this function, we iterate over all
BOs to check their ->madv state.

Fixes: ca26d28b ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Cc: <stable@vger.kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180118145821.22344-1-boris.brezillon@free-electrons.com

If the frame samples from a render target that was just written, its
cache flush during the binning step may have occurred before the
previous frame's RCL was completed.  Flush the texture caches again
before starting each RCL job to make sure that the sampling of the
previous RCL's output is correct.

Fixes flickering in the top left of 3DMMES Taiji.
Signed-off-by: NEric Anholt <eric@anholt.net>
Fixes: ca26d28b ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Link: https://patchwork.freedesktop.org/patch/msgid/20171221221722.23809-1-eric@anholt.netReviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

KASAN found a UAF due to dangling pointer. As the report below says,
rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in
rmi_irq_fn.

[  311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core]
[  311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162
[  311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2
[  311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017
[  311.424078] Call Trace:
[  311.424086]  dump_stack+0xae/0x12d
[  311.424090]  ? _atomic_dec_and_lock+0x103/0x103
[  311.424094]  ? show_regs_print_info+0xa/0xa
[  311.424099]  ? input_handle_event+0x10b/0x810
[  311.424104]  print_address_description+0x65/0x229
[  311.424108]  kasan_report.cold.5+0xa7/0x281
[  311.424117]  rmi_f11_attention+0x526/0x5e0 [rmi_core]
[  311.424123]  ? memcpy+0x1f/0x50
[  311.424132]  ? rmi_f11_attention+0x526/0x5e0 [rmi_core]
[  311.424143]  ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core]
[  311.424153]  ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core]
[  311.424163]  ? rmi_irq_fn+0x22c/0x270 [rmi_core]
[  311.424173]  ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[  311.424177]  ? free_irq+0xa0/0xa0
[  311.424180]  ? irq_finalize_oneshot.part.39+0xeb/0x180
[  311.424190]  ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[  311.424193]  ? irq_thread_fn+0x3d/0x80
[  311.424197]  ? irq_finalize_oneshot.part.39+0x180/0x180
[  311.424200]  ? irq_thread+0x21d/0x290
[  311.424203]  ? irq_thread_check_affinity+0x170/0x170
[  311.424207]  ? remove_wait_queue+0x150/0x150
[  311.424212]  ? kasan_unpoison_shadow+0x30/0x40
[  311.424214]  ? __init_waitqueue_head+0xa0/0xd0
[  311.424218]  ? task_non_contending.cold.55+0x18/0x18
[  311.424221]  ? irq_forced_thread_fn+0xa0/0xa0
[  311.424226]  ? irq_thread_check_affinity+0x170/0x170
[  311.424230]  ? kthread+0x19e/0x1c0
[  311.424233]  ? kthread_create_worker_on_cpu+0xc0/0xc0
[  311.424237]  ? ret_from_fork+0x32/0x40

[  311.424244] Allocated by task 899:
[  311.424249]  kasan_kmalloc+0xbf/0xe0
[  311.424252]  __kmalloc_track_caller+0xd9/0x1f0
[  311.424255]  kmemdup+0x17/0x40
[  311.424264]  rmi_set_attn_data+0xa4/0x1b0 [rmi_core]
[  311.424269]  rmi_raw_event+0x10b/0x1f0 [hid_rmi]
[  311.424278]  hid_input_report+0x1a8/0x2c0 [hid]
[  311.424283]  i2c_hid_irq+0x146/0x1d0 [i2c_hid]
[  311.424286]  irq_thread_fn+0x3d/0x80
[  311.424288]  irq_thread+0x21d/0x290
[  311.424291]  kthread+0x19e/0x1c0
[  311.424293]  ret_from_fork+0x32/0x40

[  311.424296] Freed by task 1162:
[  311.424300]  kasan_slab_free+0x71/0xc0
[  311.424303]  kfree+0x90/0x190
[  311.424311]  rmi_irq_fn+0x1b2/0x270 [rmi_core]
[  311.424319]  rmi_irq_fn+0x257/0x270 [rmi_core]
[  311.424322]  irq_thread_fn+0x3d/0x80
[  311.424324]  irq_thread+0x21d/0x290
[  311.424327]  kthread+0x19e/0x1c0
[  311.424330]  ret_from_fork+0x32/0x40

[  311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64
[  311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100)
[  311.424344] The buggy address belongs to the page:
[  311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0
[  311.424353] flags: 0x17ffffc0000100(slab)
[  311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a
[  311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000
[  311.424366] page dumped because: kasan: bad access detected

[  311.424369] Memory state around the buggy address:
[  311.424373]  ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  311.424377]  ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
[  311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
[  311.424384]                                                     ^
[  311.424387]  ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[  311.424391]  ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb

Cc: stable@vger.kernel.org
Signed-off-by: NNick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In the receive queue for 4096 bytes fragments, the page address
set in the SW data0 field of the descriptor is not the one we got
when doing the reassembly in receive. The page structure was retrieved
from the wrong descriptor into SW data0 which is then causing a
page fault when UDP checksum is accessing data above 1500.
Signed-off-by: NRex Chang <rchang@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>