Sync up with android11-5.4 for the following commits:
a2114d2456 ANDROID: Update KMI_GENERATION after KMI change
9bb683349b ANDROID: GKI: update the .xml file with the October 15 ABI breakages
b7d30a3293 ANDROID: GKI: fs.h: add Android ABI padding to struct file
3b300ff4c5 ANDROID: vendor_hooks: Add a vendor data to file struct
e89b05984d ANDROID: vendor_hooks: Extend the vendor data array in task_struct
7ee8b58cc1 ANDROID: GKI: add fields required to enable CONFIG_TRANSPARENT_HUGEPAGE
0ce2100bcf ANDROID: Drop abi_gki_aarch64_workarounds
f0c4a768cf UPSTREAM: ehci-hcd: Move include to keep CRC stable
5427f8b72f ANDROID: GKI: update xiaomi symbol list
ecb88922f5 ANDROID: GKI: update Vivo symbol list
32b2423372 ANDROID: sysrq: add vendor hook for sysrq crash information
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia8ac3109c49a4866904c4419a17e2379156a8f77
The KMI was changed by several patches on Oct 15. Update the
generation number.
Bug: 161946584
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: If641819d24743f319cfe704b79ec479be8aae78f
Leaf changes summary: 3291 artifacts changed (10 filtered out)
Changed leaf types summary: 5 (1 filtered out) leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 3237 Changed (9 filtered out), 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 49 Changed, 0 Added variable
3237 functions with some sub-type change:
49 Changed variables:
type of variable changed:
type size hasn't changed
1 data member insertion:
'deferred_split pglist_data::deferred_split_queue', at offset 42048 (in bits) at mmzone.h:785:1
there are data member changes:
'lruvec pglist_data::lruvec' offset changed from 42048 to 42304 (in bits) (by +256 bits)
'unsigned long int pglist_data::flags' offset changed from 43136 to 43392 (in bits) (by +256 bits)
3325 impacted interfaces
type of variable changed:
type size hasn't changed
there are data member changes:
type 'u64[2]' of 'task_struct::android_vendor_data1' changed:
type name changed from 'u64[2]' to 'u64[3]'
array type size changed from 128 to 192
array type subrange 1 changed length from 2 to 3
'u64 task_struct::android_kabi_reserved1' offset changed from 21312 to 21376 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved2' offset changed from 21376 to 21440 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved3' offset changed from 21440 to 21504 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved4' offset changed from 21504 to 21568 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved5' offset changed from 21568 to 21632 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved6' offset changed from 21632 to 21696 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved7' offset changed from 21696 to 21760 (in bits) (by +64 bits)
'u64 task_struct::android_kabi_reserved8' offset changed from 21760 to 21824 (in bits) (by +64 bits)
3325 impacted interfaces
'struct file at fs.h:955:1' changed:
type size changed from 2048 to 2176 (in bits)
2 data member insertions:
'u64 file::android_kabi_reserved1', at offset 2048 (in bits) at fs.h:995:1
'u64 file::android_vendor_data1', at offset 2112 (in bits) at fs.h:996:1
3325 impacted interfaces
'struct mem_cgroup at memcontrol.h:208:1' changed:
type size changed from 21504 to 22528 (in bits)
1 data member insertion:
'deferred_split mem_cgroup::deferred_split_queue', at offset 22144 (in bits) at memcontrol.h:334:1
there are data member changes:
type 'atomic_long_t[56]' of 'mem_cgroup::vmevents' changed:
type name changed from 'atomic_long_t[56]' to 'atomic_long_t[70]'
array type size changed from 3584 to 4480
array type subrange 1 changed length from 56 to 70
'atomic_long_t mem_cgroup::memory_events[7]' offset changed from 17280 to 18176 (in bits) (by +896 bits)
'atomic_long_t mem_cgroup::memory_events_local[7]' offset changed from 17728 to 18624 (in bits) (by +896 bits)
'unsigned long int mem_cgroup::socket_pressure' offset changed from 18176 to 19072 (in bits) (by +896 bits)
'bool mem_cgroup::tcpmem_active' offset changed from 18240 to 19136 (in bits) (by +896 bits)
'int mem_cgroup::tcpmem_pressure' offset changed from 18272 to 19168 (in bits) (by +896 bits)
'int mem_cgroup::kmemcg_id' offset changed from 18304 to 19200 (in bits) (by +896 bits)
'memcg_kmem_state mem_cgroup::kmem_state' offset changed from 18336 to 19232 (in bits) (by +896 bits)
'list_head mem_cgroup::kmem_caches' offset changed from 18368 to 19264 (in bits) (by +896 bits)
'int mem_cgroup::last_scanned_node' offset changed from 18496 to 19392 (in bits) (by +896 bits)
'list_head mem_cgroup::cgwb_list' offset changed from 18560 to 19456 (in bits) (by +896 bits)
'wb_domain mem_cgroup::cgwb_domain' offset changed from 18688 to 19584 (in bits) (by +896 bits)
'memcg_cgwb_frn mem_cgroup::cgwb_frn[4]' offset changed from 19776 to 20672 (in bits) (by +896 bits)
'list_head mem_cgroup::event_list' offset changed from 21056 to 21952 (in bits) (by +896 bits)
'spinlock_t mem_cgroup::event_list_lock' offset changed from 21184 to 22080 (in bits) (by +896 bits)
'mem_cgroup_per_node* mem_cgroup::nodeinfo[]' offset changed from 21248 to 22400 (in bits) (by +1152 bits)
420 impacted interfaces
'struct memcg_vmstats_percpu at memcontrol.h:88:1' changed:
type size changed from 6272 to 7168 (in bits)
there are data member changes:
type 'unsigned long int[56]' of 'memcg_vmstats_percpu::events' changed:
type name changed from 'unsigned long int[56]' to 'unsigned long int[70]'
array type size changed from 3584 to 4480
array type subrange 1 changed length from 56 to 70
'unsigned long int memcg_vmstats_percpu::nr_page_events' offset changed from 6016 to 6912 (in bits) (by +896 bits)
'unsigned long int memcg_vmstats_percpu::targets[3]' offset changed from 6080 to 6976 (in bits) (by +896 bits)
420 impacted interfaces
'struct pglist_data at mmzone.h:713:1' changed:
details were reported earlier
'struct task_struct at sched.h:636:1' changed:
details were reported earlier
Bug: 161946584
Change-Id: I84324ddd226df0c756d61fc02081dc4bc37f36b1
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add an element to ANDROID_VENDOR_DATA_ARRAY(1,2) in task_struct
Bug: 169343953
Signed-off-by: Egor Uleyskiy <e.uleyskiy@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iee22bb544da5cc355d162d7a966c656f453c8a33
Devices with plenty of RAM might benefit from THP usage. Added fields
would allow to enable CONFIG_TRANSPARENT_HUGEPAGE without affecting ABI.
Bug: 168269341
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ieb644a8da5377383d514197ee02d7bfd6f1d346d
ehci_handshake was added to the symbol list as a temporary workaround
for CRC-related issues in the ehci code. But since this has now been
fixed, let's drop the unnecessary symbol list altogether.
Bug: 167230325
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8f56b01ff9bed8e0d417f8c90adb7c32480d55cf
The CRC calculation done by genksyms is triggered when the parser hits
EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the
types of the function parameters, and uses that as the input for the CRC
calculation. In the case of forward-declared structs, the type expands
to 'UNKNOWN'. Following this, it appears that the result of the
expansion of each type is cached somewhere, and seems to be re-used
when/if the same type is seen again for another exported symbol in the
same C file.
Unfortunately, this can cause CRC 'stability' issues when a struct
definition becomes visible in the middle of a C file. For example, let's
assume code with the following pattern:
struct foo;
int bar(struct foo *arg)
{
/* Do work ... */
}
EXPORT_SYMBOL_GPL(bar);
/* This contains struct foo's definition */
#include "foo.h"
int baz(struct foo *arg)
{
/* Do more work ... */
}
EXPORT_SYMBOL_GPL(baz);
Here, baz's CRC will be computed using the expansion of struct foo that
was cached after bar's CRC calculation ('UNKOWN' here). But if
EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol
trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded
late, during baz's CRC calculation, which now has visibility over the
full struct definition, hence resulting in a different CRC for baz.
The proper fix for this certainly is in genksyms, but that will take me
some time to get right. In the meantime, we have seen one occurrence of
this in the ehci-hcd code which hits this problem because of the way it
includes C files halfway through the code together with an unlucky mix
of symbol trimming.
In order to workaround this, move the include done in ehci-hub.c early
in ehci-hcd.c, hence making sure the struct definitions are visible to
the entire file. This improves CRC stability of the ehci-hcd exports
even when symbol trimming is enabled.
Bug: 167230325
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/r/20200916171825.3228122-1-qperret@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 29231826f3bd65500118c473fccf31c0cf14dbc0)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie56a4deee980652e5285a0744a8bcc2c9e60db73
Update the Vivo symbol list to come up to date with some more modules.
No new symbols are exported from the system, so no .xml file change
needed.
Bug: 170931247
Change-Id: I21e8ce22e327f315efecb9c4597560239b1e0aae
Signed-off-by: Chenggang Wang <wangchenggang@vivo.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl+Gt9kACgkQONu9yGCS
aT4qAg//ecjVetf6vClqaA6jNWoVHeyuSxJKNWdLWq0XkQgYInuya8irLXoGwY1j
UTTOvbFT+UwJ1N9DWIB5cLaEkYNLcGA9YYExtcVA6YUfdlhWQw5zcyovIXcw4jHx
Ma0O2usPE/7Rb9O2+3O8t4jr1YF9C7iRkY82FJJIbDa6GbFQA6hGZ4mHfnjh1l84
owgSjZ1Yy2HU2uUzX8hA6dXZeIu+SQMk5E2nQSm/DAPhDwbIqPb5Rx9UYqCXafiA
1c9Cj7RWKopPP9gxNSOzYfLVzOr0YHoFm5uMxtz4apzpNhl/j5CTGphFOnY6SuJs
BWrRK9D47PGtds5IJ1MslVVb1i1tt0in0RJsNuYV35CXCoJDuaIzaQPJBlpyvix0
ZialpH+nI3Z1yy7uzVSvrAK11AMwq+79VG/byHht02YVZycHOt7e4wRep3KjpQQq
uJHapB5djGhPkZypgHOak9Tw1A/snwxC4yR2Xl+Cqn46igIJ8xlgnuey1AmT7pzi
dSEiJoC7xzHUFildfzrNWkZwIffBFYVPJGfPFyRpyvNc2mOW3S9bwbX0NptE0qSQ
YzOxQIfqa43TOBJNKZdgHGDrpnPHTESzO63BurQ3fpUI2ex7XjWq92zrIwp23reJ
9Y/cpELW/paL/dg3ZFYp/wPoOoAh/84GICPXLZPREJkKf0WWey0=
=1GCf
-----END PGP SIGNATURE-----
Merge 5.4.71 into android11-5.4-lts
Changes in 5.4.71
fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
fbcon: Fix global-out-of-bounds read in fbcon_get_font()
Revert "ravb: Fixed to be able to unload modules"
io_uring: Fix resource leaking when kill the process
io_uring: Fix missing smp_mb() in io_cancel_async_work()
io_uring: Fix remove irrelevant req from the task_list
io_uring: Fix double list add in io_queue_async_work()
net: wireless: nl80211: fix out-of-bounds access in nl80211_del_key()
drm/nouveau/mem: guard against NULL pointer access in mem_del
vhost: Don't call access_ok() when using IOTLB
vhost: Use vhost_get_used_size() in vhost_vring_set_addr()
usermodehelper: reset umask to default before executing user process
Platform: OLPC: Fix memleak in olpc_ec_probe
platform/x86: intel-vbtn: Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360
platform/x86: thinkpad_acpi: initialize tp_nvram_state variable
bpf: Fix sysfs export of empty BTF section
bpf: Prevent .BTF section elimination
platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting
platform/x86: thinkpad_acpi: re-initialize ACPI buffer size when reuse
driver core: Fix probe_count imbalance in really_probe()
perf test session topology: Fix data path
perf top: Fix stdio interface input handling with glibc 2.28+
i2c: i801: Exclude device from suspend direct complete optimization
arm64: dts: stratix10: add status to qspi dts node
Btrfs: send, allow clone operations within the same file
Btrfs: send, fix emission of invalid clone operations within the same file
btrfs: volumes: Use more straightforward way to calculate map length
btrfs: Ensure we trim ranges across block group boundary
btrfs: fix RWF_NOWAIT write not failling when we need to cow
btrfs: allow btrfs_truncate_block() to fallback to nocow for data space reservation
nvme-core: put ctrl ref when module ref get fail
macsec: avoid use-after-free in macsec_handle_frame()
mm/khugepaged: fix filemap page_to_pgoff(page) != offset
net: introduce helper sendpage_ok() in include/linux/net.h
tcp: use sendpage_ok() to detect misused .sendpage
nvme-tcp: check page by sendpage_ok() before calling kernel_sendpage()
xfrmi: drop ignore_df check before updating pmtu
cifs: Fix incomplete memory allocation on setxattr path
i2c: meson: fix clock setting overwrite
i2c: meson: fixup rate calculation with filter delay
i2c: owl: Clear NACK and BUS error bits
sctp: fix sctp_auth_init_hmacs() error path
team: set dev->needed_headroom in team_setup_by_port()
net: team: fix memory leak in __team_options_register
openvswitch: handle DNAT tuple collision
drm/amdgpu: prevent double kfree ttm->sg
iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb()
xfrm: clone XFRMA_SET_MARK in xfrm_do_migrate
xfrm: clone XFRMA_REPLAY_ESN_VAL in xfrm_do_migrate
xfrm: clone XFRMA_SEC_CTX in xfrm_do_migrate
xfrm: clone whole liftime_cur structure in xfrm_do_migrate
net: stmmac: removed enabling eee in EEE set callback
platform/x86: fix kconfig dependency warning for FUJITSU_LAPTOP
xfrm: Use correct address family in xfrm_state_find
iavf: use generic power management
iavf: Fix incorrect adapter get in iavf_resume
net: ethernet: cavium: octeon_mgmt: use phy_start and phy_stop
bonding: set dev->needed_headroom in bond_setup_by_slave()
mdio: fix mdio-thunder.c dependency & build error
mlxsw: spectrum_acl: Fix mlxsw_sp_acl_tcam_group_add()'s error path
r8169: fix RTL8168f/RTL8411 EPHY config
net: usb: ax88179_178a: fix missing stop entry in driver_info
virtio-net: don't disable guest csum when disable LRO
net/mlx5: Avoid possible free of command entry while timeout comp handler
net/mlx5: Fix request_irqs error flow
net/mlx5e: Add resiliency in Striding RQ mode for packets larger than MTU
net/mlx5e: Fix VLAN cleanup flow
net/mlx5e: Fix VLAN create flow
rxrpc: Fix rxkad token xdr encoding
rxrpc: Downgrade the BUG() for unsupported token type in rxrpc_read()
rxrpc: Fix some missing _bh annotations on locking conn->state_lock
rxrpc: The server keyring isn't network-namespaced
rxrpc: Fix server keyring leak
perf: Fix task_function_call() error handling
mmc: core: don't set limits.discard_granularity as 0
mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected by khugepaged
tcp: fix receive window update in tcp_add_backlog()
net/core: check length before updating Ethertype in skb_mpls_{push,pop}
net/tls: race causes kernel panic
net/mlx5e: Fix driver's declaration to support GRE offload
Input: ati_remote2 - add missing newlines when printing module parameters
net: usb: rtl8150: set random MAC address when set_ethernet_addr() fails
net_sched: defer tcf_idr_insert() in tcf_action_init_1()
net_sched: commit action insertions together
Linux 5.4.71
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8c48e9e33e4375ff6662d1b23e76b963db306759
commit 0fedc63fadf0404a729e73a35349481c8009c02f upstream.
syzbot is able to trigger a failure case inside the loop in
tcf_action_init(), and when this happens we clean up with
tcf_action_destroy(). But, as these actions are already inserted
into the global IDR, other parallel process could free them
before tcf_action_destroy(), then we will trigger a use-after-free.
Fix this by deferring the insertions even later, after the loop,
and committing all the insertions in a separate loop, so we will
never fail in the middle of the insertions any more.
One side effect is that the window between alloction and final
insertion becomes larger, now it is more likely that the loop in
tcf_del_walker() sees the placeholder -EBUSY pointer. So we have
to check for error pointer in tcf_del_walker().
Reported-and-tested-by: syzbot+2287853d392e4b42374a@syzkaller.appspotmail.com
Fixes: 0190c1d452 ("net: sched: atomically check-allocate action")
Cc: Vlad Buslov <vladbu@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e49d8c22f1261c43a986a7fdbf677ac309682a07 upstream.
All TC actions call tcf_idr_insert() for new action at the end
of their ->init(), so we can actually move it to a central place
in tcf_action_init_1().
And once the action is inserted into the global IDR, other parallel
process could free it immediately as its refcnt is still 1, so we can
not fail after this, we need to move it after the goto action
validation to avoid handling the failure case after insertion.
This is found during code review, is not directly triggered by syzbot.
And this prepares for the next patch.
Cc: Vlad Buslov <vladbu@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f45a4248ea4cc13ed50618ff066849f9587226b2 upstream.
When get_registers() fails in set_ethernet_addr(),the uninitialized
value of node_id gets copied over as the address.
So, check the return value of get_registers().
If get_registers() executed successfully (i.e., it returns
sizeof(node_id)), copy over the MAC address using ether_addr_copy()
(instead of using memcpy()).
Else, if get_registers() failed instead, a randomly generated MAC
address is set as the MAC address instead.
Reported-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
Tested-by: syzbot+abbc768b560c84d92fd3@syzkaller.appspotmail.com
Acked-by: Petko Manolov <petkan@nucleusys.com>
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37bd9e803daea816f2dc2c8f6dc264097eb3ebd2 upstream.
When I cat some module parameters by sysfs, it displays as follows. It's
better to add a newline for easy reading.
root@syzkaller:~# cat /sys/module/ati_remote2/parameters/mode_mask
0x1froot@syzkaller:~# cat /sys/module/ati_remote2/parameters/channel_mask
0xffffroot@syzkaller:~#
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Link: https://lore.kernel.org/r/20200720092148.9320-1-wangxiongfeng2@huawei.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d093bc2369003b4ce6c3522d9b383e47c40045d upstream.
Declare GRE offload support with respect to the inner protocol. Add a
list of supported inner protocols on which the driver can offload
checksum and GSO. For other protocols, inform the stack to do the needed
operations. There is no noticeable impact on GRE performance.
Fixes: 2729984149 ("net/mlx5e: Support TSO and TX checksum offloads for GRE tunnels")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4296adc3e32f5d544a95061160fe7e127be1b9ff upstream.
Openvswitch allows to drop a packet's Ethernet header, therefore
skb_mpls_push() and skb_mpls_pop() might be called with ethernet=true
and mac_len=0. In that case the pointer passed to skb_mod_eth_type()
doesn't point to an Ethernet header and the new Ethertype is written at
unexpected locations.
Fix this by verifying that mac_len is big enough to contain an Ethernet
header.
Fixes: fa4e0f8855 ("net/sched: fix corrupted L2 header with MPLS 'push' and 'pop' actions")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86bccd0367130f481ca99ba91de1c6a5aa1c78c1 upstream.
We got reports from GKE customers flows being reset by netfilter
conntrack unless nf_conntrack_tcp_be_liberal is set to 1.
Traces seemed to suggest ACK packet being dropped by the
packet capture, or more likely that ACK were received in the
wrong order.
wscale=7, SYN and SYNACK not shown here.
This ACK allows the sender to send 1871*128 bytes from seq 51359321 :
New right edge of the window -> 51359321+1871*128=51598809
09:17:23.389210 IP A > B: Flags [.], ack 51359321, win 1871, options [nop,nop,TS val 10 ecr 999], length 0
09:17:23.389212 IP B > A: Flags [.], seq 51422681:51424089, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 1408
09:17:23.389214 IP A > B: Flags [.], ack 51422681, win 1376, options [nop,nop,TS val 10 ecr 999], length 0
09:17:23.389253 IP B > A: Flags [.], seq 51424089:51488857, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 64768
09:17:23.389272 IP A > B: Flags [.], ack 51488857, win 859, options [nop,nop,TS val 10 ecr 999], length 0
09:17:23.389275 IP B > A: Flags [.], seq 51488857:51521241, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 32384
Receiver now allows to send 606*128=77568 from seq 51521241 :
New right edge of the window -> 51521241+606*128=51598809
09:17:23.389296 IP A > B: Flags [.], ack 51521241, win 606, options [nop,nop,TS val 10 ecr 999], length 0
09:17:23.389308 IP B > A: Flags [.], seq 51521241:51553625, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 32384
It seems the sender exceeds RWIN allowance, since 51611353 > 51598809
09:17:23.389346 IP B > A: Flags [.], seq 51553625:51611353, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 57728
09:17:23.389356 IP B > A: Flags [.], seq 51611353:51618393, ack 1577, win 268, options [nop,nop,TS val 999 ecr 10], length 7040
09:17:23.389367 IP A > B: Flags [.], ack 51611353, win 0, options [nop,nop,TS val 10 ecr 999], length 0
netfilter conntrack is not happy and sends RST
09:17:23.389389 IP A > B: Flags [R], seq 92176528, win 0, length 0
09:17:23.389488 IP B > A: Flags [R], seq 174478967, win 0, length 0
Now imagine ACK were delivered out of order and tcp_add_backlog() sets window based on wrong packet.
New right edge of the window -> 51521241+859*128=51631193
Normally TCP stack handles OOO packets just fine, but it
turns out tcp_add_backlog() does not. It can update the window
field of the aggregated packet even if the ACK sequence
of the last received packet is too old.
Many thanks to Alexandre Ferrieux for independently reporting the issue
and suggesting a fix.
Fixes: 4f693b55c3 ("tcp: implement coalescing on backlog queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Alexandre Ferrieux <alexandre.ferrieux@orange.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4aab2be0983031a05cb4a19696c9da5749523426 upstream.
When memory is hotplug added or removed the min_free_kbytes should be
recalculated based on what is expected by khugepaged. Currently after
hotplug, min_free_kbytes will be set to a lower default and higher
default set when THP enabled is lost.
This change restores min_free_kbytes as expected for THP consumers.
[vijayb@linux.microsoft.com: v5]
Link: https://lkml.kernel.org/r/1601398153-5517-1-git-send-email-vijayb@linux.microsoft.com
Fixes: f000565adb ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Allen Pais <apais@microsoft.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/1600305709-2319-2-git-send-email-vijayb@linux.microsoft.com
Link: https://lkml.kernel.org/r/1600204258-13683-1-git-send-email-vijayb@linux.microsoft.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4243219141b67d7c2fdb2d8073c17c539b9263eb ]
In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
might be set as 0 (when card->pref_erase > max_discard) while the mmc
device still declares to support discard operation. This is buggy and
triggered the following kernel warning message,
WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294
CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1
Hardware name: Google Kevin (DT)
pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
pc : __blkdev_issue_discard+0x200/0x294
lr : __blkdev_issue_discard+0x54/0x294
sp : ffff800011dd3b10
x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace:
__blkdev_issue_discard+0x200/0x294
__submit_discard_cmd+0x128/0x374
__issue_discard_cmd_orderly+0x188/0x244
__issue_discard_cmd+0x2e8/0x33c
issue_discard_thread+0xe8/0x2f0
kthread+0x11c/0x120
ret_from_fork+0x10/0x1c
---[ end trace e4c8023d33dfe77a ]---
This patch fixes the issue by setting discard_granularity as SECTOR_SIZE
instead of 0 when (card->pref_erase > max_discard) is true. Now no more
complain from __blkdev_issue_discard() for the improper value of discard
granularity.
This issue is exposed after commit b35fd7422c2f ("block: check queue's
limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag
is also added for the commit to make sure people won't miss this patch
after applying the change of __blkdev_issue_discard().
Fixes: e056a1b5b6 ("mmc: queue: let host controllers specify maximum discard timeout")
Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()").
Reported-and-tested-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Coly Li <colyli@suse.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20201002013852.51968-1-colyli@suse.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6d6b8b9f4fceab7266ca03d194f60ec72bd4b654 ]
The error handling introduced by commit:
2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
looses any return value from smp_call_function_single() that is not
{0, -EINVAL}. This is a problem because it will return -EXNIO when the
target CPU is offline. Worse, in that case it'll turn into an infinite
loop.
Fixes: 2ed6edd33a21 ("perf: Add cond_resched() to task_function_call()")
Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Barret Rhoden <brho@google.com>
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Link: https://lkml.kernel.org/r/20200827064732.20860-1-kjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 38b1dc47a35ba14c3f4472138ea56d014c2d609b ]
If someone calls setsockopt() twice to set a server key keyring, the first
keyring is leaked.
Fix it to return an error instead if the server key keyring is already set.
Fixes: 17926a7932 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fea99111244bae44e7d82a973744d27ea1567814 ]
The keyring containing the server's tokens isn't network-namespaced, so it
shouldn't be looked up with a network namespace. It is expected to be
owned specifically by the server, so namespacing is unnecessary.
Fixes: a58946c158 ("keys: Pass the network namespace into request_key mechanism")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fa1d113a0f96f9ab7e4fe4f8825753ba1e34a9d3 ]
conn->state_lock may be taken in softirq mode, but a previous patch
replaced an outer lock in the response-packet event handling code, and lost
the _bh from that when doing so.
Fix this by applying the _bh annotation to the state_lock locking.
Fixes: a1399f8bb0 ("rxrpc: Call channels should have separate call number spaces")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9a059cd5ca7d9c5c4ca5a6e755cf72f230176b6a ]
If rxrpc_read() (which allows KEYCTL_READ to read a key), sees a token of a
type it doesn't recognise, it can BUG in a couple of places, which is
unnecessary as it can easily get back to userspace.
Fix this to print an error message instead.
Fixes: 99455153d0 ("RxRPC: Parse security index 5 keys (Kerberos 5)")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 56305118e05b2db8d0395bba640ac9a3aee92624 ]
The session key should be encoded with just the 8 data bytes and
no length; ENCODE_DATA precedes it with a 4 byte length, which
confuses some existing tools that try to parse this format.
Add an ENCODE_BYTES macro that does not include a length, and use
it for the key. Also adjust the expected length.
Note that commit 774521f353 ("rxrpc: Fix an assertion in
rxrpc_read()") had fixed a BUG by changing the length rather than
fixing the encoding. The original length was correct.
Fixes: 99455153d0 ("RxRPC: Parse security index 5 keys (Kerberos 5)")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d4a16052bccdd695982f89d815ca075825115821 ]
When interface is attached while in promiscuous mode and with VLAN
filtering turned off, both configurations are not respected and VLAN
filtering is performed.
There are 2 flows which add the any-vid rules during interface attach:
VLAN creation table and set rx mode. Each is relaying on the other to
add any-vid rules, eventually non of them does.
Fix this by adding any-vid rules on VLAN creation regardless of
promiscuous mode.
Fixes: 9df30601c8 ("net/mlx5e: Restore vlan filter after seamless reset")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8c7353b6f716436ad0bfda2b5c5524ab2dde5894 ]
Prior to this patch unloading an interface in promiscuous mode with RX
VLAN filtering feature turned off - resulted in a warning. This is due
to a wrong condition in the VLAN rules cleanup flow, which left the
any-vid rules in the VLAN steering table. These rules prevented
destroying the flow group and the flow table.
The any-vid rules are removed in 2 flows, but none of them remove it in
case both promiscuous is set and VLAN filtering is off. Fix the issue by
changing the condition of the VLAN table cleanup flow to clean also in
case of promiscuous mode.
mlx5_core 0000:00:08.0: mlx5_destroy_flow_group:2123:(pid 28729): Flow group 20 wasn't destroyed, refcount > 1
mlx5_core 0000:00:08.0: mlx5_destroy_flow_group:2123:(pid 28729): Flow group 19 wasn't destroyed, refcount > 1
mlx5_core 0000:00:08.0: mlx5_destroy_flow_table:2112:(pid 28729): Flow table 262149 wasn't destroyed, refcount > 1
...
...
------------[ cut here ]------------
FW pages counter is 11560 after reclaiming all pages
WARNING: CPU: 1 PID: 28729 at
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:660
mlx5_reclaim_startup_pages+0x178/0x230 [mlx5_core]
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
mlx5_function_teardown+0x2f/0x90 [mlx5_core]
mlx5_unload_one+0x71/0x110 [mlx5_core]
remove_one+0x44/0x80 [mlx5_core]
pci_device_remove+0x3e/0xc0
device_release_driver_internal+0xfb/0x1c0
device_release_driver+0x12/0x20
pci_stop_bus_device+0x68/0x90
pci_stop_and_remove_bus_device+0x12/0x20
hv_eject_device_work+0x6f/0x170 [pci_hyperv]
? __schedule+0x349/0x790
process_one_work+0x206/0x400
worker_thread+0x34/0x3f0
? process_one_work+0x400/0x400
kthread+0x126/0x140
? kthread_park+0x90/0x90
ret_from_fork+0x22/0x30
---[ end trace 6283bde8d26170dc ]---
Fixes: 9df30601c8 ("net/mlx5e: Restore vlan filter after seamless reset")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c3c9402373fe20e2d08c04f437ce4dcd252cffb2 ]
Prior to this fix, in Striding RQ mode the driver was vulnerable when
receiving packets in the range (stride size - headroom, stride size].
Where stride size is calculated by mtu+headroom+tailroom aligned to the
closest power of 2.
Usually, this filtering is performed by the HW, except for a few cases:
- Between 2 VFs over the same PF with different MTUs
- On bluefield, when the host physical function sets a larger MTU than
the ARM has configured on its representor and uplink representor.
When the HW filtering is not present, packets that are larger than MTU
might be harmful for the RQ's integrity, in the following impacts:
1) Overflow from one WQE to the next, causing a memory corruption that
in most cases is unharmful: as the write happens to the headroom of next
packet, which will be overwritten by build_skb(). In very rare cases,
high stress/load, this is harmful. When the next WQE is not yet reposted
and points to existing SKB head.
2) Each oversize packet overflows to the headroom of the next WQE. On
the last WQE of the WQ, where addresses wrap-around, the address of the
remainder headroom does not belong to the next WQE, but it is out of the
memory region range. This results in a HW CQE error that moves the RQ
into an error state.
Solution:
Add a page buffer at the end of each WQE to absorb the leak. Actually
the maximal overflow size is headroom but since all memory units must be
of the same size, we use page size to comply with UMR WQEs. The increase
in memory consumption is of a single page per RQ. Initialize the mkey
with all MTTs pointing to a default page. When the channels are
activated, UMR WQEs will redirect the RX WQEs to the actual memory from
the RQ's pool, while the overflow MTTs remain mapped to the default page.
Fixes: 73281b78a3 ("net/mlx5e: Derive Striding RQ size from MTU")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 50b2412b7e7862c5af0cbf4b10d93bc5c712d021 ]
Upon command completion timeout, driver simulates a forced command
completion. In a rare case where real interrupt for that command arrives
simultaneously, it might release the command entry while the forced
handler might still access it.
Fix that by adding an entry refcount, to track current amount of allowed
handlers. Command entry to be released only when this refcount is
decremented to zero.
Command refcount is always initialized to one. For callback commands,
command completion handler is the symmetric flow to decrement it. For
non-callback commands, it is wait_func().
Before ringing the doorbell, increment the refcount for the real completion
handler. Once the real completion handler is called, it will decrement it.
For callback commands, once the delayed work is scheduled, increment the
refcount. Upon callback command completion handler, we will try to cancel
the timeout callback. In case of success, we need to decrement the callback
refcount as it will never run.
In addition, gather the entry index free and the entry free into a one
flow for all command types release.
Fixes: e126ba97db ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1a03b8a35a957f9f38ecb8a97443b7380bbf6a8b ]
Open vSwitch and Linux bridge will disable LRO of the interface
when this interface added to them. Now when disable the LRO, the
virtio-net csum is disable too. That drops the forwarding performance.
Fixes: a02e8964ea ("virtio-net: ethtool configurable LRO")
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9666ea66a74adfe295cb3a8760c76e1ef70f9caf ]
Adds the missing .stop entry in the Belkin driver_info structure.
Fixes: e20bd60bf6 ("net: usb: asix88179_178a: Add support for the Belkin B2B128")
Signed-off-by: Wilken Gottwalt <wilken.gottwalt@mailbox.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 709a16be0593c08190982cfbdca6df95e6d5823b ]
Mistakenly bit 2 was set instead of bit 3 as in the vendor driver.
Fixes: a7a92cf815 ("r8169: sync PCIe PHY init with vendor driver 8.047.01")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 72865028582a678be1e05240e55d452e5c258eca ]
If mlxsw_sp_acl_tcam_group_id_get() fails, the mutex initialized earlier
is not destroyed.
Fix this by initializing the mutex after calling the function. This is
symmetric to mlxsw_sp_acl_tcam_group_del().
Fixes: 5ec2ee28d2 ("mlxsw: spectrum_acl: Introduce a mutex to guard region list updates")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4663ff60257aec4ee1e2e969a7c046f0aff35ab8 ]
To start also "phy state machine", with UP state as it should be,
the phy_start() has to be used, in another case machine even is not
triggered. After this change negotiation is supposed to be triggered
by SM workqueue.
It's not correct usage, but it appears after the following patch,
so add it as a fix.
Fixes: 74a992b359 ("net: phy: add phy_check_link_status")
Signed-off-by: Ivan Khoronzhuk <ikhoronz@cisco.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 75598a8fc0e0dff2aa5d46c62531b36a595f1d4f ]
When calling iavf_resume there was a crash because wrong
function was used to get iavf_adapter and net_device pointers.
Changed how iavf_resume is getting iavf_adapter and net_device
pointers from pci_dev.
Fixes: 5eae00c57f ("i40evf: main driver core")
Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bc5cbd73eb493944b8665dc517f684c40eb18a4a ]
With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves. The required operations are
done by PCI core.
PCI drivers are not expected to invoke PCI helper functions like
pci_save/restore_state(), pci_enable/disable_device(),
pci_set_power_state(), etc. Their tasks are completed by PCI core itself.
Compile-tested only.
Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e94ee171349db84c7cfdc5fefbebe414054d0924 ]
The struct flowi must never be interpreted by itself as its size
depends on the address family. Therefore it must always be grouped
with its original family value.
In this particular instance, the original family value is lost in
the function xfrm_state_find. Therefore we get a bogus read when
it's coupled with the wrong family which would occur with inter-
family xfrm states.
This patch fixes it by keeping the original family value.
Note that the same bug could potentially occur in LSM through
the xfrm_state_pol_flow_match hook. I checked the current code
there and it seems to be safe for now as only secid is used which
is part of struct flowi_common. But that API should be changed
so that so that we don't get new bugs in the future. We could
do that by replacing fl with just secid or adding a family field.
Reported-by: syzbot+577fbac3145a6eb2e7a5@syzkaller.appspotmail.com
Fixes: 48b8d78315 ("[XFRM]: State selection update to use inner...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit afdd1ebb72051e8b6b83c4d7dc542a9be0e1352d ]
When FUJITSU_LAPTOP is enabled and NEW_LEDS is disabled, it results in the
following Kbuild warning:
WARNING: unmet direct dependencies detected for LEDS_CLASS
Depends on [n]: NEW_LEDS [=n]
Selected by [y]:
- FUJITSU_LAPTOP [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] && INPUT [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n)
The reason is that FUJITSU_LAPTOP selects LEDS_CLASS without depending on
or selecting NEW_LEDS while LEDS_CLASS is subordinate to NEW_LEDS.
Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Fixes: d89bcc83e7 ("platform/x86: fujitsu-laptop: select LEDS_CLASS")
Signed-off-by: Necip Fazil Yildiran <fazilyildiran@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7241c5a697479c7d0c5a96595822cdab750d41ae ]
EEE should be only be enabled during stmmac_mac_link_up() when the
link are up and being set up properly. set_eee should only do settings
configuration and disabling the eee.
Without this fix, turning on EEE using ethtool will return
"Operation not supported". This is due to the driver is in a dead loop
waiting for eee to be advertised in the for eee to be activated but the
driver will only configure the EEE advertisement after the eee is
activated.
Ethtool should only return "Operation not supported" if there is no EEE
capbility in the MAC controller.
Fixes: 8a7493e58a ("net: stmmac: Fix a race in EEE enable callback")
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Acked-by: Mark Gross <mgross@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8366685b2883e523f91e9816d7be371eb1144749 ]
When we clone state only add_time was cloned. It missed values like
bytes, packets. Now clone the all members of the structure.
v1->v3:
- use memcpy to copy the entire structure
Fixes: 80c9abaabf ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7aa05d304785204703a67a6aa7f1db402889a172 ]
XFRMA_SEC_CTX was not cloned from the old to the new.
Migrate this attribute during XFRMA_MSG_MIGRATE
v1->v2:
- return -ENOMEM on error
v2->v3:
- fix return type to int
Fixes: 80c9abaabf ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 91a46c6d1b4fcbfa4773df9421b8ad3e58088101 ]
XFRMA_REPLAY_ESN_VAL was not cloned completely from the old to the new.
Migrate this attribute during XFRMA_MSG_MIGRATE
v1->v2:
- move curleft cloning to a separate patch
Fixes: af2f464e32 ("xfrm: Assign esn pointers when cloning a state")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 545e5c571662b1cd79d9588f9d3b6e36985b8007 ]
XFRMA_SET_MARK and XFRMA_SET_MARK_MASK was not cloned from the old
to the new. Migrate these two attributes during XFRMA_MSG_MIGRATE
Fixes: 9b42c1f179 ("xfrm: Extend the output_mark to support input direction and masking.")
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
