On Tue, Mar 21, 2017 at 9:23 AM, Neal Cardwell wrote:
> On Mon, Mar 20, 2017 at 8:45 PM, wrote:
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index 1e319a5..4f7f163 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -2470,7 +2470,7 @@ static int do_tcp_setsockopt(struct sock *sk, i
On Tue, Mar 21, 2017 at 12:35 AM, Sergei Shtylyov
wrote:
> On 03/20/2017 01:15 PM, Feng Gao wrote:
>
>>>> From: Gao Feng
>>>>
>>>> In the commit <93557f53e1fb> ("netfilter: nf_conntrack: nf_conntrack
>>>> snmp
>>>
>&
On Mon, Mar 20, 2017 at 5:37 PM, Sergei Shtylyov
wrote:
> Hello!
>
> On 3/20/2017 4:44 AM, f...@ikuai8.com wrote:
>
>> From: Gao Feng
>>
>> In the commit ("netfilter: nf_conntrack: nf_conntrack snmp helper"),
>
>
>Need to specify the 12-digit SHA1 ID as well.
Thanks Sergei.
I didn't know it
On Mon, Mar 20, 2017 at 6:09 PM, Sergei Shtylyov
wrote:
> On 3/20/2017 12:55 PM, f...@ikuai8.com wrote:
>
>> From: Gao Feng
>>
>> In the commit <93557f53e1fb> ("netfilter: nf_conntrack: nf_conntrack snmp
>
>
>Angle brackets not needed. :-)
>The commit citing style is the same as for the F
Hi David,
On Fri, Mar 10, 2017 at 11:58 AM, David Ahern wrote:
> On 3/9/17 7:52 PM, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> When master_idx is invalid, it is zero. It is unnecessary to iterate
>> all netdevs. Because l3mdev_master_ifindex_rcu(dev) != master_idx must
>> be true.
>> Now put
Hi Sergei,
On Tue, Mar 7, 2017 at 11:46 PM, Sergei Shtylyov
wrote:
> Hello!
>
> On 03/07/2017 05:51 PM, f...@ikuai8.com wrote:
>
>> From: Gao Feng
>>
>> There are two duplicated loop codes which used to select right
>
>
>Just "loops".
>
>> address in current codes. Now eliminate these codes
On Tue, Feb 21, 2017 at 3:13 PM, Joe Perches wrote:
> On Mon, 2017-02-20 at 22:33 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> The USEC_PER_SEC is used once in sock_set_timeout as the max value of
>> tv_usec. But there are other similar codes which use the literal
>> 100 in this file
On Fri, Dec 16, 2016 at 5:19 PM, Sven Eckelmann wrote:
> On Montag, 21. November 2016 23:00:32 CET 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,
>> macvlan, and
On Wed, Dec 14, 2016 at 10:52 PM, wrote:
> From: Gao Feng
>
> There are some duplicated codes in ipvlan_add_addr6/4 and
> ipvlan_del_addr6/4. Now define two common functions ipvlan_add_addr
> and ipvlan_del_addr to decrease the duplicated codes.
> It could be helful to maintain the codes.
>
> Si
Hi David & Mahesh,
On Tue, Nov 29, 2016 at 4:08 AM, David Miller wrote:
> From: Mahesh Bandewar (महेश बंडेवार)
> Date: Mon, 28 Nov 2016 11:02:45 -0800
>
>> On Mon, Nov 28, 2016 at 5:23 AM, wrote:
>>
>>> From: Gao Feng
>>>
>>> The ipvlan mode variable "nval" is from userspace, so the ipvlan cod
Hi Sergei,
On Mon, Nov 21, 2016 at 6:44 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 11/21/2016 3:39 AM, f...@ikuai8.com 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,
>
>
>P
Hi Sven,
On Mon, Nov 21, 2016 at 4:31 PM, Sven Eckelmann wrote:
> On Montag, 21. November 2016 16:21:52 CET Feng Gao wrote:
>> Hi Sven,
>>
>> On Mon, Nov 21, 2016 at 4:16 PM, Sven Eckelmann wrote:
>> > On Montag, 21. November 2016 08:39:39 CET f...@ikuai8.c
Hi Sven,
On Mon, Nov 21, 2016 at 4:16 PM, Sven Eckelmann wrote:
> On Montag, 21. November 2016 08:39:39 CET f...@ikuai8.com 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,
>
> s/p
On Mon, Nov 21, 2016 at 8:26 AM, wrote:
> From: Gao Feng
>
> The function macvlan_forward_source_one has already checked the flag
> IFF_UP, so needn't check it outside in macvlan_forward_source too.
>
> Signed-off-by: Gao Feng
> ---
> v2: Remove the IFF_UP check in macvlan_forward_source inste
On Fri, Nov 4, 2016 at 10:28 AM, wrote:
> From: Gao Feng
>
> When there is no existing macvlan port in lowdev, one new macvlan port
> would be created. But it doesn't be destoried when something failed later.
> It casues some memleak.
>
> Now add one flag to indicate if new macvlan port is creat
It is deprecated.
On Thu, Nov 3, 2016 at 8:50 PM, 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 struct pcpu_vstats.
> Now keep these three counters in the same struct.
>
> Signed-off-by: Gao Fen
On Tue, Oct 18, 2016 at 8:44 AM, wrote:
> From: Gao Feng
>
> Use sizeof variable instead of literal number to enhance the readability.
>
> Signed-off-by: Gao Feng
> ---
> net/8021q/vlan.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/8021q/vlan.c b/net/8021q/
Hi Liping,
On Wed, Sep 28, 2016 at 11:13 AM, Liping Zhang wrote:
> 2016-09-28 11:08 GMT+08:00 Liping Zhang :
>> Hi Feng,
>>
>> 2016-09-28 9:23 GMT+08:00 Feng Gao :
>>> Hi Aaraon,
>>>
>>> On Tue, Sep 27, 2016 at 9:38 PM, Aaron Conole wrote:
>
Hi Aaraon,
On Tue, Sep 27, 2016 at 9:38 PM, Aaron Conole wrote:
> It's possible for nf_hook_entry_head to return NULL if two
> nf_unregister_net_hook calls happen simultaneously with a single hook
The critical region of nf_unregister_net_hook is protected by &nf_hook_mutex.
When it would be call
On Tue, Sep 6, 2016 at 10:06 AM, wrote:
> From: Gao Feng
>
> It is valid that the TCP RST packet which does not set ack flag, and bytes
> of ack number are zero. For these RST packets, seqadj could not adjust the
> ack number.
>
> Signed-off-by: Gao Feng
> ---
> v2: Regenerate because the firs
Hi Pablo,
On Mon, Sep 5, 2016 at 11:02 PM, wrote:
> From: Gao Feng
>
> It is valid that the TCP RST packet which does not set ack flag, and bytes
> of ack number are zero. For these RST packets, seqadj could not adjust the
> ack number.
>
> Signed-off-by: Gao Feng
> ---
> net/netfilter/nf_con
On Mon, Aug 29, 2016 at 6:25 PM, wrote:
> From: Gao Feng
>
> The nf_log_set is an interface function, so it should do the strict sanity
> check of parameters. Convert the return value of nf_log_set as int instead
> of void. When the pf is invalid, return -EOPNOTSUPP.
>
> Signed-off-by: Gao Feng
On Sun, Aug 28, 2016 at 10:30 PM, wrote:
> From: Gao Feng
>
> The nf_log_set is an interface function, so it should do the strict sanity
> check of parameters. Add one sanity check for pf, it could not exceed
> NFPROTO_NUMPROTO, and print error log when pf is invalid.
>
> Signed-off-by: Gao Fen
On Sun, Aug 28, 2016 at 4:20 AM, Guillaume Nault wrote:
> This series fixes the issue reported by Feng where packets looping
> through a ppp device makes the module deadlock:
> https://marc.info/?l=linux-netdev&m=147134567319038&w=2
>
> The problem can occur on virtual interfaces (e.g. PPP over L2
On Thu, Aug 25, 2016 at 9:45 AM, wrote:
> From: Gao Feng
>
> When cp_rx_poll does not get enough packet, it will check the rx
> interrupt status again. If so, it will jumpt to rx_status_loop again.
> But the goto jump resets the rx variable as zero too.
>
> As a result, it causes one possible de
Hi Pablo,
inline
On Thu, Aug 25, 2016 at 8:16 PM, Pablo Neira Ayuso wrote:
> On Fri, Aug 19, 2016 at 11:03:46PM +0800, Feng Gao wrote:
>> My email server reports the last same patch email failed to send.
>> So I just sent it again.
>>
>> I am sorry, if anyone receiv
Sorry to bother you if receive duplicate email whose subject is "
[patch v2 1/2 net-next] netfilter: gre: Use consistent GRE_* macros
instead of
ones defined by netfilter.".
Because my mail server told it failed to send at the first time.
Regards
Feng
On Tue, Aug 23, 2016 at 10:20 AM, wrote:
Sorry, I forget to run the check_patch.pl script this time.
Now I send the v5 update.
Regards
Feng
On Mon, Aug 22, 2016 at 10:43 PM, Guillaume Nault wrote:
> On Mon, Aug 22, 2016 at 06:59:51PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> Use PPP_ALLSTATIONS, PPP_UI, and SEND_SHUTDOWN i
It seems a better solution, simple and apparent.
I accept any best solution which could make kernel works well :))
Best Regards
Feng
On Mon, Aug 22, 2016 at 8:35 PM, Guillaume Nault wrote:
> On Mon, Aug 22, 2016 at 09:20:14AM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> PPP channel hol
inline
On Mon, Aug 22, 2016 at 5:48 PM, Guillaume Nault wrote:
> On Sun, Aug 21, 2016 at 04:36:52PM -0600, Philp Prindeville wrote:
>> Inline
>>
>>
>> On 08/20/2016 09:52 AM, f...@48lvckh6395k16k5.yundunddos.com wrote:
>> > From: Gao Feng
>> >
>> > Use PPP_ALLSTATIONS, PPP_UI, and SEND_SHUTDOWN
inline
On Mon, Aug 22, 2016 at 6:07 PM, Guillaume Nault wrote:
> On Sat, Aug 20, 2016 at 11:52:27PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> Use PPP_ALLSTATIONS, PPP_UI, and SEND_SHUTDOWN instead of 0xff,
>> 0x03, and 2 separately.
>>
>> Signed-off-by: Gao Feng
>> ---
>> v3: Modif
inline
On Mon, Aug 22, 2016 at 6:36 AM, Philp Prindeville
wrote:
> Inline
>
>
> On 08/20/2016 09:52 AM, f...@48lvckh6395k16k5.yundunddos.com wrote:
>>
>> From: Gao Feng
>>
>> Use PPP_ALLSTATIONS, PPP_UI, and SEND_SHUTDOWN instead of 0xff,
>> 0x03, and 2 separately.
>>
>> Signed-off-by: Gao Feng
On Sat, Aug 20, 2016 at 5:48 AM, Guillaume Nault wrote:
> On Fri, Aug 19, 2016 at 11:16:41PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> PPP channel holds one spinlock before send frame. But the skb may
>> select the same PPP channel with wrong route policy. As a result,
>> the skb reac
Sorry, I forget to modify the title.
I will sent another update.
On Sat, Aug 20, 2016 at 2:28 AM, Guillaume Nault wrote:
> On Fri, Aug 19, 2016 at 05:55:26PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> 1. Use PPP_ALLSTATIONS/PPP_UI instead of literal 0xff/0x03;
>> 2. Use one static con
My email server reports the last same patch email failed to send.
So I just sent it again.
I am sorry, if anyone receives duplicated ones.
Regards
Feng
On Fri, Aug 19, 2016 at 11:01 PM, wrote:
> From: Gao Feng
>
> There are two structures which define the GRE header and PPTP
> header. So it i
pp_channel_push.
Regards
Feng
>
> It seems unlikely to me that this sort of locking problem hasn't existed
> elsewhere before and that an entirely new mechanism for handling it is
> needed... How are similar re-entrancy issues handled elsewhere?
>
> -Philip
>
>
>
&
On Fri, Aug 19, 2016 at 12:13 AM, Guillaume Nault wrote:
> On Thu, Aug 18, 2016 at 08:58:31AM +0800, Feng Gao wrote:
>> On Thu, Aug 18, 2016 at 1:42 AM, Guillaume Nault
>> wrote:
>> > On Tue, Aug 16, 2016 at 07:33:38PM +0800, f...@ikuai8.com wrote:
>> >> Fro
Hi Philp,
Yes. I am agree with you.
Just drop is better to support recursive lock.
I will send a new patch later.
Regards
Feng
On Fri, Aug 19, 2016 at 12:48 AM, Philp Prindeville
wrote:
>
>
> On 08/18/2016 09:05 AM, Feng Gao wrote:
>>
>> On Thu, Aug 18, 2016 at 10:11
inline.
On Fri, Aug 19, 2016 at 1:44 AM, Guillaume Nault wrote:
> On Thu, Aug 18, 2016 at 09:59:03AM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> There are some codes in pppoe and l2tp which use the PPPOX_CONNECTED
>> as the value including assignment and condition check.
>> They should
On Fri, Aug 19, 2016 at 2:41 AM, Guillaume Nault wrote:
> On Thu, Aug 18, 2016 at 03:05:19PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> 1. Use PPP_ALLSTATIONS/PPP_UI instead of literal 0xff/0x03;
>> 2. Use one static const global fixed_ppphdr instead of two same
>> static variable ppph
inline answer.
On Thu, Aug 18, 2016 at 1:42 AM, Guillaume Nault wrote:
> On Tue, Aug 16, 2016 at 07:33:38PM +0800, f...@ikuai8.com wrote:
>> From: Gao Feng
>>
>> PPP channel holds one spinlock before send frame. But the skb may
>> select the same PPP channel with wrong route policy. As a result,
Hi Paul,
The v1 patch does not handle the recursive lock case. It could cause
unlock multiple times.
So I send the v2 patch as one update.
Best Regards
Feng
On Tue, Aug 16, 2016 at 7:05 PM, wrote:
> From: Gao Feng
>
> PPP channel holds one spinlock before send frame. But the skb may
> select
Oh, I think I really get you this time.
Please see my inline comment.
If they are right, I could send the v6 patch.
Best Regards
Feng
On Tue, Aug 9, 2016 at 9:06 AM, Philip Prindeville
wrote:
> Inline...
>
>
>
> On 08/08/2016 06:37 PM, f...@48lvckh6395k16k5.yundunddos.com wrote:
>>
>> From
to anonymous structures, which is a feature of C11.
>
> Please see the link I sent.
>
>
>
> On 08/08/2016 03:13 AM, Feng Gao wrote:
>>
>> Hi Philip,
>>
>> Do you mean like the following?
>>
>> struct gre_full_hdr {
>> struc
t; ...
>
> so yes, I'm talking about making fixed_header be anonymous instead.
>
> -Philip
>
>
>
> On 08/07/2016 08:50 PM, Feng Gao wrote:
>>
>> Hi Philp,
>>
>> Forgive my poor English, I am not clear about the comment #1.
>> "
Hi Philp,
Forgive my poor English, I am not clear about the comment #1.
"Can you make gre_base_hdr be anonymous?".
+struct gre_full_hdr {
+ struct gre_base_hdr fixed_header;
Do you mean make the member "fixed_header" as anonymous or not?
Best Regards
Feng
On Mon, Aug 8, 2016 at 5:03 AM, Phi
The link is https://patchwork.ozlabs.org/patch/655695/
Best Regards
Feng
On Thu, Aug 4, 2016 at 3:37 PM, Feng Gao wrote:
> Hi Tom & Philp,
>
> The v4 patch is sent already.
> Could you help review again please?
>
> Tom,
> I follow your modification.
>
> P
t is only used to offset the sizeof type.
BTW, I find the struct and macro about pptp and gre are redundant.
I want to refactor them in other patches.
On Thu, Aug 4, 2016 at 8:33 AM, Philp Prindeville
wrote:
> Inline
>
>
>
> On 08/03/2016 05:58 PM, Feng Gao wrote:
>>
>> i
inline comment.
There are two comments that I am not clear.
Best Regards
Feng
On Thu, Aug 4, 2016 at 4:43 AM, Philip Prindeville
wrote:
> Inline…
>
>> On Aug 3, 2016, at 8:52 AM, f...@48lvckh6395k16k5.yundunddos.com wrote:
>>
>> From: Gao Feng
>>
>> The PPTP is encapsulated by GRE header with t
Hi Tom,
inline comments
On Thu, Aug 4, 2016 at 12:15 AM, Tom Herbert wrote:
> On Wed, Aug 3, 2016 at 7:52 AM, wrote:
>> From: Gao Feng
>>
>> The PPTP is encapsulated by GRE header with that GRE_VERSION bits
>> must contain one. But current GRE RPS needs the GRE_VERSION must be
>> zero. So RPS
ther.
Thanks both of you :-))
On Wed, Aug 3, 2016 at 12:01 PM, Tom Herbert wrote:
> On Tue, Aug 2, 2016 at 7:17 PM, Feng Gao wrote:
>> Thanks Tom's detail explanation.
>> It is my misinterpret because my mother language is not English.
>>
> No, the RFC is somew
Thanks Tom's detail explanation.
It is my misinterpret because my mother language is not English.
Thanks again:))
On Wed, Aug 3, 2016 at 9:59 AM, Tom Herbert wrote:
> On Tue, Aug 2, 2016 at 5:28 PM, Feng Gao wrote:
>> Hi Tom.
>>
>> I quote so
Hi Tom.
I quote some description in RFC 2637.
/*/
C
(Bit 0) Checksum Present. Set to zero (0).
R
(Bit 1) Routing Present. Set to zero (0).
K
(Bit 2) Key Present. Set to one (1).
S
(Bit 3)
Thanks Philp.
I get it, then i will send another update v3 patch soon.
On Wed, Aug 3, 2016 at 1:33 AM, Philp Prindeville
wrote:
> Inline...
>
>
> On 08/02/2016 12:10 AM, Feng Gao wrote:
>>
>> Thanks.
>> Because the original GRE uses the literal number direc
Thanks.
Because the original GRE uses the literal number directly, so I follow
this style.
Then I have two questions.
1. pptp_gre_header is defined in "drivers/net/ppp/pptp.c"; If we want
to use it, need to create one new header file, is it ok ?
2. The GRE version 0 patch could use the sizeof pptp
Hi Philp & Tom,
Thanks your advice.
I have send the update patch some days ago.
The link is http://www.spinics.net/lists/netdev/msg388083.html.
Could you help review it please?
Best Regards
Feng
On Thu, Jul 28, 2016 at 8:46 AM, Philp Prindeville
wrote:
> Inline...
>
>
>
> On 07/27/2016 06:04 P
g to the RFC, but
original GRE only ask the "GRE_VERSION|GRE_ROUTING" must be zero.
And the inner proto structures are different between with the original
GRE and PPTP GRE.
So I think it would be more awkful if consolidate these codes, unless
we don't check the flags strictly.
On Thu, J
Thanks Tom, I append some inline comments.
BTW, forgive me reply the email by gmail because the original mail
server doesn't support kernel email format.
I will send the update later.
Best Regards
Feng
On Thu, Jul 28, 2016 at 8:04 AM, Tom Herbert wrote:
>
> On Wed, Jul 27, 2016 at 4:42 PM, wr
58 matches
Mail list logo
