Setting max_blk_count to 1 here was causing the mmc block layer
to always use the MMC_READ_SINGLE_BLOCK command here, which the
driver does not DMA-accelerate.
Drop the max_blk_ settings here. The mmc host defaults suffice,
along with the max_segs and max_seg_size settings, which I have
now documented in more detail.
Now each MMC command reads 4 512-byte blocks, using DMA instead of
PIO. On my SD card, this increases read performance (measured with dd)
from 167kb/sec to 4.6mb/sec.
clang points out several instances of mismatched types in this drivers,
all coming from a single declaration:
drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
direction = DMA_DEV_TO_MEM;
~ ^~~~~~~~~~~~~~
drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,
The behavior is correct, so this must be a simply typo from
dma_data_direction and dma_transfer_direction being similarly named
types with a similar purpose.
Current ALSA firewire-motu driver uses the value of 'model' field
of unit directory in configuration ROM for modalias for MOTU
FireWire models. However, as long as I checked, Pre8 and
828mk3(Hybrid) have the same value for the field (=0x100800).
When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3,
I got change of the value from 0x100800 to 0x103800. On the other
hand, the value of 'version' field is fixed to 0x00000f. As a quick
glance, the higher 12 bits of the value of 'version' field represent
firmware version, while the lower 12 bits is unknown.
By induction, the value of 'version' field represents actual model.
This commit changes modalias to match the value of 'version' field,
instead of 'model' field. For degug, long name of added sound card
includes hexadecimal value of 'model' field.
Revert "ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec"
BugLink: https://bugs.launchpad.net/bugs/1822671
The backport has some whitespace issues which cause annoying
conflicts with upstream stable patches. The patch is included in
v5.0.5, so revert the version we've been carrying to take the one
from upstream stable.
In commit ffb1c820b8b6 ("scsi: hisi_sas: remove the check of sas_dev status
in hisi_sas_I_T_nexus_reset()"), we introduced a path where we may issue an
internal abort for a SATA device, but without following it with a
softreset.
We need to always follow an internal abort with a software reset, as per HW
programming flow, so add this.
Fixes: ffb1c820b8b6 ("scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset()") Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 0e83fc61eee62979260f6aeadd23ee8b615ee1a2) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Thu, 28 Feb 2019 14:51:02 +0000 (22:51 +0800)]
scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink
BugLink: https://bugs.launchpad.net/bugs/1822385
With default value of register SERDES_CFG, the link is not stable for some
special disks when running IO. According to HW guys' suggestion, need to
make the bit10~19 value of register SERDES_CFG the max value to increase
the reliability of the HiLink.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Yupeng Zhou <zhouyupeng1@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit cf9efd5d92365696580a45e0351208eef0ea1562) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Thu, 28 Feb 2019 14:51:01 +0000 (22:51 +0800)]
scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port
BugLink: https://bugs.launchpad.net/bugs/1822385
If we exchange SAS expander from one SAS controller to other SAS controller
without powering it down, the STP target port will maintain previous
affiliation and reject all subsequent connection requests from other STP
initiator ports with OPEN_REJECT (STP RESOURCES BUSY).
To solve this issue, send HARD RESET to clear the previous affiliation of
STP target port according to SPL (chapter 6.19.4).
We (re-)introduce dev status flag to know if to sleep in NEXUS reset code
or not for remote PHYs. The idea is that if the device is being
initialised, we don't require the delay, and caller would wait for link to
be established, cf. sas_ata_hard_reset().
Co-developed-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 57dbb2b218eb6b4faa39025e3e5974742a4e8986) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
root@(none)$ pwd
/sys/class/sas_phy/phy-0:0
root@(none)$ more enable
1
root@(none)$ more negotiated_linkrate
12.0 Gbit
root@(none)$ echo 0 > enable
root@(none)$ more negotiated_linkrate
12.0 Gbit
root@(none)$
This patch fixes the driver code to set it properly when the PHY comes
down.
If the PHY had been enabled, then set unknown; otherwise, flag as disabled.
The logical place to set the negotiated linkrate for this scenario is PHY
down routine, which is called from the PHY down ISR.
However, it is not possible to know if the PHY comes down due to PHY
disable or loss of link, as sas_phy.enabled member is not set until after
the transport disable routine is complete, which races with the PHY down
ISR.
As an imperfect solution, use sas_phy_data.enable as the flag to know if
the PHY is down due to disable. It's imperfect, as sas_phy_data is internal
to libsas.
I can't see another way without adding a new field to hisi_sas_phy and
managing it, or changing SCSI SAS transport.
Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit efdcad62e7b8a02fcccc5ccca57806dce1482ac8) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiaofei Tan [Thu, 28 Feb 2019 14:50:59 +0000 (22:50 +0800)]
scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw
BugLink: https://bugs.launchpad.net/bugs/1822385
The later revision of v3 hw has added an function of interrupt coalesce
according to time for PHY RX errors. We set the coalesce time to 1s. Then
we print PHY RX errors count when PHY RX errors happen, and don't need to
worry that there may be too much log prints.
Besides, we use hisi_sas_phy.lock to protect error count value. Because we
update them by calling phy_get_events_v3_hw(), which is also used by core
driver (for get PHY events function).
We relocate phy_get_events_v3_hw() to avoid a further declaration.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit aaeb82323d12f3b61015878e035d74600e1f2c85) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Thu, 28 Feb 2019 14:50:58 +0000 (22:50 +0800)]
scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO
BugLink: https://bugs.launchpad.net/bugs/1822385
For internal IO and SMP IO, there is a time-out timer for them. In the
timer handler, it checks whether IO is done according to the flag
task->task_state_lock.
There is an issue which may cause system suspended: internal IO or SMP IO
is sent, but at that time because of hardware exception (such as inject
2Bit ECC error), so IO is not completed and also not timeout. But, at that
time, the SAS controller reset occurs to recover system. It will release
the resource and set the status of IO to be SAS_TASK_STATE_DONE, so when IO
timeout, it will never complete the completion of IO and wait for ever.
Xiang Chen [Thu, 28 Feb 2019 14:50:57 +0000 (22:50 +0800)]
scsi: hisi_sas: Change return variable type in phy_up_v3_hw()
BugLink: https://bugs.launchpad.net/bugs/1822385
According to the tool fortify, phy_up_v3_hw() returns signed value, while
it should return an unsigned value.
So change variable "res" from int to irq_return_t.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit fba770c6682447f1998267f4143595e77be4f112) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Garry [Wed, 6 Feb 2019 10:52:56 +0000 (18:52 +0800)]
scsi: hisi_sas: Do some more tidy-up
BugLink: https://bugs.launchpad.net/bugs/1822385
Do some very minor tidy-up, for things like needlessly initing variable and
not leaving whitespace before quote endings.
Originally-from: Xiang Chen <chenxiang66@hisilicon.com>
Originally-from: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 4a8bec88f71a94f646aeccf26404da710019811d) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Then it decreases the performance regression that fio and CQ interrupts are
processed on different node.
For user control irq affinity mode, keep it as before.
To realize it, also need to distinguish the usage of dq lock and sas_dev
lock.
We mark as experimental due to ongoing discussion on managed MSI IRQ
during hotplug:
https://marc.info/?l=linux-scsi&m=154876335707751&w=2
We're almost at the point where we can expose multiple queues to the upper
layer for SCSI MQ, but we need to sort out the per-HBA tags performance
issue.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 4fefe5bbf599d6c6bee6b2ee376be789b33ca571) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Garry [Wed, 6 Feb 2019 10:52:54 +0000 (18:52 +0800)]
scsi: hisi_sas: Issue internal abort on all relevant queues
BugLink: https://bugs.launchpad.net/bugs/1822385
To support queue mapped to a CPU, it needs to be ensured that issuing an
internal abort is safe, in that it is guaranteed that an internal abort is
processed for a single IO or a device after all the relevant command(s)
which it is attempting to abort have been processed by the controller.
Currently we only deliver commands for any device on a single queue to
solve this problem, as we know that commands issued on the same queue will
be processed in order, and we will not have a scenario where the internal
abort is racing against a command(s) which it is trying to abort.
To enqueue commands on queue mapped to a CPU, choosing a queue for an
command is based on the associated queue for the current CPU, so this is
not safe for internal abort since it would definitely not be guaranteed
that commands for the command devices are issued on the same queue.
To solve this issue, we take a bludgeoning approach, and issue a separate
internal abort on any queue(s) relevant to the command or device, in that
we will be guaranteed that at least one of these internal aborts will be
received last in the controller.
So, for aborting a single command, we can just force the internal abort to
be issued on the same queue as the command which we are trying to abort.
For aborting all commands associated with a device, we issue a separate
internal abort on all relevant queues. Issuing multiple internal aborts in
this fashion would have not side affect.
Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 795f25a31b542df93bff892ce46390f9befa2135) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Wed, 6 Feb 2019 10:52:53 +0000 (18:52 +0800)]
scsi: hisi_sas: change queue depth from 512 to 4096
BugLink: https://bugs.launchpad.net/bugs/1822385
If sending IOs to many disks from single queue, it is possible that the
queue may be full. To avoid the situation, change queue depth from 512 to
4096 which is the max number of IOs for v3 hw.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 1273d65f29045df915ff1448672cca22f7c078e6) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 7c5e136363919d8dfa27d4bcd4b3ecedfa234997) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ede2afb9c8ed784cdf1b6de9cd02f044668b842a) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Fix this by relocating the scsi_get_prot_op() callsite.
Fixes: d6a9000b81be ("scsi: hisi_sas: Add support for DIF feature for v2 hw") Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit e1ba0b0b44512c5a209526c09ea3eb7d256b6951) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 26889e5ec87a0e4ef31ba2dc4f60933be0dbdffe) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit d1548e9c323f51e6d7da4392ec4368cfc5425a78) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiaofei Tan [Fri, 25 Jan 2019 14:22:35 +0000 (22:22 +0800)]
scsi: hisi_sas: Fix losing directly attached disk when hot-plug
BugLink: https://bugs.launchpad.net/bugs/1822385
Hot-plugging SAS wire of direct hard disk backplane may cause disk lost. We
have done this test with several types of SATA disk from different venders,
and only two models from Seagate has this problem, ST4000NM0035-1V4107 and
ST3000VM002-1ET166.
The root cause is that the disk doesn't send D2H frame after OOB finished.
SAS controller will issue phyup interrupt only when D2H frame is received,
otherwise, will be waiting there all the time.
When this issue happen, we can find the disk again with link reset. To fix
this issue, we setup an timer after OOB finished. If the PHY is not up in
20s, do link reset. Notes: the 20s is an experience value.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b6c9b15e44090aee2a7fba646b06ff166f595b16) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1822385
The SAS controller cannot support a programmed minimum linkrate of > 1.5G
(it will always negotiate to 1.5G at least), so just reject it.
This solves a strange situation where the PHY negotiated linkrate may be
less than the programmed minimum linkrate.
Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit eb44e4d7b5a3090f0114927f42ae575c29664a09) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Fri, 25 Jan 2019 14:22:32 +0000 (22:22 +0800)]
scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset()
BugLink: https://bugs.launchpad.net/bugs/1822385
When issing a hardreset to a SATA device when running IO, it is possible
that abnormal CQs of the device are returned. Then enter error handler, it
doesn't enter function hisi_sas_abort_task() as there is no timeout IO, and
it doesn't set device as HISI_SAS_DEV_EH. So when hardreset by libata
later, it actually doesn't issue hardreset as there is a check to judge
whether device is in error.
For this situation, actually need to hardreset the device to recover.
So remove the check of sas_dev status in hisi_sas_I_T_nexus_reset().
Before we add the check to avoid the endless loop of reset for
directly-attached SATA device at probe time, actually we flutter it for
it, so it is not necessary to add the check now.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ffb1c820b8b6a0466a51c467dcd8c0add77d00a7) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Fri, 25 Jan 2019 14:22:31 +0000 (22:22 +0800)]
scsi: hisi_sas: shutdown axi bus to avoid exception CQ returned
BugLink: https://bugs.launchpad.net/bugs/1822385
When injecting 2 bit ECC error, it will cause fatal AXI interrupts. Before
the recovery of SAS controller reset, the internal of SAS controller is in
error. If CQ interrupts return at the time, actually it is exception CQ
interrupt, and it may cause resource release in disorder.
To avoid the exception situation, shutdown AXI bus after fatal AXI
interrupt. In SAS controller reset, it will restart AXI bus. For later
version of v3 hw, hardware will shutdown AXI bus for this situation, so
just fix current ver of v3 hw.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 5c31b0c677531c2b8b4e29b3cfb923df663f39b7) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiang Chen [Fri, 25 Jan 2019 14:22:30 +0000 (22:22 +0800)]
scsi: hisi_sas: send primitive NOTIFY to SSP situation only
BugLink: https://bugs.launchpad.net/bugs/1822385
Send primitive NOTIFY to SSP situation only, or it causes underflow issue
when sending IO. Also rename hisi_sas_hw.sl_notify() to hisi_sas_hw.
sl_notify_ssp().
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 569eddcf3a0f4efff4ef96a7012010e0f7daa8b4) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Aaron Liu [Mon, 14 Jan 2019 08:08:32 +0000 (16:08 +0800)]
drm/amdgpu/psp: ignore psp response status
BugLink: https://bugs.launchpad.net/bugs/1822267
In some cases, psp response status is not 0 even there is no
problem while the command is submitted. Some version of PSP FW
doesn't write 0 to that field.
So here we would like to only print a warning instead of an error
during psp initialization to avoid breaking hw_init and it doesn't
return -EINVAL.
Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Xiangliang Yu<Xiangliang.Yu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Paul Menzel <pmenzel+amd-gfx@molgen.mpg.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 466bcb75b0791ba301817cdadeed20398f2224fe) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1822267
There isn't ucode when executing INVOKE command, so current code can't
check the failure of INVOKE command.
Andrea Righi [Mon, 1 Apr 2019 12:54:40 +0000 (14:54 +0200)]
btrfs: raid56: properly unmap parity page in finish_parity_scrub()
Buglink: https://bugs.launchpad.net/bugs/1812845
Parity page is incorrectly unmapped in finish_parity_scrub(), triggering
a reference counter bug on i386, i.e.:
The reason is that kunmap(p_page) was completely left out, so we never
did an unmap for the p_page and the loop unmapping the rbio page was
iterating over the wrong number of stripes: unmapping should be done
with nr_data instead of rbio->real_stripes.
- run btrfs scrub in a loop:
# while :; do btrfs scrub start -BR /mnt; done
BugLink: https://bugs.launchpad.net/bugs/1812845 Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
(cherry picked from commit 3897b6f0a859288c22fb793fad11ec2327e60fcd) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795857
CONFIG_DRM_BOCHS got disabled for LP#1378648 from 2014 which does not
seems to be an issue anymore. On the contrary, disabling it breaks
using Ubuntu in a QEMU/KVM virtuak machine when passing its 'std' VGA
driver.
Re-enable BOCHS again as module to ensure one can use Ubuntu in
QEMU/KVM backed virtual machines in common default settings.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Timo Aaltonen [Fri, 29 Mar 2019 08:49:52 +0000 (10:49 +0200)]
UBUNTU: SAUCE: drm/nouveau: Disable nouveau driver by default
BugLink: https://bugs.launchpad.net/bugs/1822026
This driver is buggy, it doesn't make sense to keep it enabled
by default. It can still be used by adding 'nouveau.modeset=1'
to the kernel cmdline.
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Anusha Srivatsa [Fri, 29 Mar 2019 09:17:26 +0000 (11:17 +0200)]
drm/i915/cml: Add CML PCI IDS
BugLink: http://bugs.launchpad.net/bugs/1821863
Comet Lake is a Intel Processor containing Gen9
Intel HD Graphics. This patch adds the initial set of
PCI IDs. Comet Lake comes off of Coffee Lake - adding
the IDs to Coffee Lake ID list.
More support and features will be in the patches that follow.
David Howells [Mon, 25 Mar 2019 22:09:50 +0000 (15:09 -0700)]
UBUNTU: SAUCE: (efi-lockdown) bpf: Restrict kernel image access functions when the kernel is locked down
There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction.
Completely prohibit the use of BPF when the kernel is locked down.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Matthew Garrett <matthewgarrett@google.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
SDEI may be one of two types of event, normal and critical. Critical
events can interrupt normal events, so these must have separate
fixmap slots and locks in case both event types are in use.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit f9f05395f384ee858520b6c65d7e3e436af20c53) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1822005
APEI's Generic Hardware Error Source structures do not describe
whether the SDEI event is shared or private, as this information is
discoverable via the API.
GHES needs to know whether an event is normal or critical to avoid
sharing locks or fixmap entries, but GHES shouldn't have to know about
the SDEI API.
Add a helper to register the GHES using the appropriate normal or
critical callback.
Signed-off-by: James Morse <james.morse@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit f96935d3bc38a5f4b5188b6470a10e3fb8c3f0cc) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:57 +0000 (18:48 +0000)]
ACPI / APEI: Use separate fixmap pages for arm64 NMI-like notifications
BugLink: https://bugs.launchpad.net/bugs/1822005
Now that ghes notification helpers provide the fixmap slots and
take the lock themselves, multiple NMI-like notifications can
be used on arm64.
These should be named after their notification method as they can't
all be called 'NMI'. x86's NOTIFY_NMI already is, change the SEA
fixmap entry to be called FIX_APEI_GHES_SEA.
Future patches can add support for FIX_APEI_GHES_SEI and
FIX_APEI_GHES_SDEI_{NORMAL,CRITICAL}.
Because all of ghes.c builds on both architectures, provide a
constant for each fixmap entry that the architecture will never
use.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit b972d2eaf0c7021579755eec6b2b79e0f5bc7930) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:56 +0000 (18:48 +0000)]
ACPI / APEI: Only use queued estatus entry during in_nmi_queue_one_entry()
BugLink: https://bugs.launchpad.net/bugs/1822005
Each struct ghes has an worst-case sized buffer for storing the
estatus. If an error is being processed by ghes_proc() in process
context this buffer will be in use. If the error source then triggers
an NMI-like notification, the same buffer will be used by
in_nmi_queue_one_entry() to stage the estatus data, before
__process_error() copys it into a queued estatus entry.
Merge __process_error()s work into in_nmi_queue_one_entry() so that
the queued estatus entry is used from the beginning. Use the new
ghes_peek_estatus() to know how much memory to allocate from
the ghes_estatus_pool before reading the records.
Reported-by: Borislav Petkov <bp@suse.de> Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de>
Change since v6:
* Added a comment explaining the 'ack-error, then goto no_work'.
* Added missing esatus-clearing, which is necessary after reading the GAS, Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit d9f608dc156487b55cb17c2ec591b06e53a6de64) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:55 +0000 (18:48 +0000)]
ACPI / APEI: Split ghes_read_estatus() to allow a peek at the CPER length
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_read_estatus() reads the record address, then the record's
header, then performs some sanity checks before reading the
records into the provided estatus buffer.
To provide this estatus buffer the caller must know the size of the
records in advance, or always provide a worst-case sized buffer as
happens today for the non-NMI notifications.
Add a function to peek at the record's header to find the size. This
will let the NMI path allocate the right amount of memory before reading
the records, instead of using the worst-case size, and having to copy
the records.
Split ghes_read_estatus() to create __ghes_peek_estatus() which
returns the address and size of the CPER records.
Signed-off-by: James Morse <james.morse@arm.com>
Changes since v7:
* Grammar
* concistent argument ordering
Changes since v6:
* Additional buf_addr = 0 error handling
* Moved checking out of peek-estatus
* Reworded an error message so we can tell them apart Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit e00a6e3392cb623b7ac4d61c5e1c1234b4520cad) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:54 +0000 (18:48 +0000)]
ACPI / APEI: Make GHES estatus header validation more user friendly
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_read_estatus() checks various lengths in the top-level header to
ensure the CPER records to be read aren't obviously corrupt.
Take the opportunity to make this more user-friendly, printing a
(ratelimited) message about the nature of the header format error.
Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: James Morse <james.morse@arm.com>
[ rjw: Add missing 'static' ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit f2a681b9160b9c80826b3062e71371cfc82b4863) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:53 +0000 (18:48 +0000)]
ACPI / APEI: Pass ghes and estatus separately to avoid a later copy
BugLink: https://bugs.launchpad.net/bugs/1822005
The NMI-like notifications scribble over ghes->estatus, before
copying it somewhere else. If this interrupts the ghes_probe() code
calling ghes_proc() on each struct ghes, the data is corrupted.
All the NMI-like notifications should use a queued estatus entry
from the beginning, instead of the ghes version, then copying it.
To do this, break up any use of "ghes->estatus" so that all
functions take the estatus as an argument.
This patch just moves these ghes->estatus dereferences into separate
arguments, no change in behaviour. struct ghes becomes unused in
ghes_clear_estatus() as it only wanted ghes->estatus, which we now
pass directly. This is removed.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit f2a7e059aa7a6a22a6f4612f31ee29e726a3bfd0) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:52 +0000 (18:48 +0000)]
ACPI / APEI: Let the notification helper specify the fixmap slot
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_copy_tofrom_phys() uses a different fixmap slot depending on in_nmi().
This doesn't work when there are multiple NMI-like notifications, that
could interrupt each other.
As with the locking, move the chosen fixmap_idx to the notification helper.
This only matters for NMI-like notifications, anything calling
ghes_proc() can use the IRQ fixmap slot as its already holding an irqsave
spinlock.
This lets us collapse the ghes_ioremap_pfn_*() helpers.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit b484079b9f520cc9a0797d885f1cd7f64b72b1b2) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:51 +0000 (18:48 +0000)]
ACPI / APEI: Move locking to the notification helper
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_copy_tofrom_phys() takes different locks depending on in_nmi().
This doesn't work if there are multiple NMI-like notifications, that
can interrupt each other.
Now that NOTIFY_SEA is always called in the same context, move the
lock-taking to the notification helper. The helper will always know
which lock to take. This avoids ghes_copy_tofrom_phys() taking a guess
based on in_nmi().
This splits NOTIFY_NMI and NOTIFY_SEA to use different locks. All
the other notifications use ghes_proc(), and are called in process
or IRQ context. Move the spin_lock_irqsave() around their ghes_proc()
calls.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 3b880cbe4df5dd78a2b2279dbe16db9d193412ca) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:50 +0000 (18:48 +0000)]
arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
BugLink: https://bugs.launchpad.net/bugs/1822005
To split up APEIs in_nmi() path, the caller needs to always be
in_nmi(). Add a helper to do the work and claim the notification.
When KVM or the arch code takes an exception that might be a RAS
notification, it asks the APEI firmware-first code whether it wants
to claim the exception. A future kernel-first mechanism may be queried
afterwards, and claim the notification, otherwise we fall through
to the existing default behaviour.
The NOTIFY_SEA code was merged before considering multiple, possibly
interacting, NMI-like notifications and the need to consider kernel
first in the future. Make the 'claiming' behaviour explicit.
Restructuring the APEI code to allow multiple NMI-like notifications
means any notification that might interrupt interrupts-masked
code must always be wrapped in nmi_enter()/nmi_exit(). This will
allow APEI to use in_nmi() to use the right fixmap entries.
Mask SError over this window to prevent an asynchronous RAS error
arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
Signed-off-by: James Morse <james.morse@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Tyler Baicar <tbaicar@codeaurora.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit d44f1b8dd7e66d80cc4205809e5ace866bd851da) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:49 +0000 (18:48 +0000)]
KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
BugLink: https://bugs.launchpad.net/bugs/1822005
To split up APEIs in_nmi() path, the caller needs to always be
in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
out into a header file.
Currently guest synchronous external aborts are claimed as RAS
notifications by handle_guest_sea(), which is hidden in the arch codes
mm/fault.c. 32bit gets a dummy declaration in system_misc.h.
There is going to be more of this in the future if/when the kernel
supports the SError-based firmware-first notification mechanism and/or
kernel-first notifications for both synchronous external abort and
SError. Each of these will come with some Kconfig symbols and a
handful of header files.
Create a header file for all this.
This patch gives handle_guest_sea() a 'kvm_' prefix, and moves the
declarations to kvm_ras.h as preparation for a future patch that moves
the ACPI-specific RAS code out of mm/fault.c.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Tyler Baicar <tbaicar@codeaurora.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 0db5e0223035b2c84e6186831fc27511270af812) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:48 +0000 (18:48 +0000)]
ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
BugLink: https://bugs.launchpad.net/bugs/1822005
Now that the estatus queue can be used by more than one notification
method, we can move notifications that have NMI-like behaviour over.
Switch NOTIFY_SEA over to use the estatus queue. This makes it behave
in the same way as x86's NOTIFY_NMI.
Remove Kconfig's ability to turn ACPI_APEI_SEA off if ACPI_APEI_GHES
is selected. This roughly matches the x86 NOTIFY_NMI behaviour, and means
each architecture has at least one user of the estatus-queue, meaning it
doesn't need guarding with ifdef.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 255097c82d821bb2bb18e9c7011841ee7342840f) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:47 +0000 (18:48 +0000)]
ACPI / APEI: Move NOTIFY_SEA between the estatus-queue and NOTIFY_NMI
BugLink: https://bugs.launchpad.net/bugs/1822005
The estatus-queue code is currently hidden by the NOTIFY_NMI #ifdefs.
Once NOTIFY_SEA starts using the estatus-queue we can stop hiding
it as each architecture has a user that can't be turned off.
Split the existing CONFIG_HAVE_ACPI_APEI_NMI block in two, and move
the SEA code into the gap.
Move the code around ... and changes the stale comment describing
why the status queue is necessary: printk() is no longer the issue,
its the helpers like memory_failure_queue() that aren't nmi safe.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9c9d08051380ad3f6e6376d4383615771c59fd99) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:46 +0000 (18:48 +0000)]
ACPI / APEI: Don't allow ghes_ack_error() to mask earlier errors
BugLink: https://bugs.launchpad.net/bugs/1822005
During ghes_proc() we use ghes_ack_error() to tell an external agent
we are done with these records and it can re-use the memory.
rc may hold an error returned by ghes_read_estatus(), ENOENT causes
us to skip ghes_ack_error() (as there is nothing to ack), but rc may
also by EIO, which gets supressed.
ghes_clear_estatus() is where we mark the records as processed for
non GHESv2 error sources, and already spots the ENOENT case as
buf_paddr is set to 0 by ghes_read_estatus().
Move the ghes_ack_error() call in here to avoid extra logic with
the return code in ghes_proc().
This enables GHESv2 acking for NMI-like error sources. This is safe
as the buffer is pre-mapped by map_gen_v2() before the GHES is added
to any NMI handler lists.
This same pre-mapping step means we can't receive an error from
apei_read()/write() here as apei_check_gar() succeeded when it
was mapped, and the mapping was cached, so the address can't be
rejected at runtime. Remove the error-returns as this is now
called from a function with no return.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 06ddeadc8d1c4f704b8956f239263bca75a3add8) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:45 +0000 (18:48 +0000)]
ACPI / APEI: Generalise the estatus queue's notify code
BugLink: https://bugs.launchpad.net/bugs/1822005
Refactor the estatus queue's pool notification routine from
NOTIFY_NMI's handlers. This will allow another notification
method to use the estatus queue without duplicating this code.
Add rcu_read_lock()/rcu_read_unlock() around the list
list_for_each_entry_rcu() walker. These aren't strictly necessary as
the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
critical section.
in_nmi_queue_one_entry() is separate from the rcu-list walker for a
later caller that doesn't need to walk a list.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
[ rjw: Drop unnecessary err variable in two places ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit ee2eb3d4ee175c2fb5c7f67e84f5fe40a8147d92) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_read_estatus() sets a flag in struct ghes if the buffer of
CPER records needs to be cleared once the records have been
processed. This flag value is a problem if a struct ghes can be
processed concurrently, as happens at probe time if an NMI arrives
for the same error source. The NMI clears the flag, meaning the
interrupted handler may never do the ghes_estatus_clear() work.
The GHES_TO_CLEAR flags is only set at the same time as
buffer_paddr, which is now owned by the caller and passed to
ghes_clear_estatus(). Use this value as the flag.
A non-zero buf_paddr returned by ghes_read_estatus() means
ghes_clear_estatus() should clear this address. ghes_read_estatus()
already checks for a read of error_status_address being zero,
so CPER records cannot be written here.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 5cc6c68287ae4be22c40b41cf6844746cddebbcc) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:43 +0000 (18:48 +0000)]
ACPI / APEI: Remove spurious GHES_TO_CLEAR check
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes_notify_nmi() checks ghes->flags for GHES_TO_CLEAR before going
on to __process_error(). This is pointless as ghes_read_estatus()
will always set this flag if it returns success, which was checked
earlier in the loop. Remove it.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 7d49f2c75af22f980fd716a13634a16cfb7dd8a7) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:42 +0000 (18:48 +0000)]
ACPI / APEI: Don't store CPER records physical address in struct ghes
BugLink: https://bugs.launchpad.net/bugs/1822005
When CPER records are found the address of the records is stashed
in the struct ghes. Once the records have been processed, this
address is overwritten with zero so that it won't be processed
again without being re-populated by firmware.
This goes wrong if a struct ghes can be processed concurrently,
as can happen at probe time when an NMI occurs. If the NMI arrives
on another CPU, the probing CPU may call ghes_clear_estatus() on the
records before the handler had finished with them.
Even on the same CPU, once the interrupted handler is resumed, it
will call ghes_clear_estatus() on the NMIs records, this memory may
have already been re-used by firmware.
Avoid this stashing by letting the caller hold the address. A
later patch will do away with the use of ghes->flags in the
read/clear code too.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit eeb2555779471abdbcc6289a52dc54ce513feaf2) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:41 +0000 (18:48 +0000)]
ACPI / APEI: Make estatus pool allocation a static size
BugLink: https://bugs.launchpad.net/bugs/1822005
Adding new NMI-like notifications duplicates the calls that grow
and shrink the estatus pool. This is all pretty pointless, as the
size is capped to 64K. Allocate this for each ghes and drop
the code that grows and shrinks the pool.
Suggested-by: Borislav Petkov <bp@suse.de> Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit fb7be08f1a091ec243780bfdad4bf0c492057808) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:40 +0000 (18:48 +0000)]
ACPI / APEI: Make hest.c manage the estatus memory pool
BugLink: https://bugs.launchpad.net/bugs/1822005
ghes.c has a memory pool it uses for the estatus cache and the estatus
queue. The cache is initialised when registering the platform driver.
For the queue, an NMI-like notification has to grow/shrink the pool
as it is registered and unregistered.
This is all pretty noisy when adding new NMI-like notifications, it
would be better to replace this with a static pool size based on the
number of users.
As a precursor, move the call that creates the pool from ghes_init(),
into hest.c. Later this will take the number of ghes entries and
consolidate the queue allocations.
Remove ghes_estatus_pool_exit() as hest.c doesn't have anywhere to put
this.
The pool is now initialised as part of ACPI's subsys_initcall():
(acpi_init(), acpi_scan_init(), acpi_pci_root_init(), acpi_hest_init())
Before this patch it happened later as a GHES specific device_initcall().
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit e147133a42cb9df6cbc99503fdf58d0e6388bf2a) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:39 +0000 (18:48 +0000)]
ACPI / APEI: Switch estatus pool to use vmalloc memory
BugLink: https://bugs.launchpad.net/bugs/1822005
The ghes code is careful to parse and round firmware's advertised
memory requirements for CPER records, up to a maximum of 64K.
However when ghes_estatus_pool_expand() does its work, it splits
the requested size into PAGE_SIZE granules.
This means if firmware generates 5K of CPER records, and correctly
describes this in the table, __process_error() will silently fail as it
is unable to allocate more than PAGE_SIZE.
Switch the estatus pool to vmalloc() memory. On x86 vmalloc() memory
may fault and be fixed up by vmalloc_fault(). To prevent this call
vmalloc_sync_all() before an NMI handler could discover the memory.
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 0ac234be1a9497498e57d958f4251f5257b116b4) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:38 +0000 (18:48 +0000)]
ACPI / APEI: Remove silent flag from ghes_read_estatus()
BugLink: https://bugs.launchpad.net/bugs/1822005
Subsequent patches will split up ghes_read_estatus(), at which
point passing around the 'silent' flag gets annoying. This is to
suppress prink() messages, which prior to commit 42a0bb3f7138
("printk/nmi: generic solution for safe printk in NMI"), were
unsafe in NMI context.
This is no longer necessary, remove the flag. printk() messages
are batched in a per-cpu buffer and printed via irq-work, or a call
back from panic().
Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 93066e9aefa16beb10bb4a32c2f1657822b57753) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Morse [Tue, 29 Jan 2019 18:48:37 +0000 (18:48 +0000)]
ACPI / APEI: Don't wait to serialise with oops messages when panic()ing
BugLink: https://bugs.launchpad.net/bugs/1822005
oops_begin() exists to group printk() messages with the oops message
printed by die(). To reach this caller we know that platform firmware
took this error first, then notified the OS via NMI with a 'panic'
severity.
Don't wait for another CPU to release the die-lock before panic()ing,
our only goal is to print this fatal error and panic().
This code is always called in_nmi(), and since commit 42a0bb3f7138
("printk/nmi: generic solution for safe printk in NMI"), it has been
safe to call printk() from this context. Messages are batched in a
per-cpu buffer and printed via irq-work, or a call back from panic().
Link: https://patchwork.kernel.org/patch/10313555/ Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 78b0b690f6558ed788dccafa45965325dd11ba89) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
ZhangXiaoxu [Wed, 27 Mar 2019 18:57:21 +0000 (18:57 +0000)]
inotify: Fix fsnotify_mark refcount leak in inotify_update_existing_watch()
Commit 4d97f7d53da7dc83 ("inotify: Add flag IN_MASK_CREATE for
inotify_add_watch()") forgot to call fsnotify_put_mark() with
IN_MASK_CREATE after fsnotify_find_mark()
Fixes: 4d97f7d53da7dc83 ("inotify: Add flag IN_MASK_CREATE for inotify_add_watch()") Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: Jan Kara <jack@suse.cz>
CVE-2019-9857
(cherry picked from commit 62c9d2674b31d4c8a674bee86b7edc6da2803aea) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-By: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tyler Hicks [Wed, 27 Mar 2019 17:45:13 +0000 (17:45 +0000)]
UBUNTU: [Config] Disable a.out support
BugLink: https://launchpad.net/bugs/1818552
The a.out core dump handler is broken and will be removed in 5.1 with
upstream commit 08300f4402ab ("a.out: remove core dumping support").
Additionally, all a.out support will be deprecated in 5.1 with upstream
commit eac616557050 ("x86: Deprecate a.out support") and completely
removed in a future release.
Disable it in Ubuntu since it is risky to leave enabled and there are
likely no users that depend on it.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-By: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Garry [Wed, 27 Mar 2019 16:47:10 +0000 (10:47 -0600)]
scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery
BugLink: https://bugs.launchpad.net/bugs/1821408
+----------+ +----------+
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SAS disk
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SAS disk
|initiator | | |
| device |--- 3.0 G ---| Expander |--- 6.0 G --- SAS disk
| | | |
| |--- 3.0 G ---| |--- 6.0 G --- SATA disk -->failed to connect
| | | |
| | | |--- 6.0 G --- SATA disk -->failed to connect
| | | |
+----------+ +----------+
According to Serial Attached SCSI - 1.1 (SAS-1.1):
If an expander PHY attached to a SATA PHY is using a physical link rate
greater than the maximum connection rate supported by the pathway from an
STP initiator port, a management application client should use the SMP PHY
CONTROL function (see 10.4.3.10) to set the PROGRAMMED MAXIMUM PHYSICAL
LINK RATE field of the expander PHY to the maximum connection rate
supported by the pathway from that STP initiator port.
Currently libsas does not support checking if this condition occurs, nor
rectifying when it does.
Such a condition is not at all common, however it has been seen on some
pre-silicon environments where the initiator PHY only supports a 1.5 Gbit
maximum linkrate, mated with 12G expander PHYs and 3/6G SATA phy.
This patch adds support for checking and rectifying this condition during
initial device discovery only.
We do support checking min pathway connection rate during revalidation phase,
when new devices can be detected in the topology. However we do not
support in the case of the the user reprogramming PHY linkrates, such that
min pathway condition is not met/maintained.
A note on root port PHY rates:
The libsas root port PHY rates calculation is broken. Libsas sets the
rates (min, max, and current linkrate) of a root port to the same linkrate
of the first PHY member of that same port. In doing so, it assumes that
all other PHYs which subsequently join the port to have the same
negotiated linkrate, when they could actually be different.
In practice this doesn't happen, as initiator and expander PHYs are
normally initialised with consistent min/max linkrates.
This has not caused an issue so far, so leave alone for now.
Tested-by: Jian Luo <luojian5@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit cec9771d2e954650095aa37a6a97722c8194e7d2) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Kai-Heng Feng [Wed, 27 Mar 2019 06:56:44 +0000 (14:56 +0800)]
HID: Increase maximum report size allowed by hid_field_extract()
Commit 71f6fa90a353 ("HID: increase maximum global item tag report size
to 256") increases the max report size from 128 to 256.
We also need to update the report size in hid_field_extract() otherwise
it complains and truncates now valid report size:
[ 406.165461] hid-sensor-hub 001F:8086:22D8.0002: hid_field_extract() called with n (192) > 32! (kworker/5:1)
BugLink: https://bugs.launchpad.net/bugs/1818547 Fixes: 71f6fa90a353 ("HID: increase maximum global item tag report size to 256") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 94a9992f7dbdfb28976b565af220e0c4a117144a linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Steve French [Mon, 25 Mar 2019 21:49:46 +0000 (21:49 +0000)]
SMB3: Fix SMB3.1.1 guest mounts to Samba
BugLink: https://launchpad.net/bugs/1821053
Workaround problem with Samba responses to SMB3.1.1
null user (guest) mounts. The server doesn't set the
expected flag in the session setup response so we have
to do a similar check to what is done in smb3_validate_negotiate
where we also check if the user is a null user (but not sec=krb5
since username might not be passed in on mount for Kerberos case).
Note that the commit below tightened the conditions and forced signing
for the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
cases where there is no user (even if server forgets to set the flag
in the response) since we don't have anything useful to sign with.
This is especially important now that the more secure SMB3.1.1 protocol
is in the default dialect list.
An earlier patch ("cifs: allow guest mounts to work for smb3.11") fixed
the guest mounts to Windows.
Fixes: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares") Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by: Paulo Alcantara <palcantara@suse.de> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit 8c11a607d1d9cd6e7f01fd6b03923597fb0ef95a) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The commit noted below tightened the conditions and forced signing for
the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
Guest/Anonumous sessions.
Fixes: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares") Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> CC: Stable <stable@vger.kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit e71ab2aa06f731a944993120b0eef1556c63b81c) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Xiongfeng Wang [Mon, 25 Mar 2019 19:57:34 +0000 (13:57 -0600)]
cpufreq / cppc: Work around for Hisilicon CPPC cpufreq
BugLink: https://bugs.launchpad.net/bugs/1821620
Hisilicon chips do not support delivered performance counter register
and reference performance counter register. But the platform can
calculate the real performance using its own method. We reuse the
desired performance register to store the real performance calculated by
the platform. After the platform finished the frequency adjust, it gets
the real performance and writes it into desired performance register. Os
can use it to calculate the real frequency.
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[ rjw: Drop unnecessary braces ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 6c8d750f9784cef32a8cffdad74c8a351b4ca3a6) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[ rjw: More white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 1757d05f3112acc5c0cdbcccad3afdee99655bf9) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Mon, 4 Feb 2019 13:23:14 +0000 (05:23 -0800)]
UBUNTU: SAUCE: apparmor: add proc subdir to attrs
This patch provides a /proc/<pid>/attr/apparmor/
subdirectory. Enabling userspace to use the apparmor attributes
without having to worry about collisions with selinux or smack on
interface files in /proc/<pid>/attr.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Casey Schaufler [Sat, 29 Dec 2018 01:35:55 +0000 (17:35 -0800)]
UBUNTU: SAUCE: LSM: Specify which LSM to display with /proc/self/attr/display
Create a new entry "display" in /proc/.../attr for controlling
which LSM security information is displayed for a process.
The name of an active LSM that supplies hooks for human readable
data may be written to "display" to set the value. The name of
the LSM currently in use can be read from "display".
Casey Schaufler [Wed, 12 Dec 2018 01:10:15 +0000 (17:10 -0800)]
UBUNTU: SAUCE: LSM: Limit calls to certain module hooks
LSM hooks dealing with security context strings should
only be called for one security module. Add call macros
that invoke a single module hook and us in for those cases.
John Johansen [Mon, 18 Mar 2019 23:11:45 +0000 (16:11 -0700)]
UBUNTU: SAUCE: LSM: Infrastructure management of the sock security
Move management of the sock->sk_security blob out
of the individual security modules and into the security
infrastructure. Instead of allocating the blobs from within
the modules the modules tell the infrastructure how much
space is required, and the space is allocated there.
Chris Coulson [Mon, 4 Feb 2019 10:21:23 +0000 (10:21 +0000)]
apparmor: delete the dentry in aafs_remove() to avoid a leak
Although the apparmorfs dentries are always dropped from the dentry cache
when the usage count drops to zero, there is no guarantee that this will
happen in aafs_remove(), as another thread might still be using it. In
this scenario, this means that the dentry will temporarily continue to
appear in the results of lookups, even after the call to aafs_remove().
In the case of removal of a profile - it also causes simple_rmdir()
on the profile directory to fail, as the directory won't be empty until
the usage counts of all child dentries have decreased to zero. This
results in the dentry for the profile directory leaking and appearing
empty in the file system tree forever.
(cherry picked from commit 201218e4d3dfa1346e30997f48725acce3f26d01) Signed-off-by: Chris Coulson <chris.coulson@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Wei Yongjun [Wed, 16 Jan 2019 05:44:32 +0000 (05:44 +0000)]
LSM: Make some functions static
Fixes the following sparse warnings:
security/security.c:533:5: warning:
symbol 'lsm_task_alloc' was not declared. Should it be static?
security/security.c:554:5: warning:
symbol 'lsm_ipc_alloc' was not declared. Should it be static?
security/security.c:575:5: warning:
symbol 'lsm_msg_msg_alloc' was not declared. Should it be static?
Fixes: f4ad8f2c4076 ("LSM: Infrastructure management of the task security") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
(cherry picked from commit 3e8c73671244af16f1a6042f1c10d13b75cd1156) Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tetsuo Handa [Fri, 18 Jan 2019 10:15:59 +0000 (19:15 +0900)]
LSM: Make lsm_early_cred() and lsm_early_task() local functions.
Since current->cred == current->real_cred when ordered_lsm_init()
is called, and lsm_early_cred()/lsm_early_task() need to be called
between the amount of required bytes is determined and module specific
initialization function is called, we can move these calls from
individual modules to ordered_lsm_init().
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
(cherry picked from commit 1cfb2a512e74e577bb0ed7c8d76df90a41a83f6a) Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
projects / mirror_ubuntu-disco-kernel.git / log