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
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
> > >
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
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
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
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
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
=
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,
+0900
> Subject: [PATCH] lockdep: Fix fs_reclaim warning.
Seems to suppress the warning for me.
Tested-by: Dave Jones <da...@codemonkey.org.uk>
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
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
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
[ 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
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:
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:
==
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
?
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
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
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
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)
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:
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:
> >>
[ 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]
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:
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
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
);
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
@@
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
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>
> >
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
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
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
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
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.
> >
> >
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
+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 <
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:
[]
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)
> > > -
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
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
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
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
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
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:
===
[ 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 =
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
===
[ 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
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
>
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
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,
===
[ 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
===
[ 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
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,
>
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
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
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
>
>
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
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
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
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
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
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)]
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,
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
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
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
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:
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:
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
--
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
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
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
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
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
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
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
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
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
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:
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
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
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:
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
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
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
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
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
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
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
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
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
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:
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
===
[ 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
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
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
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
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
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.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 - 100 of 162 matches
Mail list logo