On 11/9/20 7:26 PM, Alexander Lobakin wrote:
> From: Eric Dumazet
> Date: Mon, 9 Nov 2020 18:37:36 +0100
>
>> On 11/9/20 5:56 PM, Alexander Lobakin wrote:
>>> While testing UDP GSO fraglists forwarding through driver that uses
>>> Fast GRO (via napi_gro_frag
On 11/9/20 7:28 PM, Willem de Bruijn wrote:
> On Mon, Nov 9, 2020 at 12:37 PM Eric Dumazet wrote:
>>
>>
>>
>> On 11/9/20 5:56 PM, Alexander Lobakin wrote:
>>> While testing UDP GSO fraglists forwarding through driver that uses
>>> Fast GRO (via n
On 11/9/20 5:56 PM, Alexander Lobakin wrote:
> While testing UDP GSO fraglists forwarding through driver that uses
> Fast GRO (via napi_gro_frags()), I was observing lots of out-of-order
> iperf packets:
>
> [ ID] Interval Transfer Bitrate Jitter
> [SUM] 0.0-40.0 sec
On Mon, Nov 9, 2020 at 6:18 PM Mao Wenan wrote:
>
> When net.ipv4.tcp_syncookies=1 and syn flood is happened,
> cookie_v4_check or cookie_v6_check tries to redo what
> tcp_v4_send_synack or tcp_v6_send_synack did,
> rsk_window_clamp will be changed if SOCK_RCVBUF is set,
> which will make
On Mon, Nov 9, 2020 at 5:54 PM Mao Wenan wrote:
>
> When net.ipv4.tcp_syncookies=1 and syn flood is happened,
> cookie_v4_check or cookie_v6_check tries to redo what
> tcp_v4_send_synack or tcp_v6_send_synack did,
> rsk_window_clamp will be changed if SOCK_RCVBUF is set,
> which will make
On Mon, Nov 9, 2020 at 5:11 PM Ricardo Dias wrote:
>
> When the TCP stack is in SYN flood mode, the server child socket is
> created from the SYN cookie received in a TCP packet with the ACK flag
> set.
>
> The child socket is created when the server receives the first TCP
> packet with a valid
On 11/9/20 3:48 PM, Menglong Dong wrote:
> On Mon, Nov 9, 2020 at 9:36 PM Eric Dumazet wrote:
>>
>> I do not think this patch is useful. That is simply code churn.
>>
>> Can you trigger the WARN() in the latest upstream version ?
>> If yes this is a seriou
On Mon, Nov 9, 2020 at 12:41 PM Eric Dumazet wrote:
>
> Packetdrill test would be :
>
> // Force syncookies
> `sysctl -q net.ipv4.tcp_syncookies=2`
>
> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>
On Mon, Nov 9, 2020 at 2:07 PM wrote:
>
> From: Menglong Dong
>
> 'before(*seq, TCP_SKB_CB(skb)->seq) == true' means that one or more
> skbs are lost somehow. Once this happen, it seems that it will
> never recover automatically. As a result, a warning will be printed
> and a '-EAGAIN' will be
) = 0
+0 < S 0:0(0) win 32792
+0 > S. 0:0(0) ack 1
+.1 < . 1:1(0) ack 1 win 1024
+0 accept(3, ..., ...) = 4
+0 %{ assert tcpi_snd_wscale == 0, tcpi_snd_wscale }%
On Mon, Nov 9, 2020 at 12:02 PM Eric Dumazet wrote:
>
> On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan wrote:
&g
On Mon, Nov 9, 2020 at 11:12 AM Mao Wenan wrote:
>
>
>
> 在 2020/11/9 下午5:56, Eric Dumazet 写道:
> > On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan
> > wrote:
> >>
> >> When net.ipv4.tcp_syncookies=1 and syn flood is happened,
> >> co
On Mon, Nov 9, 2020 at 10:33 AM Mao Wenan wrote:
>
> When net.ipv4.tcp_syncookies=1 and syn flood is happened,
> cookie_v4_check or cookie_v6_check tries to redo what
> tcp_v4_send_synack or tcp_v6_send_synack did,
> rsk_window_clamp will be changed if SOCK_RCVBUF is set,
> which will make
On 11/4/20 1:36 PM, Matthew Wilcox wrote:
> On Wed, Nov 04, 2020 at 09:50:30AM +0100, Eric Dumazet wrote:
>> On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
>>>> Thanks for providing the numbers. Do you think that dropping (up to)
>>>> 7 packets is acceptable?
>
On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
>> Thanks for providing the numbers. Do you think that dropping (up to)
>> 7 packets is acceptable?
>
> net.ipv4.tcp_syn_retries = 6
>
> tcp clients wouldn't even get that far leading to connect establish issues.
This does not really matter. If
On Fri, Oct 23, 2020 at 6:48 PM Ricardo Dias wrote:
>
> In that case, I can change the patch to only iterate the ehash bucket
> only when the listening socket is using the loopback interface, correct?
No, the fix should be generic.
We could still have bad NIC, or bad configuration, spreading
On Fri, Oct 23, 2020 at 6:06 PM Ricardo Dias wrote:
> And what about the loopback interface? Why couldn't the loopback
> interface also use a single RX queue?
>
Loopback is using a per-cpu queue, with no crossing, for efficiency.
That means : whenever a packet is sent on lo interface from CPU
On Fri, Oct 23, 2020 at 5:51 PM Ricardo Dias wrote:
>
> On Fri, Oct 23, 2020 at 04:03:27PM +0200, Eric Dumazet wrote:
> > On Fri, Oct 23, 2020 at 1:14 PM Ricardo Dias wrote:
> > >
> > > When the TCP stack is in SYN flood mode, the server child socket is
> > &g
On Fri, Oct 23, 2020 at 1:14 PM Ricardo Dias wrote:
>
> When the TCP stack is in SYN flood mode, the server child socket is
> created from the SYN cookie received in a TCP packet with the ACK flag
> set.
>
...
This patch only handles IPv4, unless I am missing something ?
It looks like the fix
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
>
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
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 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
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
>&g
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 usu
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
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)
> > +
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
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:
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
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
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
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
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
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
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
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
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(),
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
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
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
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
>
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
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
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
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:
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
orgotten :(
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
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
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-
l 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
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
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
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:
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:
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
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:
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:
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
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
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
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
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
201 - 300 of 5670 matches
Mail list logo
