Rob Clark [Tue, 28 Jul 2015 12:54:09 +0000 (13:54 +0100)]
ARM: dts: apq8064: Add MDP support
This patch adds MDP node to APQ8064 dt.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[Srinivas Kandagatla] : updated with new style rpm regulators Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Currently the rates of the xo and sleep clocks are hard-coded in the
GCC driver, but this is a board layout description that actually should
be in the DT. Moving them into DT also allows us to insert the RPM
controlled clocks between the DT and GCC clocks.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Andy Gross <agross@codeaurora.org>
drm/msm: mdp4 lvds: Check the panel node in detect_panel()
This patch checks if the panel node is disabled in DT or not, this would
let us return proper error code so that the driver could stop panel
specific intialization.
drm/msm: mdp4 lvds: continue if the panel is not connected
Two issues:
1> Intializing panel specific bits without actual panel presence.
2> Bailing out if the detect_panel() return -ENODEV.
With the existing code if detect_panel() returns an error code the
driver would bail out without doing anything, However it could continue
intializing hdmi related things. This patch adds two things.
1> moves the panel specific intialization only if the panel is detected
2> let the driver continue with hdmi intialization if detect_panel()
return -ENODEV.
This patch adds panel picker support to simple-panel.
The idea of panel picker is to select the correct panel timings if it
supports probing edid via DDC bus, edid contains manufacture ID
and Manufacturer product code, so it can match against the panel_picker
entries to get the correct panel timings.
From DT point of view the panel picker uses generic compatible string
"panel-simple", keeping the panel specific compatible strings still
supported.
Panels can be static entry in the DT, but practically development boards
like IFC6410 where developers can connect any LVDS panel which makes it
difficult to maintian the dt support for those panels in dts file.
With this dynamic probing via panel picker makes it easy to support such
use-cases.
This patch also adds panel presence detection based, if there is no
panel detected or panel picker could not find the panel then the driver
would mark the panel DT node as disabled so that the drm driver would
be able to take right decision based on that panel node status.
This patch adds support to get edid way early before the connector is
created, this is mainly used for panel drivers to auto-probe the panel
based on the vendor and product id from EDID.
PCI: designware: add memory barrier after enabling region
Add 'write memory' barrier after enable region in PCIE_ATU_CR2
register. The barrier is needed to ensure that the region enable
request has been reached it's destination at time when we
read/write to PCI configuration space.
Without this barrier PCI device enumeration during kernel boot
is not reliable, and reading configuration space for particular
PCI device on the bus returns zero aka no device.
As part of Rob Clarks cleanup one of the flags have been renamed in
header which introduced a compilation failure.
drivers/iommu/msm_iommu.c: In function ‘msm_iommu_map’:
drivers/iommu/msm_iommu.c:426:7: error: ‘FL_AP_READ’ undeclared (first use in this function)
drivers/iommu/msm_iommu.c:426:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/iommu/msm_iommu.c:426:20: error: ‘FL_AP_WRITE’ undeclared (first use in this function)
make[3]: *** [drivers/iommu/msm_iommu.o] Error 1
make[2]: *** [drivers/iommu] Error 2
make[1]: *** [drivers] Error 2
iThis patch fixes the error by using the new flags in the driver.
Liping Zhang [Sat, 25 Mar 2017 08:35:29 +0000 (16:35 +0800)]
netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister
BugLink: http://bugs.launchpad.net/bugs/1709032
If one cpu is doing nf_ct_extend_unregister while another cpu is doing
__nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover,
there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to
NULL, so it's possible that we may access invalid pointer.
But actually, most of the ct extends are built-in, so the problem listed
above will not happen. However, there are two exceptions: NF_CT_EXT_NAT
and NF_CT_EXT_SYNPROXY.
For _EXT_NAT, the panic will not happen, since adding the nat extend and
unregistering the nat extend are located in the same file(nf_nat_core.c),
this means that after the nat module is removed, we cannot add the nat
extend too.
For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while
synproxy extend unregister will be done by synproxy_core_exit. So after
nf_synproxy_core.ko is removed, we may still try to add the synproxy
extend, then kernel panic may happen.
I know it's very hard to reproduce this issue, but I can play a tricky
game to make it happen very easily :)
Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook:
# iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY
Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook.
Also note, in the userspace we only add a 20s' delay, then
reinject the syn packet to the kernel:
# iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1
Step 3. Using "nc 2.2.2.2 1234" to connect the server.
Step 4. Now remove the nf_synproxy_core.ko quickly:
# iptables -F FORWARD
# rmmod ipt_SYNPROXY
# rmmod nf_synproxy_core
Step 5. After 20s' delay, the syn packet is reinjected to the kernel.
Now you will see the panic like this:
kernel BUG at net/netfilter/nf_conntrack_extend.c:91!
Call Trace:
? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack]
init_conntrack+0x12b/0x600 [nf_conntrack]
nf_conntrack_in+0x4cc/0x580 [nf_conntrack]
ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4]
nf_reinject+0x104/0x270
nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue]
? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue]
? nla_parse+0xa0/0x100
nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink]
[...]
One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e.
introduce nf_conntrack_synproxy.c and only do ct extend register and
unregister in it, similar to nf_conntrack_timeout.c.
But having such a obscure restriction of nf_ct_extend_unregister is not a
good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types
to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then
it will be easier if we add new ct extend in the future.
Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary
anymore, remove it too.
Signed-off-by: Liping Zhang <zlpnobody@gmail.com> Acked-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 9c3f3794926a997b1cab6c42480ff300efa2d162) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com>
When iteratively building a UDP datagram with MSG_MORE and that
datagram exceeds MTU, consistently choose UFO or fragmentation.
Once skb_is_gso, always apply ufo. Conversely, once a datagram is
split across multiple skbs, do not consider ufo.
Sendpage already maintains the first invariant, only add the second.
IPv6 does not have a sendpage implementation to modify.
A gso skb must have a partial checksum, do not follow sk_no_check_tx
in udp_send_skb.
Found by syzkaller.
Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Updates to tp_reserve can race with reads of the field in
packet_set_ring. Avoid this by holding the socket lock during
updates in setsockopt PACKET_RESERVE.
This bug was discovered by syzkaller.
Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c27927e372f0785f3303e8fad94b85945e2c97b7) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:46 +0000 (15:52 -0700)]
tty: Destroy ldisc instance on hangup
BugLink: http://bugs.launchpad.net/bugs/1709126
Currently, when the tty is hungup, the ldisc is re-instanced; ie., the
current instance is destroyed and a new instance is created. The purpose
of this design was to guarantee a valid, open ldisc for the lifetime of
the tty.
However, now that tty buffers are owned by and have lifetime equivalent
to the tty_port (since v3.10), any data received immediately after the
ldisc is re-instanced may cause continued driver i/o operations
concurrently with the driver's hangup() operation. For drivers that
shutdown h/w on hangup, this is unexpected and usually bad. For example,
the serial core may free the xmit buffer page concurrently with an
in-progress write() operation (triggered by echo).
With the existing stable and robust ldisc reference handling, the
cleaned-up tty_reopen(), the straggling unsafe ldisc use cleaned up, and
the preparation to properly handle a NULL tty->ldisc, the ldisc instance
can be destroyed and only re-instanced when the tty is re-opened.
If the tty was opened as /dev/console or /dev/tty0, the original behavior
of re-instancing the ldisc is retained (the 'reinit' parameter to
tty_ldisc_hangup() is true). This is required since those file descriptors
are never hungup.
This patch has neglible impact on userspace; the tty file_operations ptr
is changed to point to the hungup file operations _before_ the ldisc
instance is destroyed, so only racing file operations might now retrieve
a NULL ldisc reference (which is simply handled as if the hungup file
operation had been called instead -- see "tty: Prepare for destroying
line discipline on hangup").
This resolves a long-standing FIXME and several crash reports.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 892d1fa7eaaed9d3c04954cb140c34ebc3393932) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:45 +0000 (15:52 -0700)]
tty: Refactor tty_ldisc_reinit() for reuse
BugLink: http://bugs.launchpad.net/bugs/1709126
At tty hangup, the line discipline instance is reinitialized by
closing the current ldisc instance and opening a new instance.
This operation is complicated by error recovery: if the attempt
to reinit the current line discipline fails, the line discipline
is reset to N_TTY (which should not but can fail).
Re-purpose tty_ldisc_reinit() to return a valid, open line discipline
instance, or otherwise, an error.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7896f30d6fc602f02198999acca4840620288990) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:44 +0000 (15:52 -0700)]
tty: Use 'disc' for line discipline index name
BugLink: http://bugs.launchpad.net/bugs/1709126
tty->ldisc is a ptr to struct tty_ldisc, but unfortunately 'ldisc' is
also used as a parameter or local name to refer to the line discipline
index value (ie, N_TTY, N_GSM, etc.); instead prefer the name used
by the line discipline registration/ref counting functions.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c12da96f801a3f45b0634c966b9e7cda307daa72) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:43 +0000 (15:52 -0700)]
tty: Move tty_ldisc_kill()
BugLink: http://bugs.launchpad.net/bugs/1709126
In preparation for destroying the line discipline instance on hangup,
move tty_ldisc_kill() to eliminate needless forward declarations.
No functional change.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6ffeb4b2782b31f3d7158795a451ad371955e8a2) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:42 +0000 (15:52 -0700)]
tty: Handle NULL tty->ldisc
BugLink: http://bugs.launchpad.net/bugs/1709126
In preparation of destroying line discipline on hangup, fix
ldisc core operations to properly handle when the tty's ldisc is
NULL.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a570a49abd343102ce681bbf8273897c3c9fd2d1) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:41 +0000 (15:52 -0700)]
tty: Reset c_line from driver's init_termios
BugLink: http://bugs.launchpad.net/bugs/1709126
After the ldisc is released, but before the tty is destroyed, the termios
is saved (in tty_free_termios()); this termios is restored if a new
tty is created on next open(). However, the line discipline is always
reset, which is not obvious in the current method. Instead, reset
as part of the restore.
Restore the original line discipline, which may not have been N_TTY.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ece53405a1f8ddf60b78e1365addcad521b2c93f) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Peter Hurley [Mon, 7 Aug 2017 22:52:40 +0000 (15:52 -0700)]
tty: Simplify tty_set_ldisc() exit handling
BugLink: http://bugs.launchpad.net/bugs/1709126
Perform common exit for both successful and error exit handling
in tty_set_ldisc(). Fixes unlikely possibility of failing to restart
input kworker when switching to the same line discipline (noop case).
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 63d8cb3f19dabb409a09b4f2b8827934ab9365a3) Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Benjamin M Romer <benjamin.romer@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Laura Abbott [Thu, 27 Jul 2017 02:36:05 +0000 (10:36 +0800)]
UBUNTU: SAUCE: Bluetooth: Make request workqueue freezable
BugLink: http://bugs.launchpad.net/bugs/1706833
We've received a number of reports of warnings when coming
out of suspend with certain bluetooth firmware configurations:
When resuming, the bluetooth stack calls hci_register_dev,
allocates a new workqueue, and immediately schedules the
power_on on the newly created workqueue. Since the new
workqueue is not freezable, the work runs immediately and
triggers the warning since resume is still happening and
usermodehelper has not yet been re-enabled. Fix this by
making the request workqueue freezable. This ensures
the work will not run until unfreezing occurs and usermodehelper
is re-enabled.
Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
HID: multitouch: handle external buttons for Precision Touchpads
BugLink: https://bugs.launchpad.net/bugs/1708372
According to https://msdn.microsoft.com/en-us/library/windows/hardware/mt604195(v=vs.85).aspx
external buttons have some weird usage mapping:
- Button 2 Indicates Button State for external button for primary
(default left) clicking.
- Button 3 Indicates Button State for external button for secondary
(default right) clicking.
So in the current state, the buttons are mapped to right and middle.
Move the usage by one to correctly map the external buttons.
Tested-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit 594312b88b0f451912c964c7ff2c0eaa71ad41b4) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Seth Forshee [Thu, 3 Aug 2017 21:10:14 +0000 (16:10 -0500)]
UBUNTU: [Config] CONFIG_SATA_HIGHBANK=y
BugLink: http://bugs.launchpad.net/bugs/1703430
This changed from y to m after trusty without justification.
Having it built as a module causes issues with booting on some
ARM systems.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Brian Foster [Wed, 2 Aug 2017 17:27:23 +0000 (14:27 -0300)]
xfs: fix xfs_log_ticket leak in xfs_end_io() after fs shutdown
BugLink: https://bugs.launchpad.net/bugs/1706132
If the filesystem has shut down, xfs_end_io() currently sets an
error on the ioend and proceeds to ioend destruction. The ioend
might contain a truncate transaction if the I/O extended the size of
the file. This transaction is only cleaned up in
xfs_setfilesize_ioend(), however, which is skipped in this case.
This results in an xfs_log_ticket leak message when the associate
cache slab is destroyed (e.g., on rmmod).
This was originally reproduced by xfs/141 on a distro kernel. The
problem is reproducible on an upstream kernel, but not easily
detected in current upstream if the xfs_log_ticket cache happens to
be merged with another cache. This can be reproduced more
deterministically with the 'slab_nomerge' kernel boot option.
Update xfs_end_io() to proceed with normal end I/O processing after
an error is set on an ioend due to fs shutdown. The I/O type-based
processing is already designed to handle an I/O error and ensure
that the ioend is cleaned up correctly.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit af055e37a91d215d7174d0b84c86795ca81086a7) Signed-off-by: Rafael David Tinoco <rafael.tinoco@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jan Kara [Tue, 1 Aug 2017 09:33:33 +0000 (17:33 +0800)]
ext4: fix data exposure after a crash
CVE-2017-7495
Huang has reported that in his powerfail testing he is seeing stale
block contents in some of recently allocated blocks although he mounts
ext4 in data=ordered mode. After some investigation I have found out
that indeed when delayed allocation is used, we don't add inode to
transaction's list of inodes needing flushing before commit. Originally
we were doing that but commit f3b59291a69d removed the logic with a
flawed argument that it is not needed.
The problem is that although for delayed allocated blocks we write their
contents immediately after allocating them, there is no guarantee that
the IO scheduler or device doesn't reorder things and thus transaction
allocating blocks and attaching them to inode can reach stable storage
before actual block contents. Actually whenever we attach freshly
allocated blocks to inode using a written extent, we should add inode to
transaction's ordered inode list to make sure we properly wait for block
contents to be written before committing the transaction. So that is
what we do in this patch. This also handles other cases where stale data
exposure was possible - like filling hole via mmap in
data=ordered,nodelalloc mode.
The only exception to the above rule are extending direct IO writes where
blkdev_direct_IO() waits for IO to complete before increasing i_size and
thus stale data exposure is not possible. For now we don't complicate
the code with optimizing this special case since the overhead is pretty
low. In case this is observed to be a performance problem we can always
handle it using a special flag to ext4_map_blocks().
CC: stable@vger.kernel.org Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com> Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(backported from commit 06bd3c36a733ac27962fea7d6f47168841376824) Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1706991
This patch configures specific uapsd parameters. This setting
gives better downlink WLAN throughput when radio is shared
between WLAN and BT.
Signed-off-by: Pavani Muthyala <pavani.muthyala@redpinesignals.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
UBUNTU: SAUCE: Redpine: enable power save by default for coex mode
BugLink: https://bugs.launchpad.net/bugs/1706991
When Coex mode is enabled, enabling power save will improve
radio sharing. Hence PS on by default flag is set.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
hv_netvsc: Exclude non-TCP port numbers from vRSS hashing
BugLink: http://bugs.launchpad.net/bugs/1690174
Azure hosts are not supporting non-TCP port numbers in vRSS hashing for
now. For example, UDP packet loss rate will be high if port numbers are
also included in vRSS hash.
So, we created this patch to use only IP numbers for hashing in non-TCP
traffic.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit f72860afa2e32cdc674cbdd7f354f8fb62e908a6) Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Conflicts:
drivers/net/hyperv/netvsc_drv.c Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Yang Jiaxun [Tue, 25 Jul 2017 04:18:01 +0000 (12:18 +0800)]
platform/x86: ideapad-laptop: Add several models to no_hw_rfkill
BugLink: https://bugs.launchpad.net/linux/+bug/1705378
Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.
Fix it by adding those models to no_hw_rfkill_list.
Signed-off-by: Yang Jiaxun <yjx@flygoat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(backported from commit 710c059c248a24609051f5a3dd1d8468cdc675b0) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Chia-Lin Kao <acelan.kao@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Bluetooth: btintel: Add MODULE_FIRMWARE entries for iBT 3.5 controllers
BugLink: http://bugs.launchpad.net/bugs/1705633
The iBT 3.5 controllers (Intel 8265, Windstorm Peak) need
intel/ibt-12-16.sfi and intel/ibt-12-16.ddc firmware files from
linux-firmware repository.
Signed-off-by: Jürg Billeter <j@bitron.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit d1b7abae666cc4630daa3db4e839626bc179f6f1) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Bluetooth: hci_intel: Fix firmware file name to use hw_variant
BugLink: http://bugs.launchpad.net/bugs/1705633
The format of Intel Bluetooth firmware for bootloader product is
ibt-<hw_variant>-<device_revision_id>.sfi and .ddc.
This patch uses a hw_variant value read from the device during
runtime to form the firmware filenames instead of using a constant
value, so it can support multiple prouducts.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit b7da6a69defd195da66bfd6b35efeb376a252557) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Bluetooth: Replace constant hw_variant from Intel Bluetooth firmware filename
BugLink: http://bugs.launchpad.net/bugs/1705633
The format of Intel Bluetooth firmware filename for bootloader product
is ibt-<hw_variant>-<device_revision_id>.sfi
Currently the driver uses a constant value 11 (0x0b) for hw_variant
to support LnP/SfP product. But new product like WsP product has
a different value such as 12 (0x0c).
To support the multiple products, this patch replaces the constant
value of hw_variant to the actual hw_variant value read from
the device.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit 230b04ac8f439d0797ab85fb356f069f0472306f) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Bluetooth: Use switch statement for Intel hardware variants
BugLink: http://bugs.launchpad.net/bugs/1705633
Multiple new hardware variants are planned and the simple if statement
would get really complicated and unreadable. So instead replace it with
a simple switch statement.
The change is applied to both USB and UART.
Based-on-patch-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit 9268834b60c0b08101c7a8522b6901cf4cd57a14) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Bluetooth: btintel: Create common Intel Version Read function
BugLink: http://bugs.launchpad.net/bugs/1705633
The Intel Version Read command is used to retrieve information
about hardware and firmware version/revision of Intel Bluetooth
controllers. This is an Intel generic command used in USB and
UART drivers.
Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(backported from commit 6c483de1b3c41e939b735df1861759815e125304) Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
xhci: Bad Ethernet performance plugged in ASM1042A host
BugLink: https://bugs.launchpad.net/bugs/1667750
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow control handling of ASM1042A.
The register we modify is changes the behavior
[use quirk bit 28 instead, usleep_range 40-60us -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: Jiahau Chang <Lars_chang@asmedia.com.tw> Signed-off-by: Ian Pilcher <arequipeno@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
(backported from commit 9da5a1092b13468839b1a864b126cacfb72ad016) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
scsi: ses: don't get power status of SES device slot on probe
BugLink: http://bugs.launchpad.net/bugs/1696445
The commit 08024885a2a3 ("ses: Add power_status to SES device slot")
introduced the 'power_status' attribute to enclosure components and
the associated callbacks.
There are 2 callbacks available to get the power status of a device:
1) ses_get_power_status() for 'struct enclosure_component_callbacks'
2) get_component_power_status() for the sysfs device attribute
(these are available for kernel-space and user-space, respectively.)
However, despite both methods being available to get power status
on demand, that commit also introduced a call to get power status
in ses_enclosure_data_process().
This dramatically increased the total probe time for SCSI devices
on larger configurations, because ses_enclosure_data_process() is
called several times during the SCSI devices probe and loops over
the component devices (but that is another problem, another patch).
That results in a tremendous continuous hammering of SCSI Receive
Diagnostics commands to the enclosure-services device, which does
delay the total probe time for the SCSI devices __significantly__:
Originally, ~34 minutes on a system attached to ~170 disks:
Back to the commit discussion.. on the ses_get_power_status() call
introduced in ses_enclosure_data_process(): impact of removing it.
That may possibly be in place to initialize the power status value
on device probe. However, those 2 functions available to retrieve
that value _do_ automatically refresh/update it. So the potential
benefit would be a direct access of the 'power_status' field which
does not use the callbacks...
But the only reader of 'struct enclosure_component::power_status'
is the get_component_power_status() callback for sysfs attribute,
and it _does_ check for and call the .get_power_status callback,
(which indeed is defined and implemented by that commit), so the
power status value is, again, automatically updated.
So, the remaining potential for a direct/non-callback access to
the power_status attribute would be out-of-tree modules -- well,
for those, if they are for whatever reason interested in values
that are set during device probe and not up-to-date by the time
they need it.. well, that would be curious.
Well, to handle that more properly, set the initial power state
value to '-1' (i.e., uninitialized) instead of '1' (power 'on'),
and check for it in that callback which may do an direct access
to the field value _if_ a callback function is not defined.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot") Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Song Liu <songliubraving@fb.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 75106523f39751390b5789b36ee1d213b3af1945) Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
platform/x86: thinkpad_acpi: add mapping for new hotkeys
BugLink: http://bugs.launchpad.net/bugs/1705169
The T470, X270 emits new hkey events in the 0x1311 - 0x1315 range.
According to the user manual they should launch a user selected
favorite application (star icon, 0x1311), snipping tool (0x1312,
currently ignored), enable/disable bluetooth (0x1314) and open they
keyboard settings (0x1315).
The third nibble (0xf00) is used to differentiate between the original
hotkeys, the adaptive keyboard codes and the new, additional ones.
Signed-off-by: Christian Kellner <ckellner@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit 696c6523ec8f2a8f30f3dffef7e382f0fe5c2010) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Acked-by: Hui Wang <Wang <hui.wang@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
platform/x86: thinkpad_acpi: guard generic hotkey case
BugLink: http://bugs.launchpad.net/bugs/1705169
Currently when dispatching hotkeys we check if the scancode is in
the range of 0 and TPACPI_HOTKEY_MAP_LEN, although the bottom 20
entries in the hotkey keymap are already adaptive keycodes.
Therefore we introduce a TP_ACPI_HOTKEYSCAN_ADAPTIVE_START and
ensure that we are in the range 0 and ADAPTIVE_START for the generic
keycode case.
Signed-off-by: Christian Kellner <ckellner@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(cherry picked from commit 149c8c75b38be528b8648d907195f188bc8fb0fb) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Acked-by: Hui Wang <Wang <hui.wang@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Hui Wang [Wed, 19 Jul 2017 04:56:56 +0000 (21:56 -0700)]
platform/x86: thinkpad_acpi: Adding new hotkey ID for Lenovo thinkpad
BugLink: http://bugs.launchpad.net/bugs/1705169
Recently we met an issue on lots of Lenovo thinkpad laptops (those
laptops are not released to market yet), the issue is that the
thinkpad_acpi.ko can't be automatically loaded as before.
Through debugging, we found the HKEY_HID is LEN0268 instead of
LEN0068 on those machines, and the MHKV is 0x200 instead of
0x100. So adding the new ID into the driver.
Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
(cherry picked from commit a3c42a467a254a17236ab817d5c7c6bc054e4f84) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Acked-by: Hui Wang <Wang <hui.wang@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Dave Young [Thu, 29 Sep 2016 14:43:55 +0000 (15:43 +0100)]
UBUNTU: SAUCE: (no-up) kexec/uefi: copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot. Adding a patch to fix this by retain the secure_boot flag
in original kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com>
CVE-2015-7837
(cherry-picked from https://github.com/mjg59/linux/commit/4b2b64d5a6ebc84214755ebccd599baef7c1b798) Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b2504a5dbef3305ef41988ad270b0e8ec289331c) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
"
When a device changes from one netns to another, it's first unregistered,
then the netns reference is updated and the dev is registered in the new
netns. Thus, when a slave moves to another netns, it is first
unregistered. This triggers a NETDEV_UNREGISTER event which is caught by
the bonding driver. The driver calls bond_release(), which calls
dev_set_mtu() and thus triggers NETDEV_CHANGEMTU (the device is still in
the old netns).
"
This is a very special case, because the device is being unregistered
no one should still care about the NETDEV_CHANGEMTU event triggered
at this point, we can avoid broadcasting this event on this path,
and avoid touching inetdev_event()/addrconf_notify() path.
It requires to export __dev_set_mtu() to bonding driver.
Reported-by: Hongjun Li <hongjun.li@6wind.com> Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: Jay Vosburgh <j.vosburgh@gmail.com> Cc: Veaceslav Falico <vfalico@gmail.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f51048c3e07b68c90b21a77541fc4b208f9244d7) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
[ 1130.972475] xgene-edac 78800000.edac: IOB bridge agent (BA) transaction
error
[ 1130.979584] xgene-edac 78800000.edac: IOB BA write response error
[ 1130.985648] xgene-edac 78800000.edac: IOB BA write access at 0x00.00000000
()
[ 1130.993612] xgene-edac 78800000.edac: IOB BA requestor ID 0x00002400
[ 1131.000242] xgene-edac 78800000.edac: IOB bridge agent (BA) transaction
error
...
This patch fixes the errors by,
- removing the redundant prefetch buffer cleanup from port_ops->shutdown()
- moving port_ops->shutdown() after delete_rings()
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(back ported from commit 8aba8474181070a30f56ffd19359f5d80665175e) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
blk-mq: NVMe 512B/4K+T10 DIF/DIX format returns I/O error on dd with split op
BugLink: http://bugs.launchpad.net/bugs/1689946
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block layer split the bio after calling
bio_integrity_prep(bio). This patch fixes the issue.
Below is how we debug this issue:
(1)format nvme to 4K block # size with type 2 DIF
(2)dd with block size bigger than 1024k.
oflag=direct
dd: error writing '/dev/nvme0n1': Input/output error
We added some debug code in nvme device driver. It showed us the first
op and the second op have the same bi and pi address. This is not
correct.
bonding: fix 802.3ad support for 5G and 50G speeds
BugLink: http://bugs.launchpad.net/bugs/1697892
This patch adds [5|50] Gbps enum definition, and fixes
aggregated bandwidth calculation based on above slave links.
Fixes: c9a70d43461d ("net-next: ethtool: Added port speed macros.") Signed-off-by: Thibaut Collet <thibaut.collet@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c7c550670afda2e16f9e2d06a1473885312eb6b5) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 19ddde1eeca1ee81f4add5e04da66055e09281ac) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Jay Vosburgh [Fri, 14 Jul 2017 15:13:11 +0000 (11:13 -0400)]
bonding: fix 802.3ad aggregator reselection
BugLink: http://bugs.launchpad.net/bugs/1697892
Since commit 7bb11dc9f59d ("bonding: unify all places where
actor-oper key needs to be updated."), the logic in bonding to handle
selection between multiple aggregators has not functioned.
This affects only configurations wherein the bonding slaves
connect to two discrete aggregators (e.g., two independent switches, each
with LACP enabled), thus creating two separate aggregation groups within a
single bond.
The cause is a change in 7bb11dc9f59d to no longer set
AD_PORT_BEGIN on a port after a link state change, which would cause the
port to be reselected for attachment to an aggregator as if were newly
added to the bond. We cannot restore the prior behavior, as it
contradicts IEEE 802.1AX 5.4.12, which requires ports that "become
inoperable" (lose carrier, setting port_enabled=false as per 802.1AX
5.4.7) to remain selected (i.e., assigned to the aggregator). As the port
now remains selected, the aggregator selection logic is not invoked.
A side effect of this change is that aggregators in bonding will
now contain ports that are link down. The aggregator selection logic
does not currently handle this situation correctly, causing incorrect
aggregator selection.
This patch makes two changes to repair the aggregator selection
logic in bonding to function as documented and within the confines of the
standard:
First, the aggregator selection and related logic now utilizes the
number of active ports per aggregator, not the number of selected ports
(as some selected ports may be down). The ad_select "bandwidth" and
"count" options only consider ports that are link up.
Second, on any carrier state change of any slave, the aggregator
selection logic is explicitly called to insure the correct aggregator is
active.
Reported-by: Veli-Matti Lintu <veli-matti.lintu@opinsys.fi> Fixes: 7bb11dc9f59d ("bonding: unify all places where actor-oper key needs to be updated.") Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 0622cab0341cac6b30da177b0faa39fae0680e71) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log