Re: tun: mark small packets as owned by the tap sock

On Tue, Aug 13, 2019 at 04:33:59PM +0800, Jason Wang wrote: > > On 2019/8/13 上午6:19, Dave Jones wrote: > > On Wed, Aug 07, 2019 at 12:30:07AM +, Linux Kernel wrote: > > > Commit: 4b663366246be1d1d4b1b8b01245b2e88ad9e706 > > > Parent: 16b2084a8a

Re: tun: mark small packets as owned by the tap sock

On Wed, Aug 07, 2019 at 12:30:07AM +, Linux Kernel wrote: > Commit: 4b663366246be1d1d4b1b8b01245b2e88ad9e706 > Parent: 16b2084a8afa1432d14ba72b7c97d7908e178178 > Web: > https://git.kernel.org/torvalds/c/4b663366246be1d1d4b1b8b01245b2e88ad9e706 > Author: Alexis Bauvin

igb: Illegal context switch in RCU read-side critical section!

[ 32.845071] = [ 32.845084] WARNING: suspicious RCU usage [ 32.845098] 5.0.0-rc1-backup+ #1 Not tainted [ 32.845111] - [ 32.845124] ./include/linux/rcupdate.h:281 Illegal context switch in RCU read-side critical section! [ 32.8451

ixgbe / mdio dependancy error

If you build IXGBE=y, and MDIO_BUS=y, we currently fail the build like so: MODPOST vmlinux.o drivers/net/ethernet/intel/ixgbe/ixgbe_main.o: In function `ixgbe_mdio_read': /mnt/data/src/kernel/git-trees/linux-dj/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8801: undefined reference to `mdiobus_

bond: take rcu lock in netpoll_send_skb_on_dev

a layer up in netpoll_send_skb_on_dev before we call down into netpoll_poll_dev, so just take the lock there. Suggested-by: Cong Wang Signed-off-by: Dave Jones diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 3219a2932463..692367d7c280 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 12:03:22PM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 12:02 PM Cong Wang wrote: > > > > On Fri, Sep 28, 2018 at 11:26 AM Dave Jones > > wrote: > > > diff --git a/net/core/netpoll.c b/net/core/netpoll.c > > >

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Suggested-by: Cong Wang Signed-off-by: Dave Jones -- v3: Do this in netpoll_send_skb_on_de

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 10:31:39AM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 10:25 AM Dave Jones wrote: > > > > On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote: > > > On Fri, Sep 28, 2018 at 9:18 AM Dave Jones > > wrote:

Re: bond: take rcu lock in bond_poll_controller

On Fri, Sep 28, 2018 at 09:55:52AM -0700, Cong Wang wrote: > On Fri, Sep 28, 2018 at 9:18 AM Dave Jones wrote: > > > > Callers of bond_for_each_slave_rcu are expected to hold the rcu lock, > > otherwise a trace like below is shown > > So wh

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Signed-off-by: Dave Jones diff --git a/drivers/net/bonding/bond_main.c b/drivers/ne

bond: take rcu lock in bond_poll_controller

1fc/0x310 bond_mii_monitor+0x709/0x9b0 process_one_work+0x221/0x5e0 worker_thread+0x4f/0x3b0 kthread+0x100/0x140 ? process_one_work+0x5e0/0x5e0 ? kthread_delayed_work_timer_fn+0x90/0x90 ret_from_fork+0x24/0x30 Signed-off-by: Dave Jones diff --git a/drivers/net/bonding/bond_main.c b/drivers/ne

ipset: suspicious RCU usage

= WARNING: suspicious RCU usage 4.16.0-rc3-firewall+ #1 Not tainted - net/netfilter/ipset/ip_set_core.c:1354 suspicious rcu_dereference_protected() usage! \x0aother info that might help us debug this:\x0a \x0arcu_scheduler_active = 2, debug_

Re: [4.15-rc9] fs_reclaim lockdep trace

