The only common change is the regression fix of the previous PCM fix
patch for managed buffers while the rest are usual suspects, USB-audio
and HD-audio device-specific quirks. The change for UAC2 clock
validation workaround became a bit big, but the changes are fairly
straightforward.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl5Fa7IOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8UIg//RFoYt1aOERWOBmXUVAh2o+ysGYPWxyfPHt/1
eTEI1yXwZUD8jYhbIsynw0cdNvP1fTaRrv01lWQuhUbuUl02dDUYtKay6aP4yOmA
YYz8xC6YIJEvVn0YLzOvx7J8Z1BPjL4eLpgxRRMhkJxLBsWpn41m7pyLfz3BqTL8
4ZmoVPyk0rZKmhd20RLMoSlDcZ/hdqKyOLKmE/h418ko0O5am/RttyrD4cTqL/vX
j3fj9JVxrRX77wcePLoIVvYWqoadVQKFnoMBR+KKbnokt0Q6fU7FynWSH/WqQkyZ
ljxkjXNqWHXIG99eBw/OLX0oXEry8A1Keo3a0Um7ivHKucenNiJ40YUbfIP5ID95
B3PYrdyTj0u/KhlsD/Nqco8qKSSuQQz5XiM0yGvhJLSAhEdqumL0lVzHxTnEecsq
dC0xcoWd5+0yjwrsJQBuUlwexlY7uaWrKkpfBURzWGeArr40PMPBwbJuCKXY/l7N
uJbj1cgOiVN7P+t41UzuHA+RccxVVGvf1TGUqsqZoBMi/9yuZ4WVP2npOgtGBhMS
zK8ETs5F1uWp4pIW5I/Cs5pEXNwUOBwBHidtFOGL3WwSDPAotmc0IMJjclbHilN9
dQ+dKVuvKnhEt/B9xsfayHGJUUbSvffpoz9jm9enjlTIQ2sZ5FPqvytaFw2uOeYt
BjqgVY4=
=p3mr
-----END PGP SIGNATURE-----
Merge tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"The only common change is the regression fix of the previous PCM fix
patch for managed buffers while the rest are usual suspects, USB-audio
and HD-audio device-specific quirks.
The change for UAC2 clock validation workaround became a bit big, but
the changes are fairly straightforward"
* tag 'sound-5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: pcm: Fix double hw_free calls
ALSA: usb-audio: Add clock validity quirk for Denon MC7000/MCX8000
ALSA: hda/realtek - Fix silent output on MSI-GL73
ALSA: hda/realtek - Add more codec supported Headset Button
ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
ALSA: usb-audio: Fix UAC2/3 effect unit parsing
ALSA: usb-audio: Apply 48kHz fixed rate playback for Jabra Evolve 65 headset
core:
- edid build fix
mst:
- fix NULL ptr deref
vgem:
- fix close after free
msm:
- better dma-api usage
sun4i:
- disable allow_fb_modifiers
amdgpu:
- Additional OD fixes for navi
- Misc display fixes
- VCN 2.5 DPG fix
- Prevent build errors on PowerPC on some configs
- GDS EDC fix
i915:
- dsi/acpi fixes
- gvt locking and allocation fixes
- gem/gt fixes
- bios timing parameters fix
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJeRhwcAAoJEAx081l5xIa+hBoQAJtayqMkZfhrUQDkygYEieCl
Nj+ffqq7Fm6s3UveARBH1fhyXIEriZSTOqW8ibNnnTj+O/Bs3Cj1NgfuWNXm41El
6FgExtKK+dXCkqX3j5OrVB7BEkrxvkZZiR34OyFEiNDLYpHWYzGk5wL009mDnvNr
l7q5DiDS7ecFCMGRxOuC32SAlS/Flky6vl5hlVShPXLN1czRBUYW+PIN17cr3dHf
Vl08suX5ZUpYU+9qy8Fl/TyOMlHSjKSNgvWCUr5YbOag0OhbMr/Zs+DB4pJlPk1h
rNtjXQDdEstDfn9gDoFPH7+eVYRviflIBu9Ccng3RnXf7RVao+8soX5aQurPRANI
nPzqz1LWxT6W+RnjrnaK1qSOIyFacjY6rAfjuhesNpZGLQVFo6UprQc2fGFSCtkQ
qOSJTSqEczwpJpz5nwgsx1rPwHBYMm3Gbox2mLfXsaszJoAX8tjIoiYZbtSReVIF
eCOlM2QMyMFRY0FDhA1L1cSQZBkshwZvFpEsTS36xBAr6iofrk3m2MDgwX+/qbX9
DWgIoTcmgaJjoM5oEyYhPUFfBw3VZtZ2W8p2El05H4zOmLHs7vIaSZSKtNPqUbcq
ovW63I1zEX+Yt9mckdXYt6zfruw/nPA9dGbkyW/3tjJrlIT4FiurUuTYcXRWUy9l
M7gDwWdGHjam1lSiyjCr
=PGEU
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"The core has a build fix for edid code on certain compilers/arches/,
one MST fix and one vgem fix. Regular amdgpu fixes, and a couple of
small driver fixes.
The i915 fixes are bit larger than normal for this stage, but they
were having CI issues last week, and they hadn't sent any fixes last
week due to this.
core:
- edid build fix
mst:
- fix NULL ptr deref
vgem:
- fix close after free
msm:
- better dma-api usage
sun4i:
- disable allow_fb_modifiers
amdgpu:
- Additional OD fixes for navi
- Misc display fixes
- VCN 2.5 DPG fix
- Prevent build errors on PowerPC on some configs
- GDS EDC fix
i915:
- dsi/acpi fixes
- gvt locking and allocation fixes
- gem/gt fixes
- bios timing parameters fix"
* tag 'drm-fixes-2020-02-14' of git://anongit.freedesktop.org/drm/drm: (50 commits)
drm/i915: Mark the removal of the i915_request from the sched.link
drm/i915/execlists: Reclaim the hanging virtual request
drm/i915/execlists: Take a reference while capturing the guilty request
drm/i915/execlists: Offline error capture
drm/i915/gt: Allow temporary suspension of inflight requests
drm/i915: Keep track of request among the scheduling lists
drm/i915/gem: Tighten checks and acquiring the mmap object
drm/i915: Fix preallocated barrier list append
drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release
drm/i915: Stub out i915_gpu_coredump_put
drm/amdgpu:/navi10: use the ODCAP enum to index the caps array
drm/amdgpu: update smu_v11_0_pptable.h
drm/amdgpu: correct comment to clear up the confusion
drm/amd/display: DCN2.x Do not program DPPCLK if same value
drm/amd/display: Don't map ATOM_ENABLE to ATOM_INIT
drm/amdgpu/vcn2.5: fix warning
drm/amdgpu: limit GDS clearing workaround in cold boot sequence
drm/amdgpu: fix amdgpu pmu to use hwc->config instead of hwc->conf
amdgpu: Prevent build errors regarding soft/hard-float FP ABI tags
...
Otherwise we readback all ones. Fixes rlc counter
readback while gfxoff is active.
Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Otherwise we readback all ones. Fixes rlc counter
readback while gfxoff is active.
Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
It's 25 Mhz (refclk / 4). This fixes the interpretation
of the rlc clock counter.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Otherwise, the cached dpm features status may be inconsistent under some
case(e.g. baco reset of Navi asic).
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
there was a type in the terminate command.
We should be calling psp_dtm_unload() instead of psp_hdcp_unload()
Fixes: 143f230533 ("drm/amdgpu: psp DTM init")
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We were using incorrect byte order after we started using the drm_defines
So fix it.
Fixes: 02837a91ae ("drm/amd/display: add and use defines from drm_hdcp.h")
Signed-off-by: JinZe.Xu <JinZe.Xu@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
nvme fw-activate operation will get bellow warning log,
fix it by update the parameter order
[ 113.231513] nvme nvme0: Get FW SLOT INFO log error
Fixes: 0e98719b0e ("nvme: simplify the API for getting log pages")
Reported-by: Sujith Pandel <sujith_pandel@dell.com>
Reviewed-by: David Milburn <dmilburn@redhat.com>
Signed-off-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Many users have reported nvme triggered irq_startup() warnings during
shutdown. The driver uses the nvme queue's irq to synchronize scanning
for completions, and enabling an interrupt affined to only offline CPUs
triggers the alarming warning.
Move the final CQE check to after disabling the device and all
registered interrupts have been torn down so that we do not have any
IRQ to synchronize.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206509
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Delayed keep alive work is queued on system workqueue and may be cancelled
via nvme_stop_keep_alive from nvme_reset_wq, nvme_fc_wq or nvme_wq.
Check_flush_dependency detects mismatched attributes between the work-queue
context used to cancel the keep alive work and system-wq. Specifically
system-wq does not have the WQ_MEM_RECLAIM flag, whereas the contexts used
to cancel keep alive work have WQ_MEM_RECLAIM flag.
Example warning:
workqueue: WQ_MEM_RECLAIM nvme-reset-wq:nvme_fc_reset_ctrl_work [nvme_fc]
is flushing !WQ_MEM_RECLAIM events:nvme_keep_alive_work [nvme_core]
To avoid the flags mismatch, delayed keep alive work is queued on nvme_wq.
However this creates a secondary concern where work and a request to cancel
that work may be in the same work queue - namely err_work in the rdma and
tcp transports, which will want to flush/cancel the keep alive work which
will now be on nvme_wq.
After reviewing the transports, it looks like err_work can be moved to
nvme_reset_wq. In fact that aligns them better with transition into
RESETTING and performing related reset work in nvme_reset_wq.
Change nvme-rdma and nvme-tcp to perform err_work in nvme_reset_wq.
Signed-off-by: Nigel Kirkland <nigel.kirkland@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
When nvme_tcp_io_work() fails to send to socket due to
connection close/reset, error_recovery work is triggered
from nvme_tcp_state_change() socket callback.
This cancels all the active requests in the tagset,
which requeues them.
The failed request, however, was ended and thus requeued
individually as well unless send returned -EPIPE.
Another return code to be treated the same way is -ECONNRESET.
Double requeue caused BUG_ON(blk_queued_rq(rq))
in blk_mq_requeue_request() from either the individual requeue
of the failed request or the bulk requeue from
blk_mq_tagset_busy_iter(, nvme_cancel_request, );
Signed-off-by: Anton Eidelman <anton@lightbitslabs.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
RHBZ: 1752437
Before we add a new EA we should check that this will not overflow
the maximum buffer we have available to read the EAs back.
Otherwise we can get into a situation where the EAs are so big that
we can not read them back to the client and thus we can not list EAs
anymore or delete them.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Stable <stable@vger.kernel.org>
It was originally enabled only for SMB3 or later dialects, but
had requests to add it to SMB2.1 mounts as well given the
large number of systems at that dialect level.
Signed-off-by: Steve French <stfrench@microsoft.com>
Reported-by: L Walsh <cifs@tlinx.org>
Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
Eliminate all kernel-doc and Sphinx warnings in
<linux/netdevice.h>. Fixes these warnings:
../include/linux/netdevice.h:2100: warning: Function parameter or member 'gso_partial_features' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'l3mdev_ops' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'xfrmdev_ops' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'tlsdev_ops' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'name_assign_type' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'ieee802154_ptr' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'mpls_ptr' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'xdp_prog' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'gro_flush_timeout' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'xdp_bulkq' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'xps_cpus_map' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'xps_rxqs_map' not described in 'net_device'
../include/linux/netdevice.h:2100: warning: Function parameter or member 'qdisc_hash' not described in 'net_device'
../include/linux/netdevice.h:3552: WARNING: Inline emphasis start-string without end-string.
../include/linux/netdevice.h:3552: WARNING: Inline emphasis start-string without end-string.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Per Forlin says:
====================
net: dsa: Make sure there is headroom for tag
Sorry for re-posting yet another time....
I manage to include multiple email-senders and forgot to include cover-letter.
Let's hope everyhthing is in order this time.
Fix two tag drivers to make sure there is headroom for the tag data.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Passing tag size to skb_cow_head will make sure
there is enough headroom for the tag data.
This change does not introduce any overhead in case there
is already available headroom for tag.
Signed-off-by: Per Forlin <perfn@axis.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Passing tag size to skb_cow_head will make sure
there is enough headroom for the tag data.
This change does not introduce any overhead in case there
is already available headroom for tag.
Signed-off-by: Per Forlin <perfn@axis.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With ipip, it is possible to create an extra interface explicitly
attached to a given physical interface:
# ip link show tunl0
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
# ip link add tunl1 type ipip dev eth0
# ip link show tunl1
6: tunl1@eth0: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
But it is not possible with ip6tnl:
# ip link show ip6tnl0
5: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/tunnel6 :: brd ::
# ip link add ip6tnl1 type ip6tnl dev eth0
RTNETLINK answers: File exists
This patch aims to make it possible by adding link comparaison in both
tunnel locate and lookup functions; we also modify mtu calculation when
attached to an interface with a lower mtu.
This permits to make use of x-netns communication by moving the newly
created tunnel in a given netns.
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* avoid running out of tracking space for frames that need
to be reported to userspace by using more bits
* fix beacon handling suppression by adding some relevant
elements to the CRC calculation
* fix quiet mode in action frames
* fix crash in ethtool for virt_wifi and similar
* add a missing policy entry
* fix 160 & 80+80 bandwidth to take local capabilities into
account
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAl5GZQ8ACgkQB8qZga/f
l8TQYQ//fcrDPndtwJWE5IaXJq7OmnM2NsYED6r1gVK7CWeVhqfwES6x9LVbhW/B
QPwqFfL3i2II8XFVG/+BCUcEhp5FZQKGEDXaYcWXqQCuc6mU7ZKBuaEJmznMoez1
6b96vdkVa78QnNK0QjSjAMua9KaBCIS2bPP/0E5o/8T9YsRKhuC4ItpLHYAGLsfM
1QzU8ZBr/Ug4XIx28lDYOs8MHF5jm8dUgSpB4WgSQUKGTmgvyO/SefGtaJQ36R9B
tAVR3Mmstm00ufsXT3OhiqXgN6bjUENvM+osVjD6E1eqjtPlrUYTCO8b/ZC1wean
4G077eE186uao+9xQ8cLk7sL6ZJnlRwJ15RdBB5bsLZ8nG2FpclKCMxpcxc4PL/M
oIXjEU8uNhSAVDmI3c2k/sxRW0hdQoblgl8PQMZ3k/6nvpwnIrG8yoeAwP4B457Y
vgiRE212YkOaXhtwrg1EuOIhk1N3YRG8DpSdDrKlj+y0LOijTrHCnqoUwnne+RpX
2Zqm5Sz3R2Nel9iIVs1JOxIGvyg+KIoM+WjmmrjMSqlrvMMisq8O3BuMfgd6jd+t
NuZE9MkukBPMiaB4QDMDgBcaTMrLRItD+SSSQcMvkORTfGrpjUhpiQTVwOPXCYqZ
793BU8kI+gwrz9UfloYxSv2+2H12a6LDQY6Q/mJVKAuhdw6SXsE=
=L+Ik
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-net-2020-02-14' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Just a few fixes:
* avoid running out of tracking space for frames that need
to be reported to userspace by using more bits
* fix beacon handling suppression by adding some relevant
elements to the CRC calculation
* fix quiet mode in action frames
* fix crash in ethtool for virt_wifi and similar
* add a missing policy entry
* fix 160 & 80+80 bandwidth to take local capabilities into
account
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Karsten Graul says:
====================
net/smc: fixes for -net
Fix a syzbot finding and a problem with the CLC handshake content.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Just SMCR requires a CLC Peer ID, but not SMCD. The field should be
zero for SMCD.
Fixes: c758dfddc1 ("net/smc: add SMC-D support in CLC messages")
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SMC does not work together with FASTOPEN. If sendmsg() is called with
flag MSG_FASTOPEN in SMC_INIT state, the SMC-socket switches to
fallback mode. To handle the previous ioctl FIOASYNC call correctly
in this case, it is necessary to transfer the socket wait queue
fasync_list to the internal TCP socket.
Reported-by: syzbot+4b1fe8105f8044a26162@syzkaller.appspotmail.com
Fixes: ee9dfbef02 ("net/smc: handle sockopts forcing fallback")
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Huazhong Tan says:
====================
net: hns3: fixes for -net
This series includes three bugfixes for the HNS3 ethernet driver.
[patch 1] fixes a management table lost issue after IMP reset.
[patch 2] fixes a VF bandwidth configuration not work problem.
[patch 3] fixes a problem related to IPv6 address copying.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The IPv6 address defined in struct in6_addr is specified as
big endian, but there is no specified endian in struct
hclge_fd_rule_tuples, so it will cause a problem if directly
use memcpy() to copy ipv6 address between these two structures
since this field in struct hclge_fd_rule_tuples is little endian.
This patch fixes this problem by using be32_to_cpu() to convert
endian of IPv6 address of struct in6_addr before copying.
Fixes: d93ed94fbe ("net: hns3: add aRFS support for PF")
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When enabling 4 TC after setting the bandwidth of VF, the bandwidth
of VF will resume to default value, because of the qset resources
changed in this case.
This patch fixes it by using a fixed VF's qset resources according to
HNAE3_MAX_TC macro.
Fixes: ee9e44248f ("net: hns3: add support for configuring bandwidth of VF on the host")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the current process, the management table is missing after the
IMP reset. This patch adds the management table to the reset process.
Fixes: f5aac71c03 ("net: hns3: add manager table initialization for hardware")
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before this patch:
# ./perf test 39 41
39: LLVM search and compile :
39.1: Basic BPF llvm compile : Ok
39.2: kbuild searching : FAILED!
39.3: Compile source for BPF prologue generation : Skip
39.4: Compile source for BPF relocation : Skip
41: BPF filter :
41.1: Basic BPF filtering : Ok
41.2: BPF pinning : Ok
41.3: BPF prologue generation : FAILED!
41.4: BPF relocation checker : Skip
#
Using 'perf test -v' for these tests shows that it is not finding
uapi/linux/fs.h, which ends up being because we don't setup the right header
path. Fix it.
After this patch:
# perf test 39 41
39: LLVM search and compile :
39.1: Basic BPF llvm compile : Ok
39.2: kbuild searching : Ok
39.3: Compile source for BPF prologue generation : Ok
39.4: Compile source for BPF relocation : Ok
41: BPF filter :
41.1: Basic BPF filtering : Ok
41.2: BPF pinning : Ok
41.3: BPF prologue generation : Ok
41.4: BPF relocation checker : Ok
#
Longer description:
In llvm-utils.c we use some techniques to obtain the kbuild make
directives and that recently stopped working as now 'ar' gets called and
expects to find the dummy.o used to echo these variables:
$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)
Add the $(CC) line to satisfy that, making sure this works with all
kernels, i.e. preserving the temp directory and files in it used for
this technique we can see that it works everywhere:
# make -s -C /lib/modules/5.4.18-100.fc30.x86_64/build M=/tmp/tmp.qgaFHgxjZ4/ clean
# ls -la /tmp/tmp.qgaFHgxjZ4/
total 4
drwx------. 2 root root 80 Feb 14 09:42 .
drwxrwxrwt. 47 root root 1200 Feb 14 09:42 ..
-rw-r--r--. 1 root root 0 Feb 13 17:14 dummy.c
-rw-r--r--. 1 root root 121 Feb 13 17:14 Makefile
#
# cat /tmp/tmp.qgaFHgxjZ4/Makefile
obj-y := dummy.o
$(obj)/%.o: $(src)/%.c
@echo -n "$(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS)"
$(CC) -c -o $@ $<
#
Then build with an old kernel Makefile:
# make -s -C /lib/modules/5.4.18-100.fc30.x86_64/build M=/tmp/tmp.qgaFHgxjZ4/ dummy.o
-nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/9/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h
#
# ls -la /tmp/tmp.qgaFHgxjZ4/
total 8
drwx------. 2 root root 100 Feb 14 09:43 .
drwxrwxrwt. 47 root root 1200 Feb 14 09:43 ..
-rw-r--r--. 1 root root 0 Feb 13 17:14 dummy.c
-rw-r--r--. 1 root root 936 Feb 14 09:43 dummy.o
-rw-r--r--. 1 root root 121 Feb 13 17:14 Makefile
#
And a new one:
# make -s -C /lib/modules/5.4.18-100.fc30.x86_64/build M=/tmp/tmp.qgaFHgxjZ4/ clean
# ls -la /tmp/tmp.qgaFHgxjZ4/
total 4
drwx------. 2 root root 80 Feb 14 09:43 .
drwxrwxrwt. 47 root root 1200 Feb 14 09:43 ..
-rw-r--r--. 1 root root 0 Feb 13 17:14 dummy.c
-rw-r--r--. 1 root root 121 Feb 13 17:14 Makefile
# make -s -C /lib/modules/5.6.0-rc1+/build M=/tmp/tmp.qgaFHgxjZ4/ dummy.o
-nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/9/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
#
# ls -la /tmp/tmp.qgaFHgxjZ4/
total 16
drwx------. 2 root root 160 Feb 14 09:44 .
drwxrwxrwt. 47 root root 1200 Feb 14 09:44 ..
-rw-r--r--. 1 root root 158 Feb 14 09:44 built-in.a
-rw-r--r--. 1 root root 149 Feb 14 09:44 .built-in.a.cmd
-rw-r--r--. 1 root root 0 Feb 13 17:14 dummy.c
-rw-r--r--. 1 root root 936 Feb 14 09:44 dummy.o
-rw-r--r--. 1 root root 121 Feb 13 17:14 Makefile
-rw-r--r--. 1 root root 0 Feb 14 09:44 modules.order
#
Reported-by: Thomas Richter <tmricht@linux.ibm.com>
Tested-by: Thomas Richter <tmricht@linux.ibm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Zefan Li <lizefan@huawei.com>
Link: https://www.spinics.net/lists/linux-perf-users/msg10600.html
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Before this patch, STA's would set new width of 160/80+80 MHz based on AP capability only.
This is wrong because STA may not support > 80MHz BW.
Fix is to verify STA has 160/80+80 MHz capability before increasing its width to > 80MHz.
The "support_80_80" and "support_160" setting is based on:
"Table 9-272 — Setting of the Supported Channel Width Set subfield and Extended NSS BW
Support subfield at a STA transmitting the VHT Capabilities Information field"
From "Draft P802.11REVmd_D3.0.pdf"
Signed-off-by: Aviad Brikman <aviad.brikman@celeno.com>
Signed-off-by: Shay Bar <shay.bar@celeno.com>
Link: https://lore.kernel.org/r/20200210130728.23674-1-shay.bar@celeno.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The nl80211_policy is missing for NL80211_ATTR_STATUS_CODE attribute.
As a result, for strictly validated commands, it's assumed to not be
supported.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Link: https://lore.kernel.org/r/20200213131608.10541-2-sergey.matyukevich.os@quantenna.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFWWmW3ewYy4RJOWc05gHnSar7m8FAl5FGuMACgkQ05gHnSar
7m8vRxAAobELoLLkdf44Cf4f8hgIxLRYiWxSVavh6ucFXBlGEWpGVwf2t8fM6ZBB
yBNJWcxun6F8wy8aHZxjAHSK/LDL5sKUyMdU+GCUthkgtJxM/SYTJLvFL1y+Eacr
PuQ50IXQFHRRQI1Cp6kVo9Y91/oU2LuWzrX82ZOIcxglO35A8vm3iT4Ggno3cDli
1vAl1VIbXQX2GKhm1y4dGK2/lzbeN4byqJNpGQIq+1PDBEVgNsOPXRMhNLBFqIhA
yVn/t1Z780KSTh8Oa24xkLSFKj4y0Yj7TDdkmIsaxPADqxy6Ptiuysf+scuPEpOS
epRG3R3Dtajb+ZHzV2A5TmVAlgEvSDBKWKDA9wBzMIEKS8m5eW1UoDuJ4JhRy/IR
ZNVcPNRAX61owmjEhlncQh9Mx8cUF3ku1Oup17/cm5o9Tcphubl6ilGmC5JAO3zj
rX6NUyxbp4h9Gv6kY1eQfXtAe8Vo+vwejStew4ajo/r2PdAlRWzDUXyn6K7kXRb2
3btgaVKulLAQQayP5FPp3LXvyaU4/Zg6QYKaV+5sXDDy/onvwoK4m1z9dxxC511a
0DnpZOIIX0eVL5p7/FcIkfMan5wKK2QiWYfKe2jVC/9TooxK2g4brp+ImCXZlt8t
kT/M1sYKkblUy4KN+f/asKLM85jzRjw5lH7LPiCwChj8KVWS7BQ=
=BZol
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-fixes-2020-02-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for v5.6-rc2
Most of these were aimed at a "next fixes" pull already during the merge
window, but there were issues with the baseline I used, which resulted
in a lot of issues in CI. I've regenerated this stuff piecemeal now,
adding gradually to it, and it seems healthy now.
Due to the issues this is much bigger than I'd like. But it was
obviously necessary to take the time to ensure it's not garbage...
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/878sl6yfrn.fsf@intel.com
- Revert allow_fb_modifiers in sun4i, as it causes a regression for DE2 and DE3.
- Fix null pointer deref in drm_dp_mst_process_up_req().
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl49Kh8ACgkQ/lWMcqZw
E8P6rhAAsNKEdG7iZTnqrZzqMLkNdaYdwnAMSIycCSc26UW1xbNAURBWOlxFIyPA
Jz2eJorXdAZfSzmRIDWV2TetpRGQB7MH+9o4cgG/oTbElOOppKb6S4r86JqYLJrO
A0NM5juJG/+K5J0uO72ya8HiLqmCaWHl8NMXLe//fhvFYPHO+lFAYzLJ+7tTwDij
0jNMIH/svVw/HI82jKNeAK/BzIz/POJCjOD5kPEAC9E81KVU8MUlpVEIM3cXaq0w
wXeTf+uoI83GMik4ZoyAUiUNe3L1vSqoZWKIZESjOGIIvZwHyUgcdmRJwFktu5Qq
ARqxZhZm4pB/RzN+YEwuSrtS/+gwJzROZFp8HaTIajghed9FT8CI3mnuPS26nnmB
s+GKg12o/Sgr1uZWyk6ckl42hUqAFgk/H+RFLmW60nC/GtLlZkd1JVIfoA0RjarR
Ms9RAKL75p4TySncM2vlcZ9GUWHkphEqv9mpm8LLYzAj4yydX6rvGd/QkE+VINyv
cquhjYrwQU6bojt9kM6Tce1KchYLCt7DTHiXAztnYF8IJG3Ys4Z+xEkp2tM2fE0H
m++A0GE8eLN5/O00j6relDWagcDTJzt5qjDFIYIiRC2y5EmMdbu1wvOW7sW0LF4l
1bEuSaZDKfpnlJ3IfqmaWQz7i1553zFmahdfblBIX3hoVqGC6tY=
=VCDX
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2020-02-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Fixes for v5.6:
- Revert allow_fb_modifiers in sun4i, as it causes a regression for DE2 and DE3.
- Fix null pointer deref in drm_dp_mst_process_up_req().
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/672810c3-4212-0a46-337b-2cb855573fd2@linux.intel.com
The Yoga 11e is using LEN0049, but it doesn't have a trackstick.
Thus, there is no need to create a software top buttons row.
However, it seems that the device works under SMBus, so keep it as part
of the smbus_pnp_ids.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200115013023.9710-1-benjamin.tissoires@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200213002600.GA31916@embeddedor.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200213002430.GA31056@embeddedor.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Carter reported an issue where he could produce a stall on ring exit,
when we're cleaning up requests that match the given file table. For
this particular test case, a combination of a few things caused the
issue:
- The cq ring was overflown
- The request being canceled was in the overflow list
The combination of the above means that the cq overflow list holds a
reference to the request. The request is canceled correctly, but since
the overflow list holds a reference to it, the final put won't happen.
Since the final put doesn't happen, the request remains in the inflight.
Hence we never finish the cancelation flush.
Fix this by removing requests from the overflow list if we're canceling
them.
Cc: stable@vger.kernel.org # 5.5
Reported-by: Carter Li 李通洲 <carter.li@eoitek.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Fix build when KASLR is enabled but CONFIG_ARCH_RANDOM is not set
- Fix context-switching of SSBS state on systems that implement it
- Fix spinlock compiler warning introduced during the merge window
- Fix incorrect header inclusion (linux/clk-provider.h)
- Use SYSCTL_{ZERO,ONE} instead of rolling our own static variables
- Don't scream if optional SMMUv3 PMU irq is missing
- Remove some unused function prototypes
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAl5FWgUQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNHN3CACHwCJyfwTCo3A8+rKpMK29FE8CciheqPbz
hsPuS7UIYYv8yXLeOGD9d2Jplg2gqx/kWVLh4rm6KvPbaMvSJW++HPbiMy1dMWrw
xUPofQjvXajv2iOzXLonVRXF+gtLbHIYLpsUIpkg1IFZNnjRPzUW0wAqyMBwHhB7
WKoWRs+6wyGbfC1e9ZDZ5nmiyixoH3j5AZs6LN1hdkxGudc6M7FxutSgarcncxNH
k5QGKo7cdAaNduIpHUE6VCDxu+5FwHADPvY7x/aq5tyJ5vxn0CnoXL9WCofMfZ3t
X0U3VIwtGTgOrbTe29WYpy/SQtau63Yq/n96Tw7fXLvDmNSZQ/RT
=mOtY
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Summary below, but it's all reasonably straightforward. There are some
more fixes on the horizon, but nothing disastrous yet.
Summary:
- Fix build when KASLR is enabled but CONFIG_ARCH_RANDOM is not set
- Fix context-switching of SSBS state on systems that implement it
- Fix spinlock compiler warning introduced during the merge window
- Fix incorrect header inclusion (linux/clk-provider.h)
- Use SYSCTL_{ZERO,ONE} instead of rolling our own static variables
- Don't scream if optional SMMUv3 PMU irq is missing
- Remove some unused function prototypes"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: time: Replace <linux/clk-provider.h> by <linux/of_clk.h>
arm64: Fix CONFIG_ARCH_RANDOM=n build
perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
arm64/spinlock: fix a -Wunused-function warning
arm64: ssbs: Fix context-switch when SSBS is present on all CPUs
arm64: use shared sysctl constants
arm64: Drop do_el0_ia_bp_hardening() & do_sp_pc_abort() declarations
- Revert two patches to gpio_do_set_config() and implement
the proper solution that works, also drop an unecessary
call in set_config()
- Fix up the lockdep class for hierarchical IRQ domains.
- Remove some bridge code for line directions.
- Fix a register access bug in the Xilinx driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl5FOqQACgkQQRCzN7AZ
XXNjYBAAkngeRE12fWjXXRNnkoMVXh0IzvkqKXn2fi+8Kvh7rnIaSLF08Yi/yMYd
FXTWj2coXH7rjyYs4zy0W2dZIXRAlcqEZi4I2WqsQQMvS7rKNqoGeF1yD37JOjQE
gDIsnzJJ3dM1YjO7gWKQCbPSXi9T2sZPfp1EI3q16QXdVuIGqMVE90gqbESb5sJ8
vxdtNf+S+mqwsHLbNzLGGVgkQsgrh5+hmiTe36L0DZXwFAd5f2i8EehBtpTEXBVR
7u+oGun0Ds9IYfoN1puchNfPvis6xQdaBSpU4eNKx/7SKwesSahgUF276v0MJkpC
tVWJvNLXgDCb9DqkDIB1ZiurieaAMlFVZ5+kxZ1kBv9M5vsuzzjH9AVMGsp73Bl7
v75hu4gwvNXYlLXoGkwtFrJqQqhiZRxwTiWOu2uwWoc2sVm+xq8aCQY5o/h3n2qh
uqfZ/8QqM/6m8P/KH6YOqie95LR9F20Uxx912afA3RhpKGWVbpOFd3P5hq+BygjI
uU/t6k54sV2nPDRBijMa53m0R5Ns5rF4RJ6ZaQ7q2q6q0vO9YsCKMlhPZPnQRxAV
LT0P/WxH2+4qAcyUsf1SAQdRXlw+zecEhF9JRsGAlMe7iFjvCiRm27GAtTT+TeSq
vhKWOpqdHvdTl0Fo84cnakISGh4yO+hxaogBQxQ4rCY92FDatyc=
=V1Dp
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
- Revert two patches to gpio_do_set_config() and implement the proper
solution that works, also drop an unecessary call in set_config()
- Fix up the lockdep class for hierarchical IRQ domains.
- Remove some bridge code for line directions.
- Fix a register access bug in the Xilinx driver.
* tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: sifive: fix static checker warning
spmi: pmic-arb: Set lockdep class for hierarchical irq domains
gpio: xilinx: Fix bug where the wrong GPIO register is written to
gpiolib: remove unnecessary argument from set_config call
gpio: bd71828: Remove unneeded defines for GPIO_LINE_DIRECTION_IN/OUT
MAINTAINERS: Sort entries in database for GPIO
gpiolib: fix gpio_do_set_config()
Revert "gpiolib: remove set but not used variable 'config'"
Revert "gpiolib: Remove duplicated function gpio_do_set_config()"
Jason A. Donenfeld says:
====================
icmp: account for NAT when sending icmps from ndo layer
The ICMP routines use the source address for two reasons:
1. Rate-limiting ICMP transmissions based on source address, so
that one source address cannot provoke a flood of replies. If
the source address is wrong, the rate limiting will be
incorrectly applied.
2. Choosing the interface and hence new source address of the
generated ICMP packet. If the original packet source address
is wrong, ICMP replies will be sent from the wrong source
address, resulting in either a misdelivery, infoleak, or just
general network admin confusion.
Most of the time, the icmp_send and icmpv6_send routines can just reach
down into the skb's IP header to determine the saddr. However, if
icmp_send or icmpv6_send is being called from a network device driver --
there are a few in the tree -- then it's possible that by the time
icmp_send or icmpv6_send looks at the packet, the packet's source
address has already been transformed by SNAT or MASQUERADE or some other
transformation that CONNTRACK knows about. In this case, the packet's
source address is most certainly the *wrong* source address to be used
for the purpose of ICMP replies.
Rather, the source address we want to use for ICMP replies is the
original one, from before the transformation occurred.
Fortunately, it's very easy to just ask CONNTRACK if it knows about this
packet, and if so, how to fix it up. The saddr is the only field in the
header we need to fix up, for the purposes of the subsequent processing
in the icmp_send and icmpv6_send functions, so we do the lookup very
early on, so that the rest of the ICMP machinery can progress as usual.
Changes v3->v4:
- Add back the skb_shared checking, since the previous assumption isn't
actually true [Eric]. This implies dropping the additional patches v3 had
for removing skb_share_check from various drivers. We can revisit that
general set of ideas later, but that's probably better suited as a net-next
patchset rather than this stable one which is geared at fixing bugs. So,
this implements things in the safe conservative way.
Changes v2->v3:
- Add selftest to ensure this actually does what we want and never regresses.
- Check the size of the skb header before operating on it.
- Use skb_ensure_writable to ensure we can modify the cloned skb [Florian].
- Conditionalize this on IPS_SRC_NAT so we don't do anything unnecessarily
[Florian].
- It turns out that since we're calling these from the xmit path,
skb_share_check isn't required, so remove that [Florian]. This simplifes the
code a bit too. **The supposition here is that skbs passed to ndo_start_xmit
are _never_ shared. If this is not correct NOW IS THE TIME TO PIPE UP, for
doom awaits us later.**
- While investigating the shared skb business, several drivers appeared to be
calling it incorrectly in the xmit path, so this series also removes those
unnecessary calls, based on the supposition mentioned in the previous point.
Changes v1->v2:
- icmpv6 takes subtly different types than icmpv4, like u32 instead of be32,
u8 instead of int.
- Since we're technically writing to the skb, we need to make sure it's not
a shared one [Dave, 2017].
- Restore the original skb data after icmp_send returns. All current users
are freeing the packet right after, so it doesn't matter, but future users
might not.
- Remove superfluous route lookup in sunvnet [Dave].
- Use NF_NAT instead of NF_CONNTRACK for condition [Florian].
- Include this cover letter [Dave].
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Because xfrmi is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Because wireguard is calling icmp from network device context, it should
use the ndo helper so that the rate limiting applies correctly. This
commit adds a small test to the wireguard test suite to ensure that the
new functions continue doing the right thing in the context of
wireguard. It does this by setting up a condition that will definately
evoke an icmp error message from the driver, but along a nat'd path.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Because sunvnet is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly. While we're
at it, doing the additional route lookup before calling icmp_ndo_send is
superfluous, since this is the job of the icmp code in the first place.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Because gtp is calling icmp from network device context, it should use
the ndo helper so that the rate limiting applies correctly.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Harald Welte <laforge@gnumonks.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
