On Sun, Oct 18, 2020 at 1:29 AM Jakub Kicinski wrote:
>
> On Sat, 17 Oct 2020 15:45:57 +0200 Heiner Kallweit wrote:
> > When __napi_schedule_irqoff was added with bc9ad166e38a
> > ("net: introduce napi_schedule_irqoff()") the commit message stated:
> > "Many NIC drivers can use it from their hard
On Fri, Oct 16, 2020 at 2:10 PM Aleksandr Nogikh wrote:
>
> From: Aleksandr Nogikh
>
> Currently it is possible to craft a special netlink RTM_NEWQDISC
> command that result in jitter being equal to 0x8000. It is enough
> to set 32 bit jitter to 0x0200 (it will later be multiplied by
> 2^
On 10/12/20 11: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 the amo
On 10/12/20 10:39 AM, Muchun Song wrote:
> On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet wrote:
>>
>> On Mon, Oct 12, 2020 at 6:22 AM Muchun Song wrote:
>>>
>>> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
>>>>
>>>> On Sat, Oct 10,
On Mon, Oct 12, 2020 at 6:22 AM 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 significant.
> > > However, we do not display the amount
On 10/2/20 10:51 AM, 叶小龙 wrote:
> Hi, net experts,
>
> Hope this is the right place to ask the question :)
>
> Recently I've tried to measure the network latency between two
> machines by using ping, one interesting observation I found is that
> ping latency will be smaller if I use a shorter
ts")
Signed-off-by: Eric Dumazet
Cc: Jan Kara
---
fs/quota/quota_v2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/quota/quota_v2.c b/fs/quota/quota_v2.c
index
58fc2a7c7fd19f0be265e8189e476782571cbcfe..e69a2bfdd81c050c1ff2653528f803bd402fb399
100644
--- a/fs/quota/quota_v2.c
+++ b/f
On 9/21/20 10:40 AM, Yunsheng Lin wrote:
> On 2020/9/21 16:17, Eric Dumazet wrote:
>> On Mon, Sep 21, 2020 at 10:10 AM Yunsheng Lin wrote:
>>>
>>> On 2020/9/21 15:19, Eric Dumazet wrote:
>>>> On Mon, Sep 21, 2020 at 4:08 AM Yunsheng Lin
>>>
On Mon, Sep 21, 2020 at 10:10 AM Yunsheng Lin wrote:
>
> On 2020/9/21 15:19, Eric Dumazet wrote:
> > On Mon, Sep 21, 2020 at 4:08 AM Yunsheng Lin wrote:
> >>
> >> When napi_consume_skb() is called in the tx desc cleaning process,
> >> it is usually in
On Mon, Sep 21, 2020 at 4:08 AM Yunsheng Lin wrote:
>
> When napi_consume_skb() is called in the tx desc cleaning process,
> it is usually in the softirq context(BH disabled, or are processing
> softirqs), but it may also be in the task context, such as in the
> netpoll or loopback selftest proces
can result in long delays when deleting a large number of interfaces,
> and it can be observed with this script:
>
>
>
> Signed-off-by: Francesco Ruggeri
>
Reviewed-by: Eric Dumazet
Thanks !
On Fri, Sep 18, 2020 at 10:48 AM Eric Dumazet wrote:
>
>
> Also, I would try using synchronize_rcu() instead of the first
s/synchronize_rcu/rcu_barrier/ of course :/
> msleep(), this might avoid all msleep() calls in your case.
>
> Patch without the macros to see the gener
On Fri, Sep 18, 2020 at 1:49 AM Francesco Ruggeri wrote:
>
> The combination of aca_free_rcu, introduced in commit 2384d02520ff
> ("net/ipv6: Add anycast addresses to a global hashtable"), and
> fib6_info_destroy_rcu, introduced in commit 9b0a8da8c4c6 ("net/ipv6:
> respect rcu grace period before
On Thu, Sep 17, 2020 at 8:33 AM Francesco Ruggeri wrote:
>
> > static inline void dev_put(struct net_device *dev)
> > {
> > + struct task_struct *destroy_task = dev->destroy_task;
> > +
> > this_cpu_dec(*dev->pcpu_refcnt);
> > + if (destroy_task)
> > + wake_up_p
On Wed, Sep 16, 2020 at 10:33 AM Saeed Mahameed wrote:
>
> On Tue, 2020-09-15 at 15:04 +0800, Yunsheng Lin wrote:
> > On 2020/9/15 13:09, Saeed Mahameed wrote:
> > > On Mon, 2020-09-14 at 20:06 +0800, Huazhong Tan wrote:
> > > > From: Yunsheng Lin
> > > >
> > > > Use napi_consume_skb() to batch c
On 9/3/20 1:48 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:1996cf46 net: bcmgenet: fix mask check in bcmgenet_validat..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=17233f4d90
> kernel config: https://syzkall
On 9/2/20 6:14 PM, Yunsheng Lin wrote:
>
> It seems semantics for some_qdisc_is_busy() is changed, which does not only do
> the checking, but also do the reseting?
Yes, obviously, we would have to rename to a better name.
>
> Also, qdisc_reset() could be called multi times for the same qdis
On 9/2/20 10:16 AM, izabela.bakoll...@gmail.com 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.
On 9/2/20 2:41 AM, Luo bin wrote:
> When calling hinic_close in hinic_set_channels, netif_carrier_off
> and netif_tx_disable are excuted, and TX host resources are freed
> after that. Core may call hinic_xmit_frame to send pkt after
> netif_tx_disable within a short time, so we should judge whet
On 9/2/20 1:14 AM, Yunsheng Lin wrote:
> On 2020/9/2 15:32, Eric Dumazet wrote:
>>
>>
>> On 9/1/20 11:34 PM, Yunsheng Lin wrote:
>>
>>>
>>> I am not familiar with TCQ_F_CAN_BYPASS.
>>> From my understanding, the problem is that there i
On 9/1/20 11:34 PM, Yunsheng Lin wrote:
>
> I am not familiar with TCQ_F_CAN_BYPASS.
> From my understanding, the problem is that there is no order between
> qdisc enqueuing and qdisc reset.
Thw qdisc_reset() should be done after rcu grace period, when there is
guarantee no enqueue is in pro
On Tue, Sep 1, 2020 at 4:55 PM Willy Tarreau wrote:
>
> On Tue, Sep 01, 2020 at 04:41:13PM +0200, Sedat Dilek wrote:
> > I have tested with the patchset from [1].
> > ( Later I saw, you dropped "WIP: tcp: reuse incoming skb hash in
> > tcp_conn_request()". )
>
> Yes because it's a bit out of the c
On 8/31/20 11:43 PM, Willy Tarreau wrote:
> With the removal of the interrupt perturbations in previous random32
> change (random32: make prandom_u32() output unpredictable), the PRNG
> has become 100% deterministic again. While SipHash is expected to be
> way more robust against brute force tha
On Tue, Sep 1, 2020 at 8:58 AM Brian Vazquez wrote:
>
> The problem is exposed when the system has multiple ifaces and
> forwarding is enabled on a subset of them, __rt6_purge_dflt_routers will
> clean the default route on all the ifaces which is not desired.
What is the exact problem you want to
On Tue, Sep 1, 2020 at 8:58 AM Brian Vazquez wrote:
>
> The problem is exposed when the system has multiple ifaces and
> forwarding is enabled on a subset of them, __rt6_purge_dflt_routers will
> clean the default route on all the ifaces which is not desired.
>
> This patches fixes that by cleanin
On 8/31/20 5:55 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_deactivate_queue(), w
On 8/28/20 2:52 PM, Stephen Hemminger wrote:
> On Fri, 28 Aug 2020 22:44:47 +0200
> Bart Groeneveld wrote:
>
>> IANA specifies User ports as 1024-49151,
>> and Private ports (local/ephemeral/dynamic/w/e) as 49152-65535 [1].
>>
>> This means Linux uses 32768-49151 'illegally'.
>> This is not ju
On Thu, Aug 27, 2020 at 4:25 AM Miaohe Lin wrote:
>
> In the case of off = 0, skb_headers_offset_update() do nothing indeed.
>
> Signed-off-by: Miaohe Lin
> ---
> net/core/skbuff.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 18ed56316e
On Thu, Aug 27, 2020 at 4:03 AM Wang Long wrote:
>
> Hi，
>
> we encountered a kernel panic as following:
>
> [4394470.273792] general protection fault: [#1] SMP NOPTI
> [4394470.274038] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Tainted: G
> W - - - 4.18.0-80.el8.x86_64 #1
On Thu, Aug 27, 2020 at 4:31 AM Miaohe Lin wrote:
>
> Set trailer iff skb1 is the skbuff where the tailbits space begins.
>
> Signed-off-by: Miaohe Lin
> ---
> net/core/skbuff.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> ind
On 8/21/20 8:12 AM, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if allocating PMD
On Fri, Aug 21, 2020 at 1:59 AM wrote:
>
> On Fri, Aug 21, 2020 at 08:30:43AM +0200, Marco Elver wrote:
> > With KCSAN enabled, prandom_u32() may be called from any context,
> > including idle CPUs.
> >
> > Therefore, switch to using trace_prandom_u32_rcuidle(), to avoid various
> > issues due to
On Tue, Aug 18, 2020 at 4:58 AM Miaohe Lin wrote:
>
> The npages test against MAX_SKB_FRAGS can be relaxed if we succeed to
> allocate high order pages as the note in comment said.
>
> Signed-off-by: Miaohe Lin
> ---
> net/core/skbuff.c | 11 ---
> 1 file changed, 4 insertions(+), 7 dele
On 8/16/20 12:08 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 kernel_sendpa
On 8/15/20 11:23 AM, Pascal Bouchareine wrote:
> This command attaches the zero terminated string in optval to the
> socket for troubleshooting purposes. The free string is displayed in the
> process fdinfo file for that fd (/proc//fdinfo/).
>
> One intended usage is to allow processes to self-
On Sat, Aug 15, 2020 at 4:48 AM Ingo Molnar wrote:
>
>
> * Eric Dumazet wrote:
>
> > syzbot found its way in 86_fsgsbase_read_task() [1]
> >
> > Fix is to make sure ldt pointer is not NULL.
>
> Thanks for this fix. Linus has picked it up (inclusive the t
On Fri, Aug 14, 2020 at 12:03 PM Andy Lutomirski wrote:
>
>
>
> > On Aug 14, 2020, at 11:16 AM, Eric Dumazet wrote:
> >
> > syzbot found its way in 86_fsgsbase_read_task() [1]
> >
> > Fix is to make sure ldt pointer is not NULL
>
> Acked-by: Andy Lut
ace() to read the FS/GS base
accurately")
Co-developed-by: Jann Horn
Signed-off-by: Eric Dumazet
Reported-by: syzbot
Cc: Andy Lutomirski
Cc: Chang S. Bae
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torval
On Fri, Aug 14, 2020 at 12:14 AM linmiaohe wrote:
>
> Willem de Bruijn wrote:
> >On Thu, Aug 6, 2020 at 1:48 PM linmiaohe wrote:
> >>
> >> From: Miaohe Lin
> >>
> >> We could be trapped in deadloop when we try to copy userspace skb
> >> frags buffers to kernel with a cloned skb:
> >> Reproduce
On 8/14/20 6:17 AM, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 1378817486d6860f6a927f573491afe65287abf1
> Author: Eric Dumazet
> Date: Thu May 21 18:29:58 2020 +
>
> tipc: block BH before using dst_cache
>
On 8/11/20 5:10 AM, linmiaohe wrote:
> Eric Dumazet wrote:
>> On 8/10/20 5:28 AM, Miaohe Lin wrote:
>>> The skb_shared_info part of the data is assigned in the following
>>> loop. It is meaningless to do a memcpy here.
>>>
>>
>> Reminder : net-n
gt; forgotten :(
Sure, I'll take care of this shortly.
Thanks.
>
> Thanks,
> Jason
>
> On Thu, Jun 4, 2020 at 9:47 PM Jason Xing wrote:
>>
>> On Thu, Jun 4, 2020 at 9:10 PM Eric Dumazet wrote:
>>>
>>> On Thu, Jun 4, 2020 at 2:01 AM wrote
On 8/10/20 5:28 AM, Miaohe Lin wrote:
> The skb_shared_info part of the data is assigned in the following loop. It
> is meaningless to do a memcpy here.
>
> Signed-off-by: Miaohe Lin
> ---
> net/core/skbuff.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/
On 8/10/20 6:09 AM, Jiang Yu wrote:
> skb distinguished by uid can only recorded to user who consume them.
> in many case, skb should been recorded more specific to process who
> consume them. E.g, the unexpected large data traffic of illegal process
> in metered network.
>
> this helper is use
On 8/7/20 2:18 AM, David Laight wrote:
> From: Eric Dumazet
>> Sent: 06 August 2020 23:21
>>
>> On 7/22/20 11:09 PM, Christoph Hellwig wrote:
>>> Rework the remaining setsockopt code to pass a sockptr_t instead of a
>>> plain user pointer. This remo
On 8/6/20 4:17 PM, Eric Dumazet wrote:
>
>
> On 8/6/20 2:39 PM, John Stultz wrote:
>> On Wed, Aug 5, 2020 at 6:57 PM David Miller wrote:
>>> There is a minor conflict in net/ipv6/ip6_flowlabel.c, it's because of
>>> the commit that did the tree-wid
, kill all of the conflict markers and content
>> within, and remove the uninitialized_var() marker that got moved
>> elsewhere in the file in the net-next tree.
>>
>> Otherwise, we have:
>>
>> 1) Support 6Ghz band in ath11k driver, from Rajkumar Manoharan.
>>
On 7/22/20 11:09 PM, Christoph Hellwig wrote:
> Rework the remaining setsockopt code to pass a sockptr_t instead of a
> plain user pointer. This removes the last remaining set_fs(KERNEL_DS)
> outside of architecture specific code.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Stefan Schmid
On 8/4/20 5:30 AM, Colin King wrote:
> From: Colin Ian King
>
> The current test will exit with a failure if it cannot set affinity on
> specific CPUs which is problematic when running this on single CPU
> systems. Add a check for the number of CPUs and skip the test if
> the CPU requirement i
On Tue, Aug 4, 2020 at 4:46 AM linmiaohe wrote:
>
> From: Miaohe Lin
>
> The head_frag of skb would occupy one extra skb_frag_t. Take it into
> account or out of bound write to skb frags may happen.
>
> Signed-off-by: Miaohe Lin
Please share a stack trace if this was a real bug spotted in the w
On 8/3/20 9:35 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:8bbbc5cf kmsan: don't compile memmove
> git tree: https://github.com/google/kmsan.git master
> console output: https://syzkaller.appspot.com/x/log.txt?x=11fbfe09e0
> kernel config:
On 8/3/20 8:23 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:bd0b33b2 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13f236a490
> kernel config: https://sy
On 8/2/20 3:45 PM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1323497090
> kernel config: https://sy
On Fri, Jul 31, 2020 at 10:17 AM Jason Gunthorpe wrote:
>
> On Wed, Jul 29, 2020 at 06:57:55PM -0700, Eric Dumazet wrote:
> > Mapping as little as 64GB can take more than 10 seconds,
> > triggering issues on kernels with CONFIG_PREEMPT_NONE=y.
> >
> > ib_umem_get()
On Thu, Jul 30, 2020 at 2:24 PM Florian Fainelli wrote:
>
> On 7/30/20 2:16 PM, Eric Dumazet wrote:
> > On Thu, Jul 30, 2020 at 2:07 PM Florian Fainelli
> > wrote:
> >>
> >> After tcp_write_queue_purge() got uninlined with commit ac3f09ba3e49
> >>
On Thu, Jul 30, 2020 at 2:07 PM Florian Fainelli wrote:
>
> After tcp_write_queue_purge() got uninlined with commit ac3f09ba3e49
> ("tcp: uninline tcp_write_queue_purge()"), it became no longer possible
> to reference this symbol from kernel modules.
>
> Fixes: ac3f09ba3e49 ("tcp: uninline tcp_wri
On 7/30/20 10:44 AM, Vinicius Costa Gomes wrote:
> Hi,
>
> Dmitry Vyukov writes:
>
>> On Wed, Jul 29, 2020 at 9:13 PM Vinicius Costa Gomes
>> wrote:
>>>
>>> Hi,
>>>
>>> "Zhang, Qiang" writes:
>>>
发件人: linux-kernel-ow...@vger.kernel.org
>>>
more than 100 ms,
which is also problematic. This might be addressed later
in ib_umem_add_sg_table(), adding new blocks in sgl
on demand.
Signed-off-by: Eric Dumazet
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
---
drivers/infiniband/core/umem.c | 1 +
1 file changed, 1
On 7/27/20 8:12 PM, Cong Wang wrote:
> 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
On 7/23/20 11:21 AM, Mark Salyzyn wrote:
> Many of the nla_get_* inlines fail to check attribute's length before
> copying the content resulting in possible out-of-boundary accesses.
> Adjust the inlines to perform nla_len checking, for the most part
> using the nla_memcpy function to faciliate
On Wed, Jul 22, 2020 at 11:09 PM Christoph Hellwig wrote:
>
> Add a uptr_t type that can hold a pointer to either a user or kernel
> memory region, and simply helpers to copy to and from it.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/sockptr.h | 104 ++
On 7/22/20 11:02 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:4fa640dc Merge tag 'vfio-v5.8-rc7' of git://github.com/awi..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=145cac3090
> kernel config: https://
On 7/14/20 1:05 AM, qiang.zh...@windriver.com wrote:
> From: Zhang Qiang
>
> CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
>
> Fixes: fc1b6d6de2208 ("tipc: introduce TIPC
On 7/13/20 6:53 PM, qiang.zh...@windriver.com wrote:
> From: Zhang Qiang
>
> CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
>
> Reported-by: syzbot+263f8c0d007dc09b2...@syzk
On 7/7/20 9:37 PM, Xie He wrote:
> This driver is not working because of problems of its receiving code.
> This patch fixes it to make it work.
>
> When the driver receives an LAPB frame, it should first pass the frame
> to the LAPB module to process. After processing, the LAPB module passes
>
On 7/7/20 10:15 AM, izabela.bakoll...@gmail.com 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.
On 7/7/20 10:33 AM, Eric Dumazet wrote:
>
>
> What happens after this monitoring is started, then the admin does :
>
> rmmod ifb
>
I meant : rmmod dummy
On 7/7/20 10:15 AM, izabela.bakoll...@gmail.com 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.
On Tue, Jun 30, 2020 at 3:07 PM Eric Dumazet wrote:
> Oh well, tcp_syn_options() is supposed to have the same logic.
>
> Maybe we have an issue with SYNCOOKIES (with MD5 + TS + SACK)
>
> Nice can of worms.
Yes, MD5 does not like SYNCOOKIES in some cases.
In this trace, S is a
On Wed, Jul 1, 2020 at 5:19 AM Mathieu Desnoyers
wrote:
> The approach below looks good to me, but you'll also need to annotate
> both tcp_md5_hash_key and tcp_md5_do_add with __no_kcsan or use
> data_race(expr) to let the concurrency sanitizer know that there is
> a known data race which is ther
On Tue, Jun 30, 2020 at 7:59 PM Herbert Xu wrote:
>
> On Tue, Jun 30, 2020 at 07:30:43PM -0700, Eric Dumazet wrote:
> >
> > I made this clear in the changelog, do we want comments all over the places
> > ?
> > Do not get me wrong, we had this bug for years and s
On Tue, Jun 30, 2020 at 7:23 PM Herbert Xu wrote:
>
> On Tue, Jun 30, 2020 at 07:17:46PM -0700, Eric Dumazet wrote:
> >
> > The main issue of the prior code was the double read of key->keylen in
> > tcp_md5_hash_key(), not that few bytes could change under us.
>
On Tue, Jun 30, 2020 at 7:02 PM Herbert Xu wrote:
>
> Eric Dumazet wrote:
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index
> > 810cc164f795f8e1e8ca747ed5df51bb20fec8a2..ecc0e3fabce8b03bef823cbfc5c1b0a9e24df124
> > 100644
> > ---
On Tue, Jun 30, 2020 at 4:44 PM Mathieu Desnoyers
wrote:
>
> - On Jun 30, 2020, at 6:38 PM, Eric Dumazet eduma...@google.com wrote:
> [...]
> >
> > For updates of keys, it seems existing code lacks some RCU care.
> >
> > MD5 keys use RCU for lookups/hashes,
On Tue, Jun 30, 2020 at 3:07 PM Eric Dumazet wrote:
>
> On Tue, Jun 30, 2020 at 2:54 PM Eric Dumazet wrote:
> >
> > On Tue, Jun 30, 2020 at 2:23 PM Eric Dumazet wrote:
> > >
> > > On Tue, Jun 30, 2020 at 2:17 PM Mathieu Desnoyers
> > > wrote:
>
On Tue, Jun 30, 2020 at 2:54 PM Eric Dumazet wrote:
>
> On Tue, Jun 30, 2020 at 2:23 PM Eric Dumazet wrote:
> >
> > On Tue, Jun 30, 2020 at 2:17 PM Mathieu Desnoyers
> > wrote:
> > >
> > > - On Jun 30, 2020, at 4:56 PM, Eric Dumazet eduma...@goog
On Tue, Jun 30, 2020 at 2:23 PM Eric Dumazet wrote:
>
> On Tue, Jun 30, 2020 at 2:17 PM Mathieu Desnoyers
> wrote:
> >
> > - On Jun 30, 2020, at 4:56 PM, Eric Dumazet eduma...@google.com wrote:
> >
> > > On Tue, Jun 30, 2020 at 1:44 PM David Miller wro
On Tue, Jun 30, 2020 at 2:17 PM Mathieu Desnoyers
wrote:
>
> - On Jun 30, 2020, at 4:56 PM, Eric Dumazet eduma...@google.com wrote:
>
> > On Tue, Jun 30, 2020 at 1:44 PM David Miller wrote:
> >>
> >> From: Eric Dumazet
> >> Date: Tue, 30 Jun 20
On Tue, Jun 30, 2020 at 1:44 PM David Miller wrote:
>
> From: Eric Dumazet
> Date: Tue, 30 Jun 2020 13:39:27 -0700
>
> > The (C) & (B) case are certainly doable.
> >
> > A) case is more complex, I have no idea of breakages of various TCP
> > stacks if a
On Tue, Jun 30, 2020 at 1:34 PM Mathieu Desnoyers
wrote:
>
> - On Jun 30, 2020, at 3:52 PM, Linus Torvalds
> torva...@linux-foundation.org wrote:
>
> > On Tue, Jun 30, 2020 at 12:43 PM Linus Torvalds
> > wrote:
> >>
> [...]
> > So I think it's still wrong (clearly others do change passwords
On Tue, Jun 30, 2020 at 1:21 PM David Miller wrote:
>
> From: Linus Torvalds
> Date: Tue, 30 Jun 2020 12:43:21 -0700
>
> > If you're not willing to do the work to fix it, I will revert that
> > commit.
>
> Please let me handle this situation instead of making threats, this
> just got reported.
>
On Mon, Jun 29, 2020 at 12:43 PM Mathieu Desnoyers
wrote:
>
> - On May 13, 2020, at 3:56 PM, Eric Dumazet eduma...@google.com wrote:
>
> > On Wed, May 13, 2020 at 12:49 PM Eric Dumazet wrote:
> >>
> >>
> >> On Wed, May 13, 2020 at 12:38 PM Mathi
On 6/16/20 12:47 AM, Jan Kara wrote:
> On Mon 15-06-20 19:26:38, Amir Goldstein wrote:
>>> This patch changes alloc_file_pseudo() to always opt out of fsnotify by
>>> setting FMODE_NONOTIFY flag so that no check is made for fsnotify watchers
>>> on pseudo files. This should be safe as the underl
On 6/17/20 6:43 PM, Gaurav Singh wrote:
> Add null check for skb
>
Bad choice really.
You have to really understand code intent before trying to fix it.
> Signed-off-by: Gaurav Singh
> ---
> net/sched/act_api.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/n
On 6/17/20 6:23 PM, Gaurav Singh wrote:
> Signed-off-by: Gaurav Singh
Two Signed-off-by ?
>
> Fix build errors
Your patch does not fix a build error.
>
> Signed-off-by: Gaurav Singh
> ---
> net/sched/sch_api.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net
;)
> Signed-off-by: Greg Thelen
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Eric Dumazet
Thanks Greg
On Mon, Jun 15, 2020 at 11:07 AM Nick Desaulniers
wrote:
>
> On Mon, Jun 15, 2020 at 10:59 AM 'Eric Dumazet' via Clang Built Linux
> wrote:
> >
> > On Mon, Jun 15, 2020 at 10:54 AM Eric Dumazet wrote:
> > >
> > > On Mon, Jun 15, 2020 at 10:44 AM
On Mon, Jun 15, 2020 at 10:54 AM Eric Dumazet wrote:
>
> On Mon, Jun 15, 2020 at 10:44 AM Nick Desaulniers
> wrote:
> >
> > On Mon, Jun 15, 2020 at 9:17 AM 'Eric Dumazet' via Clang Built Linux
> > wrote:
> > >
> > > On Sun, Jun 14, 2020 at
On Mon, Jun 15, 2020 at 10:44 AM Nick Desaulniers
wrote:
>
> On Mon, Jun 15, 2020 at 9:17 AM 'Eric Dumazet' via Clang Built Linux
> wrote:
> >
> > On Sun, Jun 14, 2020 at 11:26 PM kernel test robot wrote:
> > >
> > > tree:
> > >
7ceee167743620dd33f4417
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git remote update linus
> git checkout 39d010504e6b4485d7ceee167743620dd33f4417
> vim +/fq_dump +966 net/sched/sch_fq.c
>
> afe4fd062416b1 Eric Dumazet 2013-08-
On Fri, Jun 12, 2020 at 3:28 AM Xiaoming Ni wrote:
>
> Cred release and usage check code flow:
> 1. put_cred()
> if (atomic_dec_and_test(&(cred)->usage))
> __put_cred(cred);
>
> 2. __put_cred()
> BUG_ON(atomic_read(&cred->usag
On 6/5/20 12:22 PM, Denis Efremov wrote:
> Use kfree() instead of kvfree() on ft->g in arfs_create_groups() because
> the memory is allocated with kcalloc().
>
> Signed-off-by: Denis Efremov
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Fri, Jun 5, 2020 at 1:10 AM kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-4.9):
>
> commit: a6211caa634da39d861a47437ffcda8b38ef421b ("net: revert "net: get rid
> of an signed integer overflow in ip_idents_reserve()"")
> https://git.kernel.org/
u could notice that the number would not decrease.
>
> v2: extend the timer which could cover all those related potential risks
> (suggested by Eric Dumazet and Neal Cardwell)
>
> Signed-off-by: Jason Xing
> Signed-off-by: liweishi
> Signed-off-by: Shujin Li
That is not ho
On Wed, Jun 3, 2020 at 5:02 AM Neal Cardwell wrote:
>
> On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote:
> >
> > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing
> > wrote:
> > >
> > > Hi Eric,
> > >
> > > I'm still trying to un
long while. I will send the fix to the correct tree soon :)
> >
> > If you run BBR at scale (thousands of machines), you probably should
> > use sch_fq instead of internal pacing,
> > just saying ;)
> >
> >
> > >
> > > Thanks again,
> > > Jason
> > >
n our thousands of machines after running for a
> long while. I will send the fix to the correct tree soon :)
If you run BBR at scale (thousands of machines), you probably should
use sch_fq instead of internal pacing,
just saying ;)
>
> Thanks again,
> Jason
>
> On Wed, Jun
ent.
It is too late to 'give up pacing'
The packet should not have been sent if the pacing timer is queued
(otherwise this means we do not respect pacing)
So the bug should be caught earlier. check where tcp_pacing_check()
calls are missing.
>
>
> Thanks,
> Jason
>
> O
On Tue, Jun 2, 2020 at 1:05 AM wrote:
>
> From: Jason Xing
>
> TCP socks cannot be released because of the sock_hold() increasing the
> sk_refcnt in the manner of tcp_internal_pacing() when RTO happens.
> Therefore, this situation could increase the slab memory and then trigger
> the OOM if the m
On 5/29/20 10:32 AM, Eric Dumazet wrote:
> L2TP seems to use sk->sk_node to insert sockets into l2tp_ip_table, _and_
> uses l2tp_ip_prot.unhash == inet_unhash
>
> So if/when BPF_CGROUP_RUN_PROG_INET_SOCK(sk) returns an error and
> inet_create() calls sk_common_release()
&
201 - 300 of 2092 matches
Mail list logo
