On Sun, Jul 26, 2020 at 8:39 PM Gaurav Singh wrote:
>
> ipv6_pinfo is initlialized by inet6_sk() which returns NULL.
Why? It only returns NULL for timewait or request sock, but
I don't see how ip6_autoflowlabel() could be called on these
sockets. So please explain.
> Hence it can cause segmentat
On Sat, Jul 25, 2020 at 11:12 PM B K Karthik wrote:
>
> On Sun, Jul 26, 2020 at 11:05 AM Cong Wang wrote:
> >
> > On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote:
> > > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net
> > > *net, u3
On Sat, Jul 25, 2020 at 8:09 PM B K Karthik wrote:
> @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net,
> u32 spi)
> {
> struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
> struct xfrm6_tunnel_spi *x6spi;
> - int index = xfrm6_tunnel_spi_
&value, sizeof(value));
close(s);
return 0;
}
Reported-by: ch333...@gmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Cong Wang
---
include/net/addrconf.h | 1 +
net/ipv6/anycast.c | 17 -
net/ipv6/ipv6_sockglue.c | 1 +
3 files cha
sched: sch_red: Add qevents "early_drop" and "mark"")
Cc: Petr Machata
Cc: Jamal Hadi Salim
Cc: Jiri Pirko
Signed-off-by: Cong Wang
---
net/sched/sch_red.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/sched/sch_red.c b/net/sche
On Thu, Jul 23, 2020 at 5:06 PM \xcH3332\ wrote:
>
> Hi,
>
> SYZKALLER found the following Memory Leak
Thanks for your report!
Can you test the attached patch? I only did compile test as I don't
have an environment to run syz programs.
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
.appspotmail.com
Fixes: 28fb4e59a47d ("net: qrtr: Expose tunneling endpoint to user space")
Cc: Bjorn Andersson
Cc: Eric Dumazet
Signed-off-by: Cong Wang
---
net/qrtr/qrtr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 24a8c3c6da0d..300
On Thu, Jul 23, 2020 at 11:00 PM Cong Wang wrote:
>
> I said socket, not sock. I believe the socket can be gone while the sock is
> still there.
Hmm, looks llike sock_orphan() should be called...
On Thu, Jul 23, 2020 at 10:35 PM Eric Dumazet wrote:
>
>
>
> On 7/23/20 9:50 PM, Cong Wang wrote:
> > Similar to tun_net_xmit(), we have to orphan the skb
> > before queuing it, otherwise we may use the socket when
> > purging the queue after it is freed by user
point to user space")
Cc: Bjorn Andersson
Signed-off-by: Cong Wang
---
net/qrtr/tun.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/qrtr/tun.c b/net/qrtr/tun.c
index 15ce9b642b25..54a565dcfef3 100644
--- a/net/qrtr/tun.c
+++ b/net/qrtr/tun.c
@@ -20,6 +20,7 @@ static int qrtr_tun_s
#syz test: https://github.com/congwang/linux.git net
#syz test: https://github.com/congwang/linux.git net
mail.com
Cc: Sabrina Dubroca
Signed-off-by: Cong Wang
---
drivers/net/geneve.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 4661ef865807..dec52b763d50 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1615,11 +1
link")
Reported-and-tested-by: syzbot+bbc3a11c4da63c1b7...@syzkaller.appspotmail.com
Cc: Beniamino Galvani
Cc: Taehee Yoo
Cc: Jay Vosburgh
Signed-off-by: Cong Wang
---
drivers/net/bonding/bond_netlink.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/bondi
#syz test: https://github.com/congwang/linux.git net
On Tue, Jul 21, 2020 at 6:17 AM guodeqing wrote:
>
> The ip header checksum can be error in the following steps.
> $ ip netns add ns1
> $ ip link add gw link eth0 type ipvlan
> $ ip addr add 168.16.0.1/24 dev gw
> $ ip link set dev gw up
> $ ip link add ip1 link eth0 type ipvlan
> $ ip link set ip
On Mon, Jul 20, 2020 at 1:10 AM Jiri Pirko wrote:
> diff --git a/include/linux/hashtable.h b/include/linux/hashtable.h
> index 78b6ea5fa8ba..f6c666730b8c 100644
> --- a/include/linux/hashtable.h
> +++ b/include/linux/hashtable.h
> @@ -173,9 +173,9 @@ static inline void hash_del_rcu(struct hlist_no
On Sat, Jul 18, 2020 at 12:14 AM Taehee Yoo wrote:
>
> If register_netdevice() is failed, net_device should not be used
> because variables are uninitialized or freed.
> So, the routine should be stopped immediately.
> But, bond_create() doesn't check return value of register_netdevice()
> immedia
On Wed, Jul 15, 2020 at 2:17 PM Florian Westphal wrote:
>
> Jakub Kicinski wrote:
> > On Tue, 7 Jul 2020 12:55:08 +0800 we...@ucloud.cn wrote:
> > > From: wenxu
> > >
> > > Add nf_ct_frag_gather and Make nf_ct_frag6_gather elide the CB clear
> > > when packets are defragmented by connection tra
On Mon, Jul 13, 2020 at 8:17 PM Ariel Levkovich wrote:
>
> On 7/13/20 6:04 PM, Cong Wang wrote:
> > On Sat, Jul 11, 2020 at 2:28 PM Ariel Levkovich wrote:
> >> Allow user to set a packet's hash value using a bpf program.
> >>
> >> The user provided B
On Tue, Jul 14, 2020 at 6:27 PM Weilong Chen wrote:
>
> When vlan_newlink call register_vlan_dev fails, it might return error
> with dev->reg_state = NETREG_UNREGISTERED. The rtnl_newlink should
> free the memory. But currently rtnl_newlink only free the memory which
> state is NETREG_UNINITIALIZE
On Thu, Jul 9, 2020 at 12:53 PM Thomas Habets wrote:
>
> Here's a test program that illustrates the problem:
> https://github.com/ThomasHabets/radiostuff/blob/master/ax25/axftp/examples/client_lockcheck.cc
>
> Before this patch, this hangs, because the read(2) blocks the
> write(2).
>
> I see that
On Fri, Jul 10, 2020 at 7:40 AM Petr Machata wrote:
>
>
> Cong Wang writes:
>
> > On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
> >>
> >>
> >> Petr Machata writes:
> >>
> >> > Cong Wang writes:
> >> >
On Sat, Jul 11, 2020 at 2:28 PM Ariel Levkovich wrote:
>
> Allow user to set a packet's hash value using a bpf program.
>
> The user provided BPF program is required to compute and return
> a hash value for the packet which is then stored in skb->hash.
Can be done by act_bpf, right?
>
> Using th
On Thu, Jul 9, 2020 at 11:07 PM YU, Xiangning
wrote:
>
>
> On 7/9/20 10:20 PM, Cong Wang wrote:
> > On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> >> IOW, without these *additional* efforts, it is broken in terms of
> >> out-of-order.
> >>
> >
On Thu, Jul 9, 2020 at 10:49 PM YU, Xiangning
wrote:
>
> Well, we do ask packets from a flow to be classified to a single class, not
> multiple ones. It doesn't have to be socket priority, it could be five tuple
> hash, or even container classid.
I don't see how it is so in your code, without s
On Thu, Jul 9, 2020 at 10:04 PM Cong Wang wrote:
> IOW, without these *additional* efforts, it is broken in terms of
> out-of-order.
>
Take a look at fq_codel, it provides a hash function for flow classification,
fq_codel_hash(), as default, thus its default configuration does not
On Wed, Jul 8, 2020 at 2:07 PM YU, Xiangning
wrote:
>
>
>
> On 7/8/20 1:24 PM, Cong Wang wrote:
> > On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
> > wrote:
> >>
> >> The key is to avoid classifying packets from a same flow into different
> >
On Thu, Jul 9, 2020 at 4:32 PM David Miller wrote:
>
>
> From: Cong Wang
>
> In order for no_refcnt and is_data to be the lowest order two
> bits in the 'val' we have to pad out the bitfield of the u8.
>
> Fixes: ad0f75e5f57c ("cgroup: fix cgroup_sk_allo
On Wed, Jul 8, 2020 at 5:13 PM Petr Machata wrote:
>
>
> Petr Machata writes:
>
> > Cong Wang writes:
> >
> > I'll think about it some more. For now I will at least fix the lack of
> > locking.
>
> I guess I could store smp_processor_id() that acq
On Thu, Jul 9, 2020 at 12:13 PM Guenter Roeck wrote:
>
> On 7/9/20 11:51 AM, Cong Wang wrote:
> > On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> >>
> >> Something seems fishy with the use of skcd->val on big endian systems.
> >>
> >&g
On Thu, Jul 9, 2020 at 11:51 AM Cong Wang wrote:
>
> On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
> >
> > Something seems fishy with the use of skcd->val on big endian systems.
> >
> > Some debug output:
> >
> > [ 22.643703] sock:
On Thu, Jul 9, 2020 at 10:10 AM Guenter Roeck wrote:
>
> Something seems fishy with the use of skcd->val on big endian systems.
>
> Some debug output:
>
> [ 22.643703] sock: # sk_alloc(sk=1be28100): Calling
> cgroup_sk_alloc(1be28550)
> [ 22.643807] cgroup: # cgroup_sk
sched: introduce tcf block infractructure")
Reported-and-tested-by: syzbot+d411cff6ab29cc2c3...@syzkaller.appspotmail.com
Cc: Jamal Hadi Salim
Cc: Jiri Pirko
Signed-off-by: Cong Wang
---
net/sched/sch_atm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/sched
On Tue, Jul 7, 2020 at 2:24 PM YU, Xiangning
wrote:
>
> The key is to avoid classifying packets from a same flow into different
> classes. So we use socket priority to classify packets. It's always going to
> be correctly classified.
>
> Not sure what do you mean by default configuration. But we
On Tue, Jul 7, 2020 at 7:18 AM Paolo Abeni wrote:
> So the regression with 2 pktgen threads is still relevant. 'perf' shows
> relevant time spent into net_tx_action() and __netif_schedule().
So, touching the __QDISC_STATE_SCHED bit in __dev_xmit_skb() is
not a good idea.
Let me see if there is a
On Wed, Jul 8, 2020 at 12:07 PM Guenter Roeck wrote:
>
> On 7/8/20 11:34 AM, Cong Wang wrote:
> > Hi,
> >
> > On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
> >> This patch causes all my s390 boot tests to crash. Reverting it fixes
> >> the proble
On Wed, Jul 8, 2020 at 9:21 AM Petr Machata wrote:
>
> Actually I guess I could qdisc_refcount_inc() the current qdisc so that
> it doesn't go away. Then when enqueing I could access the child
> directly, not relying on the now-obsolete cache from the beginning of
> the enqueue function. I suppose
On Wed, Jul 8, 2020 at 5:35 AM Petr Machata wrote:
> Do you have another solution in mind here? I think the deadlock (in both
> classification and qevents) is an issue, but really don't know how to
> avoid it except by dropping the lock.
Ideally we should only take the lock once, but it clearly r
Hi,
On Wed, Jul 8, 2020 at 8:33 AM Guenter Roeck wrote:
> This patch causes all my s390 boot tests to crash. Reverting it fixes
> the problem. Please see bisect results and and crash log below.
>
...
> Crash log:
Interesting. I don't see how unix socket is any special here, it creates
a peer soc
On Fri, Jun 26, 2020 at 3:46 AM Maxim Mikityanskiy wrote:
>
> HTB doesn't scale well because of contention on a single lock, and it
> also consumes CPU. Mellanox hardware supports hierarchical rate limiting
> that can be leveraged by offloading the functionality of HTB.
True, essentially because
On Mon, Jul 6, 2020 at 1:34 PM YU, Xiangning
wrote:
>
>
>
> On 7/6/20 1:10 PM, Cong Wang wrote:
> > On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
> > wrote:
> >> +static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
> >> *roo
On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> The function tcf_qevent_handle() should be invoked when qdisc hits the
> "interesting event" corresponding to a block. This function releases root
> lock for the duration of executing the attached filters, to allow packets
> generated through u
On Tue, Jul 7, 2020 at 8:25 AM Petr Machata wrote:
>
>
> Cong Wang writes:
>
> > On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> >>
> >> A following patch introduces qevents, points in qdisc algorithm where
> >> packet can be processed by
On Tue, Jul 7, 2020 at 8:22 AM Petr Machata wrote:
>
>
> Cong Wang writes:
>
> > On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> >> The function tcf_qevent_handle() should be invoked when qdisc hits the
> >> "interesting event" corresp
On Mon, Jul 6, 2020 at 11:11 AM YU, Xiangning
wrote:
> +static int ltb_enqueue(struct sk_buff *skb, struct Qdisc *sch, spinlock_t
> *root_lock,
> + struct sk_buff **to_free)
> +{
> + struct ltb_sched *ltb = qdisc_priv(sch);
> + struct ltb_pcpu_sched *pcpu_q;
> +
On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
> The function tcf_qevent_handle() should be invoked when qdisc hits the
> "interesting event" corresponding to a block. This function releases root
> lock for the duration of executing the attached filters, to allow packets
> generated through u
On Fri, Jun 26, 2020 at 3:46 PM Petr Machata wrote:
>
> A following patch introduces qevents, points in qdisc algorithm where
> packet can be processed by user-defined filters. Should this processing
> lead to a situation where a new packet is to be enqueued on the same port,
> holding the root lo
On Sun, Jul 5, 2020 at 7:33 AM wenxu wrote:
> Thanks， I also think It is ok do fragment in the mirred output.
Please stop doing it. There is no way to make this acceptable.
You must be smart enough to find solutions elsewhere, possibly
not even in TC at all. It would be best if you can solve thi
On Thu, Jul 2, 2020 at 5:47 PM Marcelo Ricardo Leitner
wrote:
>
> in this case a act_output_it_well could do it. ;-)
Yeah, still much better than making "mirred" do "mirror, redirect, frag,
defrag", can't we all agree it is too late to rename mirred? :)
Please do not try to add any arbitrary fun
On Sun, Jul 5, 2020 at 7:34 AM wrote:
> +static int nf_ct_frag_reinit(struct ipq *qp)
> +{
> + unsigned int sum_truesize = 0;
> +
> + if (!mod_timer(&qp->q.timer, jiffies + qp->q.fqdir->timeout)) {
> + refcount_inc(&qp->q.refcnt);
> + return -ETIMEDOUT;
> +
On Sun, Jul 5, 2020 at 2:50 PM Jamal Hadi Salim wrote:
> BTW, nothing in skbedit is against computing what the new metadata
> should be.
Yup.
>
> IMO: A good arguement to not make it part of skbedit is if it adds
> unnecessary complexity to skbedit or policy definitions.
>
TCA_HASH_ALG_L4 liter
On Sun, Jul 5, 2020 at 10:26 AM Ariel Levkovich wrote:
> However I believe that from a concept point of view, using it is wrong.
>
> In my honest opinion, the concept here is to perform some calculation on
> the packet itself and its headers while the skb->hash field
>
> is the storage location of
On Fri, Jul 3, 2020 at 8:22 AM Toke Høiland-Jørgensen wrote:
> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
> index b05e855f1ddd..d0c1cb0d264d 100644
> --- a/include/linux/if_vlan.h
> +++ b/include/linux/if_vlan.h
> @@ -308,6 +308,35 @@ static inline bool eth_type_vlan(__be16 eth
On Thu, Jul 2, 2020 at 10:32 AM Marcelo Ricardo Leitner
wrote:
>
> On Thu, Jul 02, 2020 at 05:36:38PM +0800, wenxu wrote:
> >
> > On 7/2/2020 1:33 AM, Cong Wang wrote:
> > > On Wed, Jul 1, 2020 at 1:21 AM wenxu wrote:
> > >>
> > >> On 7/1/202
On Wed, Jul 1, 2020 at 11:47 AM Ariel Levkovich wrote:
>
> Allow setting a hash value to a packet for a future match.
>
> The action will determine the packet's hash result according to
> the selected hash type.
>
> The first option is to select a basic asymmetric l4 hash calculation
> on the pack
On Fri, Jun 19, 2020 at 7:42 PM Ariel Levkovich wrote:
> I'll try to address both of your comments regarding existing
> alternatives to this new action
>
> here so that we can have a single thread about it.
>
> Act_bpf indeed can provide a similar functionality. Furthermore, there
> are already ex
Qiang
Tested-by: Cameron Berkenpas
Tested-by: Peter Geis
Tested-by: Thomas Lamprecht
Cc: Daniel Borkmann
Cc: Zefan Li
Cc: Tejun Heo
Cc: Roman Gushchin
Signed-off-by: Cong Wang
---
include/linux/cgroup-defs.h | 6 --
include/linux/cgroup.h | 4 +++-
kernel/cgroup/cgroup.c
On Tue, Jun 30, 2020 at 3:48 PM Roman Gushchin wrote:
>
> Btw if we want to backport the problem but can't blame a specific commit,
> we can always use something like "Cc: [3.1+]".
Sure, but if we don't know which is the right commit to blame, then how
do we know which stable version should t
On Wed, Jul 1, 2020 at 9:05 AM Cong Wang wrote:
>
> On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
> > Do either of you know if there's been any development on a fix for this
> > issue? If not we can propose something.
>
> If you have a reproducer, I can look
On Wed, Jul 1, 2020 at 1:21 AM wenxu wrote:
>
>
> On 7/1/2020 2:21 PM, wenxu wrote:
> > On 7/1/2020 2:12 PM, Cong Wang wrote:
> >> On Tue, Jun 30, 2020 at 11:03 PM wenxu wrote:
> >>> Only forward packet case need do fragment again and there is no need
On Tue, Jun 30, 2020 at 2:08 PM Josh Hunt wrote:
> Do either of you know if there's been any development on a fix for this
> issue? If not we can propose something.
If you have a reproducer, I can look into this.
Thanks.
On Tue, Jun 30, 2020 at 11:03 PM wenxu wrote:
>
> Only forward packet case need do fragment again and there is no need do
> defrag explicit.
Same question: why act_mirred? You have to explain why act_mirred
has the responsibility to do this job.
Thanks.
On Tue, Jun 30, 2020 at 7:36 PM wenxu wrote:
>
>
> On 7/1/2020 3:02 AM, Cong Wang wrote:
> > On Mon, Jun 29, 2020 at 7:55 PM wrote:
> >> From: wenxu
> >>
> >> The fragment packets do defrag in act_ct module. The reassembled packet
> >> over t
On Sat, Jun 27, 2020 at 4:41 PM Roman Gushchin wrote:
>
> On Fri, Jun 26, 2020 at 10:58:14AM -0700, Cong Wang wrote:
> > On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas wrote:
> > >
> > > Hello,
> > >
> > > Somewhere along the way I got th
On Sat, Jun 27, 2020 at 3:59 PM Cameron Berkenpas wrote:
>
> The box has been up without issue for over 25 hours now. The patch seems
> solid.
That's great! Thanks for testing!
On Mon, Jun 29, 2020 at 7:55 PM wrote:
>
> From: wenxu
>
> The fragment packets do defrag in act_ct module. The reassembled packet
> over the mtu in the act_mirred. This big packet should be fragmented
> to send out.
This is too brief. Why act_mirred should handle the burden introduced by
act_ct
On Tue, Jun 30, 2020 at 10:50 AM Sean Tranchetti
wrote:
>
> A potential deadlock can occur during registering or unregistering a
> new generic netlink family between the main nl_table_lock and the
> cb_lock where each thread wants the lock held by the other, as
> demonstrated below.
>
> 1) Thread
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
#syz fix: genetlink: get rid of family->attrbuf
On Mon, Jun 29, 2020 at 6:17 PM Jason A. Donenfeld wrote:
>
> Hey Cong,
Hi, Jason
>
> I'm wondering if the below error is related to what you've been
> looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
> passed to the start method. I recall recently you were working on the
> lock
On Fri, Jun 26, 2020 at 5:32 PM Sean Tranchetti wrote:
>
> A potential deadlock can occur during registering or unregistering a new
> generic netlink family between the main nl_table_lock and the cb_lock where
> each thread wants the lock held by the other, as demonstrated below.
>
> 1) Thread 1 i
#syz test: https://github.com/congwang/linux.git net
80cad1e3cb4c41cde...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+736bcbcb11b60d0c0...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+520f8704db2b68091...@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+c96e4dfb32f8987fd...@syzkaller.appspotmail.com
Cc: Jiri Pirko
#syz test: https://github.com/congwang/linux.git net
The lockdep annotations for dev_uc_unsync() and dev_mc_unsync()
are not easy to understand, so add some comments to explain
why they are correct.
Similar for the rest netif_addr_lock_bh() cases, they don't
need nested version.
Cc: Taehee Yoo
Cc: Dmitry Vyukov
Signed-off-by: Cong Wang
---
stick with our _nested()
annotations.
Fixes: 845e0ebb4408 ("net: change addr_list_lock back to static key")
Suggested-by: Taehee Yoo
Cc: Dmitry Vyukov
Signed-off-by: Cong Wang
---
drivers/net/macsec.c | 5 ++---
drivers/net/macvlan.c | 5 ++---
net/8021q/vlan_dev.c | 9
ore
applying this one.
(Just in case of any confusion: I still believe we should check NULL on
top of this refcnt fix. But it should be a separate patch.)
Thank you!
commit 259150604c0b77c717fdaab057da5722e2dfd922
Author: Cong Wang
Date: Sat Jun 13 12:34:40 2020 -0700
cgroup: fix cgr
On Tue, Jun 23, 2020 at 1:45 AM Zhang,Qiang wrote:
>
> There are some message in kernelv5.4, I don't know if it will help.
>
> demsg:
>
> cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or
> net_cls activation
...
> ---[ cut here ]---
> percpu ref (cgroup_bpf_rele
On Sat, Jun 20, 2020 at 8:58 AM Roman Gushchin wrote:
>
> On Fri, Jun 19, 2020 at 08:00:41PM -0700, Cong Wang wrote:
> > On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
> > >
> > > On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> > > >
On Fri, Jun 19, 2020 at 5:51 PM Zefan Li wrote:
>
> 在 2020/6/20 8:45, Zefan Li 写道:
> > On 2020/6/20 3:51, Cong Wang wrote:
> >> On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
> >>>
> >>> On 2020/6/19 5:09, Cong Wang wrote:
> >>>
On Fri, Jun 19, 2020 at 6:14 PM Roman Gushchin wrote:
>
> On Sat, Jun 20, 2020 at 09:00:40AM +0800, Zefan Li wrote:
> > I think so, though I'm not familiar with the bfp cgroup code.
> >
> > > If so, we might wanna fix it in a different way,
> > > just checking if (!(css->flags & CSS_NO_REF)) in cg
On Thu, Jun 18, 2020 at 11:40 PM Zefan Li wrote:
>
> On 2020/6/19 5:09, Cong Wang wrote:
> > On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
> >>
> >> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> >>> On Wed, Jun 17, 2020 at 6:44 P
On Tue, Jun 16, 2020 at 7:06 AM Roberto J. Blandino Cisneros
wrote:
> I am seing "rate 0bit".
>
> But installing from debian package iproute2 i got nothing so i decide to
> compile iproute2 using version 5.7.0
>
> But my output is the same as below:
You either need to enable /sys/module/sch_htb/p
On Thu, Jun 18, 2020 at 12:36 PM Roman Gushchin wrote:
>
> On Thu, Jun 18, 2020 at 12:19:13PM -0700, Cong Wang wrote:
> > On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
> > >
> > > Cc: Roman Gushchin
> > >
> > > Thanks for fixing this
On Thu, Jun 18, 2020 at 1:33 PM Vladimir Oltean wrote:
>
> On Thu, 18 Jun 2020 at 23:06, Cong Wang wrote:
> >
> > On Thu, Jun 18, 2020 at 12:56 PM Cong Wang wrote:
> > >
> > > On Thu, Jun 18, 2020 at 12:40 PM Vladimir Oltean
> > > wrote:
> &g
On Thu, Jun 18, 2020 at 12:56 PM Cong Wang wrote:
>
> On Thu, Jun 18, 2020 at 12:40 PM Vladimir Oltean wrote:
> >
> > It's me with the stacked DSA devices again:
>
> It looks like DSA never uses netdev API to link master
> device with slave devices? If so, their
On Thu, Jun 18, 2020 at 12:40 PM Vladimir Oltean wrote:
>
> It's me with the stacked DSA devices again:
It looks like DSA never uses netdev API to link master
device with slave devices? If so, their dev->lower_level
are always 1, therefore triggers this warning.
I think it should call one of the
On Wed, Jun 17, 2020 at 6:44 PM Zefan Li wrote:
>
> Cc: Roman Gushchin
>
> Thanks for fixing this.
>
> On 2020/6/17 2:03, Cong Wang wrote:
> > When we clone a socket in sk_clone_lock(), its sk_cgrp_data is
> > copied, so the cgroup refcnt must be taken too. And,
On Tue, Jun 16, 2020 at 8:03 AM Taehee Yoo wrote:
>
> I agree with that.
> And, do you have any plan to replace netif_addr_lock_bh() with
> netif_addr_lock_nested()?
> (Of course, it needs BH handling code)
> I'm not sure but I think it would be needed.
Yeah, I agree it's needed. I have a patch n
f v2
cgroups")
Reported-by: Cameron Berkenpas
Reported-by: Peter Geis
Reported-by: Lu Fengqi
Reported-by: Daniël Sonck
Tested-by: Cameron Berkenpas
Cc: Daniel Borkmann
Cc: Zefan Li
Cc: Tejun Heo
Signed-off-by: Cong Wang
---
include/linux/cgroup.h | 2 ++
kernel/cg
On Mon, Jun 15, 2020 at 6:06 AM Daniël Sonck wrote:
>
> Op zo 14 jun. 2020 om 22:43 schreef Daniël Sonck :
> >
> > Hello,
> >
> > Op zo 14 jun. 2020 om 20:29 schreef Cong Wang :
> > >
> > > Hello,
> > >
> > > On Sun,
501 - 600 of 2972 matches
Mail list logo
