To create boot images for multiple kernels for CI testing, we
need the initramfs image. To generate initramfs, vmlinux and
System.map were also added to the list of artifacts.
Bug: 162034308
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I08fc4a45402dfff78da4d322ee70c2f63a262468
CEC_{CORE,NOTIFIER,PIN} are hidden options which are selected by
drivers. Select them here so the ABI surface is available to
modules.
Bug: 162507365
Bug: 164180803
Change-Id: Idf8d072388b387442d967bf1c6d3be1f9a734ab6
Signed-off-by: Alistair Delva <adelva@google.com>
Update the ABI snapshot after the additions made to struct
io_pgtable_cfg for adding support for IOMMU drivers to allocate/free
page-table memory.
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some sub-type change:
[C] 'function io_pgtable_ops* alloc_io_pgtable_ops(io_pgtable_fmt, io_pgtable_cfg*, void*)' at io-pgtable.c:29:1 has some sub-type changes:
CRC value (modversions) changed from 0xe49d2ea to 0x153c3f3b
'struct io_pgtable_cfg at io-pgtable.h:64:1' changed:
type size changed from 704 to 768 (in bits)
1 data member insertion:
'const iommu_pgtable_ops* io_pgtable_cfg::iommu_pgtable_ops', at offset 320 (in bits) at io-pgtable.h:113:1
there are data member changes:
'device* io_pgtable_cfg::iommu_dev' offset changed from 320 to 384 (in bits) (by +64 bits)
anonymous data member 'union {struct {u64 ttbr[2]; u64 tcr; u64 mair[2];} arm_lpae_s1_cfg; struct {u64 vttbr; u64 vtcr;} arm_lpae_s2_cfg; struct {u32 ttbr[2]; u32 tcr; u32 nmrr; u32 prrr;} arm_v7s_cfg; struct {u64 transtab; u64 memattr;} arm_mali_lpae_cfg;}' offset changed from 384 to 448 (in bits) (by +64 bits)
one impacted interface:
function io_pgtable_ops* alloc_io_pgtable_ops(io_pgtable_fmt, io_pgtable_cfg*, void*)
Bug: 147086566
Change-Id: I17904a2dde3bf17e5917a6af8ef886c4fdcd3c95
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The page-table memory is currently allocated and freed by the io-pgtable
layer, and there is no intervention from the IOMMU driver during this
process. However, in some environments, where the IOMMU driver may need
to be aware of the pages that are used for its page-tables, it is useful
to allow the IOMMU driver to manage the allocation and freeing of the
page table memory.
Thus, add support in the io-pgtable layer to allow IOMMU drivers to
allocate and free page-table memory.
Bug: 147086566
Change-Id: I7b38a72da1654273a4312e04c776b10612c57bdc
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
ac2e6c2e7e ("BACKPORT: cfg80211: express channels with a KHz
component") added ieee80211_get_channel_khz and introduced a dependency
on it in cuttlefish. Add this symbol to the ABI.
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 1 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 Added function:
[A] 'function ieee80211_channel* ieee80211_get_channel_khz(wiphy*, u32)'
Bug: 163218447
Signed-off-by: Steve Muckle <smuckle@google.com>
Change-Id: I3a4ca99eea0cb65ab82ef4e78fe0d83e2da5af12
A number of upstream patches are getting rejected by checkpatch in
treehugger despite following the correct checkpatch rules as they have
changed since the 5.4 release.
So update to the latest version, from 5.9-rc1, to quiet things that are
now valid.
Bug: 164355829
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit a1d21081a60dfb7fddf4a38b66d9cef603b317a9)
Change-Id: Ic3768ec45972d43885fd3170f96ad03dd9d852fc
Currently, UFS driver checks if fDeviceInit
is cleared at several times, not period. This patch
is to wait its completion with the period, not retrying.
Many device vendors usually provides the specification on
it with just period, not a combination of a number of retrying
and period. So it could be proper to regard to the information
coming from device vendors.
v1 -> v2: switch the method to get time from jiffies to ktime
Bug: 163478167
Change-Id: I167d8a3480b1a75f6fadb3e73d15d67807608e93
Link: https://lore.kernel.org/linux-scsi/SN6PR04MB4640676A86C1A3C598CD804AFC440@SN6PR04MB4640.namprd04.prod.outlook.com/T/#t
Tested-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 68815d5b7e which was
commit 0845447d9c783a502bd3e13af0f38aa4c7655a77 in 4.19.y and is commit
1e82a62fec613844da9e558f3493540a5b7a7b67 upstream.
It was reported that this issue affects Android devices and a vendor
wishes it to be applied back, ABI is not an issue here.
Leaf changes summary: 5 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 4 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
4 functions with some sub-type change:
[C] 'function void genl_notify(const genl_family*, sk_buff*, genl_info*, u32, gfp_t)' at genetlink.c:1109:1 has some sub-type changes:
[C] 'function int genl_register_family(genl_family*)' at genetlink.h:145:1 has some sub-type changes:
[C] 'function int genl_unregister_family(const genl_family*)' at genetlink.h:146:1 has some sub-type changes:
[C] 'function void* genlmsg_put(sk_buff*, unsigned int, unsigned int, const genl_family*, int, unsigned char)' at genetlink.h:150:1 has some sub-type changes:
'struct genl_family at genetlink.h:52:1' changed:
type size changed from 1024 to 896 (in bits)
2 data member deletions:
'int (net*, int)* genl_family::mcast_bind', at offset 512 (in bits) at genetlink.h:67:1
'void (net*, int)* genl_family::mcast_unbind', at offset 576 (in bits) at genetlink.h:68:1
there are data member changes:
'nlattr** genl_family::attrbuf' offset changed from 640 to 512 (in bits) (by -128 bits)
'const genl_ops* genl_family::ops' offset changed from 704 to 576 (in bits) (by -128 bits)
'const genl_multicast_group* genl_family::mcgrps' offset changed from 768 to 640 (in bits) (by -128 bits)
'unsigned int genl_family::n_ops' offset changed from 832 to 704 (in bits) (by -128 bits)
'unsigned int genl_family::n_mcgrps' offset changed from 864 to 736 (in bits) (by -128 bits)
'unsigned int genl_family::mcgrp_offset' offset changed from 896 to 768 (in bits) (by -128 bits)
'module* genl_family::module' offset changed from 960 to 832 (in bits) (by -128 bits)
4 impacted interfaces
Bug: 163861691
Cc: Sean Tranchetti <stranche@codeaurora.org>
Cc: Will McVicker <willmcvicker@google.com>
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ieaa81ed2445ff12a9a8e00f69d64c78baeec07e5
Set CONFIG_LEDS_TRIGGER_TIMER=y to enable the "timer" trigger for the
LED subsystem. This creates the sysfs parameters "delay_on" and
"delay_off" for LEDs, which can then be used to specify a blinking
pattern for them.
Bug: 163765274
Change-Id: I66ada688aa5026253e76588ae1d6d85eb4cd8536
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
[fixed up arm64 config location as it was incorrect - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
b519ac4237 ("ANDROID: vendor_hooks: add waiting information for
blocked tasks") changed the abi, but the definition xml file never got
updated.
Bug: 162776704
Cc: Sangmoon Kim <sangmoon.kim@samsung.com>
Fixes: b519ac4237 ("ANDROID: vendor_hooks: add waiting information for blocked tasks")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibb92f7c0e29a7a05a997e16a07b05053a6c05ae3
- Add the hook to get mutex/rwsem information that the tasks
are waiting for.
- Add the hook to print messages for sched_show_task.
- ANDROID_VENDOR_DATA_ARRAY added to task_struct
Bug: 162776704
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: Ib436fbd8d0ad509c3b5a73ea8f5170e0761a13fd
Introduce low power mode so that listeners are aware when display is
going into low power mode. This requires moving notifier inside sde code
to be able to retrieve the low power state.
Add mode for fps change so that clients can be
notified whenever there is a change in fps.
Include the current vrefresh in the msm_drm_notifier data provided to
registered clients.
Include the index id in the drm_panel_notifier data
provided to registered clients.
Bug: 155453628
Co-Developed-by: Adrian Salido <salidoa@google.com>
Co-Developed-by: Steve Pfetsch <spfetsch@google.com>
Co-Developed-by: Krishna Manikandan <mkrishn@codeaurora.org>
Co-Developed-by: Samantha Tran <samtran@codeaurora.org>
Co-Developed-by: Dhaval Patel <pdhaval@codeaurora.org>
[chandanu@codeaurora.org: Squashed four different gerrits
into one change]
Change-Id: I8e29ab65991b5777c3bd64182ce989e80d2462bf
Signed-off-by: Chandan Uddaraju <chandanu@codeaurora.org>
Add missing setup_xfer_req() call in ufshcd_issue_devman_upiu_cmd() in
ufs-bsg path. Relocate existing setup_xfer_req() calls to a common place,
i.e., ufshcd_send_command(), to simplify the driver.
Bug: 163100328
Link: https://lore.kernel.org/r/20200706060707.32608-3-stanley.chu@mediatek.com
Acked-by: Avri Altman <Avri.Altman@wdc.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Change-Id: Ibe16a421e5f3f003529379b1ac96b0a9306b0fe0
(cherry picked from commit 6edfdcfe285e499994b94a0f93e1f46ab2398162)
Signed-off-by: nanich.lee <nanich.lee@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Some devices need the USB UVC drivers built in, so enable the following
config options to do so:
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_GSPCA=y
Bug: 163679730
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I2e1a80eceef8d3effe4efe452c94f1e98d1a3bdc
It's needed by devices, so add it to the gki defconfig files
Bug: 163679730
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ia9c77c07e7e4c590b2f82355a9db24e9bd8ab1b2
Set CONFIG_LEDS_CLASS_FLASH=y to enable the
flash LED sysfs class in /sys/class/leds
Bug: 163582665
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I19fa50c328ed0ddda7a11a0ab49f878544ac9b46
This reverts commit 4bba72b72c which is
commit 2a1658bf922ffd9b7907e270a7d9cdc9643fc45d upstream.
It breaks the abi of some Android drivers and can be safely reverted as
Android does not currently run on sparc64 systems :)
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5245629207bf163908a72aeea92495494b71e92c
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl8ynngACgkQONu9yGCS
aT5cPw/9GiiNZCLyjB3jVyalmN9uDYKQ+eS8H97GG7IBVYyg9whOKIrOCZHcLINH
DV5s/qnhRWJPzmQ47410ySuPb6QMvkhWTK7i5Xf+K7BOvoz/snfFGcmdu1CA4KxR
CuuH449Y4l3sH+5fPv7+EToovBqA2cfeiz/i5d5Di/N4yODWBCbHHAsZIt0oGvuK
sI1aI1K//R7vKZQvQo85tvENbWJWQwDN7eYVQj3aSbvnq8JqVpwTKTBpKfshzgzB
RmMSOVpQoQYNivW9oleG0NTQeHqj7alG8anFs3Drgu1hs5dzQhqAFlKddhtRS69j
mtrSJuf0GgJEYA6n+PfacoM4l7kHUZcQH9+bglbCXTA3nH24DLT7h0Lybm+ETPXc
ZAYo7cHqrS1BWv8VHZggSbqPr6YNKvgeflgS394wAgNEFcaJmaPfS6+elmc0qf2t
VPSas7QQruRS1Bqwb6CF2tHsl4N+VdvxX1a2JjHHcF5N3z5aqDm1qaVVQHxAg2rE
gXepFNGkEIBhWRxPz+5quxN1XBcUDiQYrzdoaKHxwY+OcdCf635P5Ob+1WK3w1oa
qhl/2scs44D67wZSgXHo5N4vMi9HhPOSV77jklgFcg75IzM9YWwYnJADQRHxo7nT
25XEgUlMfxm0ngw+CZWR0ssaP6rB9V1rRLDqb1W5HbqA7lp2YE8=
=Fe6H
-----END PGP SIGNATURE-----
Merge 5.4.58 into android11-5.4
Changes in 5.4.58
USB: serial: qcserial: add EM7305 QDL product ID
perf/core: Fix endless multiplex timer
USB: iowarrior: fix up report size handling for some devices
usb: xhci: define IDs for various ASMedia host controllers
usb: xhci: Fix ASMedia ASM1142 DMA addressing
io_uring: prevent re-read of sqe->opcode
io_uring: Fix use-after-free in io_sq_wq_submit_work()
Revert "ALSA: hda: call runtime_allow() for all hda controllers"
ALSA: hda/realtek: Add alc269/alc662 pin-tables for Loongson-3 laptops
ALSA: hda/ca0132 - Add new quirk ID for Recon3D.
ALSA: hda/ca0132 - Fix ZxR Headphone gain control get value.
ALSA: hda/ca0132 - Fix AE-5 microphone selection commands.
ALSA: seq: oss: Serialize ioctls
staging: android: ashmem: Fix lockdep warning for write operation
staging: rtl8712: handle firmware load failure
Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode
Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt()
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt()
omapfb: dss: Fix max fclk divider for omap36xx
binder: Prevent context manager from incrementing ref 0
Smack: fix use-after-free in smk_write_relabel_self()
scripts: add dummy report mode to add_namespace.cocci
vgacon: Fix for missing check in scrollback handling
mtd: properly check all write ioctls for permissions
leds: wm831x-status: fix use-after-free on unbind
leds: lm36274: fix use-after-free on unbind
leds: da903x: fix use-after-free on unbind
leds: lm3533: fix use-after-free on unbind
leds: 88pm860x: fix use-after-free on unbind
net/9p: validate fds in p9_fd_open
drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason
drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure
nvme-pci: prevent SK hynix PC400 from using Write Zeroes command
drm/drm_fb_helper: fix fbdev with sparc64
i2c: slave: improve sanity check when registering
i2c: slave: add sanity check when unregistering
usb: hso: check for return value in hso_serial_common_create()
net: ethernet: mtk_eth_soc: Always call mtk_gmac0_rgmii_adjust() for mt7623
ALSA: hda: fix NULL pointer dereference during suspend
firmware: Fix a reference count leak.
cfg80211: check vendor command doit pointer before use
igb: reinit_locked() should be called with rtnl_lock
atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent
tools lib traceevent: Fix memory leak in process_dynamic_array_len
Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)
xattr: break delegations in {set,remove}xattr
Revert "powerpc/kasan: Fix shadow pages allocation failure"
PCI: tegra: Revert tegra124 raw_violation_fixup
ipv4: Silence suspicious RCU usage warning
ipv6: fix memory leaks on IPV6_ADDRFORM path
ipv6: Fix nexthop refcnt leak when creating ipv6 route info
net: ethernet: mtk_eth_soc: fix MTU warnings
rxrpc: Fix race between recvmsg and sendmsg on immediate call failure
vxlan: Ensure FDB dump is performed under RCU
net: lan78xx: replace bogus endpoint lookup
appletalk: Fix atalk_proc_init() return path
dpaa2-eth: Fix passing zero to 'PTR_ERR' warning
hv_netvsc: do not use VF device if link is down
net: gre: recompute gre csum for sctp over gre tunnels
net: thunderx: use spin_lock_bh in nicvf_set_rx_mode_task()
openvswitch: Prevent kernel-infoleak in ovs_ct_put_key()
Revert "vxlan: fix tos value before xmit"
selftests/net: relax cpu affinity requirement in msg_zerocopy test
tcp: apply a floor of 1 for RTT samples from TCP timestamps
ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime
nfsd: Fix NFSv4 READ on RDMA when using readv
Linux 5.4.58
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0e89e2c0faf90bdf1f6ac37f9a2c2395cacab054
Because of the multi-inclusion oddities of tracepoints, the
multi-inclusion protection in vendor_hooks.h caused issues
if more than 1 vendor hook header file with restricted vendor
hooks defined were included with "CREATE_TRACE_POINTS"
defined (redefinition of symbol errors).
The problem is fixed by removing the multiple-inclusion
protection as is done for regular tracepoints.
Fixes: 5965ee663d ("ANDROID: add support for vendor hooks")
Bug: 163076069
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ic177db1693a6a2db58f08917e9115c7e6c2971b6
commit 412055398b9e67e07347a936fc4a6adddabe9cf4 upstream.
svcrdma expects that the payload falls precisely into the xdr_buf
page vector. This does not seem to be the case for
nfsd4_encode_readv().
This code is called only when fops->splice_read is missing or when
RQ_SPLICE_OK is clear, so it's not a noticeable problem in many
common cases.
Add new transport method: ->xpo_read_payload so that when a READ
payload does not fit exactly in rq_res's page vector, the XDR
encoder can inform the RPC transport exactly where that payload is,
without the payload's XDR pad.
That way, when a Write chunk is present, the transport knows what
byte range in the Reply message is supposed to be matched with the
chunk.
Note that the Linux NFS server implementation of NFS/RDMA can
currently handle only one Write chunk per RPC-over-RDMA message.
This simplifies the implementation of this fix.
Fixes: b042098063 ("nfsd4: allow exotic read compounds")
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198053
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Cc: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 311aa6aafea446c2f954cc19d66425bfed8c4b0b upstream.
The IMA_APPRAISE_BOOTPARAM config allows enabling different "ima_appraise="
modes - log, fix, enforce - at run time, but not when IMA architecture
specific policies are enabled. This prevents properly labeling the
filesystem on systems where secure boot is supported, but not enabled on the
platform. Only when secure boot is actually enabled should these IMA
appraise modes be disabled.
This patch removes the compile time dependency and makes it a runtime
decision, based on the secure boot state of that platform.
Test results as follows:
-> x86-64 with secure boot enabled
[ 0.015637] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
[ 0.015668] ima: Secure boot enabled: ignoring ima_appraise=fix boot parameter option
-> powerpc with secure boot disabled
[ 0.000000] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
[ 0.000000] Secure boot mode disabled
-> Running the system without secure boot and with both options set:
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_IMA_ARCH_POLICY=y
Audit prompts "missing-hash" but still allow execution and, consequently,
filesystem labeling:
type=INTEGRITY_DATA msg=audit(07/09/2020 12:30:27.778:1691) : pid=4976
uid=root auid=root ses=2
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data
cause=missing-hash comm=bash name=/usr/bin/evmctl dev="dm-0" ino=493150
res=no
Cc: stable@vger.kernel.org
Fixes: d958083a8f ("x86/ima: define arch_get_ima_policy() for x86")
Signed-off-by: Bruno Meneguele <bmeneg@redhat.com>
Cc: stable@vger.kernel.org # 5.0
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 730e700e2c19d87e578ff0e7d8cb1d4a02b036d2 ]
For retransmitted packets, TCP needs to resort to using TCP timestamps
for computing RTT samples. In the common case where the data and ACK
fall in the same 1-millisecond interval, TCP senders with millisecond-
granularity TCP timestamps compute a ca_rtt_us of 0. This ca_rtt_us
of 0 propagates to rs->rtt_us.
This value of 0 can cause performance problems for congestion control
modules. For example, in BBR, the zero min_rtt sample can bring the
min_rtt and BDP estimate down to 0, reduce snd_cwnd and result in a
low throughput. It would be hard to mitigate this with filtering in
the congestion control module, because the proper floor to apply would
depend on the method of RTT sampling (using timestamp options or
internally-saved transmission timestamps).
This fix applies a floor of 1 for the RTT sample delta from TCP
timestamps, so that seq_rtt_us, ca_rtt_us, and rs->rtt_us will be at
least 1 * (USEC_PER_SEC / TCP_TS_HZ).
Note that the receiver RTT computation in tcp_rcv_rtt_measure() and
min_rtt computation in tcp_update_rtt_min() both already apply a floor
of 1 timestamp tick, so this commit makes the code more consistent in
avoiding this edge case of a value of 0.
Signed-off-by: Jianfeng Wang <jfwang@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Kevin Yang <yyd@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 16f6458f2478b55e2b628797bc81a4455045c74e ]
The msg_zerocopy test pins the sender and receiver threads to separate
cores to reduce variance between runs.
But it hardcodes the cores and skips core 0, so it fails on machines
with the selected cores offline, or simply fewer cores.
The test mainly gives code coverage in automated runs. The throughput
of zerocopy ('-z') and non-zerocopy runs is logged for manual
inspection.
Continue even when sched_setaffinity fails. Just log to warn anyone
interpreting the data.
Fixes: 07b65c5b31 ("test: add msg_zerocopy test")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-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 a0dced17ad9dc08b1b25e0065b54c97a318e6e8b ]
This reverts commit 71130f29979c7c7956b040673e6b9d5643003176.
In commit 71130f29979c ("vxlan: fix tos value before xmit") we want to
make sure the tos value are filtered by RT_TOS() based on RFC1349.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+
But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
So with
IPTOS_TOS_MASK 0x1E
RT_TOS(tos) ((tos)&IPTOS_TOS_MASK)
the first 3 bits DSCP info will get lost.
To take all the DSCP info in xmit, we should revert the patch and just push
all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later.
Fixes: 71130f29979c ("vxlan: fix tos value before xmit")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 9aba6c5b49254d5bee927d81593ed4429e91d4ae ]
ovs_ct_put_key() is potentially copying uninitialized kernel stack memory
into socket buffers, since the compiler may leave a 3-byte hole at the end
of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix
it by initializing `orig` with memset().
Fixes: 9dd7f8907c ("openvswitch: Add original direction conntrack tuple to sw_flow_key.")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit bab9693a9a8c6dd19f670408ec1e78e12a320682 ]
A dead lock was triggered on thunderx driver:
CPU0 CPU1
---- ----
[01] lock(&(&nic->rx_mode_wq_lock)->rlock);
[11] lock(&(&mc->mca_lock)->rlock);
[12] lock(&(&nic->rx_mode_wq_lock)->rlock);
[02] <Interrupt> lock(&(&mc->mca_lock)->rlock);
The path for each is:
[01] worker_thread() -> process_one_work() -> nicvf_set_rx_mode_task()
[02] mld_ifc_timer_expire()
[11] ipv6_add_dev() -> ipv6_dev_mc_inc() -> igmp6_group_added() ->
[12] dev_mc_add() -> __dev_set_rx_mode() -> nicvf_set_rx_mode()
To fix it, it needs to disable bh on [1], so that the timer on [2]
wouldn't be triggered until rx_mode_wq_lock is released. So change
to use spin_lock_bh() instead of spin_lock().
Thanks to Paolo for helping with this.
v1->v2:
- post to netdev.
Reported-by: Rafael P. <rparrazo@redhat.com>
Tested-by: Dean Nelson <dnelson@redhat.com>
Fixes: 469998c861 ("net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 622e32b7d4a6492cf5c1f759ef833f817418f7b3 ]
The GRE tunnel can be used to transport traffic that does not rely on a
Internet checksum (e.g. SCTP). The issue can be triggered creating a GRE
or GRETAP tunnel and transmitting SCTP traffic ontop of it where CRC
offload has been disabled. In order to fix the issue we need to
recompute the GRE csum in gre_gso_segment() not relying on the inner
checksum.
The issue is still present when we have the CRC offload enabled.
In this case we need to disable the CRC offload if we require GRE
checksum since otherwise skb_checksum() will report a wrong value.
Fixes: 90017accff ("sctp: Add GSO support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 7c9864bbccc23e1812ac82966555d68c13ea4006 ]
If the accelerated networking SRIOV VF device has lost carrier
use the synthetic network device which is available as backup
path. This is a rare case since if VF link goes down, normally
the VMBus device will also loose external connectivity as well.
But if the communication is between two VM's on the same host
the VMBus device will still work.
Reported-by: "Shah, Ashish N" <ashish.n.shah@intel.com>
Fixes: 0c195567a8 ("netvsc: transparent VF management")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 02afa9c66bb954c6959877c70d9e128dcf0adce7 ]
Fix smatch warning:
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:2419
alloc_channel() warn: passing zero to 'ERR_PTR'
setup_dpcon() should return ERR_PTR(err) instead of zero in error
handling case.
Fixes: d7f5a9d89a ("dpaa2-eth: defer probe on object allocate")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit d0f6ba2ef2c1c95069509e71402e7d6d43452512 ]
Add a missing return statement to atalk_proc_init so it doesn't return
-ENOMEM when successful. This allows the appletalk module to load
properly.
Fixes: e2bcd8b0ce ("appletalk: use remove_proc_subtree to simplify procfs code")
Link: https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/
Reported-by: Christopher KOBAYASHI <chris@disavowed.jp>
Reported-by: Doug Brown <doug@downtowndougbrown.com>
Signed-off-by: Vincent Duvert <vincent.ldev@duvert.net>
[lukas: add missing tags]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v5.1+
Cc: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ea060b352654a8de1e070140d25fe1b7e4d50310 ]
Drop the bogus endpoint-lookup helper which could end up accepting
interfaces based on endpoints belonging to unrelated altsettings.
Note that the returned bulk pipes and interrupt endpoint descriptor
were never actually used. Instead the bulk-endpoint numbers are
hardcoded to 1 and 2 (matching the specification), while the interrupt-
endpoint descriptor was assumed to be the third descriptor created by
USB core.
Try to bring some order to this by dropping the bogus lookup helper and
adding the missing endpoint sanity checks while keeping the interrupt-
descriptor assumption for now.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b5141915b5aec3b29a63db869229e3741ebce258 ]
The commit cited below removed the RCU read-side critical section from
rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
without RCU protection.
This results in the following warning [1] in the VXLAN driver, which
relied on the callback being invoked from an RCU read-side critical
section.
Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
in the bridge driver.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
-----------------------------
drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by bridge/166:
#0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
stack backtrace:
CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
vxlan_fdb_dump+0x51e/0x6d0
rtnl_fdb_dump+0x4dc/0xad0
netlink_dump+0x540/0x1090
__netlink_dump_start+0x695/0x950
rtnetlink_rcv_msg+0x802/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
__sys_sendto+0x279/0x3b0
__x64_sys_sendto+0xe6/0x1a0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fe14fa2ade0
Code: Bad RIP value.
RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Fixes: 5e6d243587 ("bridge: netlink dump interface at par with brctl")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 65550098c1c4db528400c73acf3e46bfa78d9264 ]
There's a race between rxrpc_sendmsg setting up a call, but then failing to
send anything on it due to an error, and recvmsg() seeing the call
completion occur and trying to return the state to the user.
An assertion fails in rxrpc_recvmsg() because the call has already been
released from the socket and is about to be released again as recvmsg deals
with it. (The recvmsg_q queue on the socket holds a ref, so there's no
problem with use-after-free.)
We also have to be careful not to end up reporting an error twice, in such
a way that both returns indicate to userspace that the user ID supplied
with the call is no longer in use - which could cause the client to
malfunction if it recycles the user ID fast enough.
Fix this by the following means:
(1) When sendmsg() creates a call after the point that the call has been
successfully added to the socket, don't return any errors through
sendmsg(), but rather complete the call and let recvmsg() retrieve
them. Make sendmsg() return 0 at this point. Further calls to
sendmsg() for that call will fail with ESHUTDOWN.
Note that at this point, we haven't send any packets yet, so the
server doesn't yet know about the call.
(2) If sendmsg() returns an error when it was expected to create a new
call, it means that the user ID wasn't used.
(3) Mark the call disconnected before marking it completed to prevent an
oops in rxrpc_release_call().
(4) recvmsg() will then retrieve the error and set MSG_EOR to indicate
that the user ID is no longer known by the kernel.
An oops like the following is produced:
kernel BUG at net/rxrpc/recvmsg.c:605!
...
RIP: 0010:rxrpc_recvmsg+0x256/0x5ae
...
Call Trace:
? __init_waitqueue_head+0x2f/0x2f
____sys_recvmsg+0x8a/0x148
? import_iovec+0x69/0x9c
? copy_msghdr_from_user+0x5c/0x86
___sys_recvmsg+0x72/0xaa
? __fget_files+0x22/0x57
? __fget_light+0x46/0x51
? fdget+0x9/0x1b
do_recvmmsg+0x15e/0x232
? _raw_spin_unlock+0xa/0xb
? vtime_delta+0xf/0x25
__x64_sys_recvmmsg+0x2c/0x2f
do_syscall_64+0x4c/0x78
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 357f5ef646 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()")
Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 555a893303872e044fb86f0a5834ce78d41ad2e2 ]
in recent kernel versions there are warnings about incorrect MTU size
like these:
eth0: mtu greater than device maximum
mtk_soc_eth 1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead
Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Fixes: 72579e14a1d3 ("net: dsa: don't fail to probe if we couldn't set the MTU")
Fixes: 7a4c53bee3 ("net: report invalid mtu value via netlink extack")
Signed-off-by: Landen Chao <landen.chao@mediatek.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 706ec919164622ff5ce822065472d0f30a9e9dd2 ]
ip6_route_info_create() invokes nexthop_get(), which increases the
refcount of the "nh".
When ip6_route_info_create() returns, local variable "nh" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
ip6_route_info_create(). When nexthops can not be used with source
routing, the function forgets to decrease the refcnt increased by
nexthop_get(), causing a refcnt leak.
Fix this issue by pulling up the error source routing handling when
nexthops can not be used with source routing.
Fixes: f88d8ea67f ("ipv6: Plumb support for nexthop object in a fib6_info")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 8c0de6e96c9794cb523a516c465991a70245da1c ]
IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
to IPv4, particularly struct ipv6_ac_socklist. Similar to
struct ipv6_mc_socklist, we should just close it on this path.
This bug can be easily reproduced with the following C program:
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
int main()
{
int s, value;
struct sockaddr_in6 addr;
struct ipv6_mreq m6;
s = socket(AF_INET6, SOCK_DGRAM, 0);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(5000);
inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
connect(s, (struct sockaddr *)&addr, sizeof(addr));
inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
m6.ipv6mr_interface = 5;
setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
value = AF_INET;
setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
close(s);
return 0;
}
Reported-by: ch3332xr@gmail.com
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
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>
[ Upstream commit 83f3522860f702748143e022f1a546547314c715 ]
fib_trie_unmerge() is called with RTNL held, but not from an RCU
read-side critical section. This leads to the following warning [1] when
the FIB alias list in a leaf is traversed with
hlist_for_each_entry_rcu().
Since the function is always called with RTNL held and since
modification of the list is protected by RTNL, simply use
hlist_for_each_entry() and silence the warning.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
-----------------------------
net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/164:
#0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
stack backtrace:
CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
fib_trie_unmerge+0x608/0xdb0
fib_unmerge+0x44/0x360
fib4_rule_configure+0xc8/0xad0
fib_nl_newrule+0x37a/0x1dd0
rtnetlink_rcv_msg+0x4f7/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
____sys_sendmsg+0x879/0xa00
___sys_sendmsg+0x122/0x190
__sys_sendmsg+0x103/0x1d0
__x64_sys_sendmsg+0x7d/0xb0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc80a234e97
Code: Bad RIP value.
RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020
Fixes: 0ddcf43d5d ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7b856dfcec6d3bf028adee8c65342d7035914a1 upstream.
As reported in https://bugzilla.kernel.org/206217 , raw_violation_fixup
is causing more harm than good in some common use-cases.
This patch is a partial revert of commit:
191cd6fb5d ("PCI: tegra: Add SW fixup for RAW violations")
and fixes the following regression since then.
* Description:
When both the NIC and MMC are used one can see the following message:
NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
and
pcieport 0000:00:02.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0
r8169 0000:01:00.0: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
r8169 0000:01:00.0: AER: device [10ec:8168] error status/mask=00004000/00400000
r8169 0000:01:00.0: AER: [14] CmpltTO (First)
r8169 0000:01:00.0: AER: can't recover (no error_detected callback)
pcieport 0000:00:02.0: AER: device recovery failed
After that, the ethernet NIC is not functional anymore even after
reloading the r8169 module. After a reboot, this is reproducible by
copying a large file over the NIC to the MMC.
For some reason this is not reproducible when files are copied to a tmpfs.
* Little background on the fixup, by Manikanta Maddireddy:
"In the internal testing with dGPU on Tegra124, CmplTO is reported by
dGPU. This happened because FIFO queue in AFI(AXI to PCIe) module
get full by upstream posted writes. Back to back upstream writes
interleaved with infrequent reads, triggers RAW violation and CmpltTO.
This is fixed by reducing the posted write credits and by changing
updateFC timer frequency. These settings are fixed after stress test.
In the current case, RTL NIC is also reporting CmplTO. These settings
seems to be aggravating the issue instead of fixing it."
Link: https://lore.kernel.org/r/20200718100710.15398-1-kwizart@gmail.com
Fixes: 191cd6fb5d ("PCI: tegra: Add SW fixup for RAW violations")
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b506923ee44ae87fc9f4de16b53feb313623e146 upstream.
This reverts commit d2a91cef9bbdeb87b7449fdab1a6be6000930210.
This commit moved too much work in kasan_init(). The allocation
of shadow pages has to be moved for the reason explained in that
patch, but the allocation of page tables still need to be done
before switching to the final hash table.
First revert the incorrect commit, following patch redoes it
properly.
Fixes: d2a91cef9bbd ("powerpc/kasan: Fix shadow pages allocation failure")
Cc: stable@vger.kernel.org
Reported-by: Erhard F. <erhard_f@mailbox.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=208181
Link: https://lore.kernel.org/r/3667deb0911affbf999b99f87c31c77d5e870cd2.1593690707.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 08b5d5014a27e717826999ad20e394a8811aae92 upstream.
set/removexattr on an exported filesystem should break NFS delegations.
This is true in general, but also for the upcoming support for
RFC 8726 (NFSv4 extended attribute support). Make sure that they do.
Additionally, they need to grow a _locked variant, since callers might
call this with i_rwsem held (like the NFS server code).
Cc: stable@vger.kernel.org # v4.9+
Cc: linux-fsdevel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ddc9d357b991838c2d975e8d7e4e9db26f37a7ff ]
When a Linux hv_sock app tries to connect to a Service GUID on which no
host app is listening, a recent host (RS3+) sends a
CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such
a warning:
unknown msgtype=23
WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc
Actually Linux can safely ignore the message because the Linux app's
connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT
and vsock_stream_connect(). We don't bother to make use of the message
because: 1) it's only supported on recent hosts; 2) a non-trivial effort
is required to use the message in Linux, but the benefit is small.
So, let's not see the warning by silently ignoring the message.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]
I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:
Direct leak of 28 byte(s) in 4 object(s) allocated from:
#0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.
Free the token variable before calling read_token in order to plug the
leak.
Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 51875dad43b44241b46a569493f1e4bfa0386d86 ]
atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
reference of atm_dev with increased refcount or NULL if fails.
The refcount leaks issues occur in two error handling paths. If
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
returns 0 without decreasing the refcount kept by a local variable,
resulting in refcount leaks.
Fix the issue by adding atm_dev_put() before returning 0 both when
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 024a8168b749db7a4aa40a5fbdfa04bf7e77c1c0 ]
We observed two panics involving races with igb_reset_task.
The first panic is caused by this race condition:
kworker reboot -f
igb_reset_task
igb_reinit_locked
igb_down
napi_synchronize
__igb_shutdown
igb_clear_interrupt_scheme
igb_free_q_vectors
igb_free_q_vector
adapter->q_vector[v_idx] = NULL;
napi_disable
Panics trying to access
adapter->q_vector[v_idx].napi_state
The second panic (a divide error) is caused by this race:
kworker reboot -f tx packet
igb_reset_task
__igb_shutdown
rtnl_lock()
...
igb_clear_interrupt_scheme
igb_free_q_vectors
adapter->num_tx_queues = 0
...
rtnl_unlock()
rtnl_lock()
igb_reinit_locked
igb_down
igb_up
netif_tx_start_all_queues
dev_hard_start_xmit
igb_xmit_frame
igb_tx_queue_mapping
Panics on
r_idx % adapter->num_tx_queues
This commit applies to igb_reset_task the same changes that
were applied to ixgbe in commit 2f90b8657e ("ixgbe: this patch
adds support for DCB to the kernel and ixgbe driver"),
commit 8f4c5c9fb8 ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit 88adce4ea8 ("ixgbe: fix possible race in
reset subtask").
Signed-off-by: Francesco Ruggeri <fruggeri@arista.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>
