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
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
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
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
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 11:26 PM k
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:
> > > https://
3620dd33f4417
> 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-29 965
&
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(>usage) !=
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()"")
>
ld 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 how
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 unde
return -1;
}
-static bool tcp_pacing_check(const struct sock *sk)
-{
- return tcp_needs_internal_pacing(sk) &&
- hrtimer_is_queued(_sk(sk)->pacing_timer);
-}
/* TCP Small Queues :
* Control number of packets in qdisc/devices to two packets / or ~1 ms.
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
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
>
> On Tue, Jun 2, 2020 at 9:05 PM
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
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()
&
On 5/28/20 11:32 PM, Andrii Nakryiko wrote:
> On 5/28/20 11:23 PM, Dmitry Vyukov wrote:
>> On Thu, May 28, 2020 at 11:01 PM 'Andrii Nakryiko' via syzkaller-bugs
>> wrote:
>>>
>>> On 5/28/20 9:44 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:
On 5/28/20 2:01 PM, Andrii Nakryiko wrote:
> On 5/28/20 9:44 AM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: dc0f3ed1 net: phy: at803x: add cable diagnostics support f..
>> git tree: net-next
>> console output:
>>
On 5/19/20 11:42 PM, Ahmed S. Darwish wrote:
> Hello Eric,
>
> On Tue, May 19, 2020 at 07:01:38PM -0700, Eric Dumazet wrote:
>>
>> On 5/19/20 2:45 PM, Ahmed S. Darwish wrote:
>>> Sequence counters write paths are critical sections that must never be
>
On 5/19/20 7:57 PM, David Miller wrote:
> From: Thomas Gleixner
> Date: Wed, 20 May 2020 01:42:30 +0200
>
>> Stephen Hemminger writes:
>>> On Wed, 20 May 2020 00:23:48 +0200
>>> Thomas Gleixner wrote:
No. We did not. -ENOTESTCASE
>>>
>>> Please try, it isn't that hard..
>>>
>>> # time
s(+), 18 deletions(-)
>
Seems fine to me, assuming rwsem prevent starvation of the writer.
(Presumably this could be a per ndevice rwsem, or per netns, to provide some
isolation)
Alternative would be to convert ndev->name from char array to a pointer (rcu
protected),
but this looks quite invasive change, certainly not for stable branches.
Reviewed-by: Eric Dumazet
On Sat, May 16, 2020 at 3:35 PM Shakeel Butt wrote:
>
> On Sat, May 16, 2020 at 1:40 PM David Miller wrote:
> >
> > From: Shakeel Butt
> > Date: Fri, 15 May 2020 19:17:36 -0700
> >
> > > and thus there is no need to have any fallback after vzalloc.
> >
> > This statement is false.
> >
> > The
On Fri, May 15, 2020 at 8:23 AM Nate Karstens wrote:
>
>
> Series of 4 patches to implement close-on-fork. Tests have been
> published to https://github.com/nkarstens/ltp/tree/close-on-fork
> and cover close-on-fork functionality in the following syscalls:
>
> * accept(4)
> * dup3(2)
> *
On Wed, May 13, 2020 at 12:49 PM Eric Dumazet wrote:
>
> I do not think we want to transition sockets in the middle. since
> packets can be re-ordered in the network.
>
> MD5 is about security (and a loose form of it), so better make sure
> all packets have it from the beg
I do not think we want to transition sockets in the middle. since
packets can be re-ordered in the network.
MD5 is about security (and a loose form of it), so better make sure
all packets have it from the beginning of the flow.
A flow with TCP TS on can not suddenly be sending packets without
On 5/13/20 9:09 AM, Christoph Hellwig wrote:
> On Wed, May 13, 2020 at 08:41:57AM -0700, Eric Dumazet wrote:
>>> +* recv* side when msg_control_is_user is set, msg_control is the kernel
>>> +* buffer used for all other cases.
>>> +*/
>&g
On 5/11/20 4:59 AM, Christoph Hellwig wrote:
> The msg_control field in struct msghdr can either contain a user
> pointer when used with the recvmsg system call, or a kernel pointer
> when used with sendmsg. To complicate things further kernel_recvmsg
> can stuff a kernel pointer in and then
On Thu, May 7, 2020 at 2:12 AM Shaokun Zhang wrote:
>
> Hi Peter/Eric,
>
> Shall we use atomic_add_return() unconditionally and add some comments? Or I
> missed
> something.
>
Yes. A big fat comment, because I do not want yet another bogus
complaint from someone playing with a buggy UBSAN.
On Wed, May 6, 2020 at 5:59 AM SeongJae Park wrote:
>
> TL; DR: It was not kernel's fault, but the benchmark program.
>
> So, the problem is reproducible using the lebench[1] only. I carefully read
> it's code again.
>
> Before running the problem occurred "poll big" sub test, lebench executes
>
On 5/5/20 9:31 AM, Eric Dumazet wrote:
>
>
> On 5/5/20 9:25 AM, Eric Dumazet wrote:
>>
>>
>> On 5/5/20 9:13 AM, SeongJae Park wrote:
>>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>>>
>>>> On Tue, May 5, 2020 at 8:47 AM Seon
On 5/5/20 9:25 AM, Eric Dumazet wrote:
>
>
> On 5/5/20 9:13 AM, SeongJae Park wrote:
>> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>>
>>> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>>>>
>>>> On Tu
On 5/5/20 9:13 AM, SeongJae Park wrote:
> On Tue, 5 May 2020 09:00:44 -0700 Eric Dumazet wrote:
>
>> On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>>>
>>> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet
>>> wrote:
>>>
>>>>
&g
On Tue, May 5, 2020 at 8:47 AM SeongJae Park wrote:
>
> On Tue, 5 May 2020 08:20:50 -0700 Eric Dumazet wrote:
>
> >
> >
> > On 5/5/20 8:07 AM, SeongJae Park wrote:
> > > On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet
> > > wrote:
> > &g
On 5/5/20 8:07 AM, SeongJae Park wrote:
> On Tue, 5 May 2020 07:53:39 -0700 Eric Dumazet wrote:
>
>> Why do we have 10,000,000 objects around ? Could this be because of
>> some RCU problem ?
>
> Mainly because of a long RCU grace period, as you guess. I have no ide
On Tue, May 5, 2020 at 4:54 AM SeongJae Park wrote:
>
> CC-ing sta...@vger.kernel.org and adding some more explanations.
>
> On Tue, 5 May 2020 10:10:33 +0200 SeongJae Park wrote:
>
> > From: SeongJae Park
> >
> > The commit 6d7855c54e1e ("sockfs: switch to ->free_inode()") made the
> >
On 5/1/20 8:15 PM, Qian Cai wrote:
> netif_receive_skb_list_internal() could call enqueue_to_backlog() to put
> some skb to softnet_data.input_pkt_queue and then in
> ip_route_input_slow(), it allocates a dst_entry to be used in
> skb_dst_set(). Later,
>
> cleanup_net
>
On 10/19/19 2:18 PM, Tejun Heo wrote:
> Whatever works is fine by me. gfpflags_allow_blocking() is clearer
> than testing __GFP_DIRECT_RECLAIM directly tho. Maybe a better way is
> introducing a new gfpflags_ helper?
Sounds good to me !
On 10/19/19 10:01 AM, Tejun Heo wrote:
> From f0335a5d14d3596d36e3ffddb2fd4fa0dc6ca9c2 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Sat, 19 Oct 2019 09:10:57 -0700
>
> sk_page_frag() optimizes skb_frag allocations by using per-task
> skb_frag cache when it knows it's the only user. The
On 10/17/19 3:59 AM, Shaokun Zhang wrote:
> From: yuqi jin
>
> When the address width of DMA is greater than 32, the packet header occupies
> a BD descriptor. The starting address of the data should be added to the
> header length.
>
> Cc: Giuseppe Cavallaro
> Cc: Alexandre Torgue
> Cc:
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: ff229eee3d897f52bd001c841f2d3cce8853ecdc
Gitweb:
https://git.kernel.org/tip/ff229eee3d897f52bd001c841f2d3cce8853ecdc
Author:Eric Dumazet
AuthorDate:Tue, 08 Oct 2019 10:32:04 -07:00
On Mon, Oct 14, 2019 at 5:51 AM Markus Elfring wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_minisocks.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n306
> https://elixir.bootlin.com/linux/v5.4-rc2/source/net/ipv4/tcp_minisocks.c#L306
>
On 10/14/19 12:07 AM, Zhiyuan Hou wrote:
>
> On 2019/10/12 6:59 下午, Eric Dumazet wrote:
>>
>> On 10/12/19 12:16 AM, Zhiyuan Hou wrote:
>>> In act_mirred's ingress redirection, if the skb's dst_entry is valid
>>> when call function netif_receiv
On 10/13/19 11:51 PM, Markus Elfring wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_minisocks.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n306
>>> https://elixir.bootlin.com/linux/v5.4-rc2/source/net/ipv4/tcp_minisocks.c#L306
> …
>> Presumably
On 10/13/19 9:42 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: c208bdb9 tcp: improve recv_skip_hint for tcp_zerocopy_rece..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b6133b60
> kernel config:
On Tue, Oct 8, 2019 at 10:32 AM Eric Dumazet wrote:
>
> Followup to commit dd2261ed45aa ("hrtimer: Protect lockless access
> to timer->base")
>
> lock_hrtimer_base() fetches timer->base without lock exclusion.
>
> Compiler is allowed to read timer->base
On 10/13/19 3:41 PM, Vito Caputo wrote:
> I read it, thank you for your responses.
>
> Do you have any guidance to offer someone wanting to contribute with 1-2
> hours available per day? I don't want to cause a nuisance, but would
> like to help where I can. My flawed assumption was that
On 10/13/19 1:01 PM, Vito Caputo wrote:
> On Sun, Oct 13, 2019 at 12:30:41PM -0700, Eric Dumazet wrote:
>>
>>
>> On 10/12/19 4:55 AM, Vito Caputo wrote:
>>> Eliminate some verbosity by using min() macro and consolidating some
>>> things, also
On 10/12/19 7:51 AM, Markus Elfring wrote:
> Hello,
>
> I tried another script for the semantic patch language out.
> This source code analysis approach points out that the implementation
> of the function “tcp_time_wait” contains also a call of the function
> “kmemdup”.
>
On 10/12/19 4:55 AM, Vito Caputo wrote:
> Eliminate some verbosity by using min() macro and consolidating some
> things, also fix inconsistent zero tests (! vs. == 0).
>
> Signed-off-by: Vito Caputo
> ---
> net/core/datagram.c | 44 ++--
> 1 file
On Sat, Oct 12, 2019 at 2:22 AM Alexander Lobakin wrote:
>
> I've generated an another solution. Considering that gro_normal_batch
> is very individual for every single case, maybe it would be better to
> make it per-NAPI (or per-netdevice) variable rather than a global
> across the kernel?
> I
On 10/12/19 3:49 AM, Eric Dumazet wrote:
>
> Okay, but we also need this.
>
> diff --git a/net/rxrpc/peer_event.c b/net/rxrpc/peer_event.c
> index
> c97ebdc043e44525eaecdd54bc447c1895bdca74..38db10e61f7a5cb50f9ee036b5e16ec284e723ac
> 100644
> --- a/net/rxrpc/peer_e
On 10/12/19 12:16 AM, Zhiyuan Hou wrote:
> In act_mirred's ingress redirection, if the skb's dst_entry is valid
> when call function netif_receive_skb, the fllowing l3 stack process
> (ip_rcv_finish_core) will check dst_entry and skip the routing
> decision. Using the old dst_entry is
On 10/10/19 7:52 AM, David Howells wrote:
> If an ICMP packet comes in on the UDP socket backing an AF_RXRPC socket as
> the UDP socket is being shut down, rxrpc_error_report() may get called to
> deal with it after sk_user_data on the UDP socket has been cleared, leading
> to a NULL pointer
time spent by humans.
I knew nothing about drivers/spi/spi.c, but after few minutes reading the code,
it was clear your report was wrong.
Do not ask us to do what you should do yourself.
Thanks.
>
> On Wed, Oct 9, 2019 at 10:48 PM Eric Dumazet wrote:
>>
>>
>>
>>
On 10/9/19 10:37 PM, Yizhuo Zhai wrote:
> Hi All:
>
> drivers/spi/spi.c:
>
> The function to_spi_device() could return NULL, but some callers
> in this file does not check the return value while directly dereference
> it, which seems potentially unsafe.
>
> Such callers include
On Wed, Oct 9, 2019 at 8:18 PM Paul E. McKenney wrote:
> Again, good catch, applied for review and testing, thank you!
>
> I added another READ_ONCE() to dump_blkd_tasks(), which is not exercised
> unless you get an RCU CPU stall warning or some such. The updated patch
> is below, please let me
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Signed-off-by: Eric Dumazet
Cc: "Paul E. McKenney"
Reported-by: syzbot
---
kernel/rcu/tree_plugin.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/tr
On 10/9/19 12:45 AM, Dmitry Vyukov wrote:
> On Sat, Oct 5, 2019 at 6:16 AM Dmitry Vyukov wrote:
>>
>> On Sat, Oct 5, 2019 at 2:58 AM Eric Dumazet wrote:
>>>> This one is tricky. What I think we need to avoid is an onslaught of
>>>> patches adding
milarly the write sides should use WRITE_ONCE() to avoid
store tearing.
Signed-off-by: Eric Dumazet
Cc: Julien Grall
Cc: Thomas Gleixner
---
kernel/time/hrtimer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index
0d4dc2
On 10/7/19 2:08 PM, Yizhuo Zhai wrote:
> Hi All:
>
> net/sched/sch_mq.c:
> Inside function mq_dump_class(), mq_queue_get() could return NULL,
> however, the return value of dev_queue is not checked and get used.
> This could potentially be unsafe.
>
>
Not really.
mq_dump_class() is called
On 9/20/19 8:54 AM, Will Deacon wrote:
>
> This one is tricky. What I think we need to avoid is an onslaught of
> patches adding READ_ONCE/WRITE_ONCE without a concrete analysis of the
> code being modified. My worry is that Joe Developer is eager to get their
> first patch into the kernel,
On 9/27/19 1:55 AM, Stefano Garzarella wrote:
> Good catch!
>
> Maybe we can solve in this way:
>
> list_for_each_entry(pkt, >rx_queue, list) {
> size_t off = pkt->off;
>
> if (total == len)
> break;
>
> while (total <
On 8/21/19 6:50 AM, Thomas Gleixner wrote:
> On Wed, 21 Aug 2019, Sebastian Andrzej Siewior wrote:
>
>> On 2019-08-21 10:24:07 [+0100], Julien Grall wrote:
>>> The update to timer->base is protected by the base->cpu_base->lock().
>>> However, hrtimer_grab_expirty_lock() does not access it with
On 9/26/19 11:23 AM, Matias Ezequiel Vara Larsen wrote:
> This patch adds support for MSG_PEEK. In such a case, packets are not
> removed from the rx_queue and credit updates are not sent.
>
> Signed-off-by: Matias Ezequiel Vara Larsen
> ---
> net/vmw_vsock/virtio_transport_common.c | 50
>
On 9/23/19 8:06 AM, Petr Vorel wrote:
> Hi,
>
>> People are reporting that WireGuard experiences erratic crashes on 5.3,
>> and bisected it down to 7d30a7f6424e. Casually flipping through that
>> commit I noticed that a flag is checked using `|` instead of `&`, which in
>> this current case,
On 9/24/19 11:59 AM, Daniel Borkmann wrote:
> On Mon, Sep 23, 2019 at 02:31:04PM -0700, Eric Dumazet wrote:
>> On 9/6/19 10:06 AM, Alexei Starovoitov wrote:
>>> On Fri, Sep 6, 2019 at 3:03 AM Yonghong Song wrote:
>>>> On 9/5/19 2:15 PM, Sami Tolvanen wrote:
&g
On 9/6/19 10:06 AM, Alexei Starovoitov wrote:
> On Fri, Sep 6, 2019 at 3:03 AM Yonghong Song wrote:
>>
>>
>>
>> On 9/5/19 2:15 PM, Sami Tolvanen wrote:
>>> Instead of invoking struct bpf_prog::bpf_func directly, use the
>>> BPF_PROG_RUN macro.
>>>
>>> Signed-off-by: Sami Tolvanen
>>
>>
On Fri, Sep 6, 2019 at 11:34 AM chunguo feng wrote:
>
> From: fengchunguo
>
> This patch avoids fastopen_rsk not be cleared every times, then occur
> the below BUG_ON:
> tcp_v4_destroy_sock
> ->BUG_ON(tp->fastopen_rsk);
>
> When playback some videos from netwrok,used tcp_disconnect
On 9/5/19 4:09 PM, Qian Cai wrote:
> Instead of repeatedly make generalize statements, could you enlighten me with
> some concrete examples that have the similar properties which would trigger a
> livelock,
>
> - guaranteed GFP_ATOMIC allocations when processing softirq batches.
> - the
On 9/5/19 4:09 PM, Qian Cai wrote:
>
> I feel like you may not follow the thread closely. There are more details
> uncovered in the last few days and narrowed down to the culprits.
>
I have followed the thread closely, thank you very much.
I am happy that the problem is addressed as I
On 9/4/19 10:42 PM, Qian Cai wrote:
> To summary, those look to me are all good long-term improvement that would
> reduce the likelihood of this kind of livelock in general especially for other
> unknown allocations that happen while processing softirqs, but it is still up
> to
> the air if
On 9/4/19 11:42 AM, Mao Wenan wrote:
> When dma_map_single is failed to map buffer, skb can't be freed
> before sonic driver return to stack with NETDEV_TX_BUSY, because
> this skb may be requeued to qdisc, it might trigger use-after-free.
>
> Fixes: d9fb9f384292 ("*sonic/natsemi/ns83829: Move
On 9/3/19 3:08 AM, Gustavo A. R. Silva wrote:
> Add suffix LL to constant 1000 in order to avoid a potential integer
> overflow and give the compiler complete information about the proper
> arithmetic to use. Notice that this constant is being used in a context
> that expects an expression of
On 8/30/19 5:25 PM, Qian Cai wrote:
> On Fri, 2019-08-30 at 17:11 +0200, Eric Dumazet wrote:
>>
>> On 8/30/19 4:57 PM, Qian Cai wrote:
>>> When running heavy memory pressure workloads, the system is throwing
>>> endless warnings below due to the allocatio
On 8/30/19 4:57 PM, Qian Cai wrote:
> When running heavy memory pressure workloads, the system is throwing
> endless warnings below due to the allocation could fail from
> __build_skb(), and the volume of this call could be huge which may
> generate a lot of serial console output and cosumes
On 8/19/19 5:15 AM, Hayes Wang wrote:
> Fix accessing skb after napi_gro_receive which is caused by
> commit 47922fcde536 ("r8152: support skb_add_rx_frag").
>
> Fixes: 47922fcde536 ("r8152: support skb_add_rx_frag")
> Signed-off-by: Hayes Wang
> ---
It is customary to add a tag to credit
On 8/29/19 12:51 AM, David Dai wrote:
> For high speed adapter like Mellanox CX-5 card, it can reach upto
> 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> in tc utility. However police action rate and peakrate are still limited
> to 32bit value (upto 32 Gbits per
On 8/27/19 11:08 AM, Yi Wang wrote:
> From: Cheng Lin
>
> Originally, Router Reachability Probing require a neighbour entry
> existed. Commit 2152caea7196 ("ipv6: Do not depend on rt->n in
> rt6_probe().") removed the requirement for a neighbour entry. And
> commit f547fac624be ("ipv6:
On 8/26/19 9:23 AM, Dongxu Liu wrote:
> The __ethtool_get_link_ksettings symbol will be exported,
> and external users may use an illegal address.
> We should check the parameters before using them,
> otherwise the system will crash.
>
> [ 8980.991134] BUG: unable to handle kernel NULL pointer
On 8/17/19 10:24 AM, Sander Eikelenboom wrote:
> On 12/08/2019 19:56, Eric Dumazet wrote:
>>
>>
>> On 8/12/19 2:50 PM, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> While testing a somewhere-after-5.3-rc3 kernel (which included the latest
>>
On 8/16/19 11:08 AM, Hayes Wang wrote:
> Eric Dumazet [mailto:eric.duma...@gmail.com]
>> Sent: Friday, August 16, 2019 4:20 PM
> [...]
>> Which callback ?
>
> The USB device has two endpoints for Tx and Rx.
> If I submit tx or rx URB to the USB host controll
On 8/16/19 10:10 AM, Hayes Wang wrote:
> Eric Dumazet [mailto:eric.duma...@gmail.com]
>> Sent: Friday, August 16, 2019 2:40 PM
> [...]
>> tasklet and NAPI are scheduled on the same core (the current
>> cpu calling napi_schedule() or tasklet_schedule())
>>
>>
On 8/13/19 5:42 AM, Hayes Wang wrote:
> Use skb_add_rx_frag() to reduce the memory copy for rx data.
>
> Use a new list of rx_used to store the rx buffer which couldn't be
> reused yet.
>
> Besides, the total number of rx buffer may be increased or decreased
> dynamically. And it is limited
On 8/14/19 10:30 AM, Hayes Wang wrote:
> Move the tx bottom function from NAPI to a new tasklet. Then, for
> multi-cores, the bottom functions of tx and rx may be run at same
> time with different cores. This is used to improve performance.
>
>
tasklet and NAPI are scheduled on the same
On 8/13/19 3:48 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 61ccdad1 Revert "drm/bochs: Use shadow buffer for bochs fr..
> git tree: https://github.com/google/kmsan.git master
> console output:
On 8/12/19 2:50 PM, Sander Eikelenboom wrote:
> L.S.,
>
> While testing a somewhere-after-5.3-rc3 kernel (which included the latest net
> merge (33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9),
> one of my Xen VM's (which gets quite some network load) crashed.
> See below for the stacktrace.
>
>
On 7/29/19 7:23 PM, Cong Wang wrote:
> On Mon, Jul 29, 2019 at 1:24 AM Jia-Ju Bai wrote:
>>
>> In dequeue_func(), there is an if statement on line 74 to check whether
>> skb is NULL:
>> if (skb)
>>
>> When skb is NULL, it is used on line 77:
>> prefetch(>end);
>>
>> Thus, a possible
On 7/26/19 11:17 AM, Shaokun Zhang wrote:
> From: Yang Guo
>
> There is an significant performance regression with the following
> commit-id
> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
>
>
So, you jump around and took ownership of this issue, while some of us
On 7/25/19 6:29 AM, maowenan wrote:
>
> Syzkaller reproducer():
> r0 = socket$packet(0x11, 0x3, 0x300)
> r1 = socket$inet_tcp(0x2, 0x1, 0x0)
> bind$inet(r1, &(0x7f000300)={0x2, 0x4e21, @multicast1}, 0x10)
> connect$inet(r1, &(0x7f000140)={0x2, 0x104e21,
On 7/24/19 11:09 PM, Eric Biggers wrote:
> On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
>> From: Eric Biggers
>> Date: Wed, 24 Jul 2019 11:37:12 -0700
>>
>>> We can argue about what words to use to describe this situation, but
>>> it doesn't change the situation itself.
>>
>>
On Wed, Jul 24, 2019 at 8:37 PM Eric Biggers wrote:
> A huge number of valid open bugs are not being fixed, which is a fact. We can
> argue about what words to use to describe this situation, but it doesn't
> change
> the situation itself.
>
> What is your proposed solution?
syzbot sends
On 7/24/19 12:46 PM, maowenan wrote:
>
>
> On 2019/7/24 17:45, Eric Dumazet wrote:
>>
>>
>> On 7/24/19 11:17 AM, Mao Wenan wrote:
>>> There is one report about tcp_write_xmit use-after-free with version
>>> 4.4.136:
>>>
>>> BUG
On 7/24/19 12:36 PM, maowenan wrote:
> Actually, I have tested 4.4.184, UAF still happen.
>
>
Thanks for testing.
Acked-by: Eric Dumazet
On 7/24/19 12:01 PM, Eric Dumazet wrote:
>
>
> On 7/24/19 11:17 AM, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> Current stable 4.4 is 4.4.186
>
> Can you check the bug is still there ?
>
BTW, I tri
On 7/24/19 11:17 AM, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
Current stable 4.4 is 4.4.186
Can you check the bug is still there ?
List of patches between 4.4.136 and 4.4.186 (this list is not exhaustive)
On 7/24/19 11:17 AM, Mao Wenan wrote:
> There is one report about tcp_write_xmit use-after-free with version 4.4.136:
>
> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619
> [inline]
> BUG:
On 7/24/19 10:38 AM, Zhangshaokun wrote:
> Hi,
>
> I've observed an significant performance regression with the following
> commit-id
> ("net: get rid of an signed integer overflow in ip_idents_reserve()").
Yes this UBSAN false positive has been painful
>
> Here are my test scenes:
>
sorted by an algorithm that tries to list first the
> reports
> most likely to be still valid, important, and actionable.
>
> Of these 99 bugs, 17 were seen in mainline in the last week.
>
> Of these 99 bugs, 4 were bisected to commits from the following people:
>
> Flor
301 - 400 of 5670 matches
Mail list logo
