All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.