Re:Re: [EXT] [PATCH v3] octeontx2-af: Fix missing check bugs in rvu_cgx.c

Thanks for your reply. I have resended the email with the Reviewed-by tag. At 2021-01-15 18:58:49, "Geethasowjanya Akula" wrote: >The changes look good to me. > >You can add: >Reviewed-by: Geetha sowjanya > > >From: wangyingji...@126.com >Sent: Thursday, Ja

Re:Re: [PATCH v2] af/rvu_cgx: Fix missing check bugs in rvu_cgx.c

Thanks for your reply. I commit this change on linux-next/stable branch, and I use "git log --pretty=fixes" command to get the Fixes tag. I want to know if I need to make a change on any other branch and commit it? At 2021-01-13 10:13:28, "Jakub Kicinski" wrote: >On Mon, 11 Jan 2021 18:09:49 -0

Re:Re: linux-next: ERROR: build error for arm64

At 2020-12-06 16:25:19, "Björn Töpel" wrote: Ok, thanks.

Re:Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR

>On Thu, 12 Nov 2020 09:15:05 +0800 (GMT+08:00) 王擎 wrote: >> >Grygorii, would you mind sending a correct patch in so Wang Qing can >> >see how it's done? I've been asking for a fixes tag multiple times >> >already :( >> >> I still don't quite understand what a fixes tag means， >> can you tell me

Re:Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR

>> On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote: >> > >> > Following Richard's comments v1 of the patch has to be applied [1]. >> > I've also added my Reviewed-by there. >> > >> > [1] https://lore.kernel.org/patchwork/patch/1334067/ >> >> +1 >> >> Jakub, can you please ta

Re:Re: [PATCH] soc: qmi: allow user to set handle wq to hiprio

>> Currently the qmi_handle is initialized single threaded and strictly >> ordered with the active set to 1. This is pretty simple and safe but >> sometimes ineffency. So it is better to allow user to decide whether >> a high priority workqueue should be used. > >Can you please describe a scenario

RE:Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

> -Original Message- > From: Jamal Hadi Salim > Sent: 2020年6月24日 20:45 > To: Po Liu ; da...@davemloft.net; linux- > ker...@vger.kernel.org; netdev@vger.kernel.org; ido...@idosch.org > Cc: j...@resnulli.us; vinicius.go...@intel.com; v...@buslov.dev; Claudiu > Manoil ; Vladimir Oltean > ;

RE:Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

Hi Ido, Sorry, ignore previous email. > -Original Message- > From: Ido Schimmel > Sent: 2020年6月23日 15:10 > To: Po Liu > Cc: da...@davemloft.net; linux-ker...@vger.kernel.org; > netdev@vger.kernel.org; j...@resnulli.us; vinicius.go...@intel.com; > v...@buslov.dev; Claudiu Manoil ; Vladim

Re:Re: [PATCH net] net: defxx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles

At 2019-02-06 03:57:34, "Maciej W. Rozycki" wrote: >On Wed, 6 Feb 2019, Yang Wei wrote: > >Reviewed-by: Maciej W. Rozycki > > It looks to me the driver has to be reviewed WRT `dev_kfree_skb' vs >`kfree_skb' use too. I'll have a look into it unless you are happy to do >that. > > Thanks for your

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" 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:55, "Willem de Bruijn" wrote: >On Thu, May 10, 2

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" 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 The skb flow limit is implemented for each CPU independently.

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

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 >> this_cpu_ptr. But the target cpu of

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

At 2018-05-11 08:55:47, "Eric Dumazet" wrote: > > >On 05/10/2018 05:18 PM, Gao Feng wrote: >> 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

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

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 the softnet_data by >> this_cpu_ptr. But the ta

Re:Re: [PATCH v3] net: davicom: dm9000: Avoid spinlock recursion during dm9000_timeout routine

Hi, Because the timeout task gets the main spinlock and disable the current cpu's irq, there is no other task on the same cpu can run, and tasks on the other cpus can not enter the dm9000_timeout() again. So in the whole dm9000_timeout() routine, db->timeout_cpu can not be changed by other tas

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

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 this function when the cork->opt is NULL. But >>> the memory isn't fre

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

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 if failed in the latter rt check, and return error >> d

Re:Re:

Good Day I am Chao; I have emailed you earlier on without any response from you. please do email me for Comprehensive details Regards Mr Chao Wei.

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 >> >> 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. > >$ git grep -w skb_header_release >driver

Re:Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook

On Fri, Sep 15, 2017 at 10:46 AM, Willem de Bruijn wrote: > > In case of failure we also need to unlink and free match. I > sent the following: > > http://patchwork.ozlabs.org/patch/813945/ + spin_lock(&po->bind_lock); + if (po->running && + match->type == type &&

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" 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" check to avoid unnecessary search, because >>> the qdisc uses the sk

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" 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() to pptp_release >> after del_chan() to avoid one schedu

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" 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 >> really. >> >> I checked the SOCK_RCU_FREE, it just

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" 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_rcu to make sure it, and >> actually there

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

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 > really. > > I checked the SOCK_RCU_FREE, it just defer the __sk_destruct after one rcu > period. > B

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

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_rcu to make sure it, and > actually there is no one which would invoke del_chan except pptp

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" 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? >> >>I already told you, the dereference happends before sock_hold(). >> >>so

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" 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(). > >sock = rcu_dereference(callid_sock[call_id]); >

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

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(). sock = rcu_dereference(callid_sock[call_id]); if (sock) { opt = &sock->proto.ppt

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

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_generic.c >> >@@ -1915,21 +1915,23 @@ static void __ppp_channel_pu

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(). And the >> pppox_sock is freed when the last refcnt i

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

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 6:35 PM, wrote: >> >> > From: Gao Feng >> >> > >> >>

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(&rfs_needed)) >> +_sock_rps_

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

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 it is unnecessary to reset the >> RFS table en

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 sk_buff >> *skb) >> { >>

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 the skb is queued or freed directly by the

Re:Re: [drivers/net/vxlan]Why rcu_read_lock is not obtained before rculist travelling

Hi Cong, Thanks very much for your reply. It's indeeded acquired by upper layer. Thanks At 2017-03-01 05:29:17, "Cong Wang" wrote: >On Tue, Feb 28, 2017 at 6:03 AM, Xiaobo Yan wrote: >> But I don’t find any rcu_read_lock invoked before travelling fdb_head list. >> In vxlan_xmit and vxlan_s

RE:RE: is it useful testing __LINK_STATE_RX_SCHED in dev_close()?

__LINK_STATE_RX_SCHED still exist in kernel 2.6.23.8. Netdevice.h: /* Test if receive needs to be scheduled */ static inline int __netif_rx_schedule_prep(struct net_device *dev) { return !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state); } /* Test if receive needs to be scheduled bu