[ Upstream commit a9b952d267 ]
MTU changes may affect the number of IRQs so we must call
bnxt_close_nic()/bnxt_open_nic() with the irq_re_init parameter
set to true. The reason is that a larger MTU may require
aggregation rings not needed with smaller MTU. We may not be
able to allocate the required number of aggregation rings and
so we reduce the number of channels which will change the number
of IRQs. Without this patch, it may crash eventually in
pci_disable_msix() when the IRQs are not properly unwound.
Fixes: c0c050c58d ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4b1bd9db07 ]
It's a resource, not a parameter, so we can't copy it into the new
channel's TX queues, otherwise aliasing will lead to resource-
management bugs if the channel is subsequently torn down without
being initialised.
Before the Fixes:-tagged commit there was a similar bug with
tsoh_page, but I'm not sure it's worth doing another fix for such
old kernels.
Fixes: e9117e5099 ("sfc: Firmware-Assisted TSO version 2")
Suggested-by: Derek Shute <Derek.Shute@stratus.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit d64c7a0803 ]
Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 13, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M
where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.
When hotplugging such dock with additional usb devices already attached on
it, the probing process may reset usb 2.1 port, therefore r8152 ethernet
device is also reset. However, during r8152 device init there are several
for-loops that, when it's unable to retrieve hardware registers due to
being disconnected from USB, may take up to 14 seconds each in practice,
and that has to be completed before USB may re-enumerate devices on the
bus. As a result, devices attached to the dock will only be available
after nearly 1 minute after the dock was plugged in:
[ 216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
[ 216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
[ 258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY not ready
[ 258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr
[ 258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get ether addr fail
This happens in, for example, r8153_init:
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
void *data, u16 type)
{
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return -ENODEV;
...
}
static u16 ocp_read_word(struct r8152 *tp, u16 type, u16 index)
{
u32 data;
...
generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen);
data = __le32_to_cpu(tmp);
...
return (u16)data;
}
static void r8153_init(struct r8152 *tp)
{
...
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
for (i = 0; i < 500; i++) {
if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) &
AUTOLOAD_DONE)
break;
msleep(20);
}
...
}
Since ocp_read_word() doesn't check the return status of
generic_ocp_read(), and the only exit condition for the loop is to have
a match in the returned value, such loops will only ends after exceeding
its maximum runs when the device has been marked as disconnected, which
takes 500 * 20ms = 10 seconds in theory, 14 in practice.
To solve this long latency another test to RTL8152_UNPLUG flag should be
added after those 20ms sleep to skip unnecessary loops, so that the device
probe can complete early and proceed to parent port reset/reprobe process.
This can be reproduced on all kernel versions up to latest v5.6-rc2, but
after v5.5-rc7 the reproduce rate is dramatically lowered to 1/30 or less
while it was around 1/2.
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c0368595c1 ]
Currently the bounds check on index is off by one and can lead to
an out of bounds access on array priv->filters_loc when index is
RXCHK_BRCM_TAG_MAX.
Fixes: bb9051a2b2 ("net: systemport: Add support for WAKE_FILTER")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b723bd9339 ]
ACS (auto PAD/FCS stripping) removes FCS off 802.3 packets (LLC) so that
there is no need to manually strip it for such packets. The enhanced DMA
descriptors allow to flag LLC packets so that the receiving callback can
use that to strip FCS manually or not. On the other hand, normal
descriptors do not support that.
Thus in order to not truncate LLC packet ACS should be disabled when
using normal DMA descriptors.
Fixes: 47dd7a540b ("net: add support for STMicroelectronics Ethernet controllers.")
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 46e4c421a0 ]
In one error case, tpacket_rcv drops packets after incrementing the
ring producer index.
If this happens, it does not update tp_status to TP_STATUS_USER and
thus the reader is stalled for an iteration of the ring, causing out
of order arrival.
The only such error path is when virtio_net_hdr_from_skb fails due
to encountering an unknown GSO type.
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>
[ Upstream commit a3aefbfe45 ]
This is similar to commit 674d9de02a ("NFC: Fix possible memory
corruption when handling SHDLC I-Frame commands") and commit d7ee81ad09
("NFC: nci: Add some bounds checking in nci_hci_cmd_received()") which
added range checks on "pipe".
The "pipe" variable comes skb->data[0] in nfc_hci_msg_rx_work().
It's in the 0-255 range. We're using it as the array index into the
hdev->pipes[] array which has NFC_HCI_MAX_PIPES (128) members.
Fixes: 118278f20a ("NFC: hci: Add pipes table to reference them with a tuple {gate, host}")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 84b3268027 ]
Userspace might send a batch that is composed of several netlink
messages. The netlink_ack() function must use the pointer to the netlink
header as base to calculate the bad attribute offset.
Fixes: 2d4bc93368 ("netlink: extended ACK reporting")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 07758eb9ff ]
When we add peer address with metric configured, IPv4 could set the dest
metric correctly, but IPv6 do not. e.g.
]# ip addr add 192.0.2.1 peer 192.0.2.2/32 dev eth1 metric 20
]# ip route show dev eth1
192.0.2.2 proto kernel scope link src 192.0.2.1 metric 20
]# ip addr add 2001:db8::1 peer 2001:db8::2/128 dev eth1 metric 20
]# ip -6 route show dev eth1
2001:db8::1 proto kernel metric 20 pref medium
2001:db8::2 proto kernel metric 256 pref medium
Fix this by using configured metric instead of default one.
Reported-by: Jianlin Shi <jishi@redhat.com>
Fixes: 8308f3ff17 ("net/ipv6: Add support for specifying metric of connected routes")
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ad8192767c ]
IPvlan in L3 mode discards outbound multicast packets but performs
the check before ensuring the ether-header is set or not. This is
an error that Eric found through code browsing.
Fixes: 2ad7bf3638 (“ipvlan: Initial check-in of the IPVLAN driver.”)
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit afe207d80a ]
Commit e18b353f10 ("ipvlan: add cond_resched_rcu() while
processing muticast backlog") added a cond_resched_rcu() in a loop
using rcu protection to iterate over slaves.
This is breaking rcu rules, so lets instead use cond_resched()
at a point we can reschedule
Fixes: e18b353f10 ("ipvlan: add cond_resched_rcu() while processing muticast backlog")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 63aae7b173 ]
There is a problem when ipvlan slaves are created on a master device that
is a vmxnet3 device (ipvlan in VMware guests). The vmxnet3 driver does not
support unicast address filtering. When an ipvlan device is brought up in
ipvlan_open(), the ipvlan driver calls dev_uc_add() to add the hardware
address of the vmxnet3 master device to the unicast address list of the
master device, phy_dev->uc. This inevitably leads to the vmxnet3 master
device being forced into promiscuous mode by __dev_set_rx_mode().
Promiscuous mode is switched on the master despite the fact that there is
still only one hardware address that the master device should use for
filtering in order for the ipvlan device to be able to receive packets.
The comment above struct net_device describes the uc_promisc member as a
"counter, that indicates, that promiscuous mode has been enabled due to
the need to listen to additional unicast addresses in a device that does
not implement ndo_set_rx_mode()". Moreover, the design of ipvlan
guarantees that only the hardware address of a master device,
phy_dev->dev_addr, will be used to transmit and receive all packets from
its ipvlan slaves. Thus, the unicast address list of the master device
should not be modified by ipvlan_open() and ipvlan_stop() in order to make
ipvlan a workable option on masters that do not support unicast address
filtering.
Fixes: 2ad7bf3638 ("ipvlan: Initial check-in of the IPVLAN driver")
Reported-by: Per Sundstrom <per.sundstrom@redqube.se>
Signed-off-by: Jiri Wiesner <jwiesner@suse.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 60380488e4 ]
Rafał found an issue that for non-Ethernet interface, if we down and up
frequently, the memory will be consumed slowly.
The reason is we add allnodes/allrouters addressed in multicast list in
ipv6_add_dev(). When link down, we call ipv6_mc_down(), store all multicast
addresses via mld_add_delrec(). But when link up, we don't call ipv6_mc_up()
for non-Ethernet interface to remove the addresses. This makes idev->mc_tomb
getting bigger and bigger. The call stack looks like:
addrconf_notify(NETDEV_REGISTER)
ipv6_add_dev
ipv6_dev_mc_inc(ff01::1)
ipv6_dev_mc_inc(ff02::1)
ipv6_dev_mc_inc(ff02::2)
addrconf_notify(NETDEV_UP)
addrconf_dev_config
/* Alas, we support only Ethernet autoconfiguration. */
return;
addrconf_notify(NETDEV_DOWN)
addrconf_ifdown
ipv6_mc_down
igmp6_group_dropped(ff02::2)
mld_add_delrec(ff02::2)
igmp6_group_dropped(ff02::1)
igmp6_group_dropped(ff01::1)
After investigating, I can't found a rule to disable multicast on
non-Ethernet interface. In RFC2460, the link could be Ethernet, PPP, ATM,
tunnels, etc. In IPv4, it doesn't check the dev type when calls ip_mc_up()
in inetdev_event(). Even for IPv6, we don't check the dev type and call
ipv6_add_dev(), ipv6_dev_mc_inc() after register device.
So I think it's OK to fix this memory consumer by calling ipv6_mc_up() for
non-Ethernet interface.
v2: Also check IFF_MULTICAST flag to make sure the interface supports
multicast
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Fixes: 74235a25c6 ("[IPV6] addrconf: Fix IPv6 on tuntap tunnels")
Fixes: 1666d49e1d ("mld: do not remove mld souce list info when set link down")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 83f73c5bb7 ]
In commit 1ec17dbd90 ("inet_diag: fix reporting cgroup classid and
fallback to priority") croup classid reporting was fixed. But this works
only for TCP sockets because for other socket types icsk parameter can
be NULL and classid code path is skipped. This change moves classid
handling to inet_diag_msg_attrs_fill() function.
Also inet_diag_msg_attrs_size() helper was added and addends in
nlmsg_new() were reordered to save order from inet_sk_diag_fill().
Fixes: 1ec17dbd90 ("inet_diag: fix reporting cgroup classid and fallback to priority")
Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 018d26fcd1 ]
In our production environment we have faced with problem that updating
classid in cgroup with heavy tasks cause long freeze of the file tables
in this tasks. By heavy tasks we understand tasks with many threads and
opened sockets (e.g. balancers). This freeze leads to an increase number
of client timeouts.
This patch implements following logic to fix this issue:
аfter iterating 1000 file descriptors file table lock will be released
thus providing a time gap for socket creation/deletion.
Now update is non atomic and socket may be skipped using calls:
dup2(oldfd, newfd);
close(oldfd);
But this case is not typical. Moreover before this patch skip is possible
too by hiding socket fd in unix socket buffer.
New sockets will be allocated with updated classid because cgroup state
is updated before start of the file descriptors iteration.
So in common cases this patch has no side effects.
Signed-off-by: Dmitry Yakunin <zeil@yandex-team.ru>
Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 503ba7c696 upstream.
It is currently possible for a PHY device to be suspended as part of a
network device driver's suspend call while it is still being attached to
that net_device, either via phy_suspend() or implicitly via phy_stop().
Later on, when the MDIO bus controller get suspended, we would attempt
to suspend again the PHY because it is still attached to a network
device.
This is both a waste of time and creates an opportunity for improper
clock/power management bugs to creep in.
Fixes: 803dd9c77a ("net: phy: avoid suspending twice a PHY")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7b566f70e1 upstream.
This reverts:
ef1b5bf506 ("net: phy: Fix not to call phy_resume() if PHY is not attached")
8c85f4b812 ("net: phy: micrel: add toggling phy reset if PHY is not attached")
Andrew Lunn informs me that there are alternative efforts
underway to fix this more properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
[just take the ef1b5bf506 revert - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KBUILD_LDS_MODULE didn't exist in 4.19, it was added in upstream commit
10df063855 ("kbuild: rebuild modules when module linker scripts are
updated"), which means the module-lto.lds linker script is not actually
passed to the linker. Append the flags directly to KBUILD_LDFLAGS_MODULE
instead.
Bug: 151700304
Fixes: 6cea04778e ("ANDROID: kbuild: merge module sections with LTO")
Change-Id: I600db54d2ff9cd4e287913e8ddd463a20741a4a3
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
With LTO, modules with a large number of compilation units maybe end
up exceeding the for loop argument list in the shell. Reduce the
probability for this happening by including only the modules that have
exported symbols.
Bug: 150234396
Change-Id: I4a289aff47e1444aca28d1bd00b125628f39bcd5
Suggested-by: Hsiu-Chang Chen <hsiuchangchen@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
PF_EXITING is set earlier than actual removal from css_set when a task
is exitting. This can confuse cgroup.procs readers who see no PF_EXITING
tasks, however, rmdir is checking against css_set membership so it can
transitionally fail with EBUSY.
Fix this by listing tasks that weren't unlinked from css_set active
lists.
It may happen that other users of the task iterator (without
CSS_TASK_ITER_PROCS) spot a PF_EXITING task before cgroup_exit(). This
is equal to the state before commit c03cd7738a ("cgroup: Include dying
leaders with live threads in PROCS iterations") but it may be reviewed
later.
Reported-by: Suren Baghdasaryan <surenb@google.com>
Fixes: c03cd7738a ("cgroup: Include dying leaders with live threads in PROCS iterations")
Signed-off-by: Michal Koutný <mkoutny@suse.com>
(cherry picked from commit 9c974c7724)
Bug: 141213848
Bug: 146758430
Test: test_cgcore_destroy from linux-kselftest
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Iac57661b931129ed1e44b89675f8115bb89084ff
(cherry picked from commit 21ee296526c70d6dc3c64639406f156f39b80fd0)
Userspace clients will be able to restrict cache maintenance to only
the subset of the dma-buf which is mmap(ed) by setting the
DMA_BUF_SYNC_USER_MAPPED flag when calling the DMA_BUF_IOCTL_SYNC IOCT.
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
Bug: 150611569
Test: build
(cherry-picked from bbbc80b6d8b75ffea6a0eb1f53ab503ccf0011f1)
[surenb: partial cherry-pick from
bbbc80b6d8b7 ion : Merge ion changes from ...
to resolve ABI diffs caused by {begin/end}_cpu_access_umapped
dma_buf_ops.
changed dma_buf_end_cpu_access_umapped to be static.]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ic2029c5218ca99330a0e7e6128e12ac29cdd1c08
dma-buf destructor support is useful as it allows clients an opportunity
to undo any attributes, such as security attributes, they have applied to
the dma-buf's memory.
The destructor is called when the dma-buf is freed, if the destructor
returns an error the dma-buf's exporter release function is not called in
order to ensure that memory which has not been properly cleaned up isn't
returned to the system.
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
[surenb: cherry-picked from:
3af4db1543c9 "dma-buf: Add support to set a destructor on a dma-buf"]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I2d435b99fb9b1747bc1b32a4e0d484957614a5a3
We introduced setname ioctl in commit bb2bb90304 ("dma-buf:
add DMA_BUF_SET_NAME ioctls") that provides userpsace
to attach a free-form name for tracking and counting shared
buffers. However the d_dname callback could be called in atomic
context. This call path comes from selinux that verifies all
inherited open files from exec call. To verify all inherited
open files, kernel would iterate all fds which need to hold
spin_lock to get denty name by calling d_dname operation.
In dma-buf d_dname callback, we use mutex lock to prevent the
race from setname causing this issue.
This commit adds a spinlock to protect set/get name operation
to fix this issue.
[ 165.617090] Call trace:
[ 165.620504] ___might_sleep+0x114/0x118
[ 165.625344] __might_sleep+0x50/0x84
[ 165.629928] __mutex_lock_common+0x5c/0x10b0
[ 165.635215] mutex_lock_nested+0x40/0x50
[ 165.640157] dmabuffs_dname+0x48/0xdc
[ 165.644821] d_path+0x78/0x1e4
[ 165.648870] audit_log_d_path+0x68/0x134
[ 165.653807] common_lsm_audit+0x33c/0x6f4
[ 165.658832] slow_avc_audit+0xb4/0xf0
[ 165.663503] avc_has_perm+0xdc/0x1a4
[ 165.668081] file_has_perm+0x70/0x154
[ 165.672750] match_file+0x54/0x6c
[ 165.677064] iterate_fd+0x74/0xac
[ 165.681369] selinux_bprm_committing_creds+0xfc/0x210
[ 165.687459] security_bprm_committing_creds+0x2c/0x40
[ 165.693546] install_exec_creds+0x1c/0x68
[ 165.698569] load_elf_binary+0x3a0/0x13c8
[ 165.703590] search_binary_handler+0xb8/0x1e4
[ 165.708964] __do_execve_file+0x6e4/0x9c8
[ 165.713984] __arm64_sys_execve+0x44/0x54
[ 165.719008] el0_svc_common+0xa8/0x168
[ 165.723765] el0_svc_handler+0x78/0x94
[ 165.728522] el0_svc+0x8/0xc
Signed-off-by: Martin Liu <liumartin@google.com>
[surenb: cherry-picked and backported from:
https://lkml.org/lkml/2020/1/14/799
Conflicts:
drivers/dma-buf/dma-buf.c
1. Resolved diffs between 4.19 and upstream by replacing dma_resv_lock
with dmabuf->lock
]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia0b20a40d491eb41b8844d05dc86dfd6039de07f
Allow kernel clients to get the flags associated with a buffer
that is wrapped by a dma-buf. This information can be used to
communicate the type of memory associated with the
buffer(e.g. uncached vs cached memory).
Bug: 133508579
Test: ion-unit-tests
Change-Id: I82eab8beb738b258616c22a01080615d7ffb6ad5
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I6f094f625f38b363fe7815bb5b0ab33273a4a3a5
When mapping the memory represented by a dma-buf into a device's
address space, it might be desireable to map the memory with
certain DMA attributes. Thus, introduce the dma_mapping_attrs
field in the dma_buf_attachment structure so that when
the memory is mapped with dma_buf_map_attachment, it is mapped
with the desired DMA attributes.
Bug: 133508579
Test: ion-unit-tests
Change-Id: Ib2e5bafdc02ae31a58ce96a82d77cc508dd71bd4
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9a8b4f83a61bcff6e5d3ee2d7f4887875a9654ef
In order to improve performance, allow dma-buf clients to
apply cache maintenance to only a subset of a dma-buf.
Kernel clients will be able to use the dma_buf_begin_cpu_access_partial
and dma_buf_end_cpu_access_partial functions to only apply cache
maintenance to a range within the dma-buf.
Bug: 133508579
Test: ion-unit-tests
Change-Id: Icce61fc21b1542f5248daea34f713184449a62c3
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
[surenb: cherry-picked from ACK 5.4 branch]
Bug: 150611569
Test: build
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I453e69fa792508c367fb03a8d543ee42254e7138
Currently the removed_dma_ops are set only once for dev nodes
which are associated with a reserved-memory region (PIL devices)
in device_init and when the probe of these devices fail,
we end up calling dma_deconfigure which sets the dma_ops to NULL.
Eventually when the probe succeeds, since dma_ops was set to
NULL during probe failure, we end up setting dma_ops to
arm64_swiotlb_dma_ops. Hence in arch_setup_dma_ops, if the
dma_ops is NULL, check to see if there is a reserved memory
associated with the dev and if so set dma_ops to removed_dma_ops
such that the right callback functions are invoked.
Bug: 145617272
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
[surenb: cherry picked from commit:
903192a5412d "mm: Support setting removed_dma_ops in arch_setup_dma_ops"]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibc1028391ba90cbdd5c5826022b5015d9e261c09
The current DMA coherent pool assumes that there is a kernel
mapping at all times for the entire pool. This may not be
what we want for the entire times. Add the dma_removed ops to
support this use case.
Bug: 145617272
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
[surenb Squashed the following commits:
a478a8bf78ad "drivers: Add dma removed ops"
8510985ae320 "dma: removed: Merge dma removed changes from 4.14"
and removed-dma-pool driver changes from
9d4b7d641556 "iommu: arm-smmu: Merge for ..."]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ie4f1e9bdf57b79699fa8fa7e7a6087e6d88ebbfa
Trimmed down version of:
4008eb493aa2 "iommu/arm-smmu: Merge of smmu changes from 4.14"
which includes only changes required for removed-dma-pool driver.
Bug: 145617272
Signed-off-by: Swathi Sridhar <swatsrid@codeaurora.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I4b9ae665aaf8aabf89c3b158bc38db458f31657a
Enables us to catch build-breaks for 32-bit ARM with an allmodconfig
build in continuous integration testing.
Bug: 151459448
Change-Id: I825a18771c214e6389fc2755fce20c8fc2531695
Signed-off-by: Alistair Delva <adelva@google.com>
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct module at module.h:331:1' changed:
type size hasn't changed
2 data member insertions:
'jump_entry* module::jump_entries', at offset 5632 (in bits) at module.h:444:1
'unsigned int module::num_jump_entries', at offset 5696 (in bits) at module.h:445:1
there are data member changes:
'unsigned int module::num_trace_bprintk_fmt' offset changed from 5632 to 5728 (in bits) (by +96 bits)
'const char** module::trace_bprintk_fmt_start' offset changed from 5696 to 5760 (in bits) (by +64 bits)
'trace_event_call** module::trace_events' offset changed from 5760 to 5824 (in bits) (by +64 bits)
'unsigned int module::num_trace_events' offset changed from 5824 to 5888 (in bits) (by +64 bits)
'trace_eval_map** module::trace_evals' offset changed from 5888 to 5952 (in bits) (by +64 bits)
'unsigned int module::num_trace_evals' offset changed from 5952 to 6016 (in bits) (by +64 bits)
'list_head module::source_list' offset changed from 6016 to 6080 (in bits) (by +64 bits)
'list_head module::target_list' offset changed from 6144 to 6208 (in bits) (by +64 bits)
'void ()* module::exit' offset changed from 6272 to 6336 (in bits) (by +64 bits)
'atomic_t module::refcnt' offset changed from 6336 to 6400 (in bits) (by +64 bits)
1532 impacted interfaces:
'struct static_key at jump_label.h:110:1' changed:
type size changed from 32 to 128 (in bits)
1 data member insertion:
'union {unsigned long int type; jump_entry* entries; static_key_mod* next;}', at offset 64 (in bits) at jump_label.h:102:1
1532 impacted interfaces:
'struct tracepoint at tracepoint-defs.h:30:1' changed:
type size changed from 320 to 384 (in bits)
there are data member changes:
type 'struct static_key' of 'tracepoint::key' changed as reported earlier
and size changed from 32 to 128 (in bits) (by +96 bits)
'void ()* tracepoint::regfunc' offset changed from 128 to 192 (in bits) (by +64 bits)
'void ()* tracepoint::unregfunc' offset changed from 192 to 256 (in bits) (by +64 bits)
'tracepoint_func* tracepoint::funcs' offset changed from 256 to 320 (in bits) (by +64 bits)
1532 impacted interfaces:
Bug: 145162121
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3b11e0952c06f1a0dda7a9eb28dcb4988e5f050a
It's needed to speed up trace points and other dynamic debugging stuff.
Bug: 145162121
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I811b538bc5280a633c56e0544ba1f54cd6b234f2
Add a gki-debug build.config file which disables whitelisting trimming.
This is intended to ease GKI development.
Bug: 150772411
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I4b7f001eaca37fe993260ddff914fb05a1310df9
Add a gki-debug build.config file which disables whitelisting trimming.
This is intended to ease GKI development.
Bug: 150772411
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ia5241f17b1cf730b357c6501180834bd01eb589f
There is a big delay between DMA transmission completed and waiting for
interruption, which results in the degradation of read performance.
It is modified to use usleep_range delay without interruption, and
the read performance is improved by 40%.
Change-Id: Ia9b92382d7a1a4fbd157dace2067c7dd15cb69ca
Signed-off-by: Yifeng Zhao <zyf@rock-chips.com>
When I backported 52918ed5fc ("KVM: SVM: Override default MMIO mask if
memory encryption is enabled") to 4.19 (which resulted in commit
a4e761c9f6 ("KVM: SVM: Override default MMIO mask if memory encryption
is enabled")), I messed up the call to kvm_mmu_set_mmio_spte_mask()
Fix that here now.
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
