Message ID | 20210824071926.68019-1-benbjiang@gmail.com (mailing list archive) |
---|---|
State | Awaiting Upstream |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | ipv4/mptcp: fix divide error | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
Hi Jiang, On 24/08/2021 09:19, Jiang Biao wrote: (...) > There is a fix divide error reported, > divide error: 0000 [#1] PREEMPT SMP KASAN > RIP: 0010:tcp_tso_autosize build/../net/ipv4/tcp_output.c:1975 [inline] > RIP: 0010:tcp_tso_segs+0x14f/0x250 build/../net/ipv4/tcp_output.c:1992 Thank you for this patch and validating MPTCP on your side! This issue is actively tracked on our Github project [1] and a patch is already in our tree [2] but still under validation. > It's introduced by non-initialized info->mss_now in __mptcp_push_pending. > Fix it by adding protection in mptcp_push_release. Indeed, you are right, info->mss_now can be set to 0 in some cases but that's not normal. Instead of adding a protection here, we preferred fixing the root cause, see [2]. Do not hesitate to have a look at the other patch and comment there if you don't agree with this version. Except if [2] is difficult to backport, I think we don't need your extra protection. WDYT? Cheers, Matt [1] https://github.com/multipath-tcp/mptcp_net-next/issues/219 [2] https://patchwork.kernel.org/project/mptcp/patch/286de8f451b32f60e75d3b8bcc4df515e186b930.1629481305.git.pabeni@redhat.com/
Hi, On Tue, 24 Aug 2021 at 15:36, Matthieu Baerts <matthieu.baerts@tessares.net> wrote: > > Hi Jiang, > > On 24/08/2021 09:19, Jiang Biao wrote: > > (...) > > > There is a fix divide error reported, > > divide error: 0000 [#1] PREEMPT SMP KASAN > > RIP: 0010:tcp_tso_autosize build/../net/ipv4/tcp_output.c:1975 [inline] > > RIP: 0010:tcp_tso_segs+0x14f/0x250 build/../net/ipv4/tcp_output.c:1992 > > Thank you for this patch and validating MPTCP on your side! > > This issue is actively tracked on our Github project [1] and a patch is > already in our tree [2] but still under validation. > > It's introduced by non-initialized info->mss_now in __mptcp_push_pending. > > Fix it by adding protection in mptcp_push_release. > > Indeed, you are right, info->mss_now can be set to 0 in some cases but > that's not normal. > > Instead of adding a protection here, we preferred fixing the root cause, > see [2]. Do not hesitate to have a look at the other patch and comment > there if you don't agree with this version. > Except if [2] is difficult to backport, I think we don't need your extra > protection. WDYT? > Agreed, fixing the root cause is much better. Thanks for the reply. Regards, Jiang
On Tue, 24 Aug 2021, Jiang Biao wrote: > Hi, > > On Tue, 24 Aug 2021 at 15:36, Matthieu Baerts > <matthieu.baerts@tessares.net> wrote: >> >> Hi Jiang, >> >> On 24/08/2021 09:19, Jiang Biao wrote: >> >> (...) >> >>> There is a fix divide error reported, >>> divide error: 0000 [#1] PREEMPT SMP KASAN >>> RIP: 0010:tcp_tso_autosize build/../net/ipv4/tcp_output.c:1975 [inline] >>> RIP: 0010:tcp_tso_segs+0x14f/0x250 build/../net/ipv4/tcp_output.c:1992 >> >> Thank you for this patch and validating MPTCP on your side! >> >> This issue is actively tracked on our Github project [1] and a patch is >> already in our tree [2] but still under validation. >>> It's introduced by non-initialized info->mss_now in __mptcp_push_pending. >>> Fix it by adding protection in mptcp_push_release. >> >> Indeed, you are right, info->mss_now can be set to 0 in some cases but >> that's not normal. >> >> Instead of adding a protection here, we preferred fixing the root cause, >> see [2]. Do not hesitate to have a look at the other patch and comment >> there if you don't agree with this version. >> Except if [2] is difficult to backport, I think we don't need your extra >> protection. WDYT? >> > Agreed, fixing the root cause is much better. > Thanks for the reply. > Hi Jiang - Could you try cherry-picking this commit to see if it eliminates the error in your system? https://github.com/multipath-tcp/mptcp_net-next/commit/9ef5aea5a794f4a369e26ed816e9c80cdc5a5f86 Thanks! -- Mat Martineau Intel
On Thu, 26 Aug 2021 at 01:56, Mat Martineau <mathew.j.martineau@linux.intel.com> wrote: > > > On Tue, 24 Aug 2021, Jiang Biao wrote: > > > Hi, > > > > On Tue, 24 Aug 2021 at 15:36, Matthieu Baerts > > <matthieu.baerts@tessares.net> wrote: > >> > >> Hi Jiang, > >> > >> On 24/08/2021 09:19, Jiang Biao wrote: > >> > >> (...) > >> > >>> There is a fix divide error reported, > >>> divide error: 0000 [#1] PREEMPT SMP KASAN > >>> RIP: 0010:tcp_tso_autosize build/../net/ipv4/tcp_output.c:1975 [inline] > >>> RIP: 0010:tcp_tso_segs+0x14f/0x250 build/../net/ipv4/tcp_output.c:1992 > >> > >> Thank you for this patch and validating MPTCP on your side! > >> > >> This issue is actively tracked on our Github project [1] and a patch is > >> already in our tree [2] but still under validation. > >>> It's introduced by non-initialized info->mss_now in __mptcp_push_pending. > >>> Fix it by adding protection in mptcp_push_release. > >> > >> Indeed, you are right, info->mss_now can be set to 0 in some cases but > >> that's not normal. > >> > >> Instead of adding a protection here, we preferred fixing the root cause, > >> see [2]. Do not hesitate to have a look at the other patch and comment > >> there if you don't agree with this version. > >> Except if [2] is difficult to backport, I think we don't need your extra > >> protection. WDYT? > >> > > Agreed, fixing the root cause is much better. > > Thanks for the reply. > > > > Hi Jiang - > > Could you try cherry-picking this commit to see if it eliminates the error > in your system? > > https://github.com/multipath-tcp/mptcp_net-next/commit/9ef5aea5a794f4a369e26ed816e9c80cdc5a5f86 > ok, I'll try and give you feedback. Regards, Jiang
On Thu, 26 Aug 2021 at 01:56, Mat Martineau <mathew.j.martineau@linux.intel.com> wrote: > > > On Tue, 24 Aug 2021, Jiang Biao wrote: > > > Hi, > > > > On Tue, 24 Aug 2021 at 15:36, Matthieu Baerts > > <matthieu.baerts@tessares.net> wrote: > >> > >> Hi Jiang, > >> > >> On 24/08/2021 09:19, Jiang Biao wrote: > >> > >> (...) > >> > >>> There is a fix divide error reported, > >>> divide error: 0000 [#1] PREEMPT SMP KASAN > >>> RIP: 0010:tcp_tso_autosize build/../net/ipv4/tcp_output.c:1975 [inline] > >>> RIP: 0010:tcp_tso_segs+0x14f/0x250 build/../net/ipv4/tcp_output.c:1992 > >> > >> Thank you for this patch and validating MPTCP on your side! > >> > >> This issue is actively tracked on our Github project [1] and a patch is > >> already in our tree [2] but still under validation. > >>> It's introduced by non-initialized info->mss_now in __mptcp_push_pending. > >>> Fix it by adding protection in mptcp_push_release. > >> > >> Indeed, you are right, info->mss_now can be set to 0 in some cases but > >> that's not normal. > >> > >> Instead of adding a protection here, we preferred fixing the root cause, > >> see [2]. Do not hesitate to have a look at the other patch and comment > >> there if you don't agree with this version. > >> Except if [2] is difficult to backport, I think we don't need your extra > >> protection. WDYT? > >> > > Agreed, fixing the root cause is much better. > > Thanks for the reply. > > > > Hi Jiang - > > Could you try cherry-picking this commit to see if it eliminates the error > in your system? > > https://github.com/multipath-tcp/mptcp_net-next/commit/9ef5aea5a794f4a369e26ed816e9c80cdc5a5f86 > Errors' gone with the patch.:) Regards, Jiang > > Thanks! > > -- > Mat Martineau > Intel
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index a88924947815..bfb3cd85bf19 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1433,8 +1433,10 @@ static struct sock *mptcp_subflow_get_send(struct mptcp_sock *msk) static void mptcp_push_release(struct sock *sk, struct sock *ssk, struct mptcp_sendmsg_info *info) { + int mss_now = info->mss_now ? info->mss_now : tcp_current_mss(ssk); + mptcp_set_timeout(sk, ssk); - tcp_push(ssk, 0, info->mss_now, tcp_sk(ssk)->nonagle, info->size_goal); + tcp_push(ssk, 0, mss_now, tcp_sk(ssk)->nonagle, info->size_goal); release_sock(ssk); }