ix fs_reclaim warning. Seems to suppress the warning for me. Tested-by: Dave Jones

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev h

ipset related DEBUG_VIRTUAL crash.

I have a script that hourly replaces an ipset list. This has been in place for a year or so, but last night it triggered this on 4.14-rc7 [455951.731181] kernel BUG at arch/x86/mm/physaddr.c:26! [455951.737016] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [455951.742525] CPU: 0 PID:

Re: [4.14rc6] __tcp_select_window divide by zero.

On Tue, Oct 24, 2017 at 09:00:30AM -0400, Dave Jones wrote: > divide error: [#1] SMP KASAN > CPU: 0 PID: 31140 Comm: trinity-c12 Not tainted 4.14.0-rc6-think+ #1 > RIP: 0010:__tcp_select_window+0x21f/0x400 > Call Trace: > tcp_cleanup_rbuf+0x27d/0x2a0 > tcp_re

[net-next] tcp_delack_timer circular locking dependancy

[ 105.316650] == [ 105.316818] WARNING: possible circular locking dependency detected [ 105.316986] 4.14.0-rc7-think+ #1 Not tainted [ 105.317108] -- [ 105.317273] swapper/2/0 is trying to a

[4.14rc6] __tcp_select_window divide by zero.

divide error: [#1] SMP KASAN CPU: 0 PID: 31140 Comm: trinity-c12 Not tainted 4.14.0-rc6-think+ #1 task: 8803c0d08040 task.stack: 8803df548000 RIP: 0010:__tcp_select_window+0x21f/0x400 RSP: 0018:8803df54f418 EFLAGS: 00010246 RAX: RBX: 880458fd3140 RCX:

BUG_ON(sg->sg_magic != SG_MAGIC) on tls socket.

kernel BUG at ./include/linux/scatterlist.h:189! invalid opcode: [#1] SMP KASAN CPU: 3 PID: 20890 Comm: trinity-c51 Not tainted 4.13.0-rc4-think+ #5 task: 88036e3d1cc0 task.stack: 88033e9d8000 RIP: 0010:tls_push_record+0x675/0x680 RSP: 0018:88033e9df630 EFLAGS: 00010287 RAX: 0

KASAN: slab-out-of-bounds from net_namespace.c:ops_init

== BUG: KASAN: slab-out-of-bounds in ops_init+0x201/0x330 Write of size 8 at addr 88045744c448 by task trinity-c4/1499 CPU: 2 PID: 1499 Comm: trinity-c4 Not tainted 4.13.0-rc4-think+ #5 Call Trace: dump_stack+0xc5/0x151 ? dma_v

Re: sctp refcount bug.

On Thu, Jul 13, 2017 at 11:38:34AM -0300, Marcelo Ricardo Leitner wrote: > On Thu, Jul 13, 2017 at 10:36:39AM -0400, Dave Jones wrote: > > Hit this on Linus' current tree. > > > > > > refcount_t: underflow; use-after-free. > > Any tips on how to rep

sctp refcount bug.

Hit this on Linus' current tree. refcount_t: underflow; use-after-free. [ cut here ] WARNING: CPU: 2 PID: 14455 at lib/refcount.c:186 refcount_sub_and_test+0x45/0x50 CPU: 2 PID: 14455 Comm: trinity-c46 Tainted: G D 4.12.0-think+ #11 task: 8804fc71b8c0 tas

netconsole refcount warning

The new refcount debugging code spews this twice during boot on my router.. refcount_t: increment on 0; use-after-free. [ cut here ] WARNING: CPU: 1 PID: 17 at lib/refcount.c:152 refcount_inc+0x2b/0x30 CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.12.0-firewall+ #8 task:

Re: af_packet: use after free in prb_retire_rx_blk_timer_expired

On Mon, Apr 10, 2017 at 07:03:30PM +, alexander.le...@verizon.com wrote: > Hi all, > > I seem to be hitting this use-after-free on a -next kernel using trinity: > > [ 531.036054] BUG: KASAN: use-after-free in prb_retire_rx_blk_timer_expired > (net/packet/af_packet.c:688)

Re: run_timer_softirq gpf. [smc]

On Tue, Mar 21, 2017 at 08:25:39PM +0100, Thomas Gleixner wrote: > > I just hit this while fuzzing.. > > > > general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC > > CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1 > > task: 88017f0ed440 task.stack: c90

Re: [4.10+] sctp lockdep trace

On Tue, Mar 14, 2017 at 11:35:33AM +0800, Xin Long wrote: > >> > [ 245.416594] ( > >> > [ 245.424928] sk_lock-AF_INET > >> > [ 245.433279] ){+.+.+.} > >> > [ 245.441889] , at: [] sctp_sendmsg+0x330/0xfe0 > >> > [sctp] > >> > [ 245.450167] > >> >stack backtrace: > >> >

[4.10+] sctp lockdep trace

[ 244.251557] === [ 244.263321] [ ERR: suspicious RCU usage. ] [ 244.274982] 4.10.0-think+ #7 Not tainted [ 244.286511] --- [ 244.298008] ./include/linux/rhashtable.h:602 suspicious rcu_dereference_check() usage! [ 244.309665]

prb_retire_rx_blk_timer_expired use-after-free

RSI looks kinda like slab poison here, so re-using a free'd ptr ? general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc4-think+ #2 task: 81e16500 task.stack: 81e0 RIP: 0010:prb_retire_rx_blk_timer_expired+0x42/0x130

ipv6: remove unnecessary inet6_sk check

np is already assigned in the variable declaration of ping_v6_sendmsg. At this point, we have already dereferenced np several times, so the NULL check is also redundant. Suggested-by: Eric Dumazet Signed-off-by: Dave Jones diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c index e1f8b34d7a2e

sunrpc: Illegal context switch in RCU read-side critical section!

Just noticed this on 4.9. Will try and repro on 4.10rc1 later, but hitting unrelated boot problems on that machine right now. === [ INFO: suspicious RCU usage. ] 4.9.0-backup-debug+ #1 Not tainted --- ./include/linux/rcupdate.h:557 Illegal co

ipv6: handle -EFAULT from skb_copy_bits

o, 4); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by: Dave Jones diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c index 291ebc260e70..ea89073c8247 100644 --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@ -591,7 +591,11 @@ st

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, Dec 21, 2016 at 10:33:20PM +0100, Hannes Frederic Sowa wrote: > > Given all of this, I think the best thing to do is validate the offset > > after the queue walks, which is pretty much what Dave Jones's original > > patch was doing. > > I think both approaches protect against the bug

Re: ipv6: handle -EFAULT from skb_copy_bits

On Tue, Dec 20, 2016 at 11:31:38AM -0800, Cong Wang wrote: > On Tue, Dec 20, 2016 at 10:17 AM, Dave Jones wrote: > > On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > > > From: Dave Jones > > > Date: Mon, 19 Dec 2016 19:40:13 -0500 > > >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Tue, Dec 20, 2016 at 01:28:13PM -0500, David Miller wrote: > This has to do with the SKB buffer layout and geometry, not whether > the packet is "fragmented" in the protocol sense. > > So no, this isn't a criteria for packets being filtered out by this > point. > > Can you try to capt

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > From: Dave Jones > Date: Mon, 19 Dec 2016 19:40:13 -0500 > > > On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > > > > > Unfortunately, this made no difference. I spent some time

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote: > Unfortunately, this made no difference. I spent some time today trying > to make a better reproducer, but failed. I'll revisit again tomorrow. > > Maybe I need >1 process/thread to trigger this. That would

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 02:48:48PM -0500, David Miller wrote: > One thing that's interesting is that if the user picks "IPPROTO_RAW" > as the value of 'protocol' we set inet->hdrincl to 1. > > The user can also set inet->hdrincl to 1 or 0 via setsockopt(). > > I think this is part of the p

Re: ipv6: handle -EFAULT from skb_copy_bits

50 > > [] SYSC_sendto+0xef/0x170 > > [] SyS_sendto+0xe/0x10 > > [] do_syscall_64+0x50/0xa0 > > [] entry_SYSCALL64_slow_path+0x25/0x25 > > > > Handle this in rawv6_push_pending_frames and jump to the failure path. > > > > Signed-off-by:

Re: ipv6: handle -EFAULT from skb_copy_bits

On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote: > From: Dave Jones > Date: Wed, 14 Dec 2016 10:47:29 -0500 > > > It seems to be possible to craft a packet for sendmsg that triggers > > the -EFAULT path in skb_copy_bits resulting in a BUG_ON that looks

ipv6: handle -EFAULT from skb_copy_bits

+0x693/0x830 [] inet_sendmsg+0x67/0xa0 [] sock_sendmsg+0x38/0x50 [] SYSC_sendto+0xef/0x170 [] SyS_sendto+0xe/0x10 [] do_syscall_64+0x50/0xa0 [] entry_SYSCALL64_slow_path+0x25/0x25 Handle this in rawv6_push_pending_frames and jump to the failure path. Signed-off-by: Dave Jones diff --git a/net

netconsole: sleeping function called from invalid context

I think this has been around for a while, but for some reason I'm running into it a lot today. BUG: sleeping function called from invalid context at kernel/irq/manage.c:110 in_atomic(): 1, irqs_disabled(): 1, pid: 1839, name: modprobe no locks held by modprobe/1839. Preemption disabled at: [] wri

Re: ipv6: release dst in ping_v6_sendmsg

On Tue, Sep 06, 2016 at 10:52:43AM -0700, Eric Dumazet wrote: > > > @@ -126,8 +126,10 @@ static int ping_v6_sendmsg(struct sock *sk, struct > > > msghdr *msg, size_t len) > > > rt = (struct rt6_info *) dst; > > > > > > np = inet6_sk(sk); > > > -if (!np) > > > -

ipv6: release dst in ping_v6_sendmsg

had been fixed post 3.10, but it seems at least one case wasn't, where I've seen this triggered a lot from machines doing unprivileged icmp sockets. Cc: Martin Lau Signed-off-by: Dave Jones diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c index 0900352c924c..0e983b694ee8 100644 --- a/

e1000: __pskb_pull_tail failed

MY NFS server running 4.8-rc1 is getting flooded with this message: e1000e :00:19.0 eth0: __pskb_pull_tail failed. Never saw it happen with 4.7 or earlier. That device is this onboard NIC: 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V Dave

[4.6] kernel BUG at net/ipv6/raw.c:592

Found this logs after a Trinity run. kernel BUG at net/ipv6/raw.c:592! [ cut here ] invalid opcode: [#1] SMP Modules linked in: udp_diag dccp_ipv6 dccp_ipv4 dccp sctp af_key tcp_diag inet_diag ip6table_filter xt_NFLOG nfnetlink_log xt_comment xt_statistic iptable_

af_packet: tone down the Tx-ring unsupported spew.

Trinity and other fuzzers can hit this WARN on far too easily, resulting in a tainted kernel that hinders automated fuzzing. Replace it with a rate-limited printk. Signed-off-by: Dave Jones diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 1ecfa710ca98..f12c17f355d9 100644

Make DST_CACHE a silent config option

commit 911362c70d ("net: add dst_cache support") added a new kconfig option that gets selected by other networking options. It seems the intent wasn't to offer this as a user-selectable option given the lack of help text, so this patch converts it to a silent option. Signed-off

Re: gro: Make GRO aware of lightweight tunnels.

On Tue, Feb 02, 2016 at 02:28:58AM +, Linux Kernel wrote: > Web: > https://git.kernel.org/torvalds/c/ce87fc6ce3f9f4488546187e3757cf666d9d4a2a > Commit: ce87fc6ce3f9f4488546187e3757cf666d9d4a2a > Parent: 5f2f3cad8b878b23f17a11dd5af4f4a2cc41c797 > Refname:refs/heads/maste

net/ipv6/ip6_flowlabel.c:543 suspicious rcu_dereference_check() usage!

=== [ INFO: suspicious RCU usage. ] 4.5.0-rc2-think+ #2 Tainted: GW --- net/ipv6/ip6_flowlabel.c:543 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1

Re: out of bounds in pptp_connect.

On Sun, Jan 17, 2016 at 12:06:58PM -0500, Dave Jones wrote: > I've managed to trigger this a few times the last few days, on Linus' tree. > > == > BUG: KASAN: slab-out-of-bounds in pptp_connect+0xb7

suspicious rcu_dereference in tcp_v6_send_synack

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc8-firewall+ #1 Not tainted --- net/ipv6/tcp_ipv6.c:465 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 1 lock held by

Re: 4.4-rc7 failure report

On Wed, Dec 30, 2015 at 10:38:56AM +0100, Daniel Borkmann wrote: > Given that this drop doesn't strictly need to be caused by filter code, > it would be nice if you could pin the location down where the packet gets > dropped exactly. Perhaps dropwatch or perf with '-e skb:kfree_skb -a -g > dhc

Re: suspicious RCU usage (netlink/rhashtable)

On Tue, Dec 22, 2015 at 04:50:20PM -0500, David Miller wrote: > > > > Simple fix is below. Though, I don't understand the history of the > > > > multiple locks in this structure to be sure it's correct. I'll send > > > > it as a formal patch. Please reject if it's not the right approach.

Re: suspicious RCU usage (netlink/rhashtable)

On Tue, Dec 22, 2015 at 04:42:25PM -0500, David Miller wrote: > From: Craig Gallek > Date: Tue, 22 Dec 2015 16:38:32 -0500 > > > On Tue, Dec 22, 2015 at 4:28 PM, David Miller wrote: > >> From: Craig Gallek > >> Date: Tue, 22 Dec 2015 15:51:19 -0500 > >> > >>> I was actually just looking

suspicious RCU usage (netlink/rhashtable)

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc6-think+ #1 Not tainted --- lib/rhashtable.c:522 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by t

Re: suspicious rcu_dereference_check in sctp_v6_get_dst

On Sat, Dec 05, 2015 at 05:13:06PM -0800, Eric Dumazet wrote: > > diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c > > index acb45b8c2a9d..7081183f4d9f 100644 > > --- a/net/sctp/ipv6.c > > +++ b/net/sctp/ipv6.c > > @@ -328,7 +328,9 @@ static void sctp_v6_get_dst(struct sctp_transport *t, > >

suspicious rcu_dereference_check in sctp_v6_get_dst

=== [ INFO: suspicious RCU usage. ] 4.4.0-rc3-think+ #8 Tainted: GW --- net/sctp/ipv6.c:331 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock h

4.4-rc2 xfrm_lookup kasan trace

My router fell off the internet. When I got home, I found a few hundred of these traces in the logs, and it refusing to route packets. Oddly, it only prints a stack trace, and no clue as to why it printed that trace. There was also nothing in the log prior to this that indicates how it got that

dccp->bind_conflict jump to null.

I've been trying to figure this one out for a while. It smells like a race, but I can't figure out any more than the clues below, and I've not really got the time to dig into it. After running Trinity for a while, I saw the machine just suddenly reboot. I managed to capture a partial trace over se

Re: 4.3.0+ breaks software VPN

On Fri, Nov 13, 2015 at 02:37:00PM -0700, Jens Axboe wrote: > Hi, > > Tried to connect to sw vpn today, and it isn't working. Running git > as-of yesterday. In dmesg: > > [23703.921542] vpn0: set_features() failed (-1); wanted > 0x008048c1, left 0x0080001b48c9 > > Revertin

Re: kasan r8169 use-after-free trace.

On Wed, Nov 11, 2015 at 10:19:28AM +0100, Francois Romieu wrote: > Dave Jones : > > This happens during boot, (and then there's a flood of traces that happen > > so fast > > afterwards it completely overwhelms serial console; not sure if they'

kasan r8169 use-after-free trace.

This happens during boot, (and then there's a flood of traces that happen so fast afterwards it completely overwhelms serial console; not sure if they're the same/related or not). == BUG: KASAN: use-after-free in rtl8169_poll+0x4b6/

Re: [PATCH] sh_eth: merge sh_eth_free_dma_buffer() into sh_eth_ring_free()

On Thu, Nov 05, 2015 at 01:29:15PM -0500, David Miller wrote: > From: Sergei Shtylyov > Date: Thu, 5 Nov 2015 20:19:17 +0300 > > >Hmm, I hadn't seen your announcement, else I would have refrained from > >sending. Will look for it now... > > I really don't know how to better get pe

I218 e1000e hangs.

I've got a machine with an onboard NIC that reproduces a hardware hang every time I do an rsync to it. [ 488.752630] e1000e :00:19.0 eth0: Detected Hardware Unit Hang: TDH <27> TDT <34> next_to_use <34> next_to_clean<23> buffer_info[n

Re: dccp related oops in inet_csk_get_port

On Wed, Jul 15, 2015 at 06:07:10PM -0400, Dave Jones wrote: > While experimenting with some dccp fuzzing, I hit this.. > > Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC > CPU: 3 PID: 19269 Comm: trinity-c22 Not tainted 4.2.0-rc2-think+ #2 > task: 88006f3954c0 ti: 8802b

dccp related oops in inet_csk_listen_start

While experimenting with some dccp fuzzing, I hit this.. Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 3 PID: 19269 Comm: trinity-c22 Not tainted 4.2.0-rc2-think+ #2 task: 88006f3954c0 ti: 8802b89b task.ti: 8802b89b RIP: 0010:[<>] [< (null)>]

Re: [RFC net-next] net: Build IPv6 into kernel by default

On Thu, Jul 09, 2015 at 01:42:29PM -0700, Tom Herbert wrote: >For general information about IPv6, see >. > - For Linux IPv6 development information, see > . > - For specific information about IPv6 under

4.1+ use after free in netlink_broadcast_filtered

I taught Trinity about NETLINK_LISTEN_ALL_NSID and NETLINK_LIST_MEMBERSHIPS yesterday, and this evening, this fell out.. general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 9130 Comm: kworker/1:1 Not tainted 4.1.0-gelk-debug+ #1 Workqueue: sock_diag_events sock_diag_broadc

Re: ssh connections hanging on 4.1rc7

On Thu, Jun 11, 2015 at 11:24:21AM -0700, Eric Dumazet wrote: > > Just hit this weird problem where I can ssh into a machine once, > > then after logging out, subsequent ssh connections hang. > > Your tcpdumps look one way only. ok hit it again, so let's try again... client side: 15:34:1

Re: ssh connections hanging on 4.1rc7

On Thu, Jun 11, 2015 at 01:46:18PM -0400, Dave Jones wrote: > Just hit this weird problem where I can ssh into a machine once, > then after logging out, subsequent ssh connections hang. > > The client side looks like.. derp, missed half the tcpdump capture on both sides, and

ssh connections hanging on 4.1rc7

Just hit this weird problem where I can ssh into a machine once, then after logging out, subsequent ssh connections hang. The client side looks like.. 13:39:06.307781 IP wopr.kernelslacker.org.43982 > gelk.kernelslacker.org.ssh: Flags [S], seq 319726787, win 29200, options [mss 1460,sackOK,TS va

lockdep trace from rc2.

https://bugzilla.redhat.com/show_bug.cgi?id=431038 has some more info, but the trace is below... I'll get an rc3 kernel built and ask the user to retest, but in case this isn't a known problem, I'm forwarding this here. Dave Feb 24 17:53:21 cirithungol kernel: ==

Re: [RFC] ehea: kdump support using new shutdown hook

On Wed, Dec 12, 2007 at 05:53:43PM +0100, Thomas Klein wrote: > +static void ehea_update_adapter_handles(struct ehea_adapter *adapter) > +{ > +int i, k; > +int j = 0; > + > +memset(adapter->res_handles, sizeof(adapter->res_handles), 0); arguments wrong way around. Dave

delay via-rhine irq initialisation.

r the alloc_tbufs(), but I feel if a real interrupt occured, this diff would stand more chance of doing the right thing. Comments? Dave Delay irq registration until after we've allocated ring buffers, otherwise DEBUG_SHIRQ will complain. Signed-off-by: Dave Jones <[EMAIL PROTECTED]&g

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote: > On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote: > > On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote: > > > > > 1) Why is everyone so concerned that expo

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote: > 1) Why is everyone so concerned that export symbol space is large? > - does it cost cpu or running memory? > - does it cause bugs? > - or are you just worried about "evil modules"? To clarify something here,

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen wrote: > There seems to be rough consensus that the kernel currently has too many > exported symbols. A lot of these exports are generally usable utility > functions or important driver interfaces; but another large part are > functions

Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.

On Tue, Oct 23, 2007 at 04:03:38PM -0700, Kok, Auke wrote: > Dave Jones wrote: > > On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote: > > > > > > In any case, this patch should not be merged. We often send it around > > to users to > > &g

Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.

On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote: > > In any case, this patch should not be merged. We often send it around to > > users to > > debug their issue in case it involves eeproms, but merging it will just > > conceal > > the real issue and all of a sudden a flood of pe

Re: e100 problems in .23rc8 ?

On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote: > David Mack wrote: > > It appears that the needed e100 fix made it into the Fedora > > 2.6.23.1-23.fc8 kernel. Boots reliably now. > > > > Huge thanks and great work, guys. > > DaveJ, I didn't push anything upstream. Can you verif

Re: e100 problems in .23rc8 ?

On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote: > Herbert Xu wrote: > > On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote: > >> The e1000 changes you reference above, is this the changeset you mean? > >> > >> commit 416b5d10afdc797c2

Re: e100 problems in .23rc8 ?

On Thu, Sep 27, 2007 at 02:58:27PM +0800, Herbert Xu wrote: > Kok, Auke <[EMAIL PROTECTED]> wrote: > > Dave Jones wrote: > >> Last night, I hit this bug during boot up.. > >> http://www.codemonkey.org.uk/junk/e100-2.jpg > >> > >> This m

lockdep report from bonding.

Reported by a Fedora user this morning. Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007) bonding: MII link monitoring set to 100 ms ADDRCONF(NETDEV_UP): bond0: link is not ready bonding: bond0: Adding slave eth0. e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex bonding: bond0: makin

Re: e100 problems in .23rc8 ?

On Wed, Sep 26, 2007 at 11:10:11AM -0700, Kok, Auke wrote: > Dave Jones wrote: > > Last night, I hit this bug during boot up.. > > http://www.codemonkey.org.uk/junk/e100-2.jpg > > > > This morning, I got a mail from a Fedora user of the same > > .23

e100 problems in .23rc8 ?

Last night, I hit this bug during boot up.. http://www.codemonkey.org.uk/junk/e100-2.jpg This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100.. http://www.codemonkey.org.uk/junk/e100.jpg It may be that the two proble

lockdep report in the bonding code.

A Fedora users reported this against our 2.6.23-rc3 build Dave NET: Registered protocol family 10 lo: Disabled Privacy Extensions Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007) bonding: MII link monitoring set to 100 ms ADDRCONF(NETDEV_UP): bond0: link is not ready bonding: bond0

Re: [PATCH] [IPv6]: Invalid semicolon after if statement

t the entire tree for these > things :-))) Indeed. Here's another one. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c index 74f9b14..bec4279 100644 --- a/net/netfilter/xt_u32.c +++ b/net/netfilter/xt_u32.c @@ -36

