Re:Re: Re: Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS

At 2018-05-11 22:56:04, "Willem de Bruijn" <willemdebruijn.ker...@gmail.com> wrote: >On Fri, May 11, 2018 at 10:44 AM, Gao Feng <gfree.w...@vip.163.com> wrote: >> At 2018-05-11 21:23:55, "Willem de Bruijn" <willemdebruijn.ker...@gmail.com> >>

Re:Re: Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS

At 2018-05-11 21:23:55, "Willem de Bruijn" <willemdebruijn.ker...@gmail.com> wrote: >On Fri, May 11, 2018 at 2:20 AM, Gao Feng <gfree.w...@vip.163.com> wrote: >> At 2018-05-11 11:54:55, "Willem de Bruijn" <willemdebruijn.ker...@gmail.com> >>

Re:Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS

At 2018-05-11 11:54:55, "Willem de Bruijn" <willemdebruijn.ker...@gmail.com> wrote: >On Thu, May 10, 2018 at 4:28 AM, <gfree.w...@vip.163.com> wrote: >> From: Gao Feng <gfree.w...@vip.163.com> >> >> The skb flow limit is implemented fo

Re:Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS

At 2018-05-11 08:55:47, "Eric Dumazet" eric.duma...@gmail.com wrote: On 05/10/2018 05:18 PM, Gao Feng wrote: At 2018-05-10 21:02:55, "Eric Dumazet" eric.duma...@gmail.com wrote: On 05/10/2018 01:28 AM, gfree.w...@vip.163.com wrote: From: Gao Feng gfree.w...@vip.16

Re:Re: [PATCH net] net: Correct wrong skb_flow_limit check when enable RPS

At 2018-05-10 21:02:55, "Eric Dumazet" <eric.duma...@gmail.com> wrote: > > >On 05/10/2018 01:28 AM, gfree.w...@vip.163.com wrote: >> From: Gao Feng <gfree.w...@vip.163.com> >> >> The skb flow limit is implemented for each CPU independently. In

Re:Re: [PATCH net] net: Fix one possible memleak in ip_setup_cork

At 2018-04-17 05:18:25, "Eric Dumazet" <eric.duma...@gmail.com> wrote: > > >On 04/16/2018 09:58 AM, David Miller wrote: >> From: gfree.w...@vip.163.com >> Date: Mon, 16 Apr 2018 10:16:45 +0800 >> >>> From: Gao Feng <gfree.w...@vip.163.com&

Re:Re: [PATCH net] net: Fix one possible memleak in ip_setup_cork

At 2018-04-16 10:55:56, "David Miller" <da...@davemloft.net> wrote: >From: gfree.w...@vip.163.com >Date: Mon, 16 Apr 2018 10:16:45 +0800 > >> From: Gao Feng <gfree.w...@vip.163.com> >> >> It would allocate memory in this function when the cork->

Re:Re: [PATCH net-next ] net: Remove useless function skb_header_release

>On Thu, 2017-09-21 at 12:39 +0800, gfree.w...@vip.163.com wrote: >> From: Gao Feng <gfree.w...@vip.163.com> >> >> There is no one which would invokes the function skb_header_release. >> So just remove it now. > >This in incomplete. >There are other ref

Re:Re: [PATCH net-next] net: sched: Add the invalid handle check in qdisc_class_find

At 2017-08-22 03:58:03, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Mon, Aug 21, 2017 at 10:47 AM, David Miller <da...@davemloft.net> wrote: >> From: gfree.w...@vip.163.com >> Date: Fri, 18 Aug 2017 15:23:24 +0800 >> >>> From: Gao Feng <

Re:Re: [PATCH net-next 1/1] driver: pptp: Remove unnecessary statements in pptp_sock_destruct

