At 2018-05-11 22:56:04, "Willem de Bruijn"
wrote:
>On Fri, May 11, 2018 at 10:44 AM, Gao Feng wrote:
>> At 2018-05-11 21:23:55, "Willem de Bruijn"
>> wrote:
>>>On Fri, May 11, 2018 at 2:20 AM, Gao Feng wrote:
>>>> At 2018-05-11 11:54:
At 2018-05-11 21:23:55, "Willem de Bruijn"
wrote:
>On Fri, May 11, 2018 at 2:20 AM, Gao Feng wrote:
>> At 2018-05-11 11:54:55, "Willem de Bruijn"
>> wrote:
>>>On Thu, May 10, 2018 at 4:28 AM, wrote:
>>>> From: Gao Feng
>>>&g
At 2018-05-11 11:54:55, "Willem de Bruijn"
wrote:
>On Thu, May 10, 2018 at 4:28 AM, wrote:
>> From: Gao Feng
>>
>> The skb flow limit is implemented for each CPU independently. In the
>> current codes, the function skb_flow_limit gets the softnet_data by
&
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
At 2018-05-10 21:02:55, "Eric Dumazet" wrote:
>
>
>On 05/10/2018 01:28 AM, gfree.w...@vip.163.com wrote:
>> From: Gao Feng
>>
>> The skb flow limit is implemented for each CPU independently. In the
>> current codes, the function skb_flow_limit gets t
At 2018-04-17 05:18:25, "Eric Dumazet" 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
>>>
>>> It would allocate memory in th
At 2018-04-16 10:55:56, "David Miller" wrote:
>From: gfree.w...@vip.163.com
>Date: Mon, 16 Apr 2018 10:16:45 +0800
>
>> From: Gao Feng
>>
>> It would allocate memory in this function when the cork->opt is NULL. But
>> the memory isn't freed
>On Thu, 2017-09-21 at 12:39 +0800, gfree.w...@vip.163.com wrote:
>> From: Gao Feng
>>
>> There is no one which would invokes the function skb_header_release.
>> So just remove it now.
>
>This in incomplete.
>There are other references to this function.
At 2017-08-22 03:58:03, "Cong Wang" wrote:
>On Mon, Aug 21, 2017 at 10:47 AM, David Miller wrote:
>> From: gfree.w...@vip.163.com
>> Date: Fri, 18 Aug 2017 15:23:24 +0800
>>
>>> From: Gao Feng
>>>
>>> Add the invalid handle "0&quo
At 2017-08-10 02:08:30, "Cong Wang" wrote:
>On Wed, Aug 9, 2017 at 8:57 AM, wrote:
>> From: Gao Feng
>>
>> In the commit ddab82821fa6 ("ppp: Fix a scheduling-while-atomic bug in
>> del_chan"), I moved the synchronize_rcu() from del_chan() t
At 2017-08-10 05:00:19, "Cong Wang" wrote:
>On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng wrote:
>> Hi Cong,
>>
>> Actually I have one question about the SOCK_RCU_FREE.
>> I don't think it could resolve the issue you raised even though it exists
>&g
At 2017-08-10 02:18:44, "Cong Wang" wrote:
>On Tue, Aug 8, 2017 at 10:13 PM, Gao Feng wrote:
>> Maybe I didn't show my explanation clearly.
>> I think it won't happen as I mentioned in the last email.
>> Because the pptp_release invokes the synchronize_rc
At 2017-08-09 13:13:53, "Gao Feng" wrote:
>At 2017-08-09 03:45:53, "Cong Wang" wrote:
>>On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng wrote:
>>>
>>> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful?
>>
At 2017-08-09 03:45:53, "Cong Wang" wrote:
>On Mon, Aug 7, 2017 at 6:10 PM, Gao Feng wrote:
>>
>> Sorry, I don't get you clearly. Why the sock_hold() isn't helpful?
>
>I already told you, the dereference happends before sock_hold().
>
>
At 2017-08-08 21:58:27, "Guillaume Nault" wrote:
>On Tue, Aug 08, 2017 at 09:16:33PM +0800, Gao Feng wrote:
>> At 2017-08-08 17:43:24, "Guillaume Nault" wrote:
>> >--- a/drivers/net/ppp/ppp_generic.c
>> >+++ b/drivers/net/ppp/ppp_ge
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 __ppp_channel_push() can also send pack
At 2017-08-08 01:17:02, "Cong Wang" wrote:
>On Sun, Aug 6, 2017 at 6:32 PM, Gao Feng wrote:
>> I think the RCU should be supposed to avoid the race between del_chan and
>> lookup_chan.
>
>More precisely, it is callid_sock which is protected by RCU.
>
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(). And the
>> pppox_sock is freed when the last refcnt i
At 2017-06-28 01:49:50, "Eric Dumazet" wrote:
>On Tue, 2017-06-27 at 10:08 -0700, Cong Wang wrote:
>> On Tue, Jun 27, 2017 at 9:50 AM, Eric Dumazet wrote:
>> > On Tue, 2017-06-27 at 09:30 -0700, Cong Wang wrote:
>> >> On Mon, Jun 26, 2017 at
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(&rfs_needed))
>> +_sock_rps_
At 2017-05-23 11:02:20, "David Miller" wrote:
>From: gfree.w...@vip.163.com
>Date: Tue, 23 May 2017 08:45:11 +0800
>
>> From: Gao Feng
>>
>> When the new RFS table size specified by sysctl equals the old one,
>> there is nothing changed actually. So
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 sk_buff
>> *skb)
>> {
>>
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 the skb is queued or freed directly by the
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 tha
> 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 wrote:
> >> From: Xin Long [mailto:lucien@gmail.com]
> >> Sent: Wednesday, May 3, 2017 1:38 PM
> >> On Wed, May 3, 20
> 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
> wrote:
> >> From: netdev-ow...@vger.kernel.org
> >> [mailto:netdev-ow...@vger.kernel.org]
> >> On Behalf Of Xin Long
> &
> 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 wrote:
> >> From: Xin Long [mailto:lucien@gmail.com]
> >> Sent: Tuesday, May 2,
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 th
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 ++-
> dr
> From: Xin Long [mailto:lucien@gmail.com]
> Sent: Tuesday, May 2, 2017 3:56 PM
> On Sat, Apr 29, 2017 at 11:51 AM, wrote:
> > From: Gao Feng
[...]
> > -static void veth_dev_free(struct net_device *dev)
> > +static void veth_destructor_
> 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
> > @@
> 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 approach
> 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 +
> 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 wro
> 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
> >
[...]
>
> This has the potential of creating future bugs, because there
> 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
>
> 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
>
> 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
> >
> > Because the func batadv_softif_init_late allocate some resources and
> From: Gao Feng
>
> 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
> the uninit callback is in
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
> >
> > It should increase TCPABORTONLINGER co
er.kernel.org
> Cc: Gao Feng
> 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 trivia:
>
> > @@ -1
> -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
> Subject: Re: [PATCH ne
Hi Neal
> -Original Message-
>
> On Thu, Apr 6, 2017 at 10:05 AM, Gao Feng 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 fail to alloc skb.
>
> Moving the incr
Hi Neal,
> -Original Message-
> From: Neal Cardwell [mailto:ncardw...@google.com]
> Sent: Thursday, April 6, 2017 10:01 PM
> To: Gao Feng
> Cc: David Miller ; Alexey Kuznetsov
> ; James Morris ; Patrick McHardy
> ; Netdev ; Gao Feng
>
> Subject: Re: [PAT
> -Original Message-
> From: Neal Cardwell [mailto:ncardw...@google.com]
> Sent: Monday, April 3, 2017 2:59 AM
> To: gfree.w...@foxmail.com
> Cc: David Miller ; Alexey Kuznetsov
> ; James Morris ; Patrick McHardy
> ; Netdev ; Gao Feng
>
> Subject: Re: [PATCH net
> 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
> >
> > 1. Move the "window = tp->rcv_wnd;" into the condition blo
> -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
>
>
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
> >
> > In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_con
, 2017 at 08:22:29AM +0800, f...@ikuai8.com wrote:
> > > From: Gao Feng
> > >
> > > In the commit 93557f53e1fb ("netfilter: nf_conntrack: nf_conntrack
> > > snmp helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So
> > > the snmp_helper i
Hi Liping,
On Thu, Mar 2, 2017 at 7:18 PM, Liping Zhang wrote:
> Hi,
> 2017-03-02 18:18 GMT+08:00 Gao Feng :
> [...]
>> The expect class is NF_CT_EXPECT_CLASS_DEFAULT, and proto is
>> IPPROTO_UDP at the function "expect_rtp_rtcp",
>> And it makes sure the p
Hi Liping,
On Thu, Mar 2, 2017 at 4:50 PM, Liping Zhang wrote:
> Hi,
>
> 2017-03-02 15:57 GMT+08:00 :
>> From: Gao Feng
>>
>> When h323 and sip try to insert expect nodes, they would increase
>> the port by 2 for loop, and the loop condition is that "po
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:
> https://github.com/0day-ci/linux/commits/fgao
On Thu, Feb 9, 2017 at 12:00 AM, Eric Dumazet wrote:
> On Wed, 2017-02-08 at 21:07 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> Because the value of SO_SNDBUF and SO_RCVBUF is doubled before
>> assignment, so the real value of send and recv buffer could be
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 David.
I thought it on
Multi vsocks may setup the same cid at the same time.
Signed-off-by: Gao feng
---
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..a08332b 100644
--- a/drivers/vhost
On Thu, Dec 8, 2016 at 9:39 AM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Wed, Dec 7, 2016 at 5:21 PM, wrote:
>> From: Gao Feng
>>
>> When netdev_upper_dev_unlink failed in ipvlan_link_new, need to
>> unlink the ipvlan dev with upper dev.
>>
>> Signed-o
Hi Eric,
On Tue, Dec 6, 2016 at 11:18 PM, Eric Dumazet wrote:
> On Tue, 2016-12-06 at 21:54 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> There is no one which may reference the ipvlan port when free it in
>> ipvlan_port_create and ipvlan_port_destroy. So
Hi Eric,
On Tue, Dec 6, 2016 at 2:53 PM, Eric Dumazet 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
>> ipvlan_
Hi Eric,
On Tue, Dec 6, 2016 at 2:25 PM, Eric Dumazet wrote:
> On Tue, 2016-12-06 at 12:29 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> There is no one which may reference the "port" in ipvlan_port_create
>> when netdev_rx_handler_register failed.
Hi Mahesh,
On Tue, Nov 29, 2016 at 3:26 AM, Mahesh Bandewar (महेश बंडेवार)
wrote:
> On Sun, Nov 27, 2016 at 3:18 AM, wrote:
>> From: Gao Feng
>>
>> It is better to use NF_IP_PRI_LAST instead of INT_MAX as hook priority.
>> The former is good at readability and ea
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: x86_64-allmodcon
Hi Cong,
On Tue, Nov 22, 2016 at 1:29 PM, Cong Wang wrote:
> On Sun, Nov 20, 2016 at 4:56 PM, wrote:
>> From: Gao Feng
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packe is lost. Other modules like ipvlan,
&
Hi Florian,
On Mon, Nov 21, 2016 at 9:24 PM, Gao Feng wrote:
> Hi Florian,
>
> On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal wrote:
>> f...@ikuai8.com wrote:
>>> From: Gao Feng
>>>
>>> The tc could return NET_XMIT_CN as one congestion notificati
Hi Florian,
On Mon, Nov 21, 2016 at 7:09 PM, Florian Westphal wrote:
> f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packet is lost. Other modules like ipvlan,
>> macv
Hi David,
On Tue, Nov 8, 2016 at 9:33 AM, David Miller wrote:
> From: f...@ikuai8.com
> Date: Fri, 4 Nov 2016 10:28:49 +0800
>
>> From: Gao Feng
>>
>> When there is no existing macvlan port in lowdev, one new macvlan port
>> would be created. But it doesn
Hi Eric,
On Thu, Nov 3, 2016 at 11:07 PM, Eric Dumazet 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
>> statistics are percpu inclu
On Thu, Nov 3, 2016 at 10:31 PM, Eric Dumazet 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 wrote:
>> > On Thu, 2016-11-03 at 21:03 +0800, f...@ikuai8.com wrote:
>> >> From:
Hi Eric,
On Thu, Nov 3, 2016 at 9:30 PM, Eric Dumazet wrote:
> On Thu, 2016-11-03 at 21:03 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> The dropped count of veth is located in struct veth_priv, but other
>> statistics like packets and bytes are in another
Hi Florian,
On Thu, Nov 3, 2016 at 8:58 AM, Florian Fainelli wrote:
> On 11/02/2016 05:52 PM, Gao Feng wrote:
>> Hi Cong,
>>
>> On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang wrote:
>>> On Wed, Nov 2, 2016 at 2:59 AM, wrote:
>>>> From: Gao Feng
Hi Cong,
On Thu, Nov 3, 2016 at 4:22 AM, Cong Wang wrote:
> On Wed, Nov 2, 2016 at 2:59 AM, wrote:
>> From: Gao Feng
>>
>> Current veth_xmit always returns NETDEV_TX_OK whatever if it is really
>> sent successfully. Now return the actual value instead of NETDEV_TX
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?
> include/uapi/linux/swab.h:100:46: error: ?.lan?.may be used un
gt;> confuse readers. So create one macro SOCK_IOC_MAGIC like SPI_IOC_MAGIC to
>> enhance the readability.
>>
>> Signed-off-by: Gao Feng
>> ---
>> drivers/net/tun.c| 2 +-
>> include/uapi/linux/sockios.h | 2 ++
>> 2 files changed, 3 insertions
Hi Eric,
On Fri, Oct 21, 2016 at 7:28 PM, Eric Dumazet wrote:
> On Fri, 2016-10-21 at 19:02 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> Current tun driver permits the ifr_flags is set with IFF_TUN and
>> IFF_TAP at the same time. But actually there is only
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 feature, cleanup, or op
Hi Liping,
On Tue, Sep 27, 2016 at 2:05 PM, Liping Zhang wrote:
> Hi Feng,
>
> 2016-09-27 14:00 GMT+08:00 Gao Feng :
>> Hi Liping,
>>
>>>
>>> This xt_osf_user_finger{} is carefully designed, no padding now, and
>>> will not be changed in the futu
Hi Liping,
On Tue, Sep 27, 2016 at 1:49 PM, Liping Zhang wrote:
> Hi Feng,
>
> 2016-09-27 12:39 GMT+08:00 :
>> From: Gao Feng
>>
>> Current xt_osf codes use memcmp to check if two user fingers are same,
>> so it depends on that the struct xt_osf_user_f
inline
On Tue, Sep 6, 2016 at 10:51 PM, Florian Westphal wrote:
> f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
>> extension. But the function nf_ct_seqadj_init doesn't check if ge
inline
On Tue, Sep 6, 2016 at 6:17 PM, Pablo Neira Ayuso wrote:
> On Tue, Sep 06, 2016 at 09:57:23AM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
>> extension. But the function nf_ct_s
Hi Florian,
On Fri, Sep 2, 2016 at 2:59 PM, Florian Westphal wrote:
> f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> When memory is exhausted, nfct_seqadj_ext_add may fail to add the seqadj
>> extension. But the function nf_ct_seqadj_init doesn't check if ge
Hi Liping,
On Fri, Sep 2, 2016 at 12:50 PM, Liping Zhang wrote:
> Hi Feng,
> 2016-09-02 9:48 GMT+08:00 :
>> From: Gao Feng
>> @@ -171,6 +176,11 @@ int nf_ct_seq_adjust(struct sk_buff *skb,
>> struct nf_ct_seqadj *this_way, *other_way;
>> int r
On Wed, Aug 31, 2016 at 12:16 PM, Gao Feng wrote:
> On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet wrote:
>> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
>>> From: Gao Feng
>>>
>>> The original codes depend on that the function parameters are e
On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet wrote:
> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> The original codes depend on that the function parameters are evaluated from
>> left to right. But the parameter's eval
I'm sorry too, fell free to ignore my patch, Thanks.
2015-10-19 9:50 GMT+08:00 David Miller :
> From: Gao feng
> Date: Sun, 18 Oct 2015 23:35:56 +0800
>
>> reset transport and unlock if misc_register failed.
>>
>> Signed-off-by: Gao feng
>
> It's ext
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
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 100644
--- a/net/vmw_vsock/af_vsock.c
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
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 100644
--- a/net/vmw_vsock/af_vsock.c
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
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
--- a/net/vmw_vsock/af_vsock.c
86 matches
Mail list logo
