Hello Friend

I NEED YOUR ASSISTANCE INTO THIS TRANSACTION

Re: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186

On Fri, 2017-09-08 at 11:46 -0700, Eric Dumazet wrote: > On Fri, 2017-09-08 at 10:21 -0700, Cong Wang wrote: > > (Cc'ing netdev) > > > > On Fri, Sep 8, 2017 at 5:59 AM, Shankara Pailoor > > wrote: > > > Hi, > > > > > > I found a warning while fuzzing with Syzkaller on linux

[PATCH] net: tcp_input: Neaten DBGUNDO

Move the #ifdef into the static void function so that the use of DBGUNDO is validated when FASTRETRANS_DEBUG <= 1. Remove the now unnecessary #else and #define DBGUNDO. Signed-off-by: Joe Perches --- net/ipv4/tcp_input.c | 6 ++ 1 file changed, 2 insertions(+), 4

Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c

On Sun, Sep 10, 2017 at 4:53 PM, Oleksandr Natalenko wrote: > Hello. > > Since, IIRC, v4.11, there is some regression in TCP stack resulting in the > warning shown below. Most of the time it is harmless, but rarely it just > causes either freeze or (I believe, this is

[REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c

Hello. Since, IIRC, v4.11, there is some regression in TCP stack resulting in the warning shown below. Most of the time it is harmless, but rarely it just causes either freeze or (I believe, this is related too) panic in tcp_sacktag_walk() (because sk_buff passed to this function is NULL).

[PATCH] net/sched: fix pointer check in gen_handle

Fixes sparse warning about pointer in gen_handle: net/sched/cls_rsvp.h:392:40: warning: Using plain integer as NULL pointer Fixes: 8113c095672f6 ("net_sched: use void pointer for filter handle") Signed-off-by: Josh Hunt --- net/sched/cls_rsvp.h | 2 +- 1 file changed, 1

Re: [PATCH v5 01/10] arm64: dts: allwinner: Restore EMAC changes

On Fri, Sep 08, 2017 at 03:39:04PM +0800, Chen-Yu Tsai wrote: > On Fri, Sep 8, 2017 at 3:36 PM, Corentin Labbe > wrote: > > On Fri, Sep 08, 2017 at 09:19:54AM +0200, Maxime Ripard wrote: > >> On Fri, Sep 08, 2017 at 09:11:47AM +0200, Corentin Labbe wrote: > >> > diff

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 10/09/17 21:18, Roman Mashak wrote: > Nikolay Aleksandrov writes: > >> On 10/09/17 16:38, Roman Mashak wrote: > > [...] > >>> Since VLAN info is already in link messages, there is no other option but >>> dump it in monitor or "bridge link show". Yes, the output

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

Nikolay Aleksandrov writes: > On 10/09/17 16:38, Roman Mashak wrote: [...] >> Since VLAN info is already in link messages, there is no other option but >> dump it in monitor or "bridge link show". Yes, the output may be lengthy > > To make sure there's no

broken vlan support on Realtek RTL8111/8168/8411 rev 9

Hello I make a strange observation. I have two machines. One with a: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02) The other one with the same card, but (rev 09). The rev 02 one works flawlessly. The rev 09 one does set all vlan tags to

Fw: [Bug 196889] New: kernel panic net_rx_action+0x21e/0x22d

Begin forwarded message: Date: Sun, 10 Sep 2017 12:21:13 + From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 196889] New: kernel panic net_rx_action+0x21e/0x22d https://bugzilla.kernel.org/show_bug.cgi?id=196889 Bug ID: 196889

Re: [RFC PATCH] net: Introduce a socket option to enable picking tx queue based on rx queue.

On Thu, Aug 31, 2017 at 4:27 PM, Sridhar Samudrala wrote: > This patch introduces a new socket option SO_SYMMETRIC_QUEUES that can be used > to enable symmetric tx and rx queues on a socket. > > This option is specifically useful for epoll based multi threaded

Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain

Fri, Sep 08, 2017 at 06:37:55PM CEST, xiyou.wangc...@gmail.com wrote: >On Thu, Sep 7, 2017 at 1:52 PM, Jiri Pirko wrote: >> Thu, Sep 07, 2017 at 07:45:49PM CEST, xiyou.wangc...@gmail.com wrote: >>>Yes it is for chain 0, because block holds a reference to chain 0 during

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 10/09/17 16:38, Roman Mashak wrote: > Roopa Prabhu writes: > >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: >>> Signed-off-by: Roman Mashak >>> --- >>> bridge/link.c | 16 +--- >>> 1 file changed, 13

Re: [patch net] net: sched: fix memleak for chain zero

Sat, Sep 09, 2017 at 08:46:42PM CEST, xiyou.wangc...@gmail.com wrote: >On Thu, Sep 7, 2017 at 7:18 PM, David Miller wrote: >> >> This doesn't apply cleanly any more, please respin. >> > >Sigh, you applied this patch despite of strong objections from me. > >I seriously doubt

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

Roopa Prabhu writes: > On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: >> Signed-off-by: Roman Mashak >> --- >> bridge/link.c | 16 +--- >> 1 file changed, 13 insertions(+), 3 deletions(-) >> >> diff --git

[PATCH net] ipv6: sr: remove duplicate routing header type check

From: David Lebrun As seg6_validate_srh() already checks that the Routing Header type is correct, it is not necessary to do it again in get_srh(). Fixes: 5829d70b ("ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200") Signed-off-by: David Lebrun

Re: [PATCH net] ipv6: sr: remove duplicate routing header type check

Please ignore this one, resending with proper From lines. David

WARNING: CPU: 21 PID: 116 at net/sched/sch_generic.c:320 dev_watchdog+0xc5/0x122

With latest 4.13.0+ kernel Hardware(Tested HOST where traces catched: Intel E5-2670 Network controllers 2x 10G Intel 82599 1x 100G Mellanox Connectx-5 Test scenario: Packet generator -> (RX traffix on Mellanox 100G / 12Mpps UDP random destination ip / random port ) Tested HOST (TX traffix

[PATCH net] ipv6: sr: remove duplicate routing header type check

From: David Lebrun From: David Lebrun As seg6_validate_srh() already checks that the Routing Header type is correct, it is not necessary to do it again in get_srh(). Fixes: 5829d70b ("ipv6: sr: fix get_srh() to comply with IPv6 standard "RFC 8200")

Re: [PATCH net] netlink: fix an use-after-free issue for nlk groups

On Sat, Sep 9, 2017 at 9:56 AM, Cong Wang wrote: > On Tue, Sep 5, 2017 at 8:47 PM, Xin Long wrote: >> ChunYu found a netlink use-after-free issue by syzkaller: >> >> [28448.842981] BUG: KASAN: use-after-free in __nla_put+0x37/0x40 at addr >>

Re: [PATCH net] netlink: access nlk groups safely in netlink bind and getname

On Sat, Sep 9, 2017 at 7:35 AM, Cong Wang wrote: > On Tue, Sep 5, 2017 at 8:53 PM, Xin Long wrote: >> Now there is no lock protecting nlk ngroups/groups' accessing in >> netlink bind and getname. It's safe from nlk groups' setting in >>

[PATCH] netfilter: nat: Do not use ARRAY_SIZE() on spinlocks to fix zero div

If no spinlock debugging options (CONFIG_GENERIC_LOCKBREAK, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_LOCK_ALLOC) are enabled on a UP platform (e.g. m68k defconfig), arch_spinlock_t is an empty struct, hence using ARRAY_SIZE(nf_nat_locks) causes a division by zero: net/netfilter/nf_nat_core.c: In

Re: Division by zero on UP (was: Re: netfilter: nat: use keyed locks)

Hi Florian, On Sun, Sep 10, 2017 at 1:21 PM, Florian Westphal wrote: > Geert Uytterhoeven wrote: >> > srchash = hash_by_src(net, >> > >> > >tuplehash[IP_CT_DIR_ORIGINAL].tuple); >> > -

Re: Division by zero on UP (was: Re: netfilter: nat: use keyed locks)

Geert Uytterhoeven wrote: > > srchash = hash_by_src(net, > > > > >tuplehash[IP_CT_DIR_ORIGINAL].tuple); > > - spin_lock_bh(_nat_lock); > > + lock = _nat_locks[srchash %

[SUSPECTED SPAM] I am a Buyer

Dear Sir/Madam, I am Becca MacKenzie, We are interested in your products and want to make you and your company our major suppliers but first we would like your to send us your best price list and Catalog if possible. We will be ordering in large quantity so we are looking forward in making a

Division by zero on UP (was: Re: netfilter: nat: use keyed locks)

Hi Florian, Pablo, On Sat, Sep 9, 2017 at 9:21 PM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 > Commit: 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 > Parent:

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 09/09/17 20:23, Jamal Hadi Salim wrote: > On 17-09-09 12:24 PM, Roopa Prabhu wrote: >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: [snip] > > Agree we should be turning on this stuff by default. i.e default stays > compressed; otherwise it a huge dump. > > Having

[SUSPECTED SPAM] Can you be our Supplier

Dear Sir/Madam, I am Becca MacKenzie, We are interested in your products and want to make you and your company our major suppliers but first we would like your to send us your best price list and Catalog if possible. We will be ordering in large quantity so we are looking forward in making a

[V3 PATCH net] xdp: implement xdp_redirect_map for generic XDP

Using bpf_redirect_map is allowed for generic XDP programs, but the appropriate map lookup was never performed in xdp_do_generic_redirect(). Instead the map-index is directly used as the ifindex. For the xdp_redirect_map sample in SKB-mode '-S', this resulted in trying sending on ifindex 0 which