At 2017-08-10 02:08:30, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Wed, Aug 9, 2017 at 8:57 AM, <gfree.w...@vip.163.com> wrote: >> From: Gao Feng <gfree.w...@vip.163.com> >> >> In the commit ddab82821fa6 ("ppp: Fix a

Re:Re: Re:Re: Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-10 05:00:19, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng <gfree.w...@vip.163.com> wrote: >> Hi Cong, >> >> Actually I have one question about the SOCK_RCU_FREE. >> I don't think it could r

Re:Re: Re: Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-10 02:18:44, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Tue, Aug 8, 2017 at 10:13 PM, Gao Feng <gfree.w...@vip.163.com> wrote: >> Maybe I didn't show my explanation clearly. >> I think it won't happen as I mentioned in the last email

Re:Re:Re: Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-09 13:13:53, "Gao Feng" <gfree.w...@vip.163.com> wrote: >At 2017-08-09 03:45:53, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >>On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng <gfree.w...@vip.163.com> wrote: >>> >>> Sorry, I

Re:Re: Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-09 03:45:53, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng <gfree.w...@vip.163.com> wrote: >> >> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful? > >I already told you

Re:Re: [PATCH net] ppp: fix xmit recursion detection on ppp channels

At 2017-08-08 21:58:27, "Guillaume Nault" <g.na...@alphalink.fr> wrote: >On Tue, Aug 08, 2017 at 09:16:33PM +0800, Gao Feng wrote: >> At 2017-08-08 17:43:24, "Guillaume Nault" <g.na...@alphalink.fr> wrote: >> >--- a/drivers/net/ppp/ppp

Re:[PATCH net] ppp: fix xmit recursion detection on ppp channels

At 2017-08-08 17:43:24, "Guillaume Nault" wrote: >Commit e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp >devices") dropped the xmit_recursion counter incrementation in >ppp_channel_push() and relied on ppp_xmit_process() for this task. >But

Re:Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-08 01:17:02, "Cong Wang" <xiyou.wangc...@gmail.com> wrote: >On Sun, Aug 6, 2017 at 6:32 PM, Gao Feng <gfree.w...@vip.163.com> wrote: >> I think the RCU should be supposed to avoid the race between del_chan and >> lookup_chan. > >More prec

Re:Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

At 2017-08-03 01:13:36, "Cong Wang" wrote: >Hi, Gao > >On Tue, Aug 1, 2017 at 1:39 PM, Cong Wang wrote: >> From my understanding, this RCU is supposed to protect the pppox_sock >> pointers in 'callid_sock' which could be NULL'ed in del_chan().

Re:Re: [net PATCH] net: sched: Fix one possible panic when no destroy callback

rote: >> >> On Mon, Jun 26, 2017 at 6:35 PM, <gfree.w...@vip.163.com> wrote: >> >> > From: Gao Feng <gfree.w...@vip.163.com> >> >> > >> >> > When qdisc fail to init, qdisc_create would invoke the destroy callback >> >> &

Re:Re: [PATCH net-next] net: rps: Add the rfs_needed check when record flow hash

Hi David & Eric, At 2017-05-26 01:11:41, "David Miller" wrote: >From: gfree.w...@vip.163.com >Date: Wed, 24 May 2017 15:35:59 +0800 > >> >> +static inline void sock_rps_record_flow_hash(__u32 hash) >> +{ >> +#ifdef CONFIG_RPS >> +if (static_key_false(_needed)) >> +

Re:Re: [PATCH net-next] net: rfs: Don't reset RFS entries when nothing changed

At 2017-05-23 11:02:20, "David Miller" <da...@davemloft.net> wrote: >From: gfree.w...@vip.163.com >Date: Tue, 23 May 2017 08:45:11 +0800 > >> From: Gao Feng <gfree.w...@vip.163.com> >> >> When the new RFS table size specified by sysctl equals the

Re:Re: [PATCH net v2] driver: vrf: Fix one possible use-after-free issue

At 2017-05-10 02:37:36, "David Miller" wrote: >From: gfree.w...@vip.163.com >Date: Tue, 9 May 2017 18:27:33 +0800 > >> @@ -989,6 +989,7 @@ static u32 vrf_fib_table(const struct net_device *dev) >> >> static int vrf_rcv_finish(struct net *net, struct sock *sk, struct

Re:Re: [PATCH net] driver: vrf: Fix one possible use-after-free issue

At 2017-05-09 17:21:02, "Florian Westphal" wrote: >gfree.w...@vip.163.com wrote: >> When one netfilter rule or hook stoles the skb and return NF_STOLEN, >> it means the skb is taken by the rule, and other modules should not >> touch this skb ever. Maybe

RE: [PATCH net v4 00/12] Fix possbile memleaks when fail to register_netdevice

Hi David, > From: David Miller [mailto:da...@davemloft.net] > From: gfree.w...@foxmail.com > Date: Tue, 2 May 2017 13:58:42 +0800 > > > These following drivers allocate kinds of resources in its ndo_init > > func, free some of them or all in the destructor func. Then there is > > one memleak

RE: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice

> From: Xin Long [mailto:lucien@gmail.com] > Sent: Wednesday, May 3, 2017 7:26 PM > On Wed, May 3, 2017 at 2:37 PM, Gao Feng <gfree.w...@foxmail.com> wrote: > >> From: Xin Long [mailto:lucien@gmail.com] > >> Sent: Wednesday, May 3, 2017 1:38 PM > >

RE: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice

> From: Xin Long [mailto:lucien@gmail.com] > Sent: Wednesday, May 3, 2017 1:38 PM > On Wed, May 3, 2017 at 10:07 AM, Gao Feng <gfree.w...@foxmail.com> > wrote: > >> From: netdev-ow...@vger.kernel.org > >> [mailto:netdev-ow...@vger.kernel.org] > >&g

RE: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice

> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Xin Long > Sent: Wednesday, May 3, 2017 12:59 AM > On Tue, May 2, 2017 at 7:03 PM, Gao Feng <gfree.w...@vip.163.com> wrote: > >> From: Xin Long [mailto:lucien@gmail.com] > &

RE: [PATCH net v4 00/12] Fix possbile memleaks when fail to register_netdevice

Hi David > From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, May 3, 2017 3:30 AM > From: gfree.w...@foxmail.com > Date: Tue, 2 May 2017 13:58:42 +0800 > [...] > > > > This solution doesn't only make sure free all resources in any case, > > but also follows the original desgin

RE: [PATCH net v4 00/12] Fix possbile memleaks when fail to register_netdevice

Hi all, > From: gfree.w...@foxmail.com [mailto:gfree.w...@foxmail.com] > Sent: Tuesday, May 2, 2017 1:59 PM > drivers/net/dummy.c | 14 +++--- > drivers/net/ifb.c | 33 +++-- > drivers/net/loopback.c | 15 ++- >

RE: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice

> From: Xin Long [mailto:lucien@gmail.com] > Sent: Tuesday, May 2, 2017 3:56 PM > On Sat, Apr 29, 2017 at 11:51 AM, <gfree.w...@foxmail.com> wrote: > > From: Gao Feng <gfree.w...@foxmail.com> [...] > > -static void veth_dev_free(struct net_device *dev) >

RE: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice

> From: David Ahern [mailto:d...@cumulusnetworks.com] > Sent: Monday, May 1, 2017 11:08 PM > On 4/28/17 9:51 PM, gfree.w...@foxmail.com wrote: > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c index > > 8c39d6d..418376a 100644 > > --- a/drivers/net/veth.c > > +++ b/drivers/net/veth.c > > @@

RE: [PATCH net v3] driver: dummy: Fix one possbile memleak when fail to register_netdevice

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, May 1, 2017 10:54 AM > > Please, Gao, submit this as a proper, numbered, patch series with a proper > header posting. > > That way you can explain why you took this strategy to fix this problem, > compared to your original

RE: [PATCH net v2] net: dev: Fix possible memleaks when fail to register_netdevice

> From: David Ahern [mailto:dsah...@gmail.com] > Sent: Friday, April 28, 2017 11:23 PM > On 4/27/17 9:19 PM, gfree.w...@foxmail.com wrote: > > drivers/net/dummy.c | 14 +++--- > > drivers/net/ifb.c | 33 +++-- > > drivers/net/loopback.c | 15

RE: [PATCH net] driver/net: Fix possible memleaks when fail to register_netdevice

> From: Gao Feng [mailto:gfree.w...@foxmail.com] > Sent: Thursday, April 27, 2017 4:33 PM > > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > > Sent: Thursday, April 27, 2017 4:16 PM On Tue, Apr 25, 2017 at > > 08:01:50PM +0800, gfree.w...@foxmail.com wrote:

RE: [PATCH net] driver/net: Fix possible memleaks when fail to register_netdevice

> From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Thursday, April 27, 2017 4:16 PM > On Tue, Apr 25, 2017 at 08:01:50PM +0800, gfree.w...@foxmail.com wrote: > > From: Gao Feng <f...@ikuai8.com> > > [...] > > This has the potential

RE: [B.A.T.M.A.N.] [PATCH net] net: batman-adv: Fix possible memleaks when fail to register_netdevice

> From: Sven Eckelmann [mailto:s...@narfation.org] > Sent: Wednesday, April 26, 2017 3:17 PM > On Mittwoch, 26. April 2017 14:44:24 CEST Gao Feng wrote: > [...] > > I get it now, thanks. > [...] > > BTW, I think although the batadv_softif_create is legacy, we should >

RE: [B.A.T.M.A.N.] [PATCH net] net: batman-adv: Fix possible memleaks when fail to register_netdevice

> From: Sven Eckelmann [mailto:s...@narfation.org] > Sent: Wednesday, April 26, 2017 1:58 PM > On Mittwoch, 26. April 2017 08:41:30 CEST Gao Feng wrote: > > On Dienstag, 25. April 2017 20:03:20 CEST gfree.w...@foxmail.com wrote: > > > From: Gao Feng <f...@ikuai8.com>

RE: [B.A.T.M.A.N.] [PATCH net] net: batman-adv: Fix possible memleaks when fail to register_netdevice

> From: Sven Eckelmann [mailto:s...@narfation.org] > Sent: Tuesday, April 25, 2017 9:53 PM > On Dienstag, 25. April 2017 20:03:20 CEST gfree.w...@foxmail.com wrote: > > From: Gao Feng <f...@ikuai8.com> > > > > Because the func batadv_softif_init_late allocat

RE: [PATCH net] driver/net: Fix possible memleaks when fail to register_netdevice

> From: Gao Feng <f...@ikuai8.com> > > These drivers allocate kinds of resources in init routine, and free some > resources in the destructor of net_device. It may cause memleak when some > errors happen after register_netdevice invokes the init callback. Because only

RE: [PATCH net 1/1] net: tcp: Increase TCPABORTONLINGER when send RST by linger2 in keepalive timer

uai8.com > Subject: Re: [PATCH net 1/1] net: tcp: Increase TCPABORTONLINGER when send > RST by linger2 in keepalive timer > > From: gfree.w...@foxmail.com > Date: Sun, 9 Apr 2017 20:44:41 +0800 > > > From: Gao Feng <f...@ikuai8.com> > > > > It s

RE: [PATCH net-next v2 1/1] net: ipv4: Refine the ipv4_default_advmss

er.kernel.org > Cc: Gao Feng <f...@ikuai8.com> > Subject: Re: [PATCH net-next v2 1/1] net: ipv4: Refine the ipv4_default_advmss > > On Wed, 2017-04-12 at 10:32 +0800, gfree.w...@foxmail.com wrote: > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > > more tr

RE: [PATCH net-next 1/1] net: ipv4: Refine the ipv4_default_advmss

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Wednesday, April 12, 2017 10:03 AM > To: gfree.w...@foxmail.com; da...@davemloft.net; kuz...@ms2.inr.ac.ru; > jmor...@namei.org; netdev@vger.kernel.org > Cc: Gao Feng <f...@ikuai8.com> > S

RE: [PATCH net 1/1] net: tcp: Don't increase the TCP_MIB_OUTRSTS when fail to transmit RST

Hi Neal > -Original Message- > > On Thu, Apr 6, 2017 at 10:05 AM, Gao Feng <gfree.w...@foxmail.com> wrote: > > If so, we should increase the TCP_MIB_OUTRSTS too when fail to alloc skb. > > When machine is overloaded and mem is exhausted, it may fai

RE: [PATCH net 1/1] net: tcp: Don't increase the TCP_MIB_OUTRSTS when fail to transmit RST

Hi Neal, > -Original Message- > From: Neal Cardwell [mailto:ncardw...@google.com] > Sent: Thursday, April 6, 2017 10:01 PM > To: Gao Feng <gfree.w...@foxmail.com> > Cc: David Miller <da...@davemloft.net>; Alexey Kuznetsov > <kuz...@ms2.inr.ac.ru>; James

RE: [PATCH net-next 1/1] net: tcp: Define the TCP_MAX_WSCALE instead of literal number 14

namei.org>; Patrick McHardy > <ka...@trash.net>; Netdev <netdev@vger.kernel.org>; Gao Feng > <f...@ikuai8.com> > Subject: Re: [PATCH net-next 1/1] net: tcp: Define the TCP_MAX_WSCALE > instead of literal number 14 > > On Sat, Apr 1, 2017 at 12:14 AM, <gfree.w...@

RE: [PATCH nf-next 1/1] net: tcp: Refine the __tcp_select_window

> f...@ikuai8.com > Subject: Re: [PATCH nf-next 1/1] net: tcp: Refine the __tcp_select_window > > From: gfree.w...@foxmail.com > Date: Thu, 30 Mar 2017 06:49:19 +0800 > > > From: Gao Feng <f...@ikuai8.com> > > > > 1. Move the "window = tp->rcv_wnd;"

RE: [PATCH net-next 1/1] tcp: sysctl: Fix a race to avoid unexpected 0 window from space

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Stephen Hemminger > Sent: Saturday, March 25, 2017 4:32 AM > To: gfree.w...@foxmail.com > Cc: da...@davemloft.net; netdev@vger.kernel.org; Gao Feng > <f.

RE: [PATCH nf v3 1/1] netfilter: snmp: Fix one possible panic when snmp_trap_helper fail to register

ubject: Re: [PATCH nf v3 1/1] netfilter: snmp: Fix one possible panic when > snmp_trap_helper fail to register > > On Tue, Mar 21, 2017 at 08:22:29AM +0800, f...@ikuai8.com wrote: > > From: Gao Feng <f...@ikuai8.com> > > > > In the commit 93557f53e1fb (

RE: [PATCH nf v3 1/1] netfilter: snmp: Fix one possible panic when snmp_trap_helper fail to register

, 2017 at 08:22:29AM +0800, f...@ikuai8.com wrote: > > > From: Gao Feng <f...@ikuai8.com> > > > > > > In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack > > > snmp helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So > &

Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in nat_rtp_rtcp and nf_nat_sdp_media

Hi Liping, On Thu, Mar 2, 2017 at 7:18 PM, Liping Zhang <zlpnob...@gmail.com> wrote: > Hi, > 2017-03-02 18:18 GMT+08:00 Gao Feng <f...@ikuai8.com>: > [...] >> The expect class is NF_CT_EXPECT_CLASS_DEFAULT, and proto is >> IPPROTO_UDP at the function "

Re: [PATCH nf 1/1] netfilter: h323,sip: Fix possible dead loop in nat_rtp_rtcp and nf_nat_sdp_media

Hi Liping, On Thu, Mar 2, 2017 at 4:50 PM, Liping Zhang <zlpnob...@gmail.com> wrote: > Hi, > > 2017-03-02 15:57 GMT+08:00 <f...@ikuai8.com>: >> From: Gao Feng <f...@ikuai8.com> >> >> When h323 and sip try to insert expect nodes, they would inc

Re: [lkp-robot] [net] 0148239373: ltp.test_1_to_1_sockopt.fail

Hi Xiaolong, On Wed, Feb 15, 2017 at 9:46 AM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 0148239373801a9c0c63eefc481b710ae7ce2941 ("net: sock: Use double > send/recv buff value to compare with max value") > url: >

Re: [PATCH net 1/1] net: sock: Use double send/recv buff value to compare with max value

On Thu, Feb 9, 2017 at 12:00 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2017-02-08 at 21:07 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> Because the value of SO_SNDBUF and SO_RCVBUF is doubled before >> assignm

Re: [PATCH net-next 1/1] driver: ipvlan: Define common functions to decrease duplicated codes used to add or del IP address

On Wed, Dec 21, 2016 at 2:30 AM, David Miller wrote: > From: f...@ikuai8.com > Date: Mon, 19 Dec 2016 09:24:05 +0800 > >> It is sent again because the first email is sent during net-next closing. > > It is still closed, and will not open again for at least one week. Thanks

[PATCH] vsock: lookup and setup guest_cid inside vhost_vsock_lock

Multi vsocks may setup the same cid at the same time. Signed-off-by: Gao feng <omarapazan...@gmail.com> --- drivers/vhost/vsock.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index e3b30ea..a

Re: [PATCH net 1/1] driver: ipvlan: Unlink the upper dev when ipvlan_link_new failed

On Thu, Dec 8, 2016 at 9:39 AM, Mahesh Bandewar (महेश बंडेवार) <mahe...@google.com> wrote: > On Wed, Dec 7, 2016 at 5:21 PM, <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> When netdev_upper_dev_unlink failed in ipvlan_link_new, need to

Re: [PATCH net-next v2 1/1] driver: ipvlan: Free ipvl_port directly with kfree instead of kfree_rcu

Hi Eric, On Tue, Dec 6, 2016 at 11:18 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2016-12-06 at 21:54 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <gfree.w...@gmail.com> >> >> There is no one which may reference the ipvlan port when

Re: [PATCH net-next 1/1] driver: ipvlan: Free the port memory directly with kfree instead of kfree_rcu

Hi Eric, On Tue, Dec 6, 2016 at 2:53 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2016-12-06 at 14:31 +0800, Gao Feng wrote: > >> Because I don't fully hold the ipvlan codes now, I am afraid of that >> there is someone which may get the port address when &g

Re: [PATCH net-next 1/1] driver: ipvlan: Free the port memory directly with kfree instead of kfree_rcu

Hi Eric, On Tue, Dec 6, 2016 at 2:25 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2016-12-06 at 12:29 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> There is no one which may reference the "port" in ipvlan_por

Re: [PATCH net-next v2 1/1] driver: ipvlan: Use NF_IP_PRI_LAST as hook priority instead of INT_MAX

Hi Mahesh, On Tue, Nov 29, 2016 at 3:26 AM, Mahesh Bandewar (महेश बंडेवार) <mahe...@google.com> wrote: > On Sun, Nov 27, 2016 at 3:18 AM, <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> It is better to use NF_IP_PRI_LAST instead of

Re: [PATCH net-next 1/1] driver: ipvlan: Use NF_IP_PRI_LAST as hook priority instead of INT_MAX

On Sun, Nov 27, 2016 at 7:17 PM, kbuild test robot wrote: > Hi Gao, > > [auto build test ERROR on net-next/master] > > url: > https://github.com/0day-ci/linux/commits/fgao-ikuai8-com/driver-ipvlan-Use-NF_IP_PRI_LAST-as-hook-priority-instead-of-INT_MAX/20161127-182724 > config:

Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit

Hi Cong, On Tue, Nov 22, 2016 at 1:29 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Sun, Nov 20, 2016 at 4:56 PM, <f...@ikuai8.com> wrote: >> From: Gao Feng <gfree.w...@gmail.com> >> >> The tc could return NET_XMIT_CN as one congestion notifica

Re: [PATCH net v2 1/1] net: batman-adv: Treat NET_XMIT_CN as transmit successfully

Hi Florian, On Mon, Nov 21, 2016 at 9:24 PM, Gao Feng <f...@ikuai8.com> wrote: > Hi Florian, > > On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal <f...@strlen.de> wrote: >> f...@ikuai8.com <f...@ikuai8.com> wrote: >>> From: Gao Feng <f...@ikuai8

Re: [PATCH net v2 1/1] net: batman-adv: Treat NET_XMIT_CN as transmit successfully

Hi Florian, On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal <f...@strlen.de> wrote: > f...@ikuai8.com <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> The tc could return NET_XMIT_CN as one congestion notification, but >> it does no

Re: [PATCH net 1/1] driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.

Hi David, On Tue, Nov 8, 2016 at 9:33 AM, David Miller <da...@davemloft.net> wrote: > From: f...@ikuai8.com > Date: Fri, 4 Nov 2016 10:28:49 +0800 > >> From: Gao Feng <f...@ikuai8.com> >> >> When there is no existing macvlan port in lowdev, o

Re: [PATCH net-next v2 1/1] driver: veth: Refine the statistics codes of veth driver

Hi Eric, On Thu, Nov 3, 2016 at 11:07 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2016-11-03 at 22:38 +0800, Gao Feng wrote: > >> Because other net devices put the statistics together. >> Take tun/tap as example, it is a virtual device, but its all

Re: [PATCH net-next v2 1/1] driver: veth: Refine the statistics codes of veth driver

On Thu, Nov 3, 2016 at 10:31 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2016-11-03 at 21:39 +0800, Gao Feng wrote: >> Hi Eric, >> >> On Thu, Nov 3, 2016 at 9:30 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Thu, 2016-1

Re: [PATCH net-next v2 1/1] driver: veth: Refine the statistics codes of veth driver

Hi Eric, On Thu, Nov 3, 2016 at 9:30 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2016-11-03 at 21:03 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> The dropped count of veth is located in struct veth_priv, but other >

Re: [PATCH net 1/1] driver: veth: Return the actual value instead return NETDEV_TX_OK always

Hi Florian, On Thu, Nov 3, 2016 at 8:58 AM, Florian Fainelli <f.faine...@gmail.com> wrote: > On 11/02/2016 05:52 PM, Gao Feng wrote: >> Hi Cong, >> >> On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: >>> On Wed, Nov 2,

Re: [PATCH net 1/1] driver: veth: Return the actual value instead return NETDEV_TX_OK always

Hi Cong, On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Wed, Nov 2, 2016 at 2:59 AM, <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> Current veth_xmit always returns NETDEV_TX_OK whatever if it is

Re: [PATCH] net: avoid uninitialized variable

On Thu, Oct 27, 2016 at 11:56 AM, zhongjiang wrote: > From: zhong jiang > > when I compiler the newest kernel, I hit the following error with > Werror=may-uninitalized. > > net/core/flow_dissector.c: In function ?._skb_flow_dissect? >

Re: [PATCH net-next 1/1] driver: tun: Use new macro SOCK_IOC_MAGIC instead of literal number 0x89

the literal number 0x89 may >> confuse readers. So create one macro SOCK_IOC_MAGIC like SPI_IOC_MAGIC to >> enhance the readability. >> >> Signed-off-by: Gao Feng <f...@ikuai8.com> >> --- >> drivers/net/tun.c| 2 +- >> include/uapi/linux/sock

Re: [PATCH v2 net-next 1/1] driver: tun: Forbid to set IFF_TUN and IFF_TAP at the same time

Hi Eric, On Fri, Oct 21, 2016 at 7:28 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2016-10-21 at 19:02 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> Current tun driver permits the ifr_flags is set with IFF_TUN and >>

Re: [PATCH net-next 1/1] net: vlan: Use sizeof instead of literal number

Hi David, On Tue, Oct 18, 2016 at 9:36 AM, David Miller wrote: > > It never makes sense to send the same patch for both net and net-next. > > If it's a bug fix, it goes to 'net'. And it will be eventually > be naturally merged into 'net-next'. > > Otherwise, if it's a new

Re: [PATCH nf-next] netfilter: xt_osf: Use explicit member assignment to avoid implicit no padding rule

Hi Liping, On Tue, Sep 27, 2016 at 2:05 PM, Liping Zhang <zlpnob...@gmail.com> wrote: > Hi Feng, > > 2016-09-27 14:00 GMT+08:00 Gao Feng <f...@ikuai8.com>: >> Hi Liping, >> >>> >>> This xt_osf_user_finger{} is carefully designed, no pad

Re: [PATCH nf-next] netfilter: xt_osf: Use explicit member assignment to avoid implicit no padding rule

Hi Liping, On Tue, Sep 27, 2016 at 1:49 PM, Liping Zhang <zlpnob...@gmail.com> wrote: > Hi Feng, > > 2016-09-27 12:39 GMT+08:00 <f...@ikuai8.com>: >> From: Gao Feng <f...@ikuai8.com> >> >> Current xt_osf codes use memcmp to check if two user fingers

Re: [PATCH v5 nf] netfilter: seqadj: Drop the packet directly when fail to add seqadj extension to avoid dereference NULL pointer later

inline On Tue, Sep 6, 2016 at 10:51 PM, Florian Westphal <f...@strlen.de> wrote: > f...@ikuai8.com <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj >> extensio

Re: [PATCH v4 nf] netfilter: seqadj: Drop the packet directly when fail to add seqadj extension to avoid dereference NULL pointer later

inline On Tue, Sep 6, 2016 at 6:17 PM, Pablo Neira Ayuso <pa...@netfilter.org> wrote: > On Tue, Sep 06, 2016 at 09:57:23AM +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> When memory is exhausted, nfct_seqadj_ext_add may fa

Re: [PATCH v2 1/2 nf] netfilter: seqadj: Fix one possible panic in seqadj when mem is exhausted

Hi Florian, On Fri, Sep 2, 2016 at 2:59 PM, Florian Westphal <f...@strlen.de> wrote: > f...@ikuai8.com <f...@ikuai8.com> wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj >>

Re: [PATCH 1/2 nf] netfilter: seqadj: Fix some possible panics of seqadj when mem is exhausted

Hi Liping, On Fri, Sep 2, 2016 at 12:50 PM, Liping Zhang <zlpnob...@gmail.com> wrote: > Hi Feng, > 2016-09-02 9:48 GMT+08:00 <f...@ikuai8.com>: >> From: Gao Feng <f...@ikuai8.com> >> @@ -171,6 +176,11 @@ int nf_ct_seq_adjust(struct sk_buff *skb, >

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

On Wed, Aug 31, 2016 at 12:16 PM, Gao Feng <f...@ikuai8.com> wrote: > On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote: >>> From: Gao Feng <f...@ikuai8.com&g

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote: >> From: Gao Feng <f...@ikuai8.com> >> >> The original codes depend on that the function parameters are evaluated from >

Re: [PATCH v3] vsock: fix missing cleanup when misc_register failed

I'm sorry too, fell free to ignore my patch, Thanks. 2015-10-19 9:50 GMT+08:00 David Miller <da...@davemloft.net>: > From: Gao feng <omarapazan...@gmail.com> > Date: Sun, 18 Oct 2015 23:35:56 +0800 > >> reset transport and unlock if misc_register failed. >> >&

[PATCH] vsock: fix missing cleanup when misc_register failed

reset transport and unlock if misc_register failed. Signed-off-by: Gao feng <omarapazan...@gmail.com> --- net/vmw_vsock/af_vsock.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index df5fc6b..5f5fbed 100644 ---

[PATCH v2] vsock: fix missing cleanup when misc_register failed

reset transport and unlock if misc_register failed. Signed-off-by: Gao feng <omarapazan...@gmail.com> --- net/vmw_vsock/af_vsock.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index df5fc6b..598e045

[PATCH v3] vsock: fix missing cleanup when misc_register failed

reset transport and unlock if misc_register failed. Signed-off-by: Gao feng <omarapazan...@gmail.com> --- net/vmw_vsock/af_vsock.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index df5fc6b..00e8a34