From: kernel test robot <lkp@intel.com>
To: Geliang Tang <geliang.tang@suse.com>, mptcp@lists.linux.dev
Cc: llvm@lists.linux.dev, kbuild-all@lists.01.org,
Geliang Tang <geliang.tang@suse.com>
Subject: Re: [PATCH mptcp-next] Squash to "mptcp: infinite mapping receiving"
Date: Thu, 21 Oct 2021 21:42:11 +0800 [thread overview]
Message-ID: <202110212124.LLGxLRSx-lkp@intel.com> (raw)
In-Reply-To: <39044f0b1da24b4228ed186a751b893a94e9d56b.1634796076.git.geliang.tang@suse.com>
[-- Attachment #1: Type: text/plain, Size: 7648 bytes --]
Hi Geliang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.15-rc6 next-20211021]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Geliang-Tang/Squash-to-mptcp-infinite-mapping-receiving/20211021-140855
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2f111a6fd5b5297b4e92f53798ca086f7c7d33a4
config: hexagon-randconfig-r045-20211021 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 3cea2505fd8d99a9ba0cb625aecfe28a47c4e3f8)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/ca85326898507008f999c544140bfcecb30316b3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Geliang-Tang/Squash-to-mptcp-infinite-mapping-receiving/20211021-140855
git checkout ca85326898507008f999c544140bfcecb30316b3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=hexagon
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> net/mptcp/subflow.c:941:36: error: implicit declaration of function 'mptcp_check_infinite_map' [-Werror,-Wimplicit-function-declaration]
if (mptcp_check_fallback(ssk) && !mptcp_check_infinite_map(skb))
^
1 error generated.
--
net/mptcp/options.c:566:21: warning: parameter 'remaining' set but not used [-Wunused-but-set-parameter]
unsigned int remaining,
^
>> net/mptcp/options.c:1218:11: error: no member named 'infinite_map' in 'struct mptcp_ext'
mpext->infinite_map = 1;
~~~~~ ^
1 warning and 1 error generated.
vim +/mptcp_check_infinite_map +941 net/mptcp/subflow.c
926
927 static enum mapping_status get_mapping_status(struct sock *ssk,
928 struct mptcp_sock *msk)
929 {
930 struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
931 bool csum_reqd = READ_ONCE(msk->csum_enabled);
932 struct mptcp_ext *mpext;
933 struct sk_buff *skb;
934 u16 data_len;
935 u64 map_seq;
936
937 skb = skb_peek(&ssk->sk_receive_queue);
938 if (!skb)
939 return MAPPING_EMPTY;
940
> 941 if (mptcp_check_fallback(ssk) && !mptcp_check_infinite_map(skb))
942 return MAPPING_DUMMY;
943
944 mpext = mptcp_get_ext(skb);
945 if (!mpext || !mpext->use_map) {
946 if (!subflow->map_valid && !skb->len) {
947 /* the TCP stack deliver 0 len FIN pkt to the receive
948 * queue, that is the only 0len pkts ever expected here,
949 * and we can admit no mapping only for 0 len pkts
950 */
951 if (!(TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN))
952 WARN_ONCE(1, "0len seq %d:%d flags %x",
953 TCP_SKB_CB(skb)->seq,
954 TCP_SKB_CB(skb)->end_seq,
955 TCP_SKB_CB(skb)->tcp_flags);
956 sk_eat_skb(ssk, skb);
957 return MAPPING_EMPTY;
958 }
959
960 if (!subflow->map_valid)
961 return MAPPING_INVALID;
962
963 goto validate_seq;
964 }
965
966 trace_get_mapping_status(mpext);
967
968 data_len = mpext->data_len;
969 if (data_len == 0) {
970 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_INFINITEMAPRX);
971 return MAPPING_INVALID;
972 }
973
974 if (mpext->data_fin == 1) {
975 if (data_len == 1) {
976 bool updated = mptcp_update_rcv_data_fin(msk, mpext->data_seq,
977 mpext->dsn64);
978 pr_debug("DATA_FIN with no payload seq=%llu", mpext->data_seq);
979 if (subflow->map_valid) {
980 /* A DATA_FIN might arrive in a DSS
981 * option before the previous mapping
982 * has been fully consumed. Continue
983 * handling the existing mapping.
984 */
985 skb_ext_del(skb, SKB_EXT_MPTCP);
986 return MAPPING_OK;
987 } else {
988 if (updated && schedule_work(&msk->work))
989 sock_hold((struct sock *)msk);
990
991 return MAPPING_DATA_FIN;
992 }
993 } else {
994 u64 data_fin_seq = mpext->data_seq + data_len - 1;
995
996 /* If mpext->data_seq is a 32-bit value, data_fin_seq
997 * must also be limited to 32 bits.
998 */
999 if (!mpext->dsn64)
1000 data_fin_seq &= GENMASK_ULL(31, 0);
1001
1002 mptcp_update_rcv_data_fin(msk, data_fin_seq, mpext->dsn64);
1003 pr_debug("DATA_FIN with mapping seq=%llu dsn64=%d",
1004 data_fin_seq, mpext->dsn64);
1005 }
1006
1007 /* Adjust for DATA_FIN using 1 byte of sequence space */
1008 data_len--;
1009 }
1010
1011 map_seq = mptcp_expand_seq(READ_ONCE(msk->ack_seq), mpext->data_seq, mpext->dsn64);
1012 WRITE_ONCE(mptcp_sk(subflow->conn)->use_64bit_ack, !!mpext->dsn64);
1013
1014 if (subflow->map_valid) {
1015 /* Allow replacing only with an identical map */
1016 if (subflow->map_seq == map_seq &&
1017 subflow->map_subflow_seq == mpext->subflow_seq &&
1018 subflow->map_data_len == data_len &&
1019 subflow->map_csum_reqd == mpext->csum_reqd) {
1020 skb_ext_del(skb, SKB_EXT_MPTCP);
1021 goto validate_csum;
1022 }
1023
1024 /* If this skb data are fully covered by the current mapping,
1025 * the new map would need caching, which is not supported
1026 */
1027 if (skb_is_fully_mapped(ssk, skb)) {
1028 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSNOMATCH);
1029 return MAPPING_INVALID;
1030 }
1031
1032 /* will validate the next map after consuming the current one */
1033 goto validate_csum;
1034 }
1035
1036 subflow->map_seq = map_seq;
1037 subflow->map_subflow_seq = mpext->subflow_seq;
1038 subflow->map_data_len = data_len;
1039 subflow->map_valid = 1;
1040 subflow->map_data_fin = mpext->data_fin;
1041 subflow->mpc_map = mpext->mpc_map;
1042 subflow->map_csum_reqd = mpext->csum_reqd;
1043 subflow->map_csum_len = 0;
1044 subflow->map_data_csum = csum_unfold(mpext->csum);
1045
1046 /* Cfr RFC 8684 Section 3.3.0 */
1047 if (unlikely(subflow->map_csum_reqd != csum_reqd))
1048 return MAPPING_INVALID;
1049
1050 pr_debug("new map seq=%llu subflow_seq=%u data_len=%u csum=%d:%u",
1051 subflow->map_seq, subflow->map_subflow_seq,
1052 subflow->map_data_len, subflow->map_csum_reqd,
1053 subflow->map_data_csum);
1054
1055 validate_seq:
1056 /* we revalidate valid mapping on new skb, because we must ensure
1057 * the current skb is completely covered by the available mapping
1058 */
1059 if (!validate_mapping(ssk, skb)) {
1060 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSTCPMISMATCH);
1061 return MAPPING_INVALID;
1062 }
1063
1064 skb_ext_del(skb, SKB_EXT_MPTCP);
1065
1066 validate_csum:
1067 return validate_data_csum(ssk, skb, csum_reqd);
1068 }
1069
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28085 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH mptcp-next] Squash to "mptcp: infinite mapping receiving"
Date: Thu, 21 Oct 2021 21:42:11 +0800 [thread overview]
Message-ID: <202110212124.LLGxLRSx-lkp@intel.com> (raw)
In-Reply-To: <39044f0b1da24b4228ed186a751b893a94e9d56b.1634796076.git.geliang.tang@suse.com>
[-- Attachment #1: Type: text/plain, Size: 7843 bytes --]
Hi Geliang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.15-rc6 next-20211021]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Geliang-Tang/Squash-to-mptcp-infinite-mapping-receiving/20211021-140855
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2f111a6fd5b5297b4e92f53798ca086f7c7d33a4
config: hexagon-randconfig-r045-20211021 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 3cea2505fd8d99a9ba0cb625aecfe28a47c4e3f8)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/ca85326898507008f999c544140bfcecb30316b3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Geliang-Tang/Squash-to-mptcp-infinite-mapping-receiving/20211021-140855
git checkout ca85326898507008f999c544140bfcecb30316b3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=hexagon
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> net/mptcp/subflow.c:941:36: error: implicit declaration of function 'mptcp_check_infinite_map' [-Werror,-Wimplicit-function-declaration]
if (mptcp_check_fallback(ssk) && !mptcp_check_infinite_map(skb))
^
1 error generated.
--
net/mptcp/options.c:566:21: warning: parameter 'remaining' set but not used [-Wunused-but-set-parameter]
unsigned int remaining,
^
>> net/mptcp/options.c:1218:11: error: no member named 'infinite_map' in 'struct mptcp_ext'
mpext->infinite_map = 1;
~~~~~ ^
1 warning and 1 error generated.
vim +/mptcp_check_infinite_map +941 net/mptcp/subflow.c
926
927 static enum mapping_status get_mapping_status(struct sock *ssk,
928 struct mptcp_sock *msk)
929 {
930 struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
931 bool csum_reqd = READ_ONCE(msk->csum_enabled);
932 struct mptcp_ext *mpext;
933 struct sk_buff *skb;
934 u16 data_len;
935 u64 map_seq;
936
937 skb = skb_peek(&ssk->sk_receive_queue);
938 if (!skb)
939 return MAPPING_EMPTY;
940
> 941 if (mptcp_check_fallback(ssk) && !mptcp_check_infinite_map(skb))
942 return MAPPING_DUMMY;
943
944 mpext = mptcp_get_ext(skb);
945 if (!mpext || !mpext->use_map) {
946 if (!subflow->map_valid && !skb->len) {
947 /* the TCP stack deliver 0 len FIN pkt to the receive
948 * queue, that is the only 0len pkts ever expected here,
949 * and we can admit no mapping only for 0 len pkts
950 */
951 if (!(TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN))
952 WARN_ONCE(1, "0len seq %d:%d flags %x",
953 TCP_SKB_CB(skb)->seq,
954 TCP_SKB_CB(skb)->end_seq,
955 TCP_SKB_CB(skb)->tcp_flags);
956 sk_eat_skb(ssk, skb);
957 return MAPPING_EMPTY;
958 }
959
960 if (!subflow->map_valid)
961 return MAPPING_INVALID;
962
963 goto validate_seq;
964 }
965
966 trace_get_mapping_status(mpext);
967
968 data_len = mpext->data_len;
969 if (data_len == 0) {
970 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_INFINITEMAPRX);
971 return MAPPING_INVALID;
972 }
973
974 if (mpext->data_fin == 1) {
975 if (data_len == 1) {
976 bool updated = mptcp_update_rcv_data_fin(msk, mpext->data_seq,
977 mpext->dsn64);
978 pr_debug("DATA_FIN with no payload seq=%llu", mpext->data_seq);
979 if (subflow->map_valid) {
980 /* A DATA_FIN might arrive in a DSS
981 * option before the previous mapping
982 * has been fully consumed. Continue
983 * handling the existing mapping.
984 */
985 skb_ext_del(skb, SKB_EXT_MPTCP);
986 return MAPPING_OK;
987 } else {
988 if (updated && schedule_work(&msk->work))
989 sock_hold((struct sock *)msk);
990
991 return MAPPING_DATA_FIN;
992 }
993 } else {
994 u64 data_fin_seq = mpext->data_seq + data_len - 1;
995
996 /* If mpext->data_seq is a 32-bit value, data_fin_seq
997 * must also be limited to 32 bits.
998 */
999 if (!mpext->dsn64)
1000 data_fin_seq &= GENMASK_ULL(31, 0);
1001
1002 mptcp_update_rcv_data_fin(msk, data_fin_seq, mpext->dsn64);
1003 pr_debug("DATA_FIN with mapping seq=%llu dsn64=%d",
1004 data_fin_seq, mpext->dsn64);
1005 }
1006
1007 /* Adjust for DATA_FIN using 1 byte of sequence space */
1008 data_len--;
1009 }
1010
1011 map_seq = mptcp_expand_seq(READ_ONCE(msk->ack_seq), mpext->data_seq, mpext->dsn64);
1012 WRITE_ONCE(mptcp_sk(subflow->conn)->use_64bit_ack, !!mpext->dsn64);
1013
1014 if (subflow->map_valid) {
1015 /* Allow replacing only with an identical map */
1016 if (subflow->map_seq == map_seq &&
1017 subflow->map_subflow_seq == mpext->subflow_seq &&
1018 subflow->map_data_len == data_len &&
1019 subflow->map_csum_reqd == mpext->csum_reqd) {
1020 skb_ext_del(skb, SKB_EXT_MPTCP);
1021 goto validate_csum;
1022 }
1023
1024 /* If this skb data are fully covered by the current mapping,
1025 * the new map would need caching, which is not supported
1026 */
1027 if (skb_is_fully_mapped(ssk, skb)) {
1028 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSNOMATCH);
1029 return MAPPING_INVALID;
1030 }
1031
1032 /* will validate the next map after consuming the current one */
1033 goto validate_csum;
1034 }
1035
1036 subflow->map_seq = map_seq;
1037 subflow->map_subflow_seq = mpext->subflow_seq;
1038 subflow->map_data_len = data_len;
1039 subflow->map_valid = 1;
1040 subflow->map_data_fin = mpext->data_fin;
1041 subflow->mpc_map = mpext->mpc_map;
1042 subflow->map_csum_reqd = mpext->csum_reqd;
1043 subflow->map_csum_len = 0;
1044 subflow->map_data_csum = csum_unfold(mpext->csum);
1045
1046 /* Cfr RFC 8684 Section 3.3.0 */
1047 if (unlikely(subflow->map_csum_reqd != csum_reqd))
1048 return MAPPING_INVALID;
1049
1050 pr_debug("new map seq=%llu subflow_seq=%u data_len=%u csum=%d:%u",
1051 subflow->map_seq, subflow->map_subflow_seq,
1052 subflow->map_data_len, subflow->map_csum_reqd,
1053 subflow->map_data_csum);
1054
1055 validate_seq:
1056 /* we revalidate valid mapping on new skb, because we must ensure
1057 * the current skb is completely covered by the available mapping
1058 */
1059 if (!validate_mapping(ssk, skb)) {
1060 MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSTCPMISMATCH);
1061 return MAPPING_INVALID;
1062 }
1063
1064 skb_ext_del(skb, SKB_EXT_MPTCP);
1065
1066 validate_csum:
1067 return validate_data_csum(ssk, skb, csum_reqd);
1068 }
1069
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 28085 bytes --]
next prev parent reply other threads:[~2021-10-21 13:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 6:06 [PATCH mptcp-next] Squash to "mptcp: infinite mapping receiving" Geliang Tang
2021-10-21 6:16 ` Squash to "mptcp: infinite mapping receiving": Build Failure MPTCP CI
2021-10-21 6:43 ` Matthieu Baerts
2021-10-21 13:42 ` kernel test robot [this message]
2021-10-21 13:42 ` [PATCH mptcp-next] Squash to "mptcp: infinite mapping receiving" kernel test robot
2021-10-22 1:06 ` Mat Martineau
2021-10-22 16:10 ` Christoph Paasch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202110212124.LLGxLRSx-lkp@intel.com \
--to=lkp@intel.com \
--cc=geliang.tang@suse.com \
--cc=kbuild-all@lists.01.org \
--cc=llvm@lists.linux.dev \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.