Mika Westerberg [Wed, 25 Sep 2019 10:05:55 +0000 (13:05 +0300)]
thunderbolt: Move NVM upgrade support flag to struct icm
BugLink: http://bugs.launchpad.net/bugs/1844680
This is depends on the controller and on the platform/CPU we are
running. Move it to struct icm so we can set it per controller.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit f437c24bf694b0293f835dea8c25e3a5c1433d07) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:54 +0000 (13:05 +0300)]
thunderbolt: Correct path indices for PCIe tunnel
BugLink: http://bugs.launchpad.net/bugs/1844680
PCIe tunnel path indices got mixed up when we added support for tunnels
between switches that are not adjacent. This did not affect the
functionality as it is just an index but fix it now nevertheless to make
the code easier to understand.
Reported-by: Rajmohan Mani <rajmohan.mani@intel.com> Fixes: 8c7acaaf020f ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
(cherry picked from commit ce19f91eae43e39d5a1da55344756ab5a3c7e8d1) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reported-and-tested-by: Alexander Schmidt <alexs@linux.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit cf2c4a3f35b75d38cebb4afbd578f1594f068d1e) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1842774
New options from "s390: add support for IBM z15 machines." As per
smb's comments, these must be turned off to avoid breaking
compatibility with older hardware.
BugLink: https://bugs.launchpad.net/bugs/1842774
Add detection for machine types 0x8562 and 8x8561 and set the ELF platform
name to z15. Add the miscellaneous-instruction-extension 3 facility to
the list of facilities for z15.
And allow to generate code that only runs on a z15 machine.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
(cherry picked from commit a0e2251132995b962281aa80ab54a9288f9e0b6b) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Despite extensive testing of commit 885bd765963b ("phy: qcom-qmp: Correct
READY_STATUS poll break condition") I failed to conclude that the
PHYSTATUS bit of the PCS_STATUS register used in PCIe and USB3 falls as
the PHY gets ready. Similar to the prior bug with UFS the code will
generally get past the check before the transition and thereby
"succeed".
Correct the name of the register used PCIe and USB3 PHYs, replace
mask_pcs_ready with a constant expression depending on the type of the
PHY and check for the appropriate ready state.
Cc: stable@vger.kernel.org Cc: Vivek Gautam <vivek.gautam@codeaurora.org> Cc: Evan Green <evgreen@chromium.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Reported-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Fixes: 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
This change caused a docker regression. The root cause was mount leaks
by docker, which as far as I know, still exist.
To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
caused by exclusive upper/work dir protection") in v4.14 turned the
mount errors into warnings for the default index=off configuration.
Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
v5.2, re-introduced exclusive upper/work dir checks regardless of
index=off configuration.
This changes the status quo and mount leak related bug reports have
started to re-surface. Restore the status quo to fix the regressions.
To clarify, index=off does NOT relax overlapping layers check for this
ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
with another overlayfs mount.
To cover the part of overlapping layers detection that used the
exclusive upper/work dir checks to detect overlap with self upper/work
dir, add a trap also on the work base dir.
Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
set_{pte,pmd,pud}") removed ISB instructions immediately following updates
to the page table, on the grounds that they are not required by the
architecture and a DSB alone is sufficient to ensure that subsequent data
accesses use the new translation:
DDI0487E_a, B2-128:
| ... no instruction that appears in program order after the DSB
| instruction can alter any state of the system or perform any part of
| its functionality until the DSB completes other than:
|
| * Being fetched from memory and decoded
| * Reading the general-purpose, SIMD and floating-point,
| Special-purpose, or System registers that are directly or indirectly
| read without causing side-effects.
However, the same document also states the following:
DDI0487E_a, B2-125:
| DMB and DSB instructions affect reads and writes to the memory system
| generated by Load/Store instructions and data or unified cache
| maintenance instructions being executed by the PE. Instruction fetches
| or accesses caused by a hardware translation table access are not
| explicit accesses.
which appears to claim that the DSB alone is insufficient. Unfortunately,
some CPU designers have followed the second clause above, whereas in Linux
we've been relying on the first. This means that our mapping sequence:
MOV X0, <valid pte>
STR X0, [Xptep] // Store new PTE to page table
DSB ISHST
LDR X1, [X2] // Translates using the new PTE
can actually raise a translation fault on the load instruction because the
translation can be performed speculatively before the page table update and
then marked as "faulting" by the CPU. For user PTEs, this is ok because we
can handle the spurious fault, but for kernel PTEs and intermediate table
entries this results in a panic().
Revert the offending commit to reintroduce the missing barriers.
Cc: <stable@vger.kernel.org> Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
commit 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM
RSSI thresholds") was incomplete and requires one more fix to
prevent accessing to rssi_thresholds[n] because user can control
rssi_thresholds[i] values to make i reach to n. For example,
rssi_thresholds = {-400, -300, -200, -100} when last is -34.
Cc: stable@vger.kernel.org Fixes: 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://lore.kernel.org/r/20190908005653.17433-1-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
When half-duplex RS485 communication is used, after RX is started, TX
tasklet still needs to be scheduled tasklet. This avoids console freezing
when more data is to be transmitted, if the serial communication is not
closed.
Fixes: 69646d7a3689 ("tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped") Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190813074025.16218-1-razvan.stefanescu@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The sequence of arguments which was passed to handle_lsr_errors() didn't
match the parameters defined in that function, &lsr was passed to flag
and &flag was passed to lsr, this patch fixed that.
The VPD implementation from Chromium Vital Product Data project used to
parse data from untrusted input without checking if the meta data is
invalid or corrupted. For example, the size from decoded content may
be negative value, or larger than whole input buffer. Such invalid data
may cause buffer overflow.
To fix that, the size parameters passed to vpd_decode functions should
be changed to unsigned integer (u32) type, and the parsing of entry
header should be refactored so every size field is correctly verified
before starting to decode.
The first/last indexes are typically shared with a user app.
The app can change the 'last' index that the kernel uses
to store the next result. This change sanity checks the index
before using it for writing to a potentially arbitrary address.
This fixes CVE-2019-14821.
Cc: stable@vger.kernel.org Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)") Signed-off-by: Matt Delco <delco@chromium.org> Signed-off-by: Jim Mattson <jmattson@google.com> Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com
[Use READ_ONCE. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The DSA core, DSA taggers and DSA drivers all make use of
module_init(). Hence they get initialised at device_initcall() time.
The ordering is non-deterministic. It can be a DSA driver is bound to
a device before the needed tag driver has been initialised, resulting
in the message:
No tagger for this switch
Rather than have this be fatal, return -EPROBE_DEFER so that it is
tried again later once all the needed drivers have been loaded.
Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
When skb_shinfo(skb) is not able to cache extra fragment (that is,
skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
the sk_buff_head list is already empty. As a result, cons is increased only
by 1 and returns to error handling path in xennet_poll().
However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be
set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring
buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are
already cleared to NULL. This leads to NULL pointer access in the next
iteration to process rx ring buffer entries.
Below is how xennet_poll() does error handling. All remaining entries in
tmpq are accounted to queue->rx.rsp_cons without assuming how many
outstanding skbs are remained in the list.
985 static int xennet_poll(struct napi_struct *napi, int budget)
... ...
1032 if (unlikely(xennet_set_skb_gso(skb, gso))) {
1033 __skb_queue_head(&tmpq, skb);
1034 queue->rx.rsp_cons += skb_queue_len(&tmpq);
1035 goto err;
1036 }
It is better to always have the error handling in the same way.
Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UDP reuseport groups can hold a mix unconnected and connected sockets.
Ensure that connections only receive all traffic to their 4-tuple.
Fast reuseport returns on the first reuseport match on the assumption
that all matches are equal. Only if connections are present, return to
the previous behavior of scoring all sockets.
Record if connections are present and if so (1) treat such connected
sockets as an independent match from the group, (2) only return
2-tuple matches from reuseport and (3) do not return on the first
2-tuple reuseport match to allow for a higher scoring match later.
New field has_conns is set without locks. No other fields in the
bitmap are modified at runtime and the field is only ever set
unconditionally, so an RMW cannot miss a change.
Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection") Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Craig Gallek <kraig@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The test implemented by some_qdisc_is_busy() is somewhat loosy for
NOLOCK qdisc, as we may hit the following scenario:
CPU1 CPU2
// in net_tx_action()
clear_bit(__QDISC_STATE_SCHED...);
// in some_qdisc_is_busy()
val = (qdisc_is_running(q) ||
test_bit(__QDISC_STATE_SCHED,
&q->state));
// here val is 0 but...
qdisc_run(q)
// ... CPU1 is going to run the qdisc next
As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
both the above bit operations are under the root qdisc lock().
After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
the race can cause use after free and/or null ptr dereference, but the root
cause is likely older.
This patch addresses the issue explicitly checking for deactivation under
the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
scenario becomes a no-op.
Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
but that is safe due to the skb_array() locking, and we can't avoid that
for NOLOCK qdiscs.
Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue") Reported-by: Li Shuang <shuali@redhat.com> Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
In ip6erspan_tunnel_xmit(), if the skb will not be sent out, it has to
be freed on the tx_err path. Otherwise when deleting a netns, it would
cause dst/dev to leak, and dmesg shows:
unregister_netdevice: waiting for lo to become free. Usage count = 1
Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The hardware manual should be revised, but the initial value of
VBCTRL.OCCLREN is set to 1 actually. If the bit is set, the hardware
clears VBCTRL.VBOUT and ADPCTRL.DRVVBUS registers automatically
when the hardware detects over-current signal from a USB power switch.
However, since the hardware doesn't have any registers which
indicates over-current, the driver cannot handle it at all. So, if
"is_otg_channel" hardware detects over-current, since ADPCTRL.DRVVBUS
register is cleared automatically, the channel cannot be used after
that.
To resolve this behavior, this patch sets the VBCTRL.OCCLREN to 0
to keep ADPCTRL.DRVVBUS even if the "is_otg_channel" hardware
detects over-current. (We assume a USB power switch itself protects
over-current and turns the VBUS off.)
This patch is inspired by a BSP patch from Kazuya Mizuguchi.
Fixes: 1114e2d31731 ("phy: rcar-gen3-usb2: change the mode to OTG on the combined channel") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The error occurs when the descriptors_changed() routine (called during
a device reset) attempts to compare the old and new BOS and capability
descriptors. The length it uses for the comparison is the
wTotalLength value stored in BOS descriptor, but this value is not
necessarily the same as the length actually allocated for the
descriptors. If it is larger the routine will call memcmp() with a
length that is too big, thus reading beyond the end of the allocated
region and leading to this fault.
The kernel reads the BOS descriptor twice: first to get the total
length of all the capability descriptors, and second to read it along
with all those other descriptors. A malicious (or very faulty) device
may send different values for the BOS descriptor fields each time.
The memory area will be allocated using the wTotalLength value read
the first time, but stored within it will be the value read the second
time.
To prevent this possibility from causing any errors, this patch
modifies the BOS descriptor after it has been read the second time:
It sets the wTotalLength field to the actual length of the descriptors
that were read in and validated. Then the memcpy() call, or any other
code using these descriptors, will be able to rely on wTotalLength
being valid.
UBUNTU: [Debian]: dkms-build: Move zfs special-casing into configure script
BugLink: https://bugs.launchpad.net/bugs/1840704
Rather than special-casing zfs in dkms-build, add support for
per-package configure hooks like we already do for post-install
hooks. Move the zfs-specific code into such a hook.
Suggested-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1840704
The regex to generate dkms_build_generic from dkms_build_specific
will return the same script name if the package name does not end
with a dash followed by digits. In this case the script will be
executed twice.
Fix this by returning an empty string if the regex does not match
and skipping execution if the dkms build script name is empty.
UBUNTU: [Debian]: dkms-build: zfs: support for debug symbols
BugLink: https://bugs.launchpad.net/bugs/1840704
Add support to enable debug symbols on ZFS in 'dkms-build',
and specify the debug package directory path in the rules.
It's a bit ugly that a change for a particular package is
in the generic build script, but unfortunately this seems
to be less intrusive than other options (eg, rely on file
in /etc/ which needs privileged permissions on build time;
or patch zfs-linux/dkms.conf to detect kernel build time.)
And it seemed short enough not to create 'pre processors'.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: dkms-build: new parameter for debug package directory
BugLink: https://bugs.launchpad.net/bugs/1840704
Provide the 'dkms-build' script an argument that specifies
the path for installing modules built with debug symbols,
and update callers (currently just 'build_dkms' function)
and post-processor scripts for consistency (nvidia, vbox).
This is similar to the currently used package directory
argument 'pkgdir/lib/modules/abi-release/kernel', where
modules are installed anyway regardless of debug symbols.
The proposal is that the 'dkms-build' script, if provided
such argument, should handle the generation and stripping
of debug symbols, and installing the non-stripped modules
into the debug package directory and the stripped modules
into the other package directory (which is used currently).
The script double checks whether debug symbols are indeed
present in the module file (via the '.debug_info' section)
to avoid non-debug modules in the debug package directory,
with an additional benefit of backwards compatibility and
gracefully handling DKMS packages that do not yet support
building debug symbols (or that failed to for some reason).
The script should not handle the '.gnu_debuglink' section
to reference the non-stripped modules in stripped modules
(and re-signinig afterward), as this is now done in rules
after the DKMS modules have been built and installed.
This currently does nothing as no DKMS modules are built
with debug symbols (so this keeps the new argument empty).
This will allow for some of the DKMS-built modules to be
shipped with debug symbols to aid with debug and support.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Warn about modules without debug symbols
BugLink: https://bugs.launchpad.net/bugs/1840704
Print a warning message in the build log if a module does
not have a corresponding file in 'dbgpkgdir/usr/lib/debug'.
This should help to identify any modules without debug symbols,
which introduce additional complexity for their supportability.
In the future, it may be interesting to implement an stricter
check, to fail the build (obviously providing options to skip
the check and an exception list of modules that can bypass it).
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Check/link modules with debug symbols after DKMS modules
BugLink: https://bugs.launchpad.net/bugs/1840704
Move the snippet that checks for existing debug symbol files
and then link/re-sign them, to after DKMS modules are built.
This provides the means to check the DKMS-built modules too.
Move just that snippet, not the whole 'ifneq skipdbg' snippet
because 'modules_install' does 'rm -rf lib/modules/.../kernel'
which would remove the modules just built/installed with DKMS.
For now, only move that code, no changes to it.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Handle debug symbols for modules in extras too
BugLink: https://bugs.launchpad.net/bugs/1840704
The debug symbols section only searches for modules in the
'$(pkgdir)' path (in linux-modules package) but not in the
'$(pkdir_ex)' path (in linux-modules-extra).
Thus, modules in the extras package have no '.gnu_debuglink'.
Fix it by searching in $(pkgdir_ex) too if extras is enabled.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Remove hardcoded $(pkgdir) in debug symbols handling
BugLink: https://bugs.launchpad.net/bugs/1840704
The 'find .ko | sed | while read module' loop has the $(pkgdir) path
hardcoded in a couple places to reconstruct the path 'sed' destroyed.
Remove that 'sed' expression to destroy the first components of the
absolute pathname and get its '/lib/modules/'-based path with shell.
This is needed for the next patch.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: Revert "UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs"
BugLink: https://bugs.launchpad.net/bugs/1842382
This commit is causing the paths in /proc/self/maps to all show
up as / when proc is mounted over overlayfs in a chroot. Revert
the commit to fix the regression until a proper fix is found.
This keeps giving us problems with introducing unwanted binary
dependencies in linux-tools. These tools will work without these
dependencies, albeit with somewhat reduced functionality. Aside
from that I can't see that this dependency is needed, so let's
try removing it.
UBUNTU: [Packaging] Add lz4 build dependency for s390x
BugLink: https://bugs.launchpad.net/bugs/1840934
When switching s390x to use lz4 for compressing the kernel, the
build dependencies were not updated. Fix this.
This is no longer needed as zfs is build via the dkms build now.
I thought it had been deleted previously, but it's still there
for some reason, so let's get rid of it.
Lee Jones [Fri, 6 Sep 2019 09:38:16 +0000 (10:38 +0100)]
UBUNTU: SAUCE: i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630
We have a production-level laptop (Lenovo Yoga C630) which is exhibiting
a rather horrific bug. When I2C HID devices are being scanned for at
boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA.
When it does, the laptop reboots and the user never sees the OS.
Attempts are being made to debug the reason for the spontaneous reboot.
No luck so far, hence the requirement for this hot-fix. This workaround
will be removed once we have a viable fix.
Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
PCI: Restore Resizable BAR size bits correctly for 1MB BARs
BugLink: http://bugs.launchpad.net/bugs/1838751
In a Resizable BAR Control Register, bits 13:8 control the size of the BAR.
The encoded values of these bits are as follows (see PCIe r5.0, sec
7.8.6.3):
Previously we incorrectly set the BAR size bits for a 1 MB BAR to 0x1f
instead of 0, so devices that support that size, e.g., new megaraid_sas and
mpt3sas adapters, fail to initialize during resume from S3 sleep.
Correctly calculate the BAR size bits for Resizable BAR control registers.
Link: https://lore.kernel.org/r/20190725192552.24295-1-sumit.saxena@broadcom.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939 Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume") Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org # v4.19+
(cherry-picked from d2182b2d4b71ff0549a07f414d921525fade707b linux-next) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: sched: Add __ASSEMBLY__ guards around struct clone_args
The addition of struct clone_args to uapi/linux/sched.h is not
protected by __ASSEMBLY__ guards, cuasing a FTBFS for glibc on
RISC-V. Add the guards to fix this.
BugLink: https://bugs.launchpad.net/bugs/1837726
Until 5.2 nvram support was built into the kernel for ppc64el.
Now it is a module and not included in the installer udebs, which
causes installation to fail. Change it back to =y for ppc64el to
fix this.
Hui Wang [Mon, 2 Sep 2019 04:28:13 +0000 (12:28 +0800)]
UBUNTU: SAUCE: ALSA: hda - Define a fallback_pin_fixup_tbl for alc269 family
BugLink: https://bugs.launchpad.net/bugs/1842265
We have another Dell laptop which needs the DELL4_MIC_NO_PRESENCE,
and this laptop has different pincfg definitions from existing
ones in the pintbl, rather adding a new entry, let us define
a tbl in the fallback_pin_fixup_tbl and this tbl will match
all dell machines with alc289 codec and the pins of 0x19 and 0x1b
are undef by default.
Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 7c0a69394c265f2bb674c3f5daadfdd5c15ea0d1
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git) Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Hui Wang [Mon, 2 Sep 2019 04:28:12 +0000 (12:28 +0800)]
UBUNTU: SAUCE: ALSA: hda - Expand pin_match function to match upcoming new tbls
BugLink: https://bugs.launchpad.net/bugs/1842265
With the existing pintbl, we already have many entries in it. it is
better to figure out a new way to reduce the size of the pintbl.
We plan to define a new tbl which will match more machines with a
single tbl, To do that, this function doesn't need to match all valid
pins between machine and tbl, it just needs to match all pins defined
in the tbl with the machine.
And the plan is to move some tbls from pin_fixup_tbl to
fallback_pin_fixup_tbl gradually.
Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 0fc1e447e9e474c2460df8d0378f899b8813e1d2
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git) Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Quentin Monnet [Fri, 30 Aug 2019 17:43:53 +0000 (18:43 +0100)]
UBUNTU: [Debian] package bpftool in linux-tools-common
BugLink: https://bugs.launchpad.net/bugs/1774815
bpftool is a debugging and introspection tool for BPF elements,
developed by the BPF kernel community. Its source code is located in the
kernel repository, at tools/bpf/bpftool. Package it in linux-tools and
linux-tools-common.
Along the binary, package manual pages and bash completion file. Note
that the generated manual page bpf-helpers.7 is NOT packaged, as this
one is now included in the man-pages repository.
bpftool itself is installed under /usr/sbin/, to be consistent with its
Makefile.
Dependency python-docutils is added to Build-Depends-Indep, in order to
provide rst2man which is necessary to build bpftool's manual pages.
UBUNTU: SAUCE: shiftfs: mark slab objects SLAB_RECLAIM_ACCOUNT
BugLink: https://bugs.launchpad.net/bugs/1842059
Shiftfs does not mark it's slab cache as reclaimable. While this is not
a big deal it is not nice to the kernel in general. The shiftfs cache is
not so important that it can't be reclaimed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1841977
The way we messed with setting i_nlink was brittle and wrong. We used to
set the i_nlink of the shiftfs dentry to be deleted to the i_nlink count
of the underlay dentry of the directory it resided in which makes no
sense whatsoever. We also missed drop_nlink() which is crucial since
i_nlink affects whether a dentry is cleaned up on dput().
With this I cannot reproduce the bug anymore where shiftfs misleads zfs
into believing that a deleted file can not be removed from disk because
it is still referenced.
Fixes: commit 87011da41961 ("shiftfs: rework and extend") Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Chris Chiu [Mon, 26 Aug 2019 04:41:24 +0000 (12:41 +0800)]
pinctrl: intel: remap the pin number to gpio offset for irq enabled pin
BugLink: https://bugs.launchpad.net/bugs/1841396
On Asus X571GT, GPIO 297 is configured as an interrupt and serves
for the touchpad. The touchpad will report input events much less
than expected after S3 suspend/resume, which results in extremely
slow cursor movement. However, the number of interrupts observed
from /proc/interrupts increases much more than expected even no
touching touchpad.
This is due to the value of PADCFG0 of PIN 225 for the interrupt
has been changed from 0x80800102 to 0x80100102. The GPIROUTIOXAPIC
is toggled on which results in the spurious interrupts. The PADCFG0
of PIN 225 is expected to be saved during suspend, but the 297 is
saved instead because the gpiochip_line_is_irq() expect the GPIO
offset but what's really passed to it is PIN number. In this case,
the /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges shows
So gpiochip_line_is_irq() returns true for GPIO offset 297, the
suspend routine spuriously saves the content for PIN 297 which
we expect to save for PIN 225.
This commit maps the PIN number to GPIO offset first in the
intel_pinctrl_should_save() to make sure the values for the
specific PINs can be correctly saved and then restored.
Fixes: c538b9436751 ("pinctrl: intel: Only restore pins that are used by the driver") Signed-off-by: Chris Chiu <chiu@endlessm.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit 6cb0880f08229360c6c57416de075aa96930be78 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jeffrey Hugo [Fri, 21 Jun 2019 14:59:51 +0000 (07:59 -0700)]
arm64: dts: qcom: Add Asus NovaGo TP370QL
BugLink: https://bugs.launchpad.net/bugs/1842050
This adds the initial DT for the Asus NovaGo TP370QL laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 722eb2f65acc4cebeb710fc7cc98f51513e90f1f) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jeffrey Hugo [Fri, 21 Jun 2019 14:57:21 +0000 (07:57 -0700)]
arm64: dts: qcom: Add HP Envy x2
BugLink: https://bugs.launchpad.net/bugs/1842050
This adds the initial DT for the HP Envy x2 laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 3f527d311932791fde67ffec32536d22d5dd3030) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jeffrey Hugo [Fri, 21 Jun 2019 14:54:50 +0000 (07:54 -0700)]
arm64: dts: qcom: Add Lenovo Miix 630
BugLink: https://bugs.launchpad.net/bugs/1842050
This adds the initial DT for the Lenovo Miix 630 laptop. Supported
functionality includes USB (host), microSD-card, keyboard, and trackpad.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
(cherry picked from commit 2c6d2d3a580a852fe0a694e13af502a862293e0e) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Fri, 30 Aug 2019 14:55:56 +0000 (09:55 -0500)]
UBUNTU: SAUCE: import aufs driver
Import aufs4.x-rcN 20190805 from https://github.com/sfjro/aufs4-standalone
commit d6c8327c57132b4f2d88a43de257497ccbfe0bc9, updated to fix some
trivial conflicts and to include the changes from these commits:
- UBUNTU: SAUCE: aufs: rwsem owner changed to atmoic_long_t in 5.3
- UBUNTU: SAUCE: aufs: add "WITH Linux-syscall-note" to SPDX tag of uapi headers
Seth Forshee [Fri, 23 Aug 2019 17:59:22 +0000 (12:59 -0500)]
UBUNTU: [Packaging] add build dependencies for compression algorithms
BugLink: https://bugs.launchpad.net/bugs/1840934
I forgot to add build dependencies for the compression algorithm
changes in "UBUNTU: [Config] change kernel compression method to
improve boot speed." Add them now.
Seth Forshee [Fri, 23 Aug 2019 11:36:44 +0000 (06:36 -0500)]
UBUNTU: [Debian] disable dkms builds for autopktest rebuilds
If the specified package versions have been deleted, rebuilds in
autopkgtest may fail and block promotion of other packages.
Disable the dkms package builds for autopkgtest rebuilds to
prevent this from happening.
BugLink: https://bugs.launchpad.net/bugs/1838133
Both RTL8822BE/RTL8822CE are WiFi + BT combo chips. Since
WiFi and BT use 2.4GHz to transmit, it is important to
make sure they run concurrently without interfering each
other. To achieve this, WiFi driver requires a mechanism
to collaborate with BT, whether they share the antenna(s)
or not.
The final decision made by the co-existence mechanism is
to choose a proper strategy, or called "tdma/table", and
inform either firmware or hardware of the strategy.
To choose a strategy, co-existence mechanism needs to
have enough information from WiFi and BT.
BT information is provided through firmware C2H.
The contents describe the current status of BT, such as
if BT is connected or is idle, or the profile that is
being used.
WiFi information can be provided by WiFi itself. The WiFi
driver will call various of "notify" functions each time
the state of WiFi changed, such as WiFi is going to switch
channel or is connected. Also WiFi driver can know if it
shares antenna with BT by reading efuse content. Antenna
configuration of the module will finally get a different
strategy.
Upon receiving any information from WiFi or BT, the WiFi
driver will run the co-existence mechanism immediately.
It will set the RF antenna configuration according to the
strategy through the TDMA H2C to firmware and a hardware
table. Based on the tdma/table, WiFi + BT should work with
each other, and having a better user experience.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 4136214f7c46839c15f0f177fe1d5052302c0205 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1838133
C2H commands that cannot be handled in IRQ context should
be protected by rtwdev->mutex. Because they might have a
sequece of hardware operations that does not want to be
interfered.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 713a30de45a2ec8619228280e4832b5d6a34e759 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1838133
Some of the c2h operations are small and can be done
under interrupt context. For the rest that requires
more operations or can go sleep, enqueue onto c2h queue.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 0d762f031d702272a17910fbeb45ab15b9673617 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
drivers/net/wireless/realtek/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
variable 'ip_sel' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit d1b68c1182380e50cad4b7bd76ee68f64951a64b linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Brian Norris [Sat, 13 Jul 2019 01:32:32 +0000 (18:32 -0700)]
rtw88: use txpwr_lmt_cfg_pair struct, not arrays
BugLink: https://bugs.launchpad.net/bugs/1838133
We're just trusting that these tables are of the right dimensions, when
we could do better by just using the struct directly. Let's expose the
struct txpwr_lmt_cfg_pair instead.
The table changes were made by using some Vim macros, so that should
help prevent any translation mistakes along the way.
Remaining work: get the 'void *data' out of the generic struct
rtw_table; all of these tables really deserve to be their own data
structure, with proper type fields.
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 3457f86da60de73705bce8fe32a36651441e639e linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Zong-Zhe Yang [Tue, 16 Jul 2019 05:28:20 +0000 (13:28 +0800)]
rtw88: debug: dump tx power indexes in use
BugLink: https://bugs.launchpad.net/bugs/1838133
Add a read entry in debugfs to dump current tx power
indexes in use for each path and each rate section.
The corresponding power bases, power by rate, and
power limit are also included.
Also this patch fixes unused function warning.
Fixes: b741422218ef ("rtw88: refine flow to get tx power index") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 8812022cb2fdaa1c6d7e0c3e028b45ca039650ea linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jian-Hong Pan [Thu, 11 Jul 2019 05:24:27 +0000 (13:24 +0800)]
rtw88: pci: Use DMA sync instead of remapping in RX ISR
BugLink: https://bugs.launchpad.net/bugs/1838133
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit 29b68a920f6abb7b5ba21ab4b779f62d536bac9b linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jian-Hong Pan [Thu, 11 Jul 2019 05:24:26 +0000 (13:24 +0800)]
rtw88: pci: Rearrange the memory usage for skb in RX ISR
BugLink: https://bugs.launchpad.net/bugs/1838133
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
Then we see a variety of different error conditions and kernel panics,
such as this one (trimmed):
rtw_pci 0000:02:00.0: pci bus timeout, check dma status
skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:105!
invalid opcode: 0000 [#1] SMP NOPTI
RIP: 0010:skb_panic+0x43/0x45
When skb allocation fails and the "rx routine starvation" is hit, the
function returns immediately without updating the RX ring. At this
point, the RX ring may continue referencing an old skb which was already
handed off to ieee80211_rx_irqsafe(). When it comes to be used again,
bad things happen.
This patch allocates a new, data-sized skb first in RX ISR. After
copying the data in, we pass it to the upper layers. However, if skb
allocation fails, we effectively drop the frame. In both cases, the
original, full size ring skb is reused.
In addition, to fixing the kernel crash, the RX routine should now
generally behave better under low memory conditions.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
(cherry picked from commit ee6db78f5db9bfe426c57a1ec9713827ebccd2d4 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 21 Aug 2019 20:09:45 +0000 (15:09 -0500)]
UBUNTU: SAUCE: selftests: fib_tests: assign address to dummy1 for rp_filter tests
The rp_filter test tries to ping using the dummy1 interface
without assigning it an IP address. Give the interface an IP
address so the tests will pass.