| Message ID | 1604914417-24578-1-git-send-email-wenan.mao@linux.alibaba.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net,v2] net: Update window_clamp if SOCK_RCVBUF is set | expand |
| Context | Check | Description |
|---|---|---|
| jkicinski/patch_count | success | Link |
| jkicinski/cover_letter | success | Link |
| jkicinski/fixes_present | fail | Series targets non-next tree, but doesn't contain any Fixes tags |
| jkicinski/tree_selection | success | Clearly marked for net |
| jkicinski/subject_prefix | success | Link |
| jkicinski/source_inline | success | Was 0 now: 0 |
| jkicinski/verify_signedoff | success | Link |
| jkicinski/module_param | success | Was 0 now: 0 |
| jkicinski/build_32bit | success | Errors and warnings before: 2 this patch: 2 |
| jkicinski/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| jkicinski/verify_fixes | success | Link |
| jkicinski/checkpatch | warning | WARNING: line length of 87 exceeds 80 columns |
| jkicinski/build_allmodconfig_warn | success | Errors and warnings before: 2 this patch: 2 |
| jkicinski/header_inline | success | Link |
| jkicinski/stable | success | Stable not CCed |
On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > > When net.ipv4.tcp_syncookies=1 and syn flood is happened, > cookie_v4_check or cookie_v6_check tries to redo what > tcp_v4_send_synack or tcp_v6_send_synack did, > rsk_window_clamp will be changed if SOCK_RCVBUF is set, > which will make rcv_wscale is different, the client > still operates with initial window scale and can overshot > granted window, the client use the initial scale but local > server use new scale to advertise window value, and session > work abnormally. What is not working exactly ? Sending a 'big wscale' should not really matter, unless perhaps there is a buggy stack at the remote end ? > > Signed-off-by: Mao Wenan <wenan.mao@linux.alibaba.com> > --- > v2: fix for ipv6. > net/ipv4/syncookies.c | 4 ++++ > net/ipv6/syncookies.c | 5 +++++ > 2 files changed, 9 insertions(+) > > diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c > index 6ac473b..57ce317 100644 > --- a/net/ipv4/syncookies.c > +++ b/net/ipv4/syncookies.c > @@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb) > > /* Try to redo what tcp_v4_send_synack did. */ > req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW); > + /* limit the window selection if the user enforce a smaller rx buffer */ > + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && > + (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0)) > + req->rsk_window_clamp = tcp_full_space(sk); This seems not needed to me. We call tcp_select_initial_window() with tcp_full_space(sk) passed as the 2nd parameter. tcp_full_space(sk) will then apply : space = min(*window_clamp, space); Please cook a packetdrill test to demonstrate what you are seeing ?
在 2020/11/9 下午5:56, Eric Dumazet 写道: > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: >> >> When net.ipv4.tcp_syncookies=1 and syn flood is happened, >> cookie_v4_check or cookie_v6_check tries to redo what >> tcp_v4_send_synack or tcp_v6_send_synack did, >> rsk_window_clamp will be changed if SOCK_RCVBUF is set, >> which will make rcv_wscale is different, the client >> still operates with initial window scale and can overshot >> granted window, the client use the initial scale but local >> server use new scale to advertise window value, and session >> work abnormally. > > What is not working exactly ? > > Sending a 'big wscale' should not really matter, unless perhaps there > is a buggy stack at the remote end ? 1)in tcp_v4_send_synack, if SO_RCVBUF is set and tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to tcp_select_initial_window, rcv_wscale will be zero, and send to client, the client consider wscale is 0; 2)when ack is back from client, if there is no this patch, req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, wscale will be 7, this new rcv_wscale is no way to advertise to client. 3)if server send rcv_wind to client with window=63, it consider the real window is 63*2^7=8064, but client consider the server window is only 63*2^0=63, it can't send big packet to server, and the send-q of client is full. > >> >> Signed-off-by: Mao Wenan <wenan.mao@linux.alibaba.com> >> --- >> v2: fix for ipv6. >> net/ipv4/syncookies.c | 4 ++++ >> net/ipv6/syncookies.c | 5 +++++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c >> index 6ac473b..57ce317 100644 >> --- a/net/ipv4/syncookies.c >> +++ b/net/ipv4/syncookies.c >> @@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb) >> >> /* Try to redo what tcp_v4_send_synack did. */ >> req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW); >> + /* limit the window selection if the user enforce a smaller rx buffer */ >> + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && >> + (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0)) >> + req->rsk_window_clamp = tcp_full_space(sk); > > This seems not needed to me. > > We call tcp_select_initial_window() with tcp_full_space(sk) passed as > the 2nd parameter. > > tcp_full_space(sk) will then apply : > > space = min(*window_clamp, space); if cookie_v4_check pass window_clamp=0 to tcp_select_initial_window, it will set window_clamp to max value. (*window_clamp) = (U16_MAX << TCP_MAX_WSCALE); but space will fetch from sysctl_rmem_max and sysctl_tcp_rmem[2] which is also big value. space = max_t(u32, space, sock_net(sk)->ipv4.sysctl_tcp_rmem[2]); space = max_t(u32, space, sysctl_rmem_max); Then,space = min(*window_clamp, space) is a big value, lead wscale to 7, is different from tcp_v4_send_synack. > > Please cook a packetdrill test to demonstrate what you are seeing ? > I have real environment and reproduce this case, this patch can fix that, i will try to use packetdrill with syn cookies and syn flood happen.
在 2020/11/9 下午6:12, Mao Wenan 写道: > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: >> On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan >> <wenan.mao@linux.alibaba.com> wrote: >>> >>> When net.ipv4.tcp_syncookies=1 and syn flood is happened, >>> cookie_v4_check or cookie_v6_check tries to redo what >>> tcp_v4_send_synack or tcp_v6_send_synack did, >>> rsk_window_clamp will be changed if SOCK_RCVBUF is set, >>> which will make rcv_wscale is different, the client >>> still operates with initial window scale and can overshot >>> granted window, the client use the initial scale but local >>> server use new scale to advertise window value, and session >>> work abnormally. >> >> What is not working exactly ? >> >> Sending a 'big wscale' should not really matter, unless perhaps there >> is a buggy stack at the remote end ? > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > the client consider wscale is 0; > 2)when ack is back from client, if there is no this patch, > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > wscale will be 7, this new rcv_wscale is no way to advertise to client. > 3)if server send rcv_wind to client with window=63, it consider the real > window is 63*2^7=8064, but client consider the server window is only > 63*2^0=63, it can't send big packet to server, and the send-q of client > is full. > > >> >>> >>> Signed-off-by: Mao Wenan <wenan.mao@linux.alibaba.com> >>> --- >>> v2: fix for ipv6. >>> net/ipv4/syncookies.c | 4 ++++ >>> net/ipv6/syncookies.c | 5 +++++ >>> 2 files changed, 9 insertions(+) >>> >>> diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c >>> index 6ac473b..57ce317 100644 >>> --- a/net/ipv4/syncookies.c >>> +++ b/net/ipv4/syncookies.c >>> @@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, >>> struct sk_buff *skb) >>> >>> /* Try to redo what tcp_v4_send_synack did. */ >>> req->rsk_window_clamp = tp->window_clamp ? >>> :dst_metric(&rt->dst, RTAX_WINDOW); >>> + /* limit the window selection if the user enforce a smaller >>> rx buffer */ >>> + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && >>> + (req->rsk_window_clamp > tcp_full_space(sk) || >>> req->rsk_window_clamp == 0)) >>> + req->rsk_window_clamp = tcp_full_space(sk); >> >> This seems not needed to me. >> >> We call tcp_select_initial_window() with tcp_full_space(sk) passed as >> the 2nd parameter. >> >> tcp_full_space(sk) will then apply : >> >> space = min(*window_clamp, space); > > if cookie_v4_check pass window_clamp=0 to tcp_select_initial_window, it > will set window_clamp to max value. > (*window_clamp) = (U16_MAX << TCP_MAX_WSCALE); window_clamp=0 is from req->rsk_window_clamp = tp->window_clamp ? :dst_metric(dst, RTAX_WINDOW); and if SO_RCVBUF is set and equal to 65535,req->rsk_window_clamp will be 65535. req->rsk_window_clamp = tcp_full_space(sk); > > but space will fetch from sysctl_rmem_max and sysctl_tcp_rmem[2] which > is also big value. > space = max_t(u32, space, sock_net(sk)->ipv4.sysctl_tcp_rmem[2]); > space = max_t(u32, space, sysctl_rmem_max); > > Then,space = min(*window_clamp, space) is a big value, lead wscale to 7, > is different from tcp_v4_send_synack. > > >> >> Please cook a packetdrill test to demonstrate what you are seeing ? >> > I have real environment and reproduce this case, this patch can fix > that, i will try to use packetdrill with syn cookies and syn flood happen.
On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > >> > >> When net.ipv4.tcp_syncookies=1 and syn flood is happened, > >> cookie_v4_check or cookie_v6_check tries to redo what > >> tcp_v4_send_synack or tcp_v6_send_synack did, > >> rsk_window_clamp will be changed if SOCK_RCVBUF is set, > >> which will make rcv_wscale is different, the client > >> still operates with initial window scale and can overshot > >> granted window, the client use the initial scale but local > >> server use new scale to advertise window value, and session > >> work abnormally. > > > > What is not working exactly ? > > > > Sending a 'big wscale' should not really matter, unless perhaps there > > is a buggy stack at the remote end ? > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > the client consider wscale is 0; > 2)when ack is back from client, if there is no this patch, > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > wscale will be 7, this new rcv_wscale is no way to advertise to client. > 3)if server send rcv_wind to client with window=63, it consider the real > window is 63*2^7=8064, but client consider the server window is only > 63*2^0=63, it can't send big packet to server, and the send-q of client > is full. > I see, please change your patches so that tcp_full_space() is used _once_ listener sk_rcvbuf can change under us. I really have no idea how window can be set to 63, so please send us the packetdrill test once you have it.
Packetdrill test would be :
// Force syncookies
`sysctl -q net.ipv4.tcp_syncookies=2`
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [2048], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 32792 <mss 1000,sackOK,TS val 100 ecr 0,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 4000 ecr 100,nop,wscale 0>
+.1 < . 1:1(0) ack 1 win 1024 <nop,nop,TS val 200 ecr 4000>
+0 accept(3, ..., ...) = 4
+0 %{ assert tcpi_snd_wscale == 0, tcpi_snd_wscale }%
On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote:
> >
> >
> >
> > 在 2020/11/9 下午5:56, Eric Dumazet 写道:
> > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote:
> > >>
> > >> When net.ipv4.tcp_syncookies=1 and syn flood is happened,
> > >> cookie_v4_check or cookie_v6_check tries to redo what
> > >> tcp_v4_send_synack or tcp_v6_send_synack did,
> > >> rsk_window_clamp will be changed if SOCK_RCVBUF is set,
> > >> which will make rcv_wscale is different, the client
> > >> still operates with initial window scale and can overshot
> > >> granted window, the client use the initial scale but local
> > >> server use new scale to advertise window value, and session
> > >> work abnormally.
> > >
> > > What is not working exactly ?
> > >
> > > Sending a 'big wscale' should not really matter, unless perhaps there
> > > is a buggy stack at the remote end ?
> > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and
> > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to
> > tcp_select_initial_window, rcv_wscale will be zero, and send to client,
> > the client consider wscale is 0;
> > 2)when ack is back from client, if there is no this patch,
> > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window,
> > wscale will be 7, this new rcv_wscale is no way to advertise to client.
> > 3)if server send rcv_wind to client with window=63, it consider the real
> > window is 63*2^7=8064, but client consider the server window is only
> > 63*2^0=63, it can't send big packet to server, and the send-q of client
> > is full.
> >
>
> I see, please change your patches so that tcp_full_space() is used _once_
>
> listener sk_rcvbuf can change under us.
>
> I really have no idea how window can be set to 63, so please send us
> the packetdrill test once you have it.
On Mon, Nov 9, 2020 at 12:41 PM Eric Dumazet <edumazet@google.com> wrote: > > Packetdrill test would be : > > // Force syncookies > `sysctl -q net.ipv4.tcp_syncookies=2` > > 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 > +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 > +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [2048], 4) = 0 > +0 bind(3, ..., ...) = 0 > +0 listen(3, 1) = 0 > > +0 < S 0:0(0) win 32792 <mss 1000,sackOK,TS val 100 ecr 0,nop,wscale 7> > +0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 4000 ecr 100,nop,wscale 0> > +.1 < . 1:1(0) ack 1 win 1024 <nop,nop,TS val 200 ecr 4000> > +0 accept(3, ..., ...) = 4 > +0 %{ assert tcpi_snd_wscale == 0, tcpi_snd_wscale }% > Also, please add to your next submission an appropriate Fixes: tag : Fixes: e88c64f0a425 ("tcp: allow effective reduction of TCP's rcv-buffer via setsockopt") > On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet <edumazet@google.com> wrote: > > > > On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > > > > > > > > > > > > 在 2020/11/9 下午5:56, Eric Dumazet 写道: > > > > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: > > > >> > > > >> When net.ipv4.tcp_syncookies=1 and syn flood is happened, > > > >> cookie_v4_check or cookie_v6_check tries to redo what > > > >> tcp_v4_send_synack or tcp_v6_send_synack did, > > > >> rsk_window_clamp will be changed if SOCK_RCVBUF is set, > > > >> which will make rcv_wscale is different, the client > > > >> still operates with initial window scale and can overshot > > > >> granted window, the client use the initial scale but local > > > >> server use new scale to advertise window value, and session > > > >> work abnormally. > > > > > > > > What is not working exactly ? > > > > > > > > Sending a 'big wscale' should not really matter, unless perhaps there > > > > is a buggy stack at the remote end ? > > > 1)in tcp_v4_send_synack, if SO_RCVBUF is set and > > > tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to > > > tcp_select_initial_window, rcv_wscale will be zero, and send to client, > > > the client consider wscale is 0; > > > 2)when ack is back from client, if there is no this patch, > > > req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, > > > wscale will be 7, this new rcv_wscale is no way to advertise to client. > > > 3)if server send rcv_wind to client with window=63, it consider the real > > > window is 63*2^7=8064, but client consider the server window is only > > > 63*2^0=63, it can't send big packet to server, and the send-q of client > > > is full. > > > > > > > I see, please change your patches so that tcp_full_space() is used _once_ > > > > listener sk_rcvbuf can change under us. > > > > I really have no idea how window can be set to 63, so please send us > > the packetdrill test once you have it.
在 2020/11/9 下午10:01, Eric Dumazet 写道: > On Mon, Nov 9, 2020 at 12:41 PM Eric Dumazet <edumazet@google.com> wrote: >> >> Packetdrill test would be : >> >> // Force syncookies >> `sysctl -q net.ipv4.tcp_syncookies=2` >> >> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 >> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 >> +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [2048], 4) = 0 >> +0 bind(3, ..., ...) = 0 >> +0 listen(3, 1) = 0 >> >> +0 < S 0:0(0) win 32792 <mss 1000,sackOK,TS val 100 ecr 0,nop,wscale 7> >> +0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 4000 ecr 100,nop,wscale 0> >> +.1 < . 1:1(0) ack 1 win 1024 <nop,nop,TS val 200 ecr 4000> >> +0 accept(3, ..., ...) = 4 >> +0 %{ assert tcpi_snd_wscale == 0, tcpi_snd_wscale }% >> > > Also, please add to your next submission an appropriate Fixes: tag : > > Fixes: e88c64f0a425 ("tcp: allow effective reduction of TCP's > rcv-buffer via setsockopt") OK, thanks, I can reproduce wscale=0 with your packetdrill, and I will send v3 with the fixes tag. > >> On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet <edumazet@google.com> wrote: >>> >>> On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: >>>> >>>> >>>> >>>> 在 2020/11/9 下午5:56, Eric Dumazet 写道: >>>>> On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan <wenan.mao@linux.alibaba.com> wrote: >>>>>> >>>>>> When net.ipv4.tcp_syncookies=1 and syn flood is happened, >>>>>> cookie_v4_check or cookie_v6_check tries to redo what >>>>>> tcp_v4_send_synack or tcp_v6_send_synack did, >>>>>> rsk_window_clamp will be changed if SOCK_RCVBUF is set, >>>>>> which will make rcv_wscale is different, the client >>>>>> still operates with initial window scale and can overshot >>>>>> granted window, the client use the initial scale but local >>>>>> server use new scale to advertise window value, and session >>>>>> work abnormally. >>>>> >>>>> What is not working exactly ? >>>>> >>>>> Sending a 'big wscale' should not really matter, unless perhaps there >>>>> is a buggy stack at the remote end ? >>>> 1)in tcp_v4_send_synack, if SO_RCVBUF is set and >>>> tcp_full_space(sk)=65535, pass req->rsk_window_clamp=65535 to >>>> tcp_select_initial_window, rcv_wscale will be zero, and send to client, >>>> the client consider wscale is 0; >>>> 2)when ack is back from client, if there is no this patch, >>>> req->rsk_window_clamp is 0, and pass to tcp_select_initial_window, >>>> wscale will be 7, this new rcv_wscale is no way to advertise to client. >>>> 3)if server send rcv_wind to client with window=63, it consider the real >>>> window is 63*2^7=8064, but client consider the server window is only >>>> 63*2^0=63, it can't send big packet to server, and the send-q of client >>>> is full. >>>> >>> >>> I see, please change your patches so that tcp_full_space() is used _once_ >>> >>> listener sk_rcvbuf can change under us. >>> >>> I really have no idea how window can be set to 63, so please send us >>> the packetdrill test once you have it.
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c index 6ac473b..57ce317 100644 --- a/net/ipv4/syncookies.c +++ b/net/ipv4/syncookies.c @@ -427,6 +427,10 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb) /* Try to redo what tcp_v4_send_synack did. */ req->rsk_window_clamp = tp->window_clamp ? :dst_metric(&rt->dst, RTAX_WINDOW); + /* limit the window selection if the user enforce a smaller rx buffer */ + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && + (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0)) + req->rsk_window_clamp = tcp_full_space(sk); tcp_select_initial_window(sk, tcp_full_space(sk), req->mss, &req->rsk_rcv_wnd, &req->rsk_window_clamp, diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c index e796a64..c041360 100644 --- a/net/ipv6/syncookies.c +++ b/net/ipv6/syncookies.c @@ -241,6 +241,11 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb) } req->rsk_window_clamp = tp->window_clamp ? :dst_metric(dst, RTAX_WINDOW); + /* limit the window selection if the user enforce a smaller rx buffer */ + if (sk->sk_userlocks & SOCK_RCVBUF_LOCK && + (req->rsk_window_clamp > tcp_full_space(sk) || req->rsk_window_clamp == 0)) + req->rsk_window_clamp = tcp_full_space(sk); + tcp_select_initial_window(sk, tcp_full_space(sk), req->mss, &req->rsk_rcv_wnd, &req->rsk_window_clamp, ireq->wscale_ok, &rcv_wscale,
When net.ipv4.tcp_syncookies=1 and syn flood is happened, cookie_v4_check or cookie_v6_check tries to redo what tcp_v4_send_synack or tcp_v6_send_synack did, rsk_window_clamp will be changed if SOCK_RCVBUF is set, which will make rcv_wscale is different, the client still operates with initial window scale and can overshot granted window, the client use the initial scale but local server use new scale to advertise window value, and session work abnormally. Signed-off-by: Mao Wenan <wenan.mao@linux.alibaba.com> --- v2: fix for ipv6. net/ipv4/syncookies.c | 4 ++++ net/ipv6/syncookies.c | 5 +++++ 2 files changed, 9 insertions(+)