Re: warnings in git-wireless

On Wed, Jun 06, 2007 at 06:04:21PM -0700, Andrew Morton wrote: > There _should_ be some #ifdeffable thing which is being passed to cpp when > we run sparse (but I'm not sure what it is). #ifdef __CHECKER__ (See include/linux/compiler.h, this is how we implement __user & friends) Dave

typo in via-velocity.c

http://bugzilla.kernel.org/show_bug.cgi?id=8160 Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c index 25b75b6..b670b97 100644 --- a/drivers/net/via-velocity.c +++ b/drivers/net/via-velocity.c @@ -1562,7 +1562,7 @@ stati

Remove incorrect comment from hamradio/scc.

scc_rxint doesn't call this function at all. http://bugzilla.kernel.org/show_bug.cgi?id=8146 Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c index 6fdaad5..30bed2a 100644 --- a/drivers/net/hamradio/scc.c +++ b/

Re: [PATCH] e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1)

On Mon, May 21, 2007 at 05:58:27PM -0700, Kok, Auke wrote: > >> This probably doesn't solve the latter bug. > >> The code you reference isn't there in the kernel tested in that bug > >> (2.6.21) In 2.6.21, netif_poll_enable is only called from > >> e1000_up(), not e1000_open() > > > > Yes

Re: [PATCH] e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1)

