On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN
> Mo
On Wed, Nov 9, 2016 at 2:46 AM, Andrey Konovalov wrote:
> Hi Xin,
>
> Your patch seems to be fixing the issue.
>
> Tested-by: Andrey Konovalov
>
> Thanks!
>
> On Tue, Nov 8, 2016 at 11:06 AM, Xin Long wrote:
>> On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov
On Wed, Dec 14, 2016 at 5:37 AM, Marcelo Ricardo Leitner
wrote:
> On Tue, Dec 13, 2016 at 07:07:01PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> I am getting the following reports while running syzkaller fuzzer:
>>
>> [ INFO: suspicious RCU usage. ]
>> 4.9.0+ #85 Not tainted
>> ---
On Sat, Mar 18, 2017 at 7:13 PM, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/veth.c | 22 ++
> 1 files changed, 10 insertions(+),
On Tue, Feb 28, 2017 at 11:35 PM, Dmitry Vyukov wrote:
> On Mon, Feb 27, 2017 at 5:27 PM, Xin Long wrote:
>> On Mon, Feb 27, 2017 at 11:45 PM, Andrey Konovalov
>> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzi
-t nat)
2. the asocs info in client (# cat /proc/net/sctp/assocs)
3. more packet you captured, like 4-shake and some packets
right before these 3 packets.
4. conntrack info in router (# cat /proc/net/nf_conntrack)
> On Mon, Feb 27, 2017 at 11:06 PM, Xin Long wrote:
>> On Mon, F
On Thu, Mar 2, 2017 at 3:18 AM, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> linux-next/8813198236a044b76e251dcae937b180dd527999:
>
> BUG: KASAN: use-after-free in sctp_association_destroy
> net/sctp/associola.c:416 [inline] at addr 8801c0
On Fri, Mar 3, 2017 at 3:21 AM, Dmitry Vyukov wrote:
> On Thu, Mar 2, 2017 at 9:06 AM, Xin Long wrote:
>> On Thu, Mar 2, 2017 at 3:18 AM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> I've got the following report while r
On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however, a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
>
>
> 03:32:35.23357
ier
>
> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long wrote:
>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul wrote:
>>> Hi,
>>>
>>> sorry to get back late, the platform is running on KVM. and this
>>> problem is resolved by moving to VMware environme
On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote:
> Hi Xin
>
> do you mean we need to patch the kernel?
Yups, pls comment on that bz if it's really needed for your env.
A z-stream kernel may be available for that issue soon.
Thanks.
>
>
>
> On Wed, Feb 22, 2017 at
On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote:
> does this fixed in RHEL7?
yes, I think so.
>
> On Wed, Feb 22, 2017 at 11:03 AM, Xin Long wrote:
>> On Wed, Feb 22, 2017 at 10:29 AM, Sun Paul wrote:
>>> Hi Xin
>>>
>>> do you mean we need to patch t
ernel/git/davem/net.git
https://kernelnewbies.org/KernelBuild :
part "Setting up your kernel configuration" and
part "Building the kernel"
> On Thu, Feb 23, 2017 at 2:07 PM, Xin Long wrote:
>> On Thu, Feb 23, 2017 at 1:30 PM, Sun Paul wrote:
>>> does this fixed
On Mon, Feb 27, 2017 at 11:45 PM, Andrey Konovalov
wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26).
>
> A reproducer and .config are attached.
>
> ===
> [ ERR:
On Tue, Feb 7, 2017 at 7:09 PM, Marcelo Ricardo Leitner
wrote:
> On Tue, Feb 07, 2017 at 10:42:38AM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in sctp_addr_id2transport:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include
>> #in
On Thu, Feb 9, 2017 at 3:00 AM, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached.
>
> general protection fault: [#1] SMP KASAN
> Dump
>
> It doesn't seem memory is an issue.
>
> The whole dump is about the same.
> The MemFree and MemAvailable doesn't change much.
>
Hi, Aaron
1)
I talked with Marcelo about this one.
He said it might be related with cacheline. the new field distroyed
the prior cacheline. So on top of commit 826d
>> Hi, Aaron
>>
>> 1)
>> I talked with Marcelo about this one.
>> He said it might be related with cacheline. the new field distroyed
>> the prior cacheline. So on top of commit 826d253d57b1, pls only add
>> + unsigned long prsctp_param;
>>
>> to the end of struct sctp_chunk, then try.
>
>
that is
> part of an existing association has experienced a change of
> state (e.g., a failure or return to service of the reachability
> of an endpoint via a specific transport address).
>
> Signed-off-by: Jonas Falkevik
Reviewed-by: Xin Long
> ---
> Changes in v2:
>
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop after
> 2.5 seconds wit
t;>>
> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>>>
> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> &
On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 2:34 AM Michael Tuexen
> > wrote:
> > >
> > > > On 22. Jun 2020, at 20:32, Marcelo Ricardo Leitner
> > >
On Tue, Jul 14, 2020 at 5:37 PM Steffen Klassert
wrote:
>
> Xin,
>
> this looks a bit like it was introduced with one of your recent
> patches. Can you please look into that?
Yes, I'm looking into it.
Thanks.
>
> Thanks!
>
> On Mon, Jul 13, 2020 at 03:04:16PM -0700, syzbot wrote:
> > Hello,
> >
o.syz?x=15ada44d90
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1400746790
>
> The issue was bisected to:
>
> commit ff48b6222e65ebdba5a403ef1deba6214e749193
> Author: Xin Long
> Date: Sun Sep 13 11:37:31 2020 +
>
> tipc: use skb_unshare() instead
On Mon, May 25, 2020 at 9:10 PM Marcelo Ricardo Leitner
wrote:
>
> On Mon, May 25, 2020 at 04:42:16PM +0800, Xin Long wrote:
> > On Sat, May 23, 2020 at 8:04 PM Jonas Falkevik
> > wrote:
> > >
> > > On Tue, May 19, 2020 at 10:42 PM Marcelo Ricardo Leitner
On Fri, May 22, 2020 at 9:45 AM Yuehaibing wrote:
>
> On 2020/5/21 14:49, Xin Long wrote:
> > On Tue, May 19, 2020 at 4:53 PM Steffen Klassert
> > wrote:
> >>
> >> On Fri, May 15, 2020 at 04:39:57PM +0800, Yuehaibing wrote:
> >>>
> >&
On Fri, May 22, 2020 at 8:39 PM Yuehaibing wrote:
>
> On 2020/5/22 13:49, Xin Long wrote:
> > On Fri, May 22, 2020 at 9:45 AM Yuehaibing wrote:
> >>
> >> On 2020/5/21 14:49, Xin Long wrote:
> >>> On Tue, May 19, 2020 at 4:53 PM Steffen Klassert
> >
On Sat, May 23, 2020 at 8:04 PM Jonas Falkevik wrote:
>
> On Tue, May 19, 2020 at 10:42 PM Marcelo Ricardo Leitner
> wrote:
> >
> > On Fri, May 15, 2020 at 10:30:29AM +0200, Jonas Falkevik wrote:
> > > On Wed, May 13, 2020 at 11:32 PM Marcelo Ricardo Leitner
> > > wrote:
> > > >
> > > > On Wed,
On Wed, Aug 12, 2020 at 7:21 AM kernel test robot wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: c636eef2ee3696f261a35f34989842701a107895
> commit: 5a6f6f579178dbeb33002d93b4f646c31348fac9 tipc: set ub->ifindex for
> local ipv6 address
>
On Sun, Aug 16, 2020 at 4:32 PM kernel test robot wrote:
>
> Hi Xin,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 4b6c093e21d36bede0fd88fd0aeb3b03647260e4
> commit: 5a6f6f579178dbeb33002d93b4f646c31348f
On Sun, Nov 1, 2020 at 1:40 PM syzbot
wrote:
>
> syzbot has bisected this issue to:
>
> commit bcd623d8e9fa5f82bbd8cd464dc418d24139157b
> Author: Xin Long
> Date: Thu Oct 29 07:05:05 2020 +
>
> sctp: call sk_setup_caps in sctp_packet_transmit instead
&
On Tue, Nov 3, 2020 at 9:14 PM Xin Long wrote:
>
> On Sun, Nov 1, 2020 at 1:40 PM syzbot
> wrote:
> >
> > syzbot has bisected this issue to:
> >
> > commit bcd623d8e9fa5f82bbd8cd464dc418d24139157b
> > Author: Xin Long
> > Date: Thu Oct
On Mon, Jul 27, 2020 at 4:11 AM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit ed17b8d377eaf6b4a01d46942b4c647378a79bdd
> Author: Xin Long
> Date: Mon May 25 05:53:37 2020 +
>
> xfrm: fix a warning in xfrm_policy_insert_list
&
Hi, Steffen,
I've confirmed the patchset I posted yesterday would fix this:
[PATCH ipsec-next 0/3] xfrm: not register one xfrm(6)_tunnel object twice
Thanks.
On Tue, Jul 14, 2020 at 5:37 PM Steffen Klassert
wrote:
>
> Xin,
>
> this looks a bit like it was introduced with one of your recent
> p
On Fri, May 31, 2019 at 10:59 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bec7550c Merge tag 'docs-5.2-fixes2' of git://git.lwn.net/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=152a0916a0
> kernel config:
On Wed, Jun 19, 2019 at 11:48 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c
> git tree: kmsan
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d0a6fea0
> kernel config: https://syzkal
/0xa9
> >
> >
> > It was introduced in commit d570a59c5b5f ("sctp: only allow the out stream
> > reset when the stream outq is empty"), in orde to check stream outqs before
> > sending SCTP_STRRESET_IN_PROGRESS back to the peer of the stream. EAGAIN is
> >
On Mon, Jun 3, 2019 at 11:22 AM Young Xiao <92siuy...@gmail.com> wrote:
>
> Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti
> overflow on the underlying interface.
>
> Attempting the set IFF_ALLMULTI on the underlying interface would cause an
> error and the log message:
On Wed, Jun 24, 2020 at 12:00 AM Corey Minyard wrote:
>
> On Tue, Jun 23, 2020 at 11:40:21PM +0800, Xin Long wrote:
> > On Tue, Jun 23, 2020 at 9:29 PM Corey Minyard wrote:
> > >
> > > On Tue, Jun 23, 2020 at 06:13:30PM +0800, Xin Long wrote:
> > > &g
22 June 2020 19:33
> >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Jun 22, 202
On Wed, Mar 29, 2017 at 2:24 PM, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes
> ---
> Changelog:
> v2:
> - avoid useless initiazation to zero (tha
On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit a71c9a1c779f2499fb2afc0553e543f18aff6edf (4.11-rc5).
>
> A reproducer and .config are attached.
The script is pretty hard to reproduce the is
On Wed, Apr 5, 2017 at 5:14 AM, Marcelo Ricardo Leitner
wrote:
> On Wed, Apr 05, 2017 at 01:29:19AM +0800, Xin Long wrote:
>> On Tue, Apr 4, 2017 at 9:28 PM, Andrey Konovalov
>> wrote:
>> > Hi,
>> >
>> > I've got the following error repor
On Wed, Jul 19, 2017 at 3:02 AM, Alexander Potapenko wrote:
> On Tue, Jul 18, 2017 at 4:55 PM, Alexander Potapenko
> wrote:
>> KMSAN reported use of uninitialized sctp_addr->v4.sin_addr.s_addr and
>> sctp_addr->v6.sin6_scope_id in sctp_v6_cmp_addr() (see below).
>> Make sure all fields of an IPv
On Wed, Feb 21, 2018 at 9:59 PM, syzbot
wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 79c0ef3e85c015b0921a8fd5dd539d1480e9cd6c (Mon Feb 19 19:58:19 2018 +)
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
> So far this crash happened 2 times on
> http
On Thu, Feb 8, 2018 at 6:58 AM, syzbot
wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> a2e5790d841658485d642196dbb0927303d6c22f (Wed Feb 7 06:15:42 2018 +)
> Merge branch 'akpm' (patches from Andrew)
>
> So far this crash happened 632 times on
> https://git.kernel.org/p
On Thu, Feb 8, 2018 at 9:25 PM, Dmitry Vyukov wrote:
> On Thu, Feb 8, 2018 at 10:54 AM, Xin Long wrote:
>> On Thu, Feb 8, 2018 at 6:58 AM, syzbot
>> wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on upstream commit
>>> a2e5790d841658
On Fri, Feb 2, 2018 at 3:21 AM, syzbot
wrote:
> Hello,
>
> syzbot hit the following crash on net-next commit
> b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +)
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>
> Unfortunately, I don't have any reproduc
On Thu, Feb 1, 2018 at 7:58 PM, syzbot
wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 255442c93843f52b6891b21d0b485bf2c97f93c3 (Thu Feb 1 03:25:25 2018 +)
> Merge tag 'docs-4.16' of git://git.lwn.net/linux
>
> So far this crash happened 1587 times on net-next, upstream
On Thu, Feb 1, 2018 at 1:49 AM, Xin Long wrote:
> On Tue, Jan 30, 2018 at 11:59 PM, David Ahern wrote:
>> On 1/30/18 1:57 PM, David Ahern wrote:
>>> On 1/30/18 1:08 PM, Daniel Borkmann wrote:
>>>> On 01/30/2018 07:32 PM, Cong Wang wrote:
>>>>> O
On Sat, Dec 30, 2017 at 7:54 PM, Willem de Bruijn
wrote:
>> So this is a packet socket writing something that apparently looks
>> like an SCTP packet, is only 42 bytes long, but has GSO set in its
>> virtio_net_hdr struct.
>>
>> It crashes in skb_segment seemingly on a NULL list_skb.
>>
>> (gdb) l
On Sun, Dec 31, 2017 at 10:25 AM, Marcelo Ricardo Leitner
wrote:
> On Sat, Dec 30, 2017 at 10:52:20PM -0200, Marcelo Ricardo Leitner wrote:
>> On Sat, Dec 30, 2017 at 08:42:41AM +0100, Willem de Bruijn wrote:
> [...]
>> > Somewhat tangential, but any PF_PACKET socket can set this
>> > magic gso_si
gt;> generated in sctp_eat_data and it can't be NULL.
>>
>> Reported-by: Marcelo Ricardo Leitner
>> Signed-off-by: Xin Long
>> Acked-by: Neil Horman
>> Signed-off-by: David S. Miller
>> Signed-off-by: Sasha Levin
>> ---
>> net/sctp/ulpqueu
This patch is to fix the 'dubious one-bit signed bitfield' error reported
by sparse, when using 'make C=2'.
Fixes: 799ba82de01e ("sched/deadline: Use C bitfields for the state flags")
Signed-off-by: Xin Long
---
include/linux/sched.h | 8
1 file changed
On Fri, Nov 17, 2017 at 4:20 PM, Luca Abeni wrote:
> Hi,
>
> On Fri, 17 Nov 2017 14:50:11 +0800
> Xin Long wrote:
>
>> This patch is to fix the 'dubious one-bit signed bitfield' error reported
>> by sparse, when using 'make C=2'.
>>
>>
On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
wrote:
> On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
>
> from the log:
> [ 89.451366] FAULT_INJECTION: forcing a failure.^M
> [ 89.451366] name failslab, interval 1, probability 0, space 0,
> times 0^M
> [ 89.451374] CPU: 0
On Tue, Dec 19, 2017 at 8:47 PM, Dmitry Vyukov wrote:
> On Tue, Dec 19, 2017 at 1:36 PM, syzbot
>
> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 7ceb97a071e80f1b5e4cd5a36de135612a836388
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc
0 00 00 fc fc fc fc fb fb fb fb fb fb
> fb fb
> [ 2327.397031]^
> [ 2327.401792] ffff881be8779880: fc fc fc fc fb fb fb fb fb fb fb fb fc fc
> fc fc
> [ 2327.409850] 881be8779900: 00 00 00 00 00 04 fc fc fc fc fc fc 00 00
> 00 00
> [ 2327.417907]
> =
On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott
wrote:
[...]
>
> A system running v4.12-rc3-11-gf511c0b on s390 hangs after boot with no
> messages on the console. The message buffer obtained via a system dump
> looked like this:
>
> [...]
> [ 17.870712] virbr0: port 1(virbr0-nic) entered disable
--
> 1 file changed, 6 insertions(+), 6 deletions(-)
I guess these patches are for net-next.git
Series Reviewed-by: Xin Long
>
> --
> 2.13.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message t
thanks,
>>>>>>>>
>>>>>>>> greg k-h
>>>>>>>>
>>>>>>>
>>>>>>> Compiled and booted. Networking is dead. I will bisect tomorrow and
>>>>>>> let you know what I
On Thu, Oct 12, 2017 at 11:18 PM, Andreas Radke
wrote:
> Building the 4.9.x kernel package for Arch Linux 4.9.55 gives this IPv4 error
> here:
>
> Job for dhcpd4.service failed because the control process exited with error
> code.
> See "systemctl status dhcpd4.service" and "journalctl -xe" fo
On Tue, Jul 25, 2017 at 4:27 AM, Alexander Potapenko wrote:
> On Wed, Jul 19, 2017 at 2:58 AM, Xin Long wrote:
>> On Wed, Jul 19, 2017 at 3:02 AM, Alexander Potapenko
>> wrote:
>>> On Tue, Jul 18, 2017 at 4:55 PM, Alexander Potapenko
>>> wrote:
>>
On Fri, Dec 8, 2017 at 1:26 PM, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-6):
>
> commit: ecca8f88da5c4260cc2bccfefd2a24976704c366 ("sctp: set frag_point in
> sctp_setsockopt_maxseg correctly")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g
On Fri, Dec 8, 2017 at 4:16 PM, syzbot
wrote:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> syzka
On Fri, Dec 8, 2017 at 4:45 PM, Xin Long wrote:
> On Fri, Dec 8, 2017 at 4:16 PM, syzbot
>
> wrote:
>> syzkaller has found reproducer for the following crash on
>> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
>> git://git.cmpxchg.org/linux-mmots.git/master
>> c
On Sat, Dec 9, 2017 at 6:40 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 328b4ed93b69a6f2083d52f31a240a09e5de386a
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is at
On Sat, Dec 9, 2017 at 7:35 PM, Xin Long wrote:
> On Sat, Dec 9, 2017 at 6:40 PM, syzbot
>
> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 328b4ed93b69a6f2083d52f31a240a09e5de386a
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds
On Sun, Dec 10, 2017 at 12:59 AM, Eric Dumazet wrote:
> On Sat, 2017-12-09 at 19:23 +0800, Xin Long wrote:
>> On Fri, Dec 8, 2017 at 4:45 PM, Xin Long
>> wrote:
>> > On Fri, Dec 8, 2017 at 4:16 PM, syzbot
>> > > > .com>
>> > wrote:
>> >
On Sun, Dec 10, 2017 at 3:36 AM, Cong Wang wrote:
> On Fri, Dec 8, 2017 at 12:45 AM, Xin Long wrote:
>> This isn't a sctp problem, but mld's, seems when lo's mtu became 0,
>> it allocs a skb without enough space in add_grec():
>
> Shouldn't we just se
>
> I'm testing on Linus' master, can we all use that please?
>
[git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mechine]
Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
mem 62G (66000220K)
[system]
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 Beta (Maip
>>>
>>> I'm testing on Linus' master, can we all use that please?
>>>
>>
>> [git] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>
>> [mechine]
>> Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
>> mem 62G (66000220K)
>>
>> [system]
>> # cat /etc/redhat-release
>> Red Hat Enterprise Li
>
> And I think we should be doing test on:
> commit a6c2f79287 ("sctp: implement prsctp TTL policy") (the bisected one)
> and
> commit 826d253d57 ("sctp: add SCTP_PR_ASSOC_STATUS on sctp sockopt") (its
> immediate parent)
> instead of Linus' master HEAD to avoid other factors.
>
The test result s
>
> For commit a6c2f79287 ("sctp: implement prsctp TTL policy"), no matter
> the value of net.sctp.prsctp_enable, the throughput is almost the same:
>
> net.sctp.prsctp_enable = 0
> {
> "netperf.Throughput_Mbps": [
> 2353.311249997
> ]
> }
>
> net.sctp.prsctp_enable = 1
> {
> "netperf
> The perf-profile data for the two commits are attached(for the case of
> prsctp_enable=1, the perf-profile data doesn't get collected for the 0
> case for some reason, I'm checking the problem now).
>
> The CPU gets much more idle time in the bisected commit a6c2f79287:
>
> 68.89% 0.70%
> include/net/sctp/structs.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index d8e464aacb20..932f2780d3a4 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -602,6 +602,9 @@ struct sctp_chunk {
>> you mean only this two line:
>>> + unsigned long prsctp_param;
>>> + int sent_count;ca;
>>
>> caused the performance issue ?
>
> Right.
OK, can you remove this line from your patch
+ int sent_count;
then test again, thanks.
>
> It doesn't change on my desktop Sandybridge.
>
> $ cat 4.7.0-rc6-01199-g116558d316e8/0/netperf.json
> {
> "netperf.Throughput_Mbps": [
>748.205624998
> ]
> }
>
> Where commit 116558d316e8 is based on top of the last test commit
> 98dd2532b14e with the sent_count removed.
Nice job
I
On Fri, Sep 30, 2016 at 3:05 PM, Aaron Lu wrote:
> On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote:
>> Em 19-08-2016 04:24, Aaron Lu escreveu:
>>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
Hi,
Em 19-08-2016 02:29, Aaron Lu escreveu:
...
> + tc_check_packets "dev ep-ex ingress" 102 1
> + check_err $? "ERSPAN Type III"
> +
> + # h2 erspan cleanup
> + tc qdisc del dev ep-ex clsact
> + tunnel_destroy ep-ex
> + # h1 erspan cleanup
> + tunnel_destroy erspan2 # ERSPAN Type III
> + tunnel_destroy erspan1 # ERSPAN Type II
> +
> + log_test "erspan_opts match ($tcflags)"
> +}
> +
> setup_prepare()
> {
> h1=${NETIFS[p1]}
> --
> 2.50.1
>
Reviewed-by: Xin Long
It would be great to also add test cases for matching VXLAN and
GENEVE options in tc flower in the future.
Thanks.
101 - 180 of 180 matches
Mail list logo
