bond: take rcu lock in netpoll_send_skb_on_dev

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 @@ -330

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 > > wrot

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

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,

Re: [4.15-rc9] fs_reclaim lockdep trace

+0900 > Subject: [PATCH] lockdep: Fix fs_reclaim warning. Seems to suppress the warning for me. Tested-by: Dave Jones <da...@codemonkey.org.uk>

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 has id

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

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

[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:

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 ?

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 reproduc

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

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

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:

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:

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 <eric.duma...@gmail.com> Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --gi

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

ipv6: handle -EFAULT from skb_copy_bits

); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, , LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by: Dave Jones <da...@codemonkey.org.uk> 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 @@

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

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 <da...@codemonkey.org.uk> wrote: > > On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > > > From: Dave Jones <da...@codemonkey.org.uk> > >

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

Re: ipv6: handle -EFAULT from skb_copy_bits

On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote: > From: Dave Jones <da...@codemonkey.org.uk> > 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

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 expla

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

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. > > > >

Re: ipv6: handle -EFAULT from skb_copy_bits

On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote: > From: Dave Jones <da...@codemonkey.org.uk> > 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 resul

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 <

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: []

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

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 <ka...@fb.com> Signed-off-by: Dave Jones <da...@codemonkey.org.uk> diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c index 0900

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

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 <da...@codemonkey.org.uk> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 1ecfa7

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-by: Dave

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:

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 =

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+0xb7b/0xc70 [p

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 >

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

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,

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

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

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, >

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

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 > >

Re: kasan r8169 use-after-free trace.

On Wed, Nov 11, 2015 at 10:19:28AM +0100, Francois Romieu wrote: > Dave Jones <da...@codemonkey.org.uk> : > > 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 th

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

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

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_clean23

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: 8802b89b task.ti

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 https://en.wikipedia.org/wiki/IPv6. - For Linux IPv6 development information, see http://www.linux-ipv6.org. - For specific information about IPv6 under Linux,

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

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

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 now I can't

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:

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.

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] diff --git

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, by

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 export symbol space is large? - does it cost

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: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 people stop

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 debug their issue in case it involves eeproms

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 verify this now

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 416b5d10afdc797c21c457ade3714e8f2f75edd9 Author: Auke Kok [EMAIL

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 morning, I got a mail from a Fedora user of the same .23-rc8 based

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:

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

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-rc8 based kernel that has seen a different trace

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:

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

of bugs seemed easy to automate. This is one of them I found where it looks like this semicolon is not valid. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Yikes! Makes you want to audit the entire tree for these things :-))) Indeed. Here's another one. Signed-off-by: Dave Jones

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/drivers/net/hamradio

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 @@ static void

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

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_enable in

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 we need a

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 a/net

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

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 PROTECTED] Handled-By : Jesse Brandeburg [EMAIL

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:

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. Could someone who

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: [c05d5664] neigh_lookup+0x43/0xa2 but task

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 4c914df..ecfe8da 100644

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

Re: [PATCH] bcm43xx: Readd dropped assignment

On Wed, Oct 18, 2006 at 04:40:00PM +0200, Michael Buesch wrote: On Wednesday 18 October 2006 01:12, Daniel Drake wrote: Larry Finger pointed out a problem with my ieee80211 IV/ICV stripping patch, which I forgot about. Sorry about that. The patch readds the frame_ctl assignment

Re: [PATCH 2/3] netpoll: rework skb transmit queue

On Fri, Oct 20, 2006 at 01:25:32PM -0700, Stephen Hemminger wrote: On Fri, 20 Oct 2006 12:52:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 12:25:27 -0700 Sorry, but why should we treat out-of-tree vendor

Remove useless comment from sb1250

Signed-off-by: Dave Jones [EMAIL PROTECTED] diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index db23249..1eae16b 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -2903,7 +2903,7 @@ #endif dev = alloc_etherdev(sizeof(struct sbmac_softc

sfuzz hanging on 2.6.18

sfuzz.c (google for it if you don't have it already) used to run forver (or until I got bored and ctrl-c'd it) as long as it didn't trigger an oops or the like in 2.6.17 Running it against 2.6.18, I notice that it runs for a while, and then gets totally wedged. It doesn't respond to any signals,

  1   2   >