Pavel Shilovsky [Wed, 23 Nov 2016 23:31:54 +0000 (15:31 -0800)]
CIFS: Separate RFC1001 length processing for SMB2 read
BugLink: http://bugs.launchpad.net/bugs/1670508
Allocate and initialize SMB2 read request without RFC1001 length
field to directly call cifs_send_recv() rather than SendReceive2()
in a read codepath.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
(cherry picked from commit b8f57ee8aad414a3122bff72d7968a94baacb9b6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Pavel Shilovsky [Mon, 24 Oct 2016 23:59:57 +0000 (16:59 -0700)]
CIFS: Separate SMB2 sync header processing
BugLink: http://bugs.launchpad.net/bugs/1670508
Do not process RFC1001 length in smb2_hdr_assemble() because
it is not a part of SMB2 header. This allows to cleanup the code
and adds a possibility combine several SMB2 packets into one
for compounding.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
(cherry picked from commit cb200bd6264a80c04e09e8635fa4f3901cabdaef) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Pavel Shilovsky [Wed, 23 Nov 2016 23:14:57 +0000 (15:14 -0800)]
CIFS: Send RFC1001 length in a separate iov
BugLink: http://bugs.launchpad.net/bugs/1670508
In order to simplify further encryption support we need to separate
RFC1001 length and SMB2 header when sending a request. Put the length
field in iov[0] and the rest of the packet into following iovs.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
(cherry picked from commit 738f9de5cdb9175c19d24cfdf90b4543fc3b47bf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Pavel Shilovsky [Tue, 25 Oct 2016 18:38:47 +0000 (11:38 -0700)]
CIFS: Make SendReceive2() takes resp iov
BugLink: http://bugs.launchpad.net/bugs/1670508
Now SendReceive2 frees the first iov and returns a response buffer
in it that increases a code complexity. Simplify this by making
a caller responsible for freeing request buffer itself and returning
a response buffer in a separate iov.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
(cherry picked from commit da502f7df03d2d0b416775f92ae022f3f82bedd5) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Pavel Shilovsky [Mon, 24 Oct 2016 22:33:04 +0000 (15:33 -0700)]
CIFS: Separate SMB2 header structure
BugLink: http://bugs.launchpad.net/bugs/1670508
In order to support compounding and encryption we need to separate
RFC1001 length field and SMB2 header structure because the protocol
treats them differently. This change will allow to simplify parsing
of such complex SMB2 packets further.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
(cherry picked from commit 31473fc4f9653b73750d3792ffce6a6e1bdf0da7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Steve French <sfrench@samba.org>
(cherry picked from commit b9be76d585d48cb25af8db0d35e1ef9030fbe13a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Delvare [Wed, 25 Jan 2017 15:08:17 +0000 (16:08 +0100)]
cifs: Only select the required crypto modules
BugLink: http://bugs.launchpad.net/bugs/1670508
The sha256 and cmac crypto modules are only needed for SMB2+, so move
the select statements to config CIFS_SMB2. Also select CRYPTO_AES
there as SMB2+ needs it.
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Steve French <sfrench@samba.org>
(cherry picked from commit 3692304bba6164be3810afd41b84ecb0e1e41db1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Delvare [Wed, 25 Jan 2017 15:07:29 +0000 (16:07 +0100)]
cifs: Simplify SMB2 and SMB311 dependencies
BugLink: http://bugs.launchpad.net/bugs/1670508
* CIFS_SMB2 depends on CIFS, which depends on INET and selects NLS. So
these dependencies do not need to be repeated for CIFS_SMB2.
* CIFS_SMB311 depends on CIFS_SMB2, which depends on INET. So this
dependency doesn't need to be repeated for CIFS_SMB311.
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Steve French <sfrench@samba.org>
(cherry picked from commit c1ecea87471bbb614f8121e00e5787f363140365) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
James Smart [Mon, 19 Dec 2016 23:07:30 +0000 (15:07 -0800)]
scsi: lpfc: Add missing memory barrier
BugLink: http://bugs.launchpad.net/bugs/1670490
On loosely ordered memory systems (PPC for example), the WQE elements
were being updated in memory, but not necessarily flushed before the
separate doorbell was written to hw which would cause hw to dma the
WQE element. Thus, the hardware occasionally received partially
updated WQE data.
Add the memory barrier after updating the WQE memory.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 6b3b3bdb83b4ad51252d21bb13596db879e51850) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The driver was calculating the adapter command pagesize indicator from
the system pagesize. However, the buffers the driver allocates are only
one size (SLI4_PAGE_SIZE), so no calculation was necessary.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 8ea73db486cda442f0671f4bc9c03a76be398a28) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Using the auto-online acpability does online added memory but does not
update the associated device struct to indicate that the memory is
online. This causes the pseries memory DLPAR code to fail when trying to
remove a LMB that was previously removed and added back. This happens
when validating that the LMB is removable.
This patch reverts to the previous behavior of calling device_online()
to online the LMB when it is DLPAR added and moves the lmb_to_memblock()
routine out of CONFIG_MEMORY_HOTREMOVE now that we call it for add.
Fixes: ec999072442a ("powerpc/pseries: Auto-online hotplugged memory") Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 943db62c316c578f8e2cc6fb81a5f641096b29bf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1670315
Indexed-count remove for memory hotplug guarantees that a contiguous block
of <count> lmbs beginning at a specified <index> will be unassigned (NOT
that <count> lmbs will be removed). Because of Qemu's per-DIMM memory
management, the removal of a contiguous block of memory currently
requires a series of individual calls. Indexed-count remove reduces
this series into a single call.
Signed-off-by: Sahil Mehta <sahilmehta17@gmail.com> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 753843471cbbaeca25a5cab51981ee721ad272f7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1670315
Indexed-count add for memory hotplug guarantees that a contiguous block
of <count> lmbs beginning at a specified <drc index> will be assigned,
any LMBs in this range that are not already assigned will be DLPAR added.
Because of Qemu's per-DIMM memory management, the addition of a contiguous
block of memory currently requires a series of individual calls to add
each LMB in the block. Indexed-count add reduces this series of calls to
a single call for the entire block.
Signed-off-by: Sahil Mehta <sahilmehta17@gmail.com> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 333f7b76865bec24c66710cf352f892d69e3ba0a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1670315
Currently, memory must be hot removed and subsequently re-added in order
to dynamically update the affinity of LMBs specified by a PRRN event.
Earlier implementations of the PRRN event handler ran into issues in which
the hot remove would occur successfully, but a hotplug event would be
initiated from another source and grab the hotplug lock preventing the hot
add from occurring. To prevent this situation, this patch introduces the
notion of a hot "readd" action for memory which atomizes a hot remove and
a hot add into a single, serialized operation on the hotplug queue.
Signed-off-by: John Allen <jallen@linux.vnet.ibm.com> Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit e70d59700fc32c9249b26acd4120303c497e84f1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Allen [Fri, 6 Jan 2017 19:25:53 +0000 (13:25 -0600)]
powerpc/pseries: Make the acquire/release of the drc for memory a seperate step
BugLink: http://bugs.launchpad.net/bugs/1670315
When adding and removing LMBs we should make the acquire/release of
the DRC a separate step to allow for a few improvements. First
this will ensure that LMBs removed during a remove by count operation
are all available if a error occurs and we need to add them back. By
first removeing all the LMBs from the kernel before releasing their
DRCs the LMBs are available to add back should an error occur.
Also, this will allow for faster re-add operations of memory for
PRRN event handling since we can skip the unneeded step of having
to release the DRC and the acquire it back.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: John Allen <jallen@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit c21f515c743687c6c2b3d38227e6ad8e6b733409) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nathan Fontenot [Wed, 11 Jan 2017 17:00:58 +0000 (12:00 -0500)]
powerpc/pseries: Report DLPAR capabilities
BugLink: http://bugs.launchpad.net/bugs/1670315
As we add the ability to do DLPAR of additional devices through
the sysfs interface we need to know which devices are supported.
This adds the reporting of supported devices with a comma separated
list reported in the existing /sys/kernel/dlpar.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 673bc4354d42731018494bb69d63b6513f9ae2bb) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Michael Roth [Tue, 21 Feb 2017 01:12:18 +0000 (19:12 -0600)]
powerpc/pseries: Advertise Hot Plug Event support to firmware
BugLink: http://bugs.launchpad.net/bugs/1670315
With the inclusion of commit 333f7b76865b ("powerpc/pseries: Implement
indexed-count hotplug memory add") and commit 753843471cbb
("powerpc/pseries: Implement indexed-count hotplug memory remove"), we
now have complete handling of the RTAS hotplug event format as described
by PAPR via ACR "PAPR Changes for Hotplug RTAS Events".
This capability is indicated by byte 6, bit 2 (5 in IBM numbering) of
architecture option vector 5, and allows for greater control over
cpu/memory/pci hot plug/unplug operations.
Existing pseries kernels will utilize this capability based on the
existence of the /event-sources/hot-plug-events DT property, so we
only need to advertise it via CAS and do not need a corresponding
FW_FEATURE_* value to test for.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 3dbbaf200f532e01e56168b8339f2981f2cb1d67) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
David Gibson [Fri, 9 Dec 2016 00:07:37 +0000 (11:07 +1100)]
powerpc/pseries: Advertise HPT resizing support via CAS
BugLink: http://bugs.launchpad.net/bugs/1670315
The hypervisor needs to know a guest is capable of using the HPT resizing
PAPR extension in order to make full advantage of it for memory hotplug.
If the hypervisor knows the guest is HPT resize aware, it can size the
initial HPT based on the initial guest RAM size, relying on the guest to
resize the HPT when more memory is hot-added. Without this, the hypervisor
must size the HPT for the maximum possible guest RAM, which can lead to
a huge waste of space if the guest never actually expends to that maximum
size.
This patch advertises the guest's support for HPT resizing via the
ibm,client-architecture-support OF interface. We use bit 5 of byte 6 of
option vector 5 for this purpose, as defined in the PAPR ACR "HPT
resizing option".
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Anshuman Khandual <khandual@linux.vnet.ibm.com> Reviewed-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(back ported from commit 0de0fb09bbce1e1635a0d4c4781af6ec8cbfdb81) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Conflicts:
arch/powerpc/include/asm/prom.h
Paul Mackerras [Mon, 30 Jan 2017 10:21:36 +0000 (21:21 +1100)]
powerpc/64: Enable use of radix MMU under hypervisor on POWER9
BugLink: http://bugs.launchpad.net/bugs/1670315
To use radix as a guest, we first need to tell the hypervisor via
the ibm,client-architecture call first that we support POWER9 and
architecture v3.00, and that we can do either radix or hash and
that we would like to choose later using an hcall (the
H_REGISTER_PROC_TBL hcall).
Then we need to check whether the hypervisor agreed to us using
radix. We need to do this very early on in the kernel boot process
before any of the MMU initialization is done. If the hypervisor
doesn't agree, we can't use radix and therefore clear the radix
MMU feature bit.
Later, when we have set up our process table, which points to the
radix tree for each process, we need to install that using the
H_REGISTER_PROC_TBL hcall.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit cc3d2940133d24000e2866b21e03ce32adfead0a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Mon, 30 Jan 2017 10:21:35 +0000 (21:21 +1100)]
powerpc/pseries: Fixes for the "ibm,architecture-vec-5" options
BugLink: http://bugs.launchpad.net/bugs/1670315
This fixes the byte index values for some of the option bits in
the "ibm,architectur-vec-5" property. The "platform facilities options"
bits are in byte 17 not byte 14, so the upper 8 bits of their
definitions need to be 0x11 not 0x0E. The "sub processor support" option
is in byte 21 not byte 15.
Note none of these options are actually looked up in
"ibm,architecture-vec-5" at this time, so there is no bug.
When checking whether option bits are set, we should check that
the offset of the byte being checked is less than the vector
length that we got from the hypervisor.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 3f4ab2f83b4e443c66549206eb88a9fa5a85d647) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Mon, 30 Jan 2017 10:21:34 +0000 (21:21 +1100)]
powerpc/64: Don't try to use radix MMU under a hypervisor
BugLink: http://bugs.launchpad.net/bugs/1670315
Currently, if the kernel is running on a POWER9 processor under a
hypervisor, it will try to use the radix MMU even though it doesn't have
the necessary code to use radix under a hypervisor (it doesn't negotiate
use of radix, and it doesn't do the H_REGISTER_PROC_TBL hcall). The
result is that the guest kernel will crash when it tries to turn on the
MMU.
This fixes it by looking for the /chosen/ibm,architecture-vec-5
property, and if it exists, clears the radix MMU feature bit, before we
decide whether to initialize for radix or HPT. This property is created
by the hypervisor as a result of the guest calling the
ibm,client-architecture-support method to indicate its capabilities, so
it will indicate whether the hypervisor agreed to us using radix.
Systems without a hypervisor may have this property also (for example,
skiboot creates it), so we check the HV bit in the MSR to see whether we
are running as a guest or not. If we are in hypervisor mode, then we can
do whatever we like including using the radix MMU.
The reason for using this property is that in future, when we have
support for using radix under a hypervisor, we will need to check this
property to see whether the hypervisor agreed to us using radix.
Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines") Cc: stable@vger.kernel.org # v4.7+ Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 18569c1f134e1c5c88228f043c09678ae6052b7c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Seth Forshee [Mon, 6 Mar 2017 13:58:31 +0000 (07:58 -0600)]
UBUNTU: [Config] CONFIG_CRYPTO_DEV_VMX=y
BugLink: http://bugs.launchpad.net/bugs/1666483
We now have fixes for the regressions in 4.10 which necessitated
disabling of this option, so turn it back on.
Naveen N. Rao [Tue, 21 Feb 2017 15:00:47 +0000 (20:30 +0530)]
powerpc/optprobes: Fix TOC handling in optprobes trampoline
BugLink: http://bugs.launchpad.net/bugs/1585741
Optprobes on powerpc are limited to kernel text area. We decided to also
optimize kretprobe_trampoline since that is also in kernel text area.
However,we failed to take into consideration the fact that the same
trampoline is also used to catch function returns from kernel modules.
As an example:
Fix this by loading up the kernel TOC before calling into the kernel.
The original TOC gets restored as part of the usual pt_regs restore.
Fixes: 762df10bad69 ("powerpc/kprobes: Optimize kprobe in kretprobe_trampoline()") Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit f558b37bf4c35a54e1949f6533f39c64091bf60d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The system may panic when initialisation is done when almost all the
memory is assigned to the huge pages using the kernel command line
parameter hugepage=xxxx. Panic may occur like this:
This is a chicken and egg issue where the kernel try to get free
memory when allocating per node data in mem_cgroup_init(), but in that
path mem_cgroup_soft_limit_reclaim() is called which assumes that
these data are allocated.
As mem_cgroup_soft_limit_reclaim() is best effort, it should return
when these data are not yet allocated.
This patch also fixes potential null pointer access in
mem_cgroup_remove_from_trees() and mem_cgroup_update_tree().
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Bader [Thu, 2 Mar 2017 14:38:24 +0000 (15:38 +0100)]
UBUNTU: SAUCE: bcache: Fix bcache device names
I have sent this to upstream (got an ack already) but might be good
to carry as SAUCE until it tickles back.
-Stefan
From 4a5ec18f2bec04cebb0cd5f7ab2a2999b86b7de5 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Wed, 1 Mar 2017 11:28:07 +0100
Subject: [PATCH] UBUNTU: SAUCE: bcache: Fix bcache device names
When adding partition support to bcache, the name assignment was not
updated, resulting in numbers jumping (bcache0, bcache16, bcache32...).
Fix this by taking BCACHE_MINORS into account when assigning the disk
name.
BugLink: https://bugs.launchpad.net/bugs/1667078 Fixes: b8c0d91 (bcache: partition support: add 16 minors per bcacheN device) Cc: <stable@vger.kernel.org> # v4.10 Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
8ee83b2ab3 ("perf/x86/intel/pt: Add support for PTWRITE and power event tracing")
forgot to add format strings to the PT driver. So one could enable these features
by setting corresponding bits in the event config, but not by their mnemonic names.
This patch adds the format strings.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bp@suse.de> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: vince@deater.net Fixes: 8ee83b2ab3 ("perf/x86/intel/pt: Add support for PTWRITE...") Link: http://lkml.kernel.org/r/20170127151644.8585-2-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 5443624bedd0d23e112d5f2a919435182875bce9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Hanjun Guo [Wed, 18 Jan 2017 12:55:02 +0000 (20:55 +0800)]
UBUNTU: SAUCE: msi: platform: make platform_msi_create_device_domain() ACPI aware
The irqdomain creation is carried out in:
platform_msi_create_device_domain()
relies on the fwnode_handle interrupt controller token to associate the
interrupt controller with a specific irqdomain. Current code relies on
the OF layer to retrieve a fwnode_handle for the device representing the
interrupt controller from its device->of_node pointer. This makes
platform_msi_create_device_domain() DT specific whilst it really is not
because after the merge of commit f94277af03ea ("of/platform: Initialise
dev->fwnode appropriately") the fwnode_handle can easily be retrieved
from the dev->fwnode pointer in a firmware agnostic way.
Update platform_msi_create_device_domain() to retrieve the interrupt
controller fwnode_handle from the dev->fwnode pointer so that it can
be used seamlessly in ACPI and DT systems.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg KH <gregkh@linuxfoundation.org>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555489.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Hanjun Guo [Wed, 18 Jan 2017 12:55:01 +0000 (20:55 +0800)]
UBUNTU: SAUCE: ACPI: platform: setup MSI domain for ACPI based platform device
With the platform msi domain created, we can set up the msi domain
for a platform device when it's probed.
In order to do that, we need to get the domain that the platform
device connecting to, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from iort.
After the domain is retrieved, we need a proper way to set the
domain to paltform device, as some platform devices such as an
irqchip needs the msi irqdomain to be the interrupt parent domain,
we need to get irqdomain before platform device is probed but after
the platform device is allocated (the time slot of setting the
msi domain also works for other cases). So simply call
acpi_configure_pmsi_domain() in acpi_platform_notify() for
platform devices will work.
Acked-by: Rafael J. Wysocki <rafael@kernel.org> [for glue.c] Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555559.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Hanjun Guo [Wed, 18 Jan 2017 12:55:00 +0000 (20:55 +0800)]
UBUNTU: SAUCE: ACPI: platform-msi: retrieve dev id from IORT
For devices connecting to ITS, it needs dev id to identify itself, and
this dev id is represented in the IORT table in named component node
[1] for platform devices, so in this patch we will scan the IORT to
retrieve device's dev id.
With the preparation of iort_node_map_platform_id(), a new API
iort_pmsi_get_dev_id() is introduced for that purpose, call it in
its_pmsi_prepare() to make retrieving dev id ACPI aware.
Hanjun Guo [Wed, 18 Jan 2017 12:54:59 +0000 (20:54 +0800)]
UBUNTU: SAUCE: ACPI: IORT: introduce iort_node_map_platform_id() to retrieve dev id
For named components if we want to retrieve the dev id, we know that
there are always two steps involved (second is optional):
(1) Retrieve the initial id (this may well provide the final mapping)
(2) Map the id (optional if (1) represents the map type we need), this
is needed for use cases such as NC (named component) -> SMMU -> ITS
mappings.
we have API iort_node_get_id() for step (1) above and iort_node_map_rid()
for step (2), so create a wrapper iort_node_map_platform_id() to
retrieve the dev id.
iort_node_map_platform_id() will handle the parent type so type handing
in iort_node_get_id() is duplicate, remove it and update current
iort_node_get_id() users to move them over to iort_node_map_platform_id().
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Suggested-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555513.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Hanjun Guo [Wed, 18 Jan 2017 12:54:58 +0000 (20:54 +0800)]
UBUNTU: SAUCE: ACPI: IORT: rename iort_node_map_rid() to make it generic
iort_node_map_rid() was designed to take an input id (that is not
necessarily a PCI requester id) and map it to an output id (eg an SMMU
streamid or an ITS deviceid) according to the mappings provided by an
IORT node mapping entries. This means that the iort_node_map_rid() input
id is not always a PCI requester id as its name, parameters and local
variables suggest, which is misleading.
Apply the s/rid/id substitution to the iort_node_map_rid() mapping
function and its users to make sure its intended usage is clearer.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555527.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
With the introduction of its_pmsi_init_one(), we can add some code
on top for ACPI support of platform MSI.
We are scanning the MADT table to get the ITS entry(ies), then use
the information to create the platform msi domain for devices connect
to it, just like the PCI MSI for ITS did.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Thomas Gleixner <tglx@linutronix.de>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555500.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Adding ACPI support for platform MSI, we need to retrieve the
dev id in ACPI way instead of device tree, we already have
a well formed function its_pmsi_prepare() to get the dev id
but it's OF dependent, so collect OF related code and put them
into a single function to make its_pmsi_prepare() more friendly
to ACPI later.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Tomasz Nowicki <tn@semihalf.com> Cc: Thomas Gleixner <tglx@linutronix.de>
[v8 submission from:
https://www.spinics.net/lists/arm-kernel/msg555502.html ] BugLink: http://bugs.launchpad.net/bugs/1669061 Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
of/irq: improve error report on irq discovery process failure
BugLink: http://bugs.launchpad.net/bugs/1668382
On PowerPC machines some PCI slots might not have level triggered
interrupts capability (also know as level signaled interrupts),
leading of_irq_parse_pci() to complain by presenting error messages
on the kernel log - in this case, the properties "interrupt-map" and
"interrupt-map-mask" are not present on device's node in the device
tree.
This patch introduces a different message for this specific case,
and also reduces its level from error to warning. Besides, we warn
(once) that possibly some PCI slots on the system have no level
triggered interrupts available.
We changed some error return codes too on function of_irq_parse_raw()
in order other failure's cases can be presented in a more precise way.
Before this patch, when an adapter was plugged in a slot without level
interrupts capabilitiy on PowerPC, we saw a generic error message
like this:
[54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
Now, with this applied, we see the following specific message:
[16.154] pci 0014:60:00.1: of_irq_parse_pci: no interrupt-map found,
INTx interrupts not available
Finally, we standardize the error path in of_irq_parse_raw() by always
taking the fail path instead of returning directly from the loop.
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit f1aa54840657fe822b026ab56b75088e08c92362) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The buffered write failure handling code in
xfs_file_iomap_end_delalloc() has a couple minor problems. First, if
written == 0, start_fsb is not rounded down and it fails to kill off a
delalloc block if the start offset is block unaligned. This results in a
lingering delalloc block and broken delalloc block accounting detected
at unmount time. Fix this by rounding down start_fsb in the unlikely
event that written == 0.
Second, it is possible for a failed overwrite of a delalloc extent to
leave dirty pagecache around over a hole in the file. This is because is
possible to hit ->iomap_end() on write failure before the iomap code has
attempted to allocate pagecache, and thus has no need to clean it up. If
the targeted delalloc extent was successfully written by a previous
write, however, then it does still have dirty pages when ->iomap_end()
punches out the underlying blocks. This ultimately results in writeback
over a hole. To fix this problem, unconditionally punch out the
pagecache from XFS before the associated delalloc range.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.
Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
When !CONFIG_CGROUP_WRITEBACK, bdi has single bdi_writeback_congested
at bdi->wb_congested. cgwb_bdi_init() allocates it with kzalloc() and
doesn't do further initialization. This usually works fine as the
reference count gets bumped to 1 by wb_init() and the put from
wb_exit() releases it.
However, when wb_init() fails, it puts the wb base ref automatically
freeing the wb and the explicit kfree() in cgwb_bdi_init() error path
ends up trying to free the same pointer the second time causing a
double-free.
Fix it by explicitly initilizing the refcnt to 1 and putting the base
ref from cgwb_bdi_destroy().
But breaks one thing due to the following old issue:
Buidling Linux kernel with Intel compiler originally depends on acgcc.h
not acintel.h.
So after making Intel compiler build working in ACPICA upstream by
correctly using acintel.h, it becomes unable to build Linux kernel using
Intel compiler as there is no acintel.h in the kernel source tree.
This patch releases acintel.h to Linux kernel and fixes its inclusion in
acenv.h.
Fixes: 9fa1cebdbfff (ACPICA: OSL: Cleanup the inclusion order of the compiler-specific headers) Link: https://github.com/acpica/acpica/commit/b59347d0 Tested-by: Stepan M Mishura <stepan.m.mishura@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper
assignment") is causing behavior regressions in firewalls, as traffic
handled by conntrack helpers is now by default not passed through even
though it was before due to missing CT targets (which were not necessary
before this commit).
The default had to be switched off due to security reasons [1] [2] and
therefore should stay the way it is, but let's be friendly to firewall
admins and issue a warning the first time we're in situation where packet
would be likely passed through with the old default but we're likely going
to drop it on the floor now.
Rewrite the code a little bit as suggested by Linus, so that we avoid
spaghettiing the code even more -- namely the whole decision making
process regarding helper selection (either automatic or not) is being
separated, so that the whole logic can be simplified and code (condition)
duplication reduced.
The goldfish platform code registers the platform device unconditionally
which causes havoc in several ways if the goldfish_pdev_bus driver is
enabled:
- Access to the hardcoded physical memory region, which is either not
available or contains stuff which is completely unrelated.
- Prevents that the interrupt of the serial port can be requested
- In case of a spurious interrupt it goes into a infinite loop in the
interrupt handler of the pdev_bus driver (which needs to be fixed
seperately).
Add a 'goldfish' command line option to make the registration opt-in when
the platform is compiled in.
I'm seriously grumpy about this engineering trainwreck, which has seven
SOBs from Intel developers for 50 lines of code. And none of them figured
out that this is broken. Impressive fail!
Fixes: ddd70cf93d78 ("goldfish: platform device for x86") Reported-by: Gabriel C <nix.or.die@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Since commit 4a510969374a ("tty: Make tty_files_lock per-tty") a new
tty_struct spin lock is taken in the tty release path, but the
USB-serial-console hack was never updated hence leaving the lock of its
"fake" tty uninitialised. This was eventually detected by lockdep.
Make sure to initialise the new lock also for the fake tty to address
this regression.
Yes, this code is a mess, but cleaning it up is left for another day.
Fixes: 4a510969374a ("tty: Make tty_files_lock per-tty") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The current implementation failed to detect short transfers, something
which could lead to bits of the uninitialised heap transfer buffer
leaking to user space.
Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The opticon driver used a control request at open to trigger a CTS
status notification to be sent over the bulk-in pipe. When the driver
was converted to using the generic read implementation, an inverted test
prevented this request from being sent, something which could lead to
TIOCMGET reporting an incorrect CTS state.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Make sure to detect short control transfers and return zero on success
when retrieving the modem status.
This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB:
spcp8x5: add proper modem-status support") has returned TIOCM_LE on
successful retrieval, and avoids leaking bits from the stack on short
transfers.
This also fixes the carrier-detect implementation which since the above
mentioned commit unconditionally has returned true.
FTDI devices use a receive latency timer to periodically empty the
receive buffer and report modem and line status (also when the buffer is
empty).
When a break or error condition is detected the corresponding status
flags will be set on a packet with nonzero data payload and the flags
are not updated until the break is over or further characters are
received.
In order to avoid over-reporting break and error conditions, these flags
must therefore only be processed for packets with payload.
This specifically fixes the case where after an overrun, the error
condition is continuously reported and NULL-characters inserted until
further data is received.
Reported-by: Michael Walle <michael@walle.cc> Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on
break") Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") the FTDI driver has been using a receive latency-timer value of
1 ms instead of the device default of 16 ms.
The latency timer is used to periodically empty a non-full receive
buffer, but a status header is always sent when the timer expires
including when the buffer is empty. This means that a two-byte bulk
message is received every millisecond also for an otherwise idle port as
long as it is open.
Let's restore the pre-2009 behaviour which reduces the rate of the
status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to
62.5 Hz) by not setting ASYNC_LOW_LATENCY by default.
Anyone willing to pay the price for the minimum-latency behaviour should
set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
to set a minimal latency timer.
Reported-by: Antoine Aubert <a.aubert@overkiz.com> Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Make sure to detect short responses when fetching the modem status in
order to avoid parsing uninitialised buffer data and having bits of it
leak to user space.
Note that we still allow for short 1-byte responses.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design
change.
Signed-off-by: Ken Lin <yungching0725@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
$
Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"),
changed the exit path of recvmmsg to always return the datagrams
variable and modified the error paths to set the variable to the error
code returned by recvmsg if necessary.
However in the case sock_error returned an error, the error code was
then ignored, and recvmmsg returned 0.
Change the error path of recvmmsg to correctly return the error code
of sock_error.
The bug was triggered by using recvmmsg on a CAN interface which was
not up. Linux 4.6 and later return 0 in this case while earlier
releases returned -ENETDOWN.
Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path") Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The skbs processed by ip_cmsg_recv() are not guaranteed to
be linear e.g. when sending UDP packets over loopback with
MSGMORE.
Using csum_partial() on [potentially] the whole skb len
is dangerous; instead be on the safe side and use skb_checksum().
Thanks to syzkaller team to detect the issue and provide the
reproducer.
v1 -> v2:
- move the variable declaration in a tighter scope
Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Resizing currently drops consumer lock. This can cause entries to be
reordered, which isn't good in itself. More importantly, consumer can
detect a false ring empty condition and block forever.
Further, nesting of consumer within producer lock is problematic for
tun, since it produces entries in a BH, which causes a lock order
reversal:
To fix, nest producer lock within consumer lock during resize,
and keep consumer lock during the whole swap operation.
Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: stable@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Thu, 8 Dec 2016 10:58:45 +0000 (12:58 +0200)]
net/mlx5: Fix static checker warnings
BugLink: http://bugs.launchpad.net/bugs/1668019
For some reason, sparse doesn't like using an expression of type (!x)
with a bitwise | and &. In order to mitigate that, we use a local variable.
This removes the following sparse complaints on the core driver
(and similar ones on the IB driver too):
drivers/net/ethernet/mellanox/mlx5/core/srq.c:83:9: warning: dubious: !x & y
drivers/net/ethernet/mellanox/mlx5/core/srq.c:96:9: warning: dubious: !x & y
drivers/net/ethernet/mellanox/mlx5/core/port.c:59:9: warning: dubious: !x & y
drivers/net/ethernet/mellanox/mlx5/core/vport.c:561:9: warning: dubious: !x & y
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Matan Barak <matanb@mellanox.com> Reported-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit a61d5ce9cc56e2e41bbb1ad62ca7a16d7e7567bd) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
min(max eswitch table size, max flow counters * num flow groups)
where the max values are read from the firmware and the number of
flow groups is hard-coded as before this change.
We don't know upfront the division of flows to group. This setup allows
each group to be of size up to the where we want to support (we mandate
pairing of flows with counters for offloading). Thus, we don't expect
multiple occurences for a group which in turn adds steering hops.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Tested-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 264d7bf3c1cfd3a128d621b367f57b81d038ba10) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Sun, 11 Dec 2016 19:28:28 +0000 (21:28 +0200)]
net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels
BugLink: http://bugs.launchpad.net/bugs/1668019
Add the missing parts for offloading IPv6 tunnels. This includes
route and neigh lookups and construnction of the IPv6 tunnel headers.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit ce99f6b97fcdcb4e7f6f7e2fe5e5fe6c65585cab) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Tue, 3 Jan 2017 17:03:00 +0000 (19:03 +0200)]
net/mlx5e: Maximize ip tunnel key usage on the TC offloading path
BugLink: http://bugs.launchpad.net/bugs/1668019
Use more fields out of the tunnel key (e.g the tunnel source IP address)
provided by upper layers for the route lookup done on the encap offload path.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 9a941117fb761dcfb4f698f1f67340484b781b90) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Thu, 5 Jan 2017 14:43:29 +0000 (16:43 +0200)]
net/mlx5e: Use the full tunnel key info for encapsulation offload house-keeping
BugLink: http://bugs.launchpad.net/bugs/1668019
Currently we use subset of the input tunnel key fields (id, ip daddr,
dst port) which are provided by upper layers to indentify flows that should
go through the same encapsulation and maintain the HW encapsulation table.
This is redundant and can get us wrong.
Instead, keep a copy of the ip tunnel info provided by the user
through TC and have the tunnel key part as the key to our internal hash.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 76f7444dd5a4349af40e4c67e4b995d4ae3c5c92) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668019
Move around some settings of variables as pre-step to make things
more robust and clear for the ipv6 case in down-stream patch.
This patch doesn't change any functionality.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(back ported from commit 75c33da827365afa6f3d708ad1f7abe18e0ba4a3) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Conflicts:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
Or Gerlitz [Sun, 11 Dec 2016 10:20:53 +0000 (12:20 +0200)]
net/mlx5e: Add TC offloads matching on IPv6 encapsulation headers
BugLink: http://bugs.launchpad.net/bugs/1668019
Enhance the parsing of offloaded TC rules to set HW matching on outer
IPv6 encapsulation headers. This effectively adds support for TC tunnel
key release action (decapsulation) of SRIOV offloads over IPv6 tunnels.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 19f4440141af8cd9b2f280ec38476baa86dc87f9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Sun, 11 Dec 2016 10:15:08 +0000 (12:15 +0200)]
net/mlx5: Use exact encap header size for the FW input buffer
BugLink: http://bugs.launchpad.net/bugs/1668019
The current code is allocating the max encap size supported by
the firmware and not the size requested by the caller, fix that.
Also, spare a warning when the size of the encapsulation headers
is bigger from what is supported by the firmware.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Hadar Hen Zion <hadarh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 073ff3c8e6acdd6bae91a037e6f2d0edeed4165d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Wed, 30 Nov 2016 18:33:33 +0000 (20:33 +0200)]
IB/mlx5: Enable Eth VFs to query their min-inline value for user-space
BugLink: http://bugs.launchpad.net/bugs/1668019
For some mlx5 HW models (CX4, CX4Lx), the VF driver needs to put part
of the packet headers on the TX descriptor so the e-switch can do proper
matching and steering. This is called "min-inline", it's advertized to
the VF by the FW and also enforced on them by the HW, such that if they
don't obey, their packets are dropped.
SRIOV VF libmlx5 instances should take into account the min-inline
value of their vports. For that end, we provide this value through
the vendor response part of init_ucontext command.
The min inline value is reported in a way which will let newer libmlx5
instances realize that they are running over an older kernel and act
accordingly (e.g apply some educated guess).
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
(cherry picked from commit 7898489880f55a9c3a954cd5660a0fb4fd81b625) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Amir Vadai <amir@vadai.me> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5cecb6cc008148b4afc51f7bacfa753e1a957483) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Amir Vadai <amir@vadai.me> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 24d3dc6d27eae19f422a5e216e25d3a16628d4ff) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Amir Vadai <amir@vadai.me> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c7d2b2f5eebe6e76efc11cfd7a600c0748234f3a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Amir Vadai <amir@vadai.me> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 55593960d0d88c6d80b7b3a615dbe09de85f2541) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Thu, 16 Feb 2017 08:31:12 +0000 (10:31 +0200)]
net/sched: Reflect HW offload status
BugLink: http://bugs.launchpad.net/bugs/1668019
Currently there is no way of querying whether a filter is
offloaded to HW or not when using "both" policy (where none
of skip_sw or skip_hw flags are set by user-space).
Add two new flags, "in hw" and "not in hw" such that user
space can determine if a filter is actually offloaded to
hw or not. The "in hw" UAPI semantics was chosen so it's
similar to the "skip hw" flag logic.
If none of these two flags are set, this signals running
over older kernel.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Amir Vadai <amir@vadai.me> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e696028acc458aa3d43ad899371a963eb28336d8) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Yotam Gigi <yotamg@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7a335adad8b06778c0876aa5a5eb8954cd835bf5) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668019
Dump the classifier flags only if non zero and make sure to check
the return status of the handler that puts them into the netlink msg.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 749e6720d2ee10d5221d5d7b8cee8ac5d1cd690e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Blakey [Mon, 16 Jan 2017 08:45:13 +0000 (10:45 +0200)]
net/sched: cls_flower: Disallow duplicate internal elements
BugLink: http://bugs.launchpad.net/bugs/1668019
Flower currently allows having the same filter twice with the same
priority. Actions (and statistics update) will always execute on the
first inserted rule leaving the second rule unused.
This patch disallows that.
Signed-off-by: Paul Blakey <paulb@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a3308d8fd1f58c67aaae52d9468791c2082ab2c7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alex Ng [Mon, 27 Feb 2017 18:55:08 +0000 (13:55 -0500)]
UBUNTU: SAUCE: Tools: hv: vss: Thaw the filesystem and continue after freeze fails
BugLink: http://bugs.launchpad.net/bugs/1470250
If a FREEZE operation takes too long, the driver may time out and move on
to another operation. The daemon is unaware of this and attempts to
notify the driver that the FREEZE succeeded. This results in an error from
the driver and the daemon leaves the filesystem in frozen state.
Fix this by thawing the filesystem and continuing.
Signed-off-by: Alex Ng <alexng@messages.microsoft.com> Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Fixed expander hotplug for SMART family
BugLink: http://bugs.launchpad.net/bugs/1668726
Current driver Hotplug processing code skips over Enclosure channel,
therefore any addition/removal of expander enclosure is not processed.
Additionally device addition code relies on older device type, which
prevents the hotplug of adapter expanders.
Fixed by removing code that skips over Enclosure channels and using the
latest device type for addition or removal or enclosure expanders.
Fixes: 6223a39fe6fbbeef (scsi: aacraid: Added support for hotplug) Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: Dave Carroll <david.carroll@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit a56e574067c20d01d8fc74863fa187dd66da7b94) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Fix a potential spinlock double unlock bug
BugLink: http://bugs.launchpad.net/bugs/1668726
The driver does not unlock the reply queue spin lock after handling SMART
adapter events. Instead it might attempt to unlock an already unlocked
spin lock.
Fixed by making sure the driver locks the spin lock before freeing it.
Thank you dan for finding this issue out.
Fixes: 6223a39fe6fbbeef (scsi: aacraid: Added support for hotplug) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: David Carroll <David.Carroll@microsemi.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit d844752e1801099f92c178845f56412861a2b4af) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Save adapter fib log before an IOP reset
BugLink: http://bugs.launchpad.net/bugs/1668726
Currently the adapter firmware does not save outstanding I/O's log
information when an IOP reset is triggered. This is problematic when
trying to root cause and debug issues.
Fixed by adding sync command to trigger I/O log file save in the adapter
firmware before issuing an IOP reset.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: David Carroll <David.Carroll@microsemi.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit 09624645e1e85df8d68b04de6e0607d696268333) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668726
The driver currently checks the SELF_TEST_FAILED first and then
KERNEL_PANIC next. Under error conditions(boot code failure) both
SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.
The driver has the capability to reset the controller on an KERNEL_PANIC,
but not on SELF_TEST_FAILED.
Fixed by first checking KERNEL_PANIC and then the others.
Cc: stable@vger.kernel.org Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family) Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: David Carroll <David.Carroll@microsemi.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit c421530bf848604e97d0785a03b3fe2c62775083) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>