On Mon, May 21, 2007 at 02:51:35PM -0700, Auke Kok wrote: > Herbert Xu wrote: > "netif_poll_enable can only be called if you've previously called > netif_poll_disable. Otherwise a poll might already be in action > and you may get a crash like this." > > Removing the call to netif_poll_enabl

Correct rp_filter help text.

As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015 The helptext implies that this is on by default. This may be true on some distros (Fedora/RHEL have it enabled in /etc/sysctl.conf), but the kernel defaults to it off. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git

Re: PROBLEM: SIS900 Driver change in Linux Kernel 2.6.21 causes kernel panic.

On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote: > Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as > soon as the first received packet comes in via the sis900 ethernet > interface. The machine is locked up and part of the kernel panic message > is lost as it has sc

Re: [1/2] 2.6.21-rc7: known regressions

On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: > Adrian Bunk wrote: > > Subject: laptops with e1000: lockups > > References : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > Submitter : Dave Jones <[EMAIL PROTE

2.6.21rc7 e1000 media-detect oddness.

I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe e1000, and got this.. e1000: :02:00.0: e1000_prob

Re: [RFT] proxy arp deadlock possible

On Wed, Apr 04, 2007 at 06:10:42PM -0700, Arjan van de Ven wrote: > On Thu, 2007-04-05 at 10:44 +1000, Herbert Xu wrote: > > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > Thanks Dave, there is a classic AB BA deadlock here. > > > We should break the dependency like this. > > > > > > Cou

lockdep report from 2.6.20.5-rc1

=== [ INFO: possible circular locking dependency detected ] 2.6.20-1.2933.fc6debug #1 --- swapper/0 is trying to acquire lock: (&tbl->lock){-+-+}, at: [] neigh_lookup+0x43/0xa2 but task is alre

fix up misplaced inlines.

Turning up the warnings on gcc makes it emit warnings about the placement of 'inline' in function declarations. Here's everything that was under net/ Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c index 4c

Re: FC5 iptables-restore failure

On Thu, Feb 15, 2007 at 02:45:07AM -0800, Andrew Morton wrote: > > I've recently been noticing nasty messages come out of FC5: > > sony:/home/akpm# service iptables stop > Flushing firewall rules: [ OK ] > Setting chains to policy ACCEPT: filter

  1   2   >