The 64-bit signed bounds should not affect 32-bit signed bounds unless the
verifier knows that upper 32-bits are either all 1s or all 0s. For example the
register with smin_value==1 doesn't mean that s32_min_value is also equal to 1,
since smax_value could be larger than 32-bit subregister can hold.
The verifier refines the smax/s32_max return value from certain helpers in
do_refine_retval_range(). Teach the verifier to recognize that smin/s32_min
value is also bounded. When both smin and smax bounds fit into 32-bit
subregister the verifier can propagate those bounds.
Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking")
Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEK3kIWJt9yTYMP3ehqclaivrt76kFAl/R7dETHG1rbEBwZW5n
dXRyb25peC5kZQAKCRCpyVqK+u3vqVGdB/4kMAJaguAotadb18Zq6+5bQ3VYxKms
a9ctqOnFHv/pTPijEtZoVOMTFItMhQZeBZqYqhe4P544z1oMBg+dtGcli++me2TR
Lh8JSQIkql9EQN65XX4ZEdEE5u32fFzp2nr1WpKSa6INek5Pfv/QsiGOz2Ws0Oxy
mZNj4lf30p1+tJunKKSWXghHkw12NPX77AeYLw5uYb1Jmq7o1LIdENpBJEULVwkI
LVRcxiwcFmUkXMCXbdB8HuUiVCm5Ju3/BCaOWdQk23LYCBDGLi6jW3JAk3qtTqRA
DQO6sMo/KXrzA49qma6o7AL/i3+fVYjsVPpRjiWNioKbHduvSXoyPyKb
=u5Aa
-----END PGP SIGNATURE-----
Merge tag 'linux-can-next-for-5.11-20201210' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
pull-request: can-next 2020-12-10
here's a pull request of 7 patches for net-next/master.
The first patch is by Oliver Hartkopp for the CAN ISOTP, which adds support for
functional addressing.
A patch by Antonio Quartulli removes an unneeded unlikely() annotation from the
rx-offload helper.
The next three patches target the m_can driver. Sean Nyekjaers's patch removes
a double clearing of clock stop request bit, Patrik Flykt's patch moves the
runtime PM enable/disable to m_can_platform and Jarkko Nikula's patch adds a
PCI glue code driver.
Fabio Estevam's patch converts the flexcan driver to DT only.
And Manivannan Sadhasivam's patchd for the mcp251xfd driver adds internal
loopback mode support.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The definition of IS_ERR() already applies the unlikely() notation
when checking the error status of the passed pointer. For this
reason there is no need to have the same notation outside of
IS_ERR() itself.
Clean up code by removing redundant notation.
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Two user triggerable crashers and a some EFA related regressions:
- Syzkaller found bug in CM
- Restore access to the GID table and fix modify_qp for EFA
- Crasher in qedr
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAl/SIhwACgkQOG33FX4g
mxpGJA//avv3jik7oQYssmuCy1QwIT/aRVcigvYdhgO7f1JbIs7DkVwQRz1rYYSv
SgtoFESutwgutQacuEg6DPn2xvan04gdGxK5dxPCU8RXm19yKmHi68U2yevMfVdI
VFjgMM2+JA+i91l8rfgXcz+Ygs4gUTeppM7Znv/1RAdY+d0BNeNEsZgA5Dm95y3F
p3Fa0wTHO1UKVNnpTi4TypFELfAsP2O8oascLkV7GwN86V/asenefsfdUlrXSxK4
687y3/AnBC8/pJp9RRLFbEkS6+wKZIRg1DyHMptkf6gFcVvx9AzeQqmqGnAz/9GG
9LusGUxdI4EQeADxpRQ56STs4U+5NtPWZdmSwOZFBZConaO2TQtjYWleBZUl3WQw
rKUwOYcyZU6AwF4V72x1RnEFzzIkF7EHTJLKKDCUxnW6UGz3jo+tCwR593pTnlon
ue+6ibktk1ZcFU4rhf80Y1OUHytmFLM3j2ynXZ/SE1uUahECHDDMmC5XUOvkR5Fn
ytL9wbFoPqs7zZ8vB1lvo/MYJy9P/qOMmHGLbca8YczWaZ5yzlZF1RibalmzblES
UJeKNe6MC0+vNaDWeSY474kP1r7XXMUGPrXVX1GOsqdDVrw2Li0FksgcBFAd0oIi
BizkmKth+p10XmsjxqmHCWOjDLylB4fmgSzKjmjXLejyn3BVJgY=
=CJih
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"Two user triggerable crashers and a some EFA related regressions:
- Syzkaller found a bug in CM
- Restore access to the GID table and fix modify_qp for EFA
- Crasher in qedr"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewait
RDMA/core: Fix empty gid table for non IB/RoCE devices
RDMA/efa: Use the correct current and new states in modify QP
RDMA/qedr: iWARP invalid(zero) doorbell address fix
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl/SAkAACgkQCF8+vY7k
4RXd2A/7B2hPds737XVei8/b/Av1HmE9AMsfy77iXP7gm3BBBBamhFlCohM6e8bG
3s2YmOsJ/1tCN4SY6yKNHBDJciYWKC6ql1GLUmlgW+uvJMMRN9SsrmRRs9Ws4q6B
N2J1eD399SYpnPwcvtbsoaS6A8LQXFHQZVnoqiPRamyUEMQYvXSGdeDgw1032EL5
+74ZMbJQgs6ri3mCkX9FIp3z9foZaSD5bmjrFJKXqllkFBLgpaIxv8C6KjTwCvT/
sgvj1ihnjO4b+atC4QoYi4gyWBEU31dMxzL32riRin8gafA42IAvaUaoS+vpBY6N
yDhS8HH6vpOXVkPtzfrBXzz/7ZiZoBFJWBMdzoeHX41Nrd2D6LKWsUp9ZqC+uBmF
zb7NC20IZr8XwO8KGNSmsZ4jzw7wDbA5LstSZVQSv5WbOtnrGMQ0q2NWgMn7SziS
pk3nbZ4JtFp4SkxP/wNYyN+KdWoHRet67Fj+jOjJghw8KlnUmqoAv2+CuHYSlDEQ
e+VW63EVGZ/MNBzTdGWZMnw8meZ0QR2LXq61sIvbDoxIdVWEK2XA4cmMRBm2pZ8P
9mqITdmgeH8xy5CsEvr+hcRl/pmjqGZ9jo9u3kKshbyL1vnb8jmWo+TaEopeBE4R
LHzk+/FLAKUTuzK+lMc0wELGHVjHUa8p+TPr7yQvmSa+dIfGZCM=
=D71n
-----END PGP SIGNATURE-----
Merge tag 'media/v5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"A couple of fixes:
- videobuf2: fix a DMABUF bug, preventing it to properly handle cache
sync/flush
- vidtv: an usage after free and a few sparse/smatch warning fixes
- pulse8-cec: a duplicate free and a bug related to new firmware
usage
- mtk-cir: fix a regression on a clock setting"
* tag 'media/v5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: vidtv: fix some warnings
media: vidtv: fix kernel-doc markups
media: [next] media: vidtv: fix a read from an object after it has been freed
media: vb2: set cache sync hints when init buffers
media: pulse8-cec: add support for FW v10 and up
media: pulse8-cec: fix duplicate free at disconnect or probe error
media: mtk-cir: fix calculation of chk period
Added retry mechanism to ensure VMM enable bit is set during the
block transfer of data between host and WILC FW.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208103739.28597-1-ajay.kathat@microchip.com
* A few fixes and improvements in the FW debugging framework;
* A fix in the HE capabilities settings;
* Small fix in the logs for SAR;
* Move queue code to a common place;
* Support for 6GHz;
* Improve validation of firmware notifications;
* Debugging improvements and fixes;
* Replace terminology with inclusive words determined by the guidelines;
* Convert copyright notices to SPDX tags;
* Added more validations for firmware notifications;
* A couple of debugging/recovery fixes;
* Added some more validations for firmware notifications;
* Support for a new type of HW;
* A couple of channel switch fixes;
* Support new FW reset handshake;
* Add a couple of RX handlers that were accidentally left out;
* Some other clean-ups and small fixes;
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAl/RTY8ACgkQoUecoho8
xfofyxAAidnwDIo/iMX8c6xSbvrAy9Svys0NSgkQnEIkpMOx+t2nD8wyYC/jRUKD
vEOZT9MvPvM/i2ZSnN5Krj6oGhuoIxLVhO98MXpy9OOy783ajLC3gx8COzCnlnWW
bJdCSlHAPkN2oTD5S2NP0Y2REZA3e7I/Q9exHhMAQD0iDqVUN6AA5/7X+6b0JRKT
8ClMoCUZ8Dza41b1wlKvwzzZYoct76fvYb7ygsyot5uZXzN7sF1Mag9pNnLyK3yx
Sa1ytJDChUIqn/LfLW/4svS99+/eRwmwU9J45fisv86Pk5Fvcx+VORS6MRqvPvCP
SuirOfrEy/K7b5lHhzTIv6Ta6WM8XaCRVNubk6dnc5dT1n+uYHBwsNEO5ePUnmCN
P+mq0xm+zXUC37Ng7Cmxhm2Z9QImTgD1zbNc1UkIWjP4+IsW6swMh7JyAXHl2RIh
tQeiNYJ85BxCFl5oqJhSIjFTR0DJM6SkNF+uwisluS0k/WgeQMcgovx7+XsZR5+p
YQHRT3wxWk9Dx9iWmfrVHyeLGDezUqN9ICSdsMkXYpwNoDQ7sZJpwTQXn2fG+maT
97KcOPQbz7TazZipKjzY5Y+JLX+NG6nG2BsImEkzPv8L074GnW7djVbcOTP7cWN0
yyxsVZcQmAu4/38/J45C7aqm5ovmkI4YQBx0x3BO4FXDCcMxpak=
=0gIs
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2020-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches intended for v5.11
* A few fixes and improvements in the FW debugging framework;
* A fix in the HE capabilities settings;
* Small fix in the logs for SAR;
* Move queue code to a common place;
* Support for 6GHz;
* Improve validation of firmware notifications;
* Debugging improvements and fixes;
* Replace terminology with inclusive words determined by the guidelines;
* Convert copyright notices to SPDX tags;
* Added more validations for firmware notifications;
* A couple of debugging/recovery fixes;
* Added some more validations for firmware notifications;
* Support for a new type of HW;
* A couple of channel switch fixes;
* Support new FW reset handshake;
* Add a couple of RX handlers that were accidentally left out;
* Some other clean-ups and small fixes;
# gpg: Signature made Thu 10 Dec 2020 12:19:59 AM EET using RSA key ID 1A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>"
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
We can't compile test_core_reloc_module.c selftest with clang 11, compile
fails with:
CLNG-LLC [test_maps] test_core_reloc_module.o
progs/test_core_reloc_module.c:57:21: error: use of unknown builtin \
'__builtin_preserve_type_info' [-Wimplicit-function-declaration]
out->read_ctx_sz = bpf_core_type_size(struct bpf_testmod_test_read_ctx);
Skipping these tests if __builtin_preserve_type_info() is not supported
by compiler.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20201209142912.99145-1-jolsa@kernel.org
This patch adds *xdpxceiver* to selftests/bpf/.gitignore
Reported-by: Yonghong Song <yhs@fb.com>
Suggested-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Weqaar Janjua <weqaar.a.janjua@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20201210115435.3995-1-weqaar.a.janjua@intel.com
The files don't exist anymore so this breaks generic kselftest builds
when using "make install" or "make gen_tar".
Fixes: 247f0ec361b7 ("selftests/bpf: Drop python client/server in favor of threads")
Signed-off-by: Veronika Kabatova <vkabatov@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20201210120134.2148482-1-vkabatov@redhat.com
MCP251xFD supports internal loopback mode which can be used to verify CAN
functionality in the absence of a real CAN device.
Link: https://lore.kernel.org/r/20201201054019.11012-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[mkl: mcp251xfd_get_normal_mode(): move CAN_CTRLMODE_LOOPBACK check to front]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The flexcan driver runs only on DT platforms, so simplify the code by using
of_device_get_match_data() to retrieve the driver data and also by removing the
unused id_table.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201128132855.7724-1-festevam@gmail.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Add support for M_CAN controller on Intel Elkhart Lake attached to the PCI bus.
It integrates the Bosch M_CAN controller with Message RAM and the wrapper IP
block with additional registers which all of them are within the same MMIO
range.
Currently only interrupt control register from wrapper IP is used and the MRAM
configuration is expected to come from the firmware via "bosch,mram-cfg" device
property and parsed by m_can.c core.
Initial implementation is done by Felipe Balbi while he was working at Intel
with later changes from Raymond Tan and me.
Co-developed-by: Felipe Balbi (Intel) <balbi@kernel.org>
Co-developed-by: Raymond Tan <raymond.tan@intel.com>
Signed-off-by: Felipe Balbi (Intel) <balbi@kernel.org>
Signed-off-by: Raymond Tan <raymond.tan@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20201117160827.3636264-1-jarkko.nikula@linux.intel.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This is a preparatory patch for upcoming PCI based M_CAN devices. The current
PM implementation would cause PCI based drivers to enable PM twice, once when
the PCI device is added and a second time in m_can_class_register(). This will
cause 'Unbalanced pm_runtime_enable!' to be logged, and is a situation that
should be avoided.
Therefore, in anticipation of PCI devices, move PM enabling out from M_CAN
class registration to its only user, the m_can_platform driver.
Signed-off-by: Patrik Flykt <patrik.flykt@linux.intel.com>
Link: https://lore.kernel.org/r/20201023115800.46538-2-patrik.flykt@linux.intel.com
[mkl: m_can_plat_probe(): fix error handling
m_can_class_register(): simplify error handling]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The CSR bit is already cleared when arriving here so remove this section of
duplicate code.
The registers set in m_can_config_endisable() is set to same exact values as
before this patch.
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Acked-by: Sriram Dash <sriram.dash@samsung.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20191211063227.84259-1-sean@geanix.com
Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The definition of IS_ERR() already applies the unlikely() notation when
checking the error status of the passed pointer. For this reason there is no
need to have the same notation outside of IS_ERR() itself.
Clean up code by removing redundant notation.
Signed-off-by: Antonio Quartulli <a@unstable.cc>
Link: https://lore.kernel.org/r/20201210085321.18693-1-a@unstable.cc
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the CAN_ISOTP
socket is switched into functional addressing mode, where only single frame
(SF) protocol data units can be send on the specified CAN interface and the
given tp.tx_id after bind().
In opposite to normal and extended addressing this socket does not register a
CAN-ID for reception which would be needed for a 1-to-1 ISOTP connection with a
segmented bi-directional data transfer.
Sending SFs on this socket is therefore a TX-only 'broadcast' operation.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Thomas Wagner <thwa1@web.de>
Link: https://lore.kernel.org/r/20201206144731.4609-1-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
In zonefs_file_dio_append(), the pages obtained using
bio_iov_iter_get_pages() are not released on completion of the
REQ_OP_APPEND BIO, nor when bio_iov_iter_get_pages() fails.
Furthermore, a call to bio_put() is missing when
bio_iov_iter_get_pages() fails.
Fix these resource leaks by adding BIO resource release code (bio_put()i
and bio_release_pages()) at the end of the function after the BIO
execution and add a jump to this resource cleanup code in case of
bio_iov_iter_get_pages() failure.
While at it, also fix the call to task_io_account_write() to be passed
the correct BIO size instead of bio_iov_iter_get_pages() return value.
Reported-by: Christoph Hellwig <hch@lst.de>
Fixes: 02ef12a663c7 ("zonefs: use REQ_OP_ZONE_APPEND for sync DIO")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Add maintainers info for new Marvell Prestera Ethernet switch driver.
Signed-off-by: Mickey Rachamim <mickeyr@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Huazhong Tan says:
====================
net: hns3: updates for -next
This patchset adds support for tc mqprio offload, hw tc
offload of tc flower, and adpation for max rss size changes.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
For the max rss size of PF may be up to 512, the max queue
number of single tc may be up to 512 too. For the total queue
numbers may be up to 1280, so the queue offset of each tc may
be more than 1024. So adjust the rss tc mode configuration
command, including extend tc size field from 10 bits to 11
bits, and extend tc size field from 3 bits to 4 bits.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For the max rss size of PF may be up to 512, so adjust the
command of configuring rss indirection table to support
queue id larger than 255. The width of queue id is extended
from 8 bits to 10 bits. The high 2 bits are stored in filed
rss_qid_h when the queue id is larger than 255.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the driver gets the max rss size from configuration
file when initialization. Both the PF and VF share the same
max rss size, and no more than 128.
For DEVICE_VERSION_V3, the max rss size for PF can be up to
512, so there is a new field in configuration file to store it,
the old filed is used for VF.
To be compatible with boards using old configure file, the PF
will use the old filed if the one is zero.
For the rss size may be larger than 256, so the type of
rss_indirection_tbl of struct hclge_vport should be changed to
u16 as well.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some new device supports forwarding packet to queues of specified
TC when flow director rule hit. So add support to configure flow
director rule by tc flower. To avoid rule conflict, add a new flow
director mode HCLGE_FD_TC_FLOWER_ACTIVE, and only one mode can be
active at the same time.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For some new device, it supports forwarding packet to queues
of specified TC when flow director rule hit. So extend the
command handle to support it.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the HNS3 driver only supports offload for tc number
and prio_tc. This patch adds support for other qopts, including
queues count and offset for each tc.
When enable tc mqprio offload, it's not allowed to change
queue numbers by ethtool. For hardware limitation, the queue
number of each tc should be power of 2.
For the queues is not assigned to each tc by average, so it's
should return vport->alloc_tqps for hclge_get_max_channels().
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, there are multiple members related to tc information
in struct hnae3_knic_private_info. Merge them into a new struct
hnae3_tc_info.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Test robot reports:
drivers/net/ethernet/netronome/nfp/crypto/tls.c: In function 'nfp_net_tls_rx_resync_req':
drivers/net/ethernet/netronome/nfp/crypto/tls.c:477:18: warning: variable 'ipv6h' set but not used [-Wunused-but-set-variable]
477 | struct ipv6hdr *ipv6h;
| ^~~~~
In file included from include/linux/compiler_types.h:65,
from <command-line>:
drivers/net/ethernet/netronome/nfp/crypto/tls.c: In function 'nfp_net_tls_add':
include/linux/compiler_attributes.h:208:41: warning: statement will never be executed [-Wswitch-unreachable]
208 | # define fallthrough __attribute__((__fallthrough__))
| ^~~~~~~~~~~~~
drivers/net/ethernet/netronome/nfp/crypto/tls.c:299:3: note: in expansion of macro 'fallthrough'
299 | fallthrough;
| ^~~~~~~~~~~
Use the IPv6 header in the switch, it doesn't matter which header
we use to read the version field.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Assign stmmac's mdio_bus probe capabilities to MDIOBUS_C22_C45.
This extended the probing of C45 PHY devices on the MDIO bus.
Signed-off-by: Wong Vee Khee <vee.khee.wong@intel.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The "COMPUTE" was wrongly spelled as "CUSTOM".
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.9.x
dule'
Russell King says:
====================
Add support for VSOL V2801F/CarlitoxxPro CPGOS03 GPON module
This patch set adds support for the V2801F / CarlitoxxPro module. This
requires two changes:
1) the module only supports single byte reads to the ID EEPROM,
while we need to still permit sequential reads to the diagnostics
EEPROM for atomicity reasons.
2) we need to relax the encoding check when we have no reported
capabilities to allow 1000base-X based on the module bitrate.
Thanks to Pali Rohár for responsive testing over the last two days.
(Resending, dropping the utf-8 characters in Pali's name so the patches
get through vger. Added Andrew's r-b tags.)
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Do not check the encoding when deriving 1000BASE-X from the bitrate
when no other modes are discovered. Some GPON modules (VSOL V2801F
and CarlitoxxPro CPGOS03-0490 v2.0) indicate NRZ encoding with a
1200Mbaud bitrate, but should be driven with 1000BASE-X on the host
side.
Tested-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a workaround for the detection of VSOL V2801F / CarlitoxxPro
CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single
byte I2C reads to the EEPROM.
Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module,
which reports a manufacturer of "OEM". This manufacturer can't be
matched as it appears in many different modules, so also match the part
number too.
Reported-by: Thomas Schreiber <tschreibe@gmail.com>
Reported-by: Pali Rohár <pali@kernel.org>
Tested-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
1. When the x25 module gets loaded, layer 2 may already be running and
connected. In this case, although we are in X25_LINK_STATE_0, we still
need to handle the Restart Request received, rather than ignore it.
2. When we are in X25_LINK_STATE_2, we have already sent a Restart Request
and is waiting for the Restart Confirmation with t20timer. t20timer will
restart itself repeatedly forever so it will always be there, as long as we
are in State 2. So we don't need to check x25_t20timer_pending again.
Fixes: d023b2b9ccc2 ("net/x25: fix restart request/confirm handling")
Cc: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Acked-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Paolo Abeni says:
====================
mptcp: a bunch of fixes
This series includes a few fixes following-up the
recent code refactor for the MPTCP RX and TX paths.
Boundling them together, since the fixes are somewhat
related.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When the workqueue disposes of the msk, the subflows can still
receive some data from the peer after __mptcp_close_ssk()
completes.
The above could trigger a race between the msk receive path and the
msk destruction. Acquiring the mptcp_data_lock() in __mptcp_destroy_sock()
will not save the day: the rx path could be reached even after msk
destruction completes.
Instead use the subflow 'disposable' flag to prevent entering
the msk receive path after __mptcp_close_ssk().
Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a MPTCP listener socket is closed with unaccepted
children pending, the ULP release callback will be invoked,
but nobody will call into __mptcp_close_ssk() on the
corresponding subflow.
As a consequence, at ULP release time, the 'disposable' flag
will be cleared and the subflow context memory will be leaked.
This change addresses the issue always freeing the context if
the subflow is still in the accept queue at ULP release time.
Additionally, this fixes an incorrect code reference in the
related comment.
Note: this fix leverages the changes introduced by the previous
commit.
Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christoph reported the following splat:
WARNING: CPU: 0 PID: 4615 at net/ipv4/inet_connection_sock.c:1031 inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
Modules linked in:
CPU: 0 PID: 4615 Comm: syz-executor.4 Not tainted 5.9.0 #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:inet_csk_listen_stop+0x8e8/0xad0 net/ipv4/inet_connection_sock.c:1031
Code: 03 00 00 00 e8 79 b2 3d ff e9 ad f9 ff ff e8 1f 76 ba fe be 02 00 00 00 4c 89 f7 e8 62 b2 3d ff e9 14 f9 ff ff e8 08 76 ba fe <0f> 0b e9 97 f8 ff ff e8 fc 75 ba fe be 03 00 00 00 4c 89 f7 e8 3f
RSP: 0018:ffffc900037f7948 EFLAGS: 00010293
RAX: ffff88810a349c80 RBX: ffff888114ee1b00 RCX: ffffffff827b14cd
RDX: 0000000000000000 RSI: ffffffff827b1c38 RDI: 0000000000000005
RBP: ffff88810a2a8000 R08: ffff88810a349c80 R09: fffff520006fef1f
R10: 0000000000000003 R11: fffff520006fef1e R12: ffff888114ee2d00
R13: dffffc0000000000 R14: 0000000000000001 R15: ffff888114ee1d68
FS: 00007f2ac1945700(0000) GS:ffff88811b400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd44798bc0 CR3: 0000000109810002 CR4: 0000000000170ef0
Call Trace:
__tcp_close+0xd86/0x1110 net/ipv4/tcp.c:2433
__mptcp_close_ssk+0x256/0x430 net/mptcp/protocol.c:1761
__mptcp_destroy_sock+0x49b/0x770 net/mptcp/protocol.c:2127
mptcp_close+0x62d/0x910 net/mptcp/protocol.c:2184
inet_release+0xe9/0x1f0 net/ipv4/af_inet.c:434
__sock_release+0xd2/0x280 net/socket.c:596
sock_close+0x15/0x20 net/socket.c:1277
__fput+0x276/0x960 fs/file_table.c:281
task_work_run+0x109/0x1d0 kernel/task_work.c:151
get_signal+0xe8f/0x1d40 kernel/signal.c:2561
arch_do_signal+0x88/0x1b60 arch/x86/kernel/signal.c:811
exit_to_user_mode_loop kernel/entry/common.c:161 [inline]
exit_to_user_mode_prepare+0x9b/0xf0 kernel/entry/common.c:191
syscall_exit_to_user_mode+0x22/0x150 kernel/entry/common.c:266
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f2ac1254469
Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
RSP: 002b:00007f2ac1944dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffbf RBX: 000000000069bf00 RCX: 00007f2ac1254469
RDX: 0000000000000000 RSI: 0000000000008982 RDI: 0000000000000003
RBP: 000000000069bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000069bf0c
R13: 00007ffeb53f178f R14: 00000000004668b0 R15: 0000000000000003
After commit 0397c6d85f9c ("mptcp: keep unaccepted MPC subflow into
join list"), the msk's workqueue and/or PM can touch the MPC
subflow - and acquire its socket lock - even if it's still unaccepted.
If the above event races with the relevant listener socket close, we
can end-up with the above splat.
This change addresses the issue delaying the MPC socket insertion
in conn_list at accept time - that is, partially reverting the
blamed commit.
We must additionally ensure that mptcp_pm_fully_established()
happens after accept() time, or the PM will not be able to
handle properly such event - conn_list could be empty otherwise.
In the receive path, we check the subflow list node to ensure
it is out of the listener queue. Be sure client subflows do
not match transiently such condition moving them into the join
list earlier at creation time.
Since we now have multiple mptcp_pm_fully_established() call sites
from different code-paths, said helper can now race with itself.
Use an additional PM status bit to avoid multiple notifications.
Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/103
Fixes: 0397c6d85f9c ("mptcp: keep unaccepted MPC subflow into join list"),
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1. In x25_xmit, skb_reset_network_header is not necessary before we call
lapb_data_request. The lapb module doesn't need skb->network_header.
So there is no need to set skb->network_header before calling
lapb_data_request.
2. In x25_data_indication (called by the lapb module after data have
been received), skb_reset_network_header is not necessary before we
call netif_rx. After we call netif_rx, the code in net/core/dev.c will
call skb_reset_network_header before handing the skb to upper layers
(in __netif_receive_skb_core, called by __netif_receive_skb_one_core,
called by __netif_receive_skb, called by process_backlog). So we don't
need to call skb_reset_network_header by ourselves.
Cc: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We observed that in the error case for batched send_subcrq_indirect() the
driver does not account for the partial success case. This caused Linux to
crash when free_map and pool index are inconsistent.
Driver needs to update the rx pools "available" count when some batched
sends worked but an error was encountered as part of the whole operation.
Also track replenish_add_buff_failure for statistic purposes.
Fixes: 4f0b6812e9b9a ("ibmvnic: Introduce batched RX buffer descriptor transmission")
Signed-off-by: Dwip N. Banerjee <dnbanerg@us.ibm.com>
Reviewed-by: Dany Madden <drt@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mat Martineau says:
====================
mptcp: Add port parameter to ADD_ADDR option
The ADD_ADDR MPTCP option is used to announce available IP addresses
that a peer may connect to when adding more TCP subflows to an existing
MPTCP connection. There is an optional port number field in that
ADD_ADDR header, and this patch set adds capability for that port number
to be sent and received.
Patches 1, 2, and 4 refactor existing ADD_ADDR code to simplify implementation
of port number support.
Patches 3 and 5 are the main functional changes, for sending and
receiving the port number in the MPTCP ADD_ADDR option.
Patch 6 sends the ADD_ADDR option with port number on a bare TCP ACK,
since the extra length of the option may run in to cases where
sufficient TCP option space is not available on a data packet.
Patch 7 plumbs in port number support for the in-kernel MPTCP path
manager.
Patches 8-11 add some optional debug output and a little more cleanup
refactoring.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the local variable sk has been defined, use it instead of
open-coding.
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the RM_ADDR signal had been reused with add_addr_signal, it's not
suitable to call it add_addr_signal or mptcp_add_addr_status. So this
patch renamed add_addr_signal to addr_signal, and renamed
mptcp_add_addr_status to mptcp_addr_signal_status.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch reused add_addr_signal for the RM_ADDR announcing signal, by
defining a new ADD_ADDR status named MPTCP_RM_ADDR_SIGNAL. Then the flag
rm_addr_signal in PM could be dropped.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
