On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote:
>
> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> > >> From my understanding, we can do anything about the old qdisc (including
> > >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> &g
On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote:
> >> From my understanding, we can do anything about the old qdisc (including
> >> destorying the old qdisc) after some_qdisc_is_busy() return false.
> >
> > But the current code does the reset _before_ some_qdisc_is_busy(). ;)
>
> If lock is tak
On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin wrote:
>
> On 2020/10/30 3:05, Cong Wang wrote:
> >
> > I do not see how and why it should. synchronize_net() is merely an optimized
> > version of synchronize_rcu(), it should wait for RCU readers, softirqs are
> > n
On Thu, Oct 29, 2020 at 7:11 AM Joakim Tjernlund
wrote:
>
> OK, bisecting (was a bit of a bother since we merge upstream releases into
> our tree, is there a way to just bisect that?)
>
> Result was commit "net: sch_generic: aviod concurrent reset and enqueue op
> for lockless qdisc" (749cc0b0c
On Wed, Oct 28, 2020 at 7:54 PM Yunsheng Lin wrote:
>
> On 2020/9/18 3:26, Cong Wang wrote:
> > On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
> >>
> >> On 2020/9/11 4:07, Cong Wang wrote:
> >>> On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin
>
On Wed, Oct 28, 2020 at 8:37 AM Pai, Vishwanath wrote:
> Hi,
>
> We noticed some problems when testing the latest 5.4 LTS kernel and traced it
> back to this commit using git bisect. When running our tests the machine stops
> responding to all traffic and the only way to recover is a reboot. I do
On Tue, Oct 27, 2020 at 10:23 PM Tung Quang Nguyen
wrote:
>
> Hi Cong,
>
> No, I have never ignored any comment from reviewers. I sent v2 on Oct 26
> after discussing with Xin Long, and v3 on Oct 27 after receiving comment from
> Jakub.
> I received your 3 emails nearly at the same time on Oct 2
On Tue, Oct 27, 2020 at 2:39 PM Guillaume Nault wrote:
>
> On Tue, Oct 27, 2020 at 10:28:29AM -0700, Cong Wang wrote:
> > On Mon, Oct 26, 2020 at 4:23 AM Guillaume Nault wrote:
> > >
> > > TCA_MPLS_ACT_PUSH and TCA_MPLS_ACT_MAC_PUSH might be used on gso
> &g
reeing the fragment 2 times in
> case skb_unshare() returns NULL.
>
> Fixes: ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
> Acked-by: Jon Maloy
> Reported-by: Thang Hoang Ngo
> Signed-off-by: Tung Nguyen
Acked-by: Cong Wang
On Wed, Oct 28, 2020 at 6:59 AM Tom Rix wrote:
>
>
> On 10/28/20 4:35 AM, Lukas Bulwahn wrote:
> > @@ -2971,13 +2963,11 @@ static int tc_dump_chain(struct sk_buff *skb,
> > struct netlink_callback *cb)
> > if (!dev)
> > return skb->len;
> >
> > - pa
On Tue, Oct 27, 2020 at 1:09 PM Tung Nguyen
wrote:
>
> Commit ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
> replaced skb_unshare() with skb_copy() to not reduce the data reference
> counter of the original skb intentionally. This is not the correct
> way to handle the cloned
On Tue, Oct 27, 2020 at 11:21 AM Cong Wang wrote:
>
> On Mon, Oct 26, 2020 at 3:46 AM Tung Nguyen
> wrote:
> >
> > Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
> > replaced skb_unshare() with skb_copy() to not reduce the data refe
On Mon, Oct 26, 2020 at 3:46 AM Tung Nguyen
wrote:
>
> Commit ed42989eab57 ("fix the skb_unshare() in tipc_buf_append()")
> replaced skb_unshare() with skb_copy() to not reduce the data reference
> counter of the original skb intentionally. This is not the correct
> way to handle the cloned skb be
On Mon, Oct 26, 2020 at 4:23 AM Guillaume Nault wrote:
>
> TCA_MPLS_ACT_PUSH and TCA_MPLS_ACT_MAC_PUSH might be used on gso
> packets. Such packets will thus require mpls_gso.ko for segmentation.
Any reason not to call request_module() at run time?
ction gate offloading")
> Signed-off-by: Guillaume Nault
Looks like the err_out label can be just removed after this patch?
If any compiler complains, you have to fix it in v2, otherwise can be in a
separate patch.
Other than this,
Acked-by: Cong Wang
Thanks!
tunnel_key_get_opts_len(), like it's done for
> IPv4 tunnels.
Acked-by: Cong Wang
Thanks.
e to me,
Acked-by: Cong Wang
Thanks.
de Bruijn
Signed-off-by: Cong Wang
---
Note, there are some other suspicious use of dev->hard_header_len in
the same file, but let's leave them to a separate patch if really
needed.
v2: pass 0 to skb_cow_head()
v1: fix dev->needed_headroom and update ipgre_link_update()
net/ipv4/ip_
On Sun, Oct 11, 2020 at 3:46 PM Xie He wrote:
>
> On Sun, Oct 11, 2020 at 12:11 PM Cong Wang wrote:
> >
> > @@ -626,8 +626,7 @@ static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
> >
> > if (dev->header_ops) {
> > /* Need space fo
On Mon, Oct 12, 2020 at 2:53 AM Muchun Song wrote:
> We are not complaining about TCP using too much memory, but how do
> we know that TCP uses a lot of memory. When I firstly face this problem,
> I do not know who uses the 25GB memory and it is not shown in the
> /proc/meminfo.
> If we can know
On Sun, Oct 11, 2020 at 9:22 PM Muchun Song wrote:
>
> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> >
> > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > wrote:
> > >
> > > The amount of memory allocated to sockets buffer can become signifi
#syz fix: net_sched: check error pointer in tcf_dump_walker()
ijn
Signed-off-by: Cong Wang
---
Note, there are some other suspicious use of dev->hard_header_len in
the same file, but let's leave them to a separate patch if really
needed.
net/ipv4/ip_gre.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip
On Sat, Oct 10, 2020 at 3:39 AM Muchun Song wrote:
>
> The amount of memory allocated to sockets buffer can become significant.
> However, we do not display the amount of memory consumed by sockets
> buffer. In this case, knowing where the memory is consumed by the kernel
We do it via `ss -m`. Is
On Fri, Oct 9, 2020 at 8:10 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 6:07 PM Cong Wang wrote:
> >
> > Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
> > because 1) all other tunnels devices do not have it (ip_tunnel_header_ops
> > o
On Fri, Oct 9, 2020 at 1:38 PM Cong Wang wrote:
>
> Interesting point. I think needed_headroom is 0 until we call
> ipgre_changelink(), but needed_headroom is already being used
> in multiple places for skb_cow_head() in the same file, I guess
> they should be replaced with hard_h
On Fri, Oct 9, 2020 at 12:51 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 12:41 PM Xie He wrote:
> >
> > Thanks. But there is still something that I don't understand. What is
> > needed_headroom used for? If we are requesting space for t->encap_hlen
> > and t->tun_hlen in hard_header_len. Do we st
On Thu, Oct 8, 2020 at 4:40 PM Xie He wrote:
>
> I found another possible issue. Shouldn't we update hard_header_len
> every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
Good catch. It should be updated there like ->needed_headroom.
I will update my patch.
Thanks.
On Thu, Oct 8, 2020 at 10:34 AM Jakub Kicinski wrote:
>
> On Wed, 7 Oct 2020 23:18:21 -0700 Cong Wang wrote:
> > This fixes an uninit-value warning:
> > BUG: KMSAN: uninit-value in can_receive+0x26b/0x630 net/can/af_can.c:650
> >
> > Reported-and-tested-by:
On Thu, Oct 8, 2020 at 12:18 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 3:04 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> > >
> > > On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
> > > wrote
On Thu, Oct 8, 2020 at 1:45 AM Xin Long wrote:
>
> On Thu, Oct 8, 2020 at 12:12 PM Cong Wang wrote:
> >
> > skb_unshare() drops a reference count on the old skb unconditionally,
> > so in the failure case, we end up freeing the skb twice here.
> > And because the
On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
wrote:
>
> On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
> >
> > GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
> > conditionally. When it is set, it assumes the outer IP header is
> > alr
sij Rempel
Cc: Pengutronix Kernel Team
Cc: Oliver Hartkopp
Cc: Marc Kleine-Budde
Signed-off-by: Cong Wang
---
net/can/j1939/transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index 0cec4152f979..88cf1062e1e9 100644
--- a/net
ned-off-by: Cong Wang
---
net/tipc/msg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 52e93ba4d8e2..681224401871 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -150,7 +150,8 @@ int tipc_buf_append(struct sk_buff **headbuf, struc
if most other kernel structures are not aligned.
>
> This get rid of QDISC_ALIGN and QDISC_ALIGNTO.
>
> Addition of privdata field will help implementing
> the reverse of qdisc_priv() and documents where
> the private data is.
>
> Signed-off-by: Eric Dumazet
> Cc: C
as dev->hard_header_len is supposed to be the length of the header
created by dev->header_ops->create() anyway.
Reported-and-tested-by: syzbot+4a2c52677a8a1aa28...@syzkaller.appspotmail.com
Cc: William Tu
Cc: Willem de Bruijn
Signed-off-by: Cong Wang
---
net/ipv4/ip_gre.c | 2 ++
1 file change
ot;)
Cc: Vlad Buslov
Cc: Jamal Hadi Salim
Cc: Jiri Pirko
Signed-off-by: Cong Wang
---
net/sched/act_api.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 5612b336e18e..798430e1a79f 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -23
#syz test: https://github.com/congwang/linux.git net
On Wed, Sep 30, 2020 at 10:42 AM syzbot
wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:2b3e981a Merge branch 'mptcp-Fix-for-32-bit-DATA_FIN'
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1653724790
> kernel config:
#syz fix: net_sched: commit action insertions together
ggested-by: Davide Caratti
Cc: Jamal Hadi Salim
Cc: Jiri Pirko
Signed-off-by: Cong Wang
---
net/sched/act_api.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 104b47f5184f..5612b336e18e 100644
--- a/net/sched/act_api.c
+++ b
On Mon, Sep 28, 2020 at 3:14 AM Davide Caratti wrote:
>
> hello,
>
> On Fri, 2020-09-25 at 22:45 +0300, Vlad Buslov wrote:
> > On Fri 25 Sep 2020 at 22:22, Cong Wang wrote:
> > > On Fri, Sep 25, 2020 at 8:24 AM Vlad Buslov wrote:
> > > > &g
On Fri, Sep 25, 2020 at 8:24 AM Vlad Buslov wrote:
> > + if (TC_ACT_EXT_CMP(a->tcfa_action, TC_ACT_GOTO_CHAIN) &&
> > + !rcu_access_pointer(a->goto_chain)) {
> > + tcf_action_destroy_1(a, bind);
> > + NL_SET_ERR_MSG(extack, "can't use goto chain with NULL
> > c
-by: Cong Wang
---
include/net/act_api.h | 2 --
net/sched/act_api.c| 38 --
net/sched/act_bpf.c| 4 +---
net/sched/act_connmark.c | 1 -
net/sched/act_csum.c | 3 ---
net/sched/act_ct.c | 2 --
net/sched/act_ctinfo.c |
This patchset fixes a use-after-free triggered by syzbot. Please
find more details in each patch description.
---
Cong Wang (2):
net_sched: defer tcf_idr_insert() in tcf_action_init_1()
net_sched: commit action insertions together
include/net/act_api.h | 2 --
net/sched/act_api.c
)
Cc: Vlad Buslov
Cc: Jamal Hadi Salim
Cc: Jiri Pirko
Signed-off-by: Cong Wang
---
net/sched/act_api.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 0030f00234ee..104b47f5184f 100644
--- a
On Fri, Sep 11, 2020 at 1:13 AM Yunsheng Lin wrote:
>
> On 2020/9/11 4:07, Cong Wang wrote:
> > On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
> >>
> >> Currently there is concurrent reset and enqueue operation for the
> >> same lockless qdisc when the
On Sun, Sep 13, 2020 at 7:10 PM Yunsheng Lin wrote:
>
> On 2020/9/11 4:19, Cong Wang wrote:
> > On Thu, Sep 3, 2020 at 8:21 PM Kehuan Feng wrote:
> >> I also tried Cong's patch (shown below on my tree) and it could avoid
> >> the issue (stressing for 30 min
On Wed, Sep 16, 2020 at 11:05 PM Xiaoyong Yan wrote:
>
> in the function cbs_dequeue_soft, when q->credits <0, [now - q->last]
> should be accounted for sendslope,not idleslope.
>
> so the solution as follows: when q->credits is less than 0, directly
> calculate delay time, activate hrtimer and wh
On Wed, Sep 16, 2020 at 9:33 AM YueHaibing wrote:
>
> It is never used, so can remove it.
This is a bit confusing, it was actually used before, see commit
ab0d76f6823cc3a4e2.
On Thu, Sep 3, 2020 at 8:21 PM Kehuan Feng wrote:
> I also tried Cong's patch (shown below on my tree) and it could avoid
> the issue (stressing for 30 minutus for three times and not jitter
> observed).
Thanks for verifying it!
>
> --- ./include/net/sch_generic.h.orig 2020-08-21 15:13:51.787952
On Thu, Sep 3, 2020 at 10:08 PM John Fastabend wrote:
> Maybe this would unlock us,
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 7df6c9617321..9b09429103f1 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3749,7 +3749,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb,
On Tue, Sep 8, 2020 at 4:06 AM Yunsheng Lin wrote:
>
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by dev_deactivate
On Sat, Sep 5, 2020 at 12:28 AM Yang Yingliang wrote:
>
> Hi,
>
> I got some crashes when using connector module in linux-4.19:
Can you test a reasonably recent kernel?
> The invalid address[0x0003004c] is the value of nlmsghdr from cn
> netlink, nlmsg_type is 3 and nlmsg_len is 0x4c.
(), this is fine because we only need
to load modules we need potentially.
Reported-and-tested-by: syzbot+80e32b5d1f9923f8a...@syzkaller.appspotmail.com
Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
Cc: Jamal Hadi Salim
Cc: Vlad Buslov
Cc: Jiri Pirko
Signed-of
On Thu, Sep 3, 2020 at 2:47 AM Eric Dumazet wrote:
> This commit might be related :
>
> commit 4e407ff5cd67ec76a1deec227b7982dc7f66
> Author: Cong Wang
> Date: Sun Aug 19 12:22:12 2018 -0700
>
> act_ife: move tcfa_lock down to where necessary
It does not look l
On Thu, Sep 3, 2020 at 1:40 AM Paolo Abeni wrote:
>
> On Wed, 2020-09-02 at 22:01 -0700, Cong Wang wrote:
> > Can you test the attached one-line fix? I think we are overthinking,
> > probably all
> > we need here is a busy wait.
>
> I think that will solve, but I al
Hello, Kehuan
Can you test the attached one-line fix? I think we are overthinking,
probably all
we need here is a busy wait.
Thanks.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d60e7c39d60c..fc1bacdb102b 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_gen
On Wed, Sep 2, 2020 at 7:22 PM Yunsheng Lin wrote:
>
> On 2020/9/3 9:48, Cong Wang wrote:
> > On Wed, Sep 2, 2020 at 6:22 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/3 8:35, Cong Wang wrote:
> >>> On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin
> >
On Wed, Sep 2, 2020 at 6:22 PM Yunsheng Lin wrote:
>
> On 2020/9/3 8:35, Cong Wang wrote:
> > On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/2 12:41, Cong Wang wrote:
> >>> On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin
> &g
On Tue, Sep 1, 2020 at 11:35 PM Yunsheng Lin wrote:
>
> On 2020/9/2 12:41, Cong Wang wrote:
> > On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin wrote:
> >>
> >> On 2020/9/2 2:24, Cong Wang wrote:
> >>> On Mon, Aug 31, 2020 at 5:59 PM Yunsheng Lin
>
On Tue, Sep 1, 2020 at 6:42 PM Yunsheng Lin wrote:
>
> On 2020/9/2 2:24, Cong Wang wrote:
> > On Mon, Aug 31, 2020 at 5:59 PM Yunsheng Lin wrote:
> >>
> >> Currently there is concurrent reset and enqueue operation for the
> >> same lockless qdisc when the
On Mon, Aug 31, 2020 at 5:59 PM Yunsheng Lin wrote:
>
> Currently there is concurrent reset and enqueue operation for the
> same lockless qdisc when there is no lock to synchronize the
> q->enqueue() in __dev_xmit_skb() with the qdisc reset operation in
> qdisc_deactivate() called by dev_deactivat
On Tue, Aug 25, 2020 at 1:45 AM wrote:
>
> From: wenxu
>
> The fragment packets do defrag in act_ct module. If the reassembled
> packet should send out to another net device. This over mtu big packet
> should be fragmented to send out. This patch add the act ct_output to
> archive this.
There ar
On Tue, Aug 25, 2020 at 8:33 AM Marcelo Ricardo Leitner
wrote:
> I still don't understand Cong's argument for not having this on
> act_mirred because TC is L2. That's actually not right. TC hooks at L2
You miss a very important point that it is already too late to rename
act_mirred to reflect wha
-tested-by: syzbot+b33c1cb0a30ebdc8a...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+e5ea5f8a3ecfd4427...@syzkaller.appspotmail.com
Cc: Petr Machata
Signed-off-by: Cong Wang
---
net/sched/sch_red.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/net/sched/s
On Mon, Aug 17, 2020 at 2:39 PM David Miller wrote:
>
> From: Cong Wang
> Date: Mon, 17 Aug 2020 13:59:46 -0700
>
> > Is this a new Kconfig feature? ipv6_stub was introduced for
> > VXLAN, at that time I don't remember we have such kind of
> > Kconfig rule
On Mon, Aug 17, 2020 at 1:43 PM Randy Dunlap wrote:
>
> On 8/17/20 1:29 PM, Cong Wang wrote:
> > On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap wrote:
> >>
> >> TIPC=m and IPV6=m builds just fine.
> >>
> >> Having tipc autoload ipv6 is a different
On Mon, Aug 17, 2020 at 12:55 PM Randy Dunlap wrote:
>
> TIPC=m and IPV6=m builds just fine.
>
> Having tipc autoload ipv6 is a different problem. (IMO)
>
>
> This Kconfig entry:
> menuconfig TIPC
> tristate "The TIPC Protocol"
> depends on INET
> + depends on IPV6 || IPV6=n
On Mon, Aug 17, 2020 at 4:19 AM Jamal Hadi Salim wrote:
>
> On 2020-08-16 2:59 p.m., Cong Wang wrote:
> > On Thu, Aug 13, 2020 at 5:52 AM Jamal Hadi Salim wrote:
>
>
> [..]
> >> How do you know whether to use hash or mark or both
> >> for that
On Mon, Aug 17, 2020 at 12:00 PM Randy Dunlap wrote:
>
> On 8/17/20 11:55 AM, Cong Wang wrote:
> > On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap wrote:
> >>
> >> On 8/17/20 11:31 AM, Cong Wang wrote:
> >>> On Sun, Aug 16, 2020 at 11:37 PM Xin Long wrot
On Sun, Aug 16, 2020 at 10:45 PM Christoph Hellwig wrote:
>
> On Sun, Aug 16, 2020 at 10:55:09AM -0700, Cong Wang wrote:
> > On Sun, Aug 16, 2020 at 1:36 AM Coly Li wrote:
> > >
> > > The original problem was from nvme-over-tcp code, who mistakenly uses
> &g
On Mon, Aug 17, 2020 at 11:49 AM Randy Dunlap wrote:
>
> On 8/17/20 11:31 AM, Cong Wang wrote:
> > On Sun, Aug 16, 2020 at 11:37 PM Xin Long wrote:
> >>
> >> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang wrote:
> >>>
> >>> Or put it into struc
On Sun, Aug 16, 2020 at 11:37 PM Xin Long wrote:
>
> On Mon, Aug 17, 2020 at 2:29 AM Cong Wang wrote:
> >
> > Or put it into struct ipv6_stub?
> Hi Cong,
>
> That could be one way. We may do it when this new function becomes more
> common.
> By now, I think it&#
On Thu, Aug 13, 2020 at 5:52 AM Jamal Hadi Salim wrote:
>
> The _main_ requirement is to scale to a large number of filters
> (a million is a good handwave number). Scale means
> 1) fast datapath lookup time + 2) fast insertion/deletion/get/dump
> from control/user space.
> fwmark is good at all t
On Sun, Aug 16, 2020 at 4:54 AM Xin Long wrote:
>
> When using ipv6_dev_find() in one module, it requires ipv6 not to
> work as a module. Otherwise, this error occurs in build:
>
> undefined reference to `ipv6_dev_find'.
>
> So fix it by adding "depends on IPV6 || IPV6=n" to tipc/Kconfig,
> as i
On Sun, Aug 16, 2020 at 1:36 AM Coly Li wrote:
>
> The original problem was from nvme-over-tcp code, who mistakenly uses
> kernel_sendpage() to send pages allocated by __get_free_pages() without
> __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on
> tail pages, sending them by ke
re attrs in __tipc_nl_compat_dumpit()") makes it
easier to appear.
Reported-and-tested-by: syzbot+0e7181deafa7e0b79...@syzkaller.appspotmail.com
Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat")
Cc: Jon Maloy
Cc: Ying Xue
Cc: Richard Alpe
Signed-off-by: Cong Wang
---
net/
ned-off-by: Cong Wang
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5ad43aaf76e5..995fcb4eed92 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/b
ich can be invoked by __dp_destroy or ovs_flow_tbl_flush.
>
> Fixes: 50b0e61b32ee ("net: openvswitch: fix possible memleak on destroy
> flow-table")
> Reported-by: Johan Knöös
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-August/050489.html
&
On Wed, Aug 12, 2020 at 2:21 AM linmiaohe wrote:
>
> Hi all:
> David Miller wrote:
> >From: Cong Wang
> >Date: Tue, 11 Aug 2020 16:02:51 -0700
> >
> >>> @@ -3406,6 +3406,16 @@ static void sock_inuse_add(struct net *net,
> >>> int val) } #en
On Mon, Aug 10, 2020 at 6:14 PM wrote:
>
> From: Tonghao Zhang
>
> To avoid some issues, for example RCU usage warning, we should
> flush the flows under ovs_lock. This patch refactors
> table_instance_destroy and introduces table_instance_flow_flush
> which can be invoked by __dp_destroy or ovs_
On Mon, Aug 10, 2020 at 10:59 PM Tonghao Zhang wrote:
>
> On Tue, Aug 11, 2020 at 12:08 PM Cong Wang wrote:
> >
> > On Mon, Aug 10, 2020 at 8:27 PM Tonghao Zhang
> > wrote:
> > >
> > > On Tue, Aug 11, 2020 at 10:24 AM Cong Wang
> > > wro
On Sun, Aug 9, 2020 at 4:41 PM Jamal Hadi Salim wrote:
>
> Interesting idea. Note: my experience is that typical setup is
> to have only one of those (from offload perspective). Ariel,
> are your use cases requiring say both fields?
>
> From policy perspective, i think above will get more complex
On Mon, Aug 10, 2020 at 5:19 AM Miaohe Lin wrote:
>
> If we failed to assign proto idx, we free the twsk_slab_name but forget to
> free the twsk_slab. Add a helper function tw_prot_cleanup() to free these
> together and also use this helper function in proto_unregister().
>
> Fixes: b45ce32135d1 (
On Mon, Aug 10, 2020 at 8:27 PM Tonghao Zhang wrote:
>
> On Tue, Aug 11, 2020 at 10:24 AM Cong Wang wrote:
> >
> > On Mon, Aug 10, 2020 at 6:16 PM Tonghao Zhang
> > wrote:
> > > Hi all, I send a patch to fix this. The rcu warnings disappear. I
> >
On Mon, Aug 10, 2020 at 3:10 PM Peilin Ye wrote:
>
> do_ip_vs_set_ctl() is referencing uninitialized stack value when `len` is
> zero. Fix it.
Which exact 'cmd' is it here?
I _guess_ it is one of those uninitialized in set_arglen[], which is 0.
But if that is the case, should it be initialized t
On Mon, Aug 10, 2020 at 6:16 PM Tonghao Zhang wrote:
> Hi all, I send a patch to fix this. The rcu warnings disappear. I
> don't reproduce the double free issue.
> But I guess this patch may address this issue.
>
> http://patchwork.ozlabs.org/project/netdev/patch/20200811011001.75690-1-xiangxia.m.
On Fri, Aug 7, 2020 at 3:28 PM Jamal Hadi Salim wrote:
>
> From: Jamal Hadi Salim
>
> his classifier, in the same spirit as the tc skb mark classifier,
> provides a generic (fast lookup) approach to filter on the hash value
> and optional mask.
>
> like skb->mark, skb->hash could be set by multip
On Sat, Aug 8, 2020 at 10:07 AM Gaurav Singh wrote:
>
> This PR fixes a possible segmentation violation.
>
> In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
> unconditionally (regardless sk being NULL or not).
>
> In include/linux/ipv6.h:
>
> stat
On Fri, Aug 7, 2020 at 8:33 AM Johan Knöös wrote:
>
> On Tue, Aug 4, 2020 at 8:52 AM Gregory Rose wrote:
> >
> >
> >
> > On 8/3/2020 12:01 PM, Johan Knöös via discuss wrote:
> > > Hi Open vSwitch contributors,
> > >
> > > We have found openvswitch is causing double-freeing of memory. The
> > > is
On Fri, Aug 7, 2020 at 8:16 AM Jamal Hadi Salim wrote:
>
> I am guessing the hash table got too large.
> Smells like hard coded expectation?
Yeah, that is literally how kfree_rcu() works.
>
> How to fix?
I guess you just have to wrap up kfree() and pass it
to call_rcu().
Thanks.
On Thu, Aug 6, 2020 at 10:21 AM satish dhote wrote:
>
> Hi Cong,
>
> I tried adding below patch i.e. "return cl == 0 ? q->block : NULL;"
> but after this I'm not able to see any output using "tc filter show... "
> command. Looks like the filter is not getting configured.
What exact command did yo
Hello,
On Tue, Aug 4, 2020 at 10:39 PM satish dhote wrote:
>
> Hi Team,
>
> I have a question regarding tc filter behavior. I tried to look
> for the answer over the web and netdev FAQ but didn't get the
> answer. Hence I'm looking for your help.
>
> I added ingress qdisc for interface enp0s25 an
On Tue, Aug 4, 2020 at 9:14 AM wrote:
>
> From: Izabela Bakollari
>
> Dropwatch is a utility that monitors dropped frames by having userspace
> record them over the dropwatch protocol over a file. This augument
> allows live monitoring of dropped frames using tools like tcpdump.
>
> With this fea
set the mru
> to the qdisc_skb_cb when the packet defrag. And When the chain miss,
> The mru is set to tc_skb_ext which can be got by ovs datapath.
>
> Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
> Signed-off-by: wenxu
Reviewed-by: Cong Wang
Thanks.
On Thu, Jul 30, 2020 at 1:53 AM wenxu wrote:
>
>
> On 7/30/2020 2:03 PM, Cong Wang wrote:
> > On Wed, Jul 29, 2020 at 3:41 AM wrote:
> >> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> >> index c510b03..45401d5 100644
> >> --- a/in
lidate(const struct sk_buff *skb, int sz)
{
struct qdisc_skb_cb *qcb;
BUILD_BUG_ON(sizeof(skb->cb) < offsetof(struct qdisc_skb_cb,
data) + sz);
BUILD_BUG_ON(sizeof(qcb->data) < sz);
}
It _kinda_ expects ->data at the end.
The rest of your patch looks good to me, so feel free to add:
Reviewed-by: Cong Wang
Thanks.
Hello,
On Mon, Jul 27, 2020 at 12:41 PM Xie He wrote:
>
> Hi Cong Wang,
>
> I'm wishing to change a driver from using "hard_header_len" to using
> "needed_headroom" to declare its needed headroom. I submitted a patch
> and it is decided it need
On Mon, Jul 27, 2020 at 7:14 PM Gaurav Singh wrote:
>
> Add return to fix build issue. Haven't reproduced this issue at
> my end.
>
> My hypothesis is this: In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL.
>
> Further down the function, there's a c
401 - 500 of 2972 matches
Mail list logo
