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>
scsi: aacraid: Skip IOP reset on controller panic(SMART Family)
BugLink: http://bugs.launchpad.net/bugs/1668726
When the SMART family of controller panic (KERNEL_PANIC) , they do not
honor IOP resets. So better to skip it and directly perform a IWBR 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 146aa1786d4978795cab5347d810e00236dea1c3) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Decrease adapter health check interval
BugLink: http://bugs.launchpad.net/bugs/1668726
Currently driver checks the health status of the adapter once every 24
hours. When that happens the driver becomes dependent on the kernel to
figure out if the adapter is misbehaving. This might take some time
(when the adapter is idle). The driver currently has support to
restart/recover the controller when it fails, and decreasing the time
interval will help.
Fixed by decreasing check interval from 24 hours to 1 minute
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 11da1b7c4856de05e00f50f54efe2f5349214d5b) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Reload offlined drives after controller reset
BugLink: http://bugs.launchpad.net/bugs/1668726
During the IOP reset stress testing, it was found that the drives can be
marked offline when the adapter controller crashes and IO's are running
in parallel. When the controller does come back from the reset, the drive
that is marked offline is not exposed.
Fixed by removing and adding drives that are marked offline. In addition
invoke a scsi host bus rescan to capture any additional configuration
changes.
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 a2d0321dd532901ea64118ed5a752fa6e447d1da) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Skip wellness sync on controller failure
BugLink: http://bugs.launchpad.net/bugs/1668726
aac_command_thread checks on the health of controller periodically,
using aac_check_health. If the status is an error state KERNEL_PANIC or
anything else. The driver will attempt to restart the adapter, but the
response is not checked in aac_command_thread. This allows the periodic
sync to go thru and lead the driver to a hung state.
Fixed by terminating the periodic loop(intended per original design),
if the controller is not restored to a healthy state.
Cc: stable@vger.kernel.org Fixes: 3d77d8404478353358 (scsi: aacraid: Added support for periodic wellness sync) 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 849ac6a591bf7b5777fdb6ce65030f32a7c73e1a) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668726
Added support to retrieve driver version from a new sysfs variable called
driver_version. It makes it easier for the user to figure out the driver
version that is currently running.
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 30202e067a81754cb78cb823b7ce7e7cddd040e2) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Prevent E3 lockup when deleting units
BugLink: http://bugs.launchpad.net/bugs/1668726
Arrconf management utility at times sends fibs with AdapterProcessed set
in its fibs. This causes the controller to panic and lockup.
Fixed by failing the commands that have AdapterProcessed set in its flag.
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 a0c6143e95c5b9e1f2d83e005e4e86ed3dc6096f) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668726
This issue showed up on a kdump debug(single CPU on powerkvm), when EEH
errors rendered the adapter unusable. The driver correctly detected the
issue and attempted to restart the controller, in doing so the driver
attempted to read the status registers of the controller. This triggered
additional eeh errors which continued for a good 6 minutes.
Fixed by returning without waiting when EEH error is reported.
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 16ae9dd35d374182ce955063100fce66a9974e74) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Use correct channel number for raw srb
BugLink: http://bugs.launchpad.net/bugs/1668726
The channel being used for raw srb commands is retrieved from the utility
sent fibs and is converted into physical channel id. The driver does not
need to to do this since the management utility sends the correct channel
id in the first place and in addition the driver sets inaccurate
information in the cmd sent to the firmware and gets an invalid response.
Fixed by using channel id from srb command.
Cc: stable@vger.kernel.org Fixes: 423400e64d377c0 ("scsi: aacraid: Include HBA direct interface") 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 f3ef4a74dc3712ef0ce60d652aa87b1ba70cb2a4) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Arnd Bergmann [Tue, 7 Feb 2017 12:59:30 +0000 (13:59 +0100)]
scsi: aacraid: avoid open-coded upper_32_bits
BugLink: http://bugs.launchpad.net/bugs/1668726
Shifting a dma_addr_t right by 32 bits causes a compile-time warning
when that type is only 32 bit wide:
drivers/scsi/aacraid/src.c: In function 'aac_src_start_adapter':
drivers/scsi/aacraid/src.c:414:29: error: right shift count >= width of type [-Werror=shift-count-overflow]
This changes the driver to use the predefined macros consistently,
including one correct but open-coded upper_32_bits() instance.
Fixes: d1ef4da8487f ("scsi: aacraid: added support for init_struct_8") Fixes: 423400e64d37 ("scsi: aacraid: Include HBA direct interface") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit 80a94bb357813901e61f2dc80deae2015c50fdcd) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Colin Ian King [Tue, 7 Feb 2017 11:51:29 +0000 (11:51 +0000)]
scsi: aacraid: rcode is unsigned and should be signed int
BugLink: http://bugs.launchpad.net/bugs/1668726
aac_fib_send can return -ve error returns and hence rcode should be
signed. Currently the rcode >= 0 check is always true and -ve errors are
not being checked.
Thanks to Dan Carpenter for spotting my original broken fix to this
issue.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit 76291469772fb932523c2e0003848934cd29e7cb) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Added ioctl to trigger IOP/IWBR reset
BugLink: http://bugs.launchpad.net/bugs/1668726
Added a new ioctl interface to trigger an IOP or IWBR reset from ioctl.
Primary used by management utility to trigger resets.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Dave 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 09867a0e34d20864c3b4b1e49f688470c3f8bdc2) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1668726
This patch adds support to retrieve the unique identifier data (VPD page
83 type3) for Logical drives created on SmartIOC 2000 products. In
addition added a sysfs device structure to expose the id information.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Dave 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 999b3ffc0f3b12bb9eeafabaa88176bb7acb84a1) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
scsi: aacraid: Added support to abort cmd and reset lun
BugLink: http://bugs.launchpad.net/bugs/1668726
Added task management command support to abort any timed out commands
in case of a eh_abort call and to reset lun's in case of eh_reset call.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by: Dave 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 954b2b5ac76d6bde80974c0779d36f054e036aa5) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log