* Re: [V2 PATCH 1/9] csiostor: Chelsio FCoE offload driver submission (sources part 1).
From: Naresh Kumar Inna @ 2012-09-05 17:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <20120905092326.0a54226f@nehalam.linuxnetplumber.net>
On 9/5/2012 9:53 PM, Stephen Hemminger wrote:
> On Wed, 5 Sep 2012 18:03:54 +0530
> Naresh Kumar Inna <naresh@chelsio.com> wrote:
>
>> +
>> +/* FCoE Adapter types & its description */
>> +static struct csio_adap_desc csio_fcoe_adapters[] = {
>
> Tables like this should be const.
>
Thanks for reviewing. I will change it to const.
^ permalink raw reply
* Re: [net-next.git 4/7] stmmac: add Rx watchdog optimization to mitigate the DMA irqs
From: David Miller @ 2012-09-05 17:16 UTC (permalink / raw)
To: bhutchings; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1346861675.5325.13.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 5 Sep 2012 17:14:35 +0100
> On Wed, 2012-09-05 at 17:03 +0200, Giuseppe CAVALLARO wrote:
>> GMAC devices newer than databook 3.50 has an embedded timer
>> that can be used for mitigating the number of interrupts.
>> So this patch adds this optimizations.
>> Old MAC will continue to use NAPI.
> [...]
>
> Interrupt moderation is *not* a substitute for NAPI; you should continue
> using NAPI as well.
Absolutely correct, these two facilities are _complementary_ not _exlusive_.
In fact, the most optimal driver will use NAPI with relatively short HW
mitigation settings.
^ permalink raw reply
* Re: [PATCH] netfilter: take care of timewait sockets
From: Pablo Neira Ayuso @ 2012-09-05 17:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Patrick McHardy, netfilter-devel, netdev
In-Reply-To: <1346780943.13121.58.camel@edumazet-glaptop>
On Tue, Sep 04, 2012 at 07:49:03PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Sami Farin reported crashes in xt_LOG because it assumes skb->sk is a
> full blown socket.
>
> But with TCP early demux, we can have skb->sk pointing to a timewait
> socket.
TCP early demux is there since 3.6-rc.
I'll add that to the changelog if you don't mind, to help tracking
things for -stable.
^ permalink raw reply
* Re: when the MTU interface is modified, the promiscuous mode is reset in gianfar driver
From: David Miller @ 2012-09-05 17:09 UTC (permalink / raw)
To: claudiu.manoil; +Cc: chikazawa.akifu, netdev, linux-kernel
In-Reply-To: <504757AC.90007@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 5 Sep 2012 16:46:20 +0300
> I don't see how the promisc mode would be reset by changing the
> mtu. Maybe more details on the issue reproduction would help (or
> maybe a usecase involving multicast settings?)
Agreed, I can't see how this problem is even possible either.
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: Dave Jones @ 2012-09-05 17:08 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Lin Ming, netdev
In-Reply-To: <CAK6E8=dWnd1LYJEnvmiG+CN7x7jBt5OL5uv=4L=2Cx3=NmW3tg@mail.gmail.com>
On Wed, Sep 05, 2012 at 09:37:12AM -0700, Yuchung Cheng wrote:
> On Wed, Sep 5, 2012 at 9:04 AM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> > On Wed, Sep 5, 2012 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
> >> Just hit this bug on 3.6-rc4.
> >>
> >> The BUG is..
> >>
> >> BUG_ON(!timer->function);
> >
> > TCP keepalive timer is setup when the socket is created.
> >
> > __sock_create
> > inet_create
> > tcp_v4_init_sock
> > tcp_init_sock
> > tcp_init_xmit_timers
> > inet_csk_init_xmit_timers
> >
> > timer->function should not be NULL when set keepalive option.
> >
> > Strange...have bug somewhere.
>
> is this a passively opened socket or actively opened one?
I have no idea. That fuzzer ran for around 10 hours before it triggered
this. In that time, millions of syscalls were done.
Even though I had logs of every syscall, the volume of data to sift
through to try and map back to the socket that caused this is firmly
in 'needle in haystick' territory.
Dave
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Export nd_tbl to allow modules to support IPv6
From: David Miller @ 2012-09-05 17:06 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <fd8b9a9ad300edfc378065ef7887c3debeeb5e89.1346843399.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 5 Sep 2012 13:14:08 +0200
> It does not make sense to export these functions if we don't
> export the table itself as well.
Yes it does make perfect sense. It's exported for the sake of the
_implementation_ of a neighbour table in a kernel module.
I do not want to add more users with direct access to the neighbour
tables, because it is therefore impossible to go and add the inline
refcount'less lookups et al. to those external users.
So if one of our goals is to move towards a situation where all neigh
accesses are refcount'less, having those external users makes that
nearly impossible.
Instead, I'd rather see patches that mark arp_tbl as being exported
only for internal usage inside of the tree, so that we can reach that
goal.
I'm not applying this, sorry.
^ permalink raw reply
* Re: Commit "ipconfig wait for carrier" makes boot hang for 2 mins if no carrier
From: David Miller @ 2012-09-05 17:01 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: micha, netdev
In-Reply-To: <OF70CDBF7F.EFE301C2-ONC1257A70.002F0D3F-C1257A70.003055BF@transmode.se>
From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Date: Wed, 5 Sep 2012 10:47:56 +0200
> Please adjust the 2 min wait to nfsroot= only and keep the old way for ip=
Sorry, this is not happening, I fully support the change in the tree
as-is and will not modify it in the way you request.
You'll have to accomodate this situation in some other local way.
^ permalink raw reply
* Re: [PATCH] decnet: fix shutdown parameter checking
From: David Miller @ 2012-09-05 17:00 UTC (permalink / raw)
To: swhiteho; +Cc: xi.wang, netdev, linux-kernel
In-Reply-To: <1346834276.2799.4.camel@menhir>
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Wed, 05 Sep 2012 09:37:56 +0100
> However, I'm not overly worried and we'll soon know if it will cause any
> problems or not,
You can be sure that if we get real bug reports due to this change, I will
revert it back to how it was before.
^ permalink raw reply
* Re: [PATCH net-next] netfilter: x_tables: xt_init() should run earlier
From: Eric Dumazet @ 2012-09-05 16:59 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Cong Wang, Patrick McHardy, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <20120905165321.GA22243@1984>
On Wed, 2012-09-05 at 18:53 +0200, Pablo Neira Ayuso wrote:
> Hi Eric,
>
> It seems we've clashed fixing this, sorry. Can you still see any
> problem with my patch?
>
> Thanks for looking into this.
No problem !
It seems link order is the way to go, so your patch is good too !
Thanks
^ permalink raw reply
* Re: sctp_close/sk_free: kernel BUG at arch/x86/mm/physaddr.c:18!
From: Eric Dumazet @ 2012-09-05 16:57 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Fengguang Wu, H.K. Jerry Chu, Eric W. Biederman, networking,
linux-can
In-Reply-To: <1346859645.13121.146.camel@edumazet-glaptop>
On Wed, 2012-09-05 at 17:40 +0200, Eric Dumazet wrote:
> Could you test the following patch please ?
>
> (Not sure why sctp doesnt memset/bzero its whole socket by the way...)
>
> Thanks
Here is a more complete patch, as there are three potential problems,
not only one :
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 4f70ef0..845372b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -149,11 +149,8 @@ void inet_sock_destruct(struct sock *sk)
pr_err("Attempt to release alive inet socket %p\n", sk);
return;
}
- if (sk->sk_type == SOCK_STREAM) {
- struct fastopen_queue *fastopenq =
- inet_csk(sk)->icsk_accept_queue.fastopenq;
- kfree(fastopenq);
- }
+ if (sk->sk_protocol == IPPROTO_TCP)
+ kfree(inet_csk(sk)->icsk_accept_queue.fastopenq);
WARN_ON(atomic_read(&sk->sk_rmem_alloc));
WARN_ON(atomic_read(&sk->sk_wmem_alloc));
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 8464b79..f0c5b9c 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -314,7 +314,7 @@ struct sock *inet_csk_accept(struct sock *sk, int flags, int *err)
newsk = req->sk;
sk_acceptq_removed(sk);
- if (sk->sk_type == SOCK_STREAM && queue->fastopenq != NULL) {
+ if (sk->sk_protocol == IPPROTO_TCP && queue->fastopenq != NULL) {
spin_lock_bh(&queue->fastopenq->lock);
if (tcp_rsk(req)->listener) {
/* We are still waiting for the final ACK from 3WHS
@@ -775,7 +775,7 @@ void inet_csk_listen_stop(struct sock *sk)
percpu_counter_inc(sk->sk_prot->orphan_count);
- if (sk->sk_type == SOCK_STREAM && tcp_rsk(req)->listener) {
+ if (sk->sk_protocol == IPPROTO_TCP && tcp_rsk(req)->listener) {
BUG_ON(tcp_sk(child)->fastopen_rsk != req);
BUG_ON(sk != tcp_rsk(req)->listener);
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: x_tables: xt_init() should run earlier
From: Pablo Neira Ayuso @ 2012-09-05 16:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, Patrick McHardy, netfilter-devel,
Linux Kernel Network Developers
In-Reply-To: <1346863073.13121.155.camel@edumazet-glaptop>
Hi Eric,
On Wed, Sep 05, 2012 at 06:37:53PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Cong Wang reported a NULL dereference in xt_register_target()
>
> It turns out xt_nat_init() was called before xt_init(), so xt array
> was not yet setup.
>
> xt_init() should be marked core_initcall() to solve this problem.
>
> Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/netfilter/x_tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index 8d987c3..afcea11 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -1390,6 +1390,6 @@ static void __exit xt_fini(void)
> kfree(xt);
> }
>
> -module_init(xt_init);
> +core_initcall(xt_init);
> module_exit(xt_fini);
It seems we've clashed fixing this, sorry. Can you still see any
problem with my patch?
Thanks for looking into this.
^ permalink raw reply
* Re: [PATCH] usbnet: drop unneeded check for NULL
From: David Miller @ 2012-09-05 16:50 UTC (permalink / raw)
To: oneukum; +Cc: richardcochran, netdev
In-Reply-To: <2037108.ZemStJh9zr@linux-lqwf.site>
From: Oliver Neukum <oneukum@suse.de>
Date: Wed, 05 Sep 2012 08:24:25 +0200
> On Wednesday 05 September 2012 06:47:12 Richard Cochran wrote:
>> and so I think the problem that the test addresses is still present,
>> or am I missing something?
>
> No,
>
> you are right. Thank you.
>
> Dave, for now, please don't apply this patch. In the long run, this crap
> in cdc-ncm needs to go. I am starting rewriting this driver right now.
I already applied it several days ago, someone send me a revert with a
verbose commit message explaining the situation.
^ permalink raw reply
* Re: NULL pointer dereference in xt_register_target()
From: Pablo Neira Ayuso @ 2012-09-05 16:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <1346860506.13121.148.camel@edumazet-glaptop>
On Wed, Sep 05, 2012 at 05:55:06PM +0200, Eric Dumazet wrote:
> On Wed, 2012-09-05 at 23:43 +0800, Cong Wang wrote:
> > Hi, folks,
> >
> > The latest net-next tree can't boot due to a NULL ptr def
> > bug in the kernel, the full backtrack is:
> >
> > http://img1.douban.com/view/photo/photo/public/p1697139550.jpg
> >
> > the kernel .config file is:
> >
> > http://pastebin.com/9YTnkqKN
> >
> > I don't have time to look into the issue. If you need other info,
> > please let me know.
>
> It seems xt_nat_init() is called before xt_init(), so xt array is not
> yet setup.
I have enqueued the following patch to fix this:
http://1984.lsi.us.es/git/nf-next/commit/?id=00545bec9412d130c77f72a08d6c8b6ad21d4a1
e
commit 00545bec9412d130c77f72a08d6c8b6ad21d4a1e
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed Sep 5 18:24:55 2012 +0200
netfilter: fix crash during boot if NAT has been compiled built-in
Thanks.
^ permalink raw reply
* [PATCH net-next] netfilter: x_tables: xt_init() should run earlier
From: Eric Dumazet @ 2012-09-05 16:37 UTC (permalink / raw)
To: Cong Wang, Pablo Neira Ayuso, Patrick McHardy
Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <1346861569.13121.149.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Cong Wang reported a NULL dereference in xt_register_target()
It turns out xt_nat_init() was called before xt_init(), so xt array
was not yet setup.
xt_init() should be marked core_initcall() to solve this problem.
Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/netfilter/x_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index 8d987c3..afcea11 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1390,6 +1390,6 @@ static void __exit xt_fini(void)
kfree(xt);
}
-module_init(xt_init);
+core_initcall(xt_init);
module_exit(xt_fini);
^ permalink raw reply related
* Re: kernel BUG at kernel/timer.c:748!
From: Yuchung Cheng @ 2012-09-05 16:37 UTC (permalink / raw)
To: Lin Ming; +Cc: Dave Jones, netdev
In-Reply-To: <CAF1ivSauxzNhrm9c==_xFpuh9Lo3KrUNLNRb_62fLZxMfTuU1w@mail.gmail.com>
On Wed, Sep 5, 2012 at 9:04 AM, Lin Ming <mlin@ss.pku.edu.cn> wrote:
> On Wed, Sep 5, 2012 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
>> Just hit this bug on 3.6-rc4.
>>
>> The BUG is..
>>
>> BUG_ON(!timer->function);
>
> TCP keepalive timer is setup when the socket is created.
>
> __sock_create
> inet_create
> tcp_v4_init_sock
> tcp_init_sock
> tcp_init_xmit_timers
> inet_csk_init_xmit_timers
>
> timer->function should not be NULL when set keepalive option.
>
> Strange...have bug somewhere.
is this a passively opened socket or actively opened one?
>
> Lin Ming
>
>>
>>
>> Not much to go on... Any thoughts on what I could add to get
>> more debug info on which protocol etc this was ?
>>
>> Dave
>>
>>
>> kernel BUG at kernel/timer.c:748!
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in: tun fuse ipt_ULOG binfmt_misc nfnetlink nfc caif_socket caif phonet can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 nfsv3 nfs_acl nfs fscache lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core
>> CPU 3
>> Pid: 12330, comm: trinity-child3 Not tainted 3.6.0-rc4+ #36
>> RIP: 0010:[<ffffffff810813f5>] [<ffffffff810813f5>] mod_timer+0x2c5/0x2f0
>> RSP: 0018:ffff88000dfd7e08 EFLAGS: 00010246
>> RAX: 000000000000001a RBX: ffff880122d62948 RCX: 000000000000001a
>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88000dfd7e10
>> RBP: ffff88000dfd7e48 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000001517000 R11: 0000000000000246 R12: 000000016c000000
>> R13: 000000016c12bcb1 R14: ffff8801236cee00 R15: 00000000ffffff01
>> FS: 00007fa96745f740(0000) GS:ffff880148200000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00000000100ff000 CR3: 0000000099344000 CR4: 00000000001407e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process trinity-child3 (pid: 12330, threadinfo ffff88000dfd6000, task ffff880090890000)
>> Stack:
>> ffffffff8154cb6d 0000000007b5edf7 ffff88000dfd7e28 ffff880122d62520
>> 0000000000000009 0000000000000004 ffff8801236cee00 00000000ffffff01
>> ffff88000dfd7e68 ffffffff8154c79c ffffffff81550e6c ffff880122d62520
>> Call Trace:
>> [<ffffffff8154cb6d>] ? lock_sock_nested+0x8d/0xa0
>> [<ffffffff8154c79c>] sk_reset_timer+0x1c/0x30
>> [<ffffffff81550e6c>] ? sock_setsockopt+0x8c/0x960
>> [<ffffffff815a84a0>] inet_csk_reset_keepalive_timer+0x20/0x30
>> [<ffffffff815c018d>] tcp_set_keepalive+0x3d/0x50
>> [<ffffffff81551703>] sock_setsockopt+0x923/0x960
>> [<ffffffff810ddf76>] ? trace_hardirqs_on_caller+0x16/0x1e0
>> [<ffffffff811db0ac>] ? fget_light+0x24c/0x520
>> [<ffffffff8154af86>] sys_setsockopt+0xc6/0xe0
>> [<ffffffff816a50ed>] system_call_fastpath+0x1a/0x1f
>> Code: 00 74 43 9c 58 0f 1f 44 00 00 f6 c4 02 0f 84 14 ff ff ff eb 93 48 c7 c7 20 48 c3 81 e8 f5 70 05 00 85 c0 0f 85 fe fe ff ff eb b7 <0f> 0b 48 8b 75 08 48 89 df e8 3d f6 ff ff e9 b2 fd ff ff 4d 89
>> RIP [<ffffffff810813f5>] mod_timer+0x2c5/0x2f0
>> RSP <ffff88000dfd7e08>
>> ---[ end trace 7e7b5910138e49a3 ]---
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [V2 PATCH 6/9] csiostor: Chelsio FCoE offload driver submission (headers part 1).
From: Stephen Hemminger @ 2012-09-05 16:33 UTC (permalink / raw)
To: Naresh Kumar Inna; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1346848442-4573-7-git-send-email-naresh@chelsio.com>
On Wed, 5 Sep 2012 18:03:59 +0530
Naresh Kumar Inna <naresh@chelsio.com> wrote:
> +
> +#define CSIO_ASSERT(cond) \
> +do { \
> + if (unlikely(!((cond)))) \
> + BUG(); \
> +} while (0)
> +
Why is this not just BUG_ON(!(cond)) ?
^ permalink raw reply
* Re: [V2 PATCH 6/9] csiostor: Chelsio FCoE offload driver submission (headers part 1).
From: Stephen Hemminger @ 2012-09-05 16:31 UTC (permalink / raw)
To: Naresh Kumar Inna; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1346848442-4573-7-git-send-email-naresh@chelsio.com>
On Wed, 5 Sep 2012 18:03:59 +0530
Naresh Kumar Inna <naresh@chelsio.com> wrote:
> +#define CSIO_ROUNDUP(__v, __r) (((__v) + (__r) - 1) / (__r))
This is similar to existing round_up() in kernel.h could you use that?
^ permalink raw reply
* Re: [V2 PATCH 2/9] csiostor: Chelsio FCoE offload driver submission (sources part 2).
From: Stephen Hemminger @ 2012-09-05 16:29 UTC (permalink / raw)
To: Naresh Kumar Inna; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1346848442-4573-3-git-send-email-naresh@chelsio.com>
On Wed, 5 Sep 2012 18:03:55 +0530
Naresh Kumar Inna <naresh@chelsio.com> wrote:
> This patch contains code for driver initialization, driver resource
> allocation and the Work Request module functionality. Driver initialization
> includes module entry/exit points, registration with PCI, FC transport and
> SCSI mid layer subsystems. The Work Request module provides services for
> allocation of DMA queues, posting Work Requests on them and processing
> completions.
>
> Signed-off-by: Naresh Kumar Inna <naresh@chelsio.com>
Although the comments say you are using proc fs, there is no
code here related to that.
Any use of debugfs must be conditional the DEBUG_FS kernel configuration
parameter. Your code probably will break if DEBUG_FS is not
enabled. For a possible alternative see how a sub-config parameter
was added in sky2 driver.
^ permalink raw reply
* Re: [V2 PATCH 1/9] csiostor: Chelsio FCoE offload driver submission (sources part 1).
From: Stephen Hemminger @ 2012-09-05 16:23 UTC (permalink / raw)
To: Naresh Kumar Inna; +Cc: JBottomley, linux-scsi, dm, leedom, netdev, chethan
In-Reply-To: <1346848442-4573-2-git-send-email-naresh@chelsio.com>
On Wed, 5 Sep 2012 18:03:54 +0530
Naresh Kumar Inna <naresh@chelsio.com> wrote:
> +
> +/* FCoE Adapter types & its description */
> +static struct csio_adap_desc csio_fcoe_adapters[] = {
Tables like this should be const.
^ permalink raw reply
* Re: [net-next.git 4/7] stmmac: add Rx watchdog optimization to mitigate the DMA irqs
From: Ben Hutchings @ 2012-09-05 16:14 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, davem
In-Reply-To: <1346857432-24657-5-git-send-email-peppe.cavallaro@st.com>
On Wed, 2012-09-05 at 17:03 +0200, Giuseppe CAVALLARO wrote:
> GMAC devices newer than databook 3.50 has an embedded timer
> that can be used for mitigating the number of interrupts.
> So this patch adds this optimizations.
> Old MAC will continue to use NAPI.
[...]
Interrupt moderation is *not* a substitute for NAPI; you should continue
using NAPI as well.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: NULL pointer dereference in xt_register_target()
From: Eric Dumazet @ 2012-09-05 16:12 UTC (permalink / raw)
To: Cong Wang; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <1346860506.13121.148.camel@edumazet-glaptop>
On Wed, 2012-09-05 at 17:55 +0200, Eric Dumazet wrote:
> On Wed, 2012-09-05 at 23:43 +0800, Cong Wang wrote:
> > Hi, folks,
> >
> > The latest net-next tree can't boot due to a NULL ptr def
> > bug in the kernel, the full backtrack is:
> >
> > http://img1.douban.com/view/photo/photo/public/p1697139550.jpg
> >
> > the kernel .config file is:
> >
> > http://pastebin.com/9YTnkqKN
> >
> > I don't have time to look into the issue. If you need other info,
> > please let me know.
>
> It seems xt_nat_init() is called before xt_init(), so xt array is not
> yet setup.
>
>
Seems the following patch should help, I have to try it ;)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index 8d987c3..afcea11 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1390,6 +1390,6 @@ static void __exit xt_fini(void)
kfree(xt);
}
-module_init(xt_init);
+core_initcall(xt_init);
module_exit(xt_fini);
^ permalink raw reply related
* Re: [net-next.git 3/7] stmmac: add the initial tx coalesce schema
From: Ben Hutchings @ 2012-09-05 16:11 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, davem
In-Reply-To: <1346857432-24657-4-git-send-email-peppe.cavallaro@st.com>
On Wed, 2012-09-05 at 17:03 +0200, Giuseppe CAVALLARO wrote:
> This patch adds a new schema used for mitigating the
> number of transmit interrupts.
> It is based on a sw timer and a threshold value.
> The timer is used to periodically call the stmmac_tx
> function that can be invoked by the ISR but only for
> the descriptors where the interrupt on completion
> field has been set. This is tuned by a threshold.
>
> Next step is to add the ability to tune these coalesce
> values by ethtool.
>
> Till now I have put a default that showed a real gain
> on all the platforms ARM/SH4 where I performed benchmarks.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/common.h | 8 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 4 +
> .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 9 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 86 +++++++++++++-------
> 4 files changed, 72 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> index bd32fe6..1d6bd3e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -95,11 +95,13 @@ struct stmmac_extra_stats {
> unsigned long threshold;
> unsigned long tx_pkt_n;
> unsigned long rx_pkt_n;
> - unsigned long rx_napi_poll;
> + unsigned long normal_irq_n;
> unsigned long rx_normal_irq_n;
> + unsigned long rx_napi_poll;
> unsigned long tx_normal_irq_n;
> - unsigned long sched_timer_n;
> - unsigned long normal_irq_n;
> + unsigned long txtimer;
> + unsigned long tx_clean;
> + unsigned long tx_reset_ic_bit;
> unsigned long mmc_tx_irq_n;
> unsigned long mmc_rx_irq_n;
> unsigned long mmc_rx_csum_offload_irq_n;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 9f35769..0f5ab28 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -88,6 +88,10 @@ struct stmmac_priv {
> int eee_enabled;
> int eee_active;
> int tx_lpi_timer;
> + struct timer_list txtimer;
> + u32 tx_count_frames;
> + u32 tx_coal_frames;
> + u32 tx_coal_timer;
> };
>
> extern int phyaddr;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index 505fe71..48ad0bc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -90,12 +90,13 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
> STMMAC_STAT(threshold),
> STMMAC_STAT(tx_pkt_n),
> STMMAC_STAT(rx_pkt_n),
> - STMMAC_STAT(rx_napi_poll),
> + STMMAC_STAT(normal_irq_n),
> STMMAC_STAT(rx_normal_irq_n),
> + STMMAC_STAT(rx_napi_poll),
> STMMAC_STAT(tx_normal_irq_n),
> - STMMAC_STAT(sched_timer_n),
> - STMMAC_STAT(normal_irq_n),
> - STMMAC_STAT(normal_irq_n),
> + STMMAC_STAT(txtimer),
> + STMMAC_STAT(tx_clean),
> + STMMAC_STAT(tx_reset_ic_bit),
> STMMAC_STAT(mmc_tx_irq_n),
> STMMAC_STAT(mmc_rx_irq_n),
> STMMAC_STAT(mmc_rx_csum_offload_irq_n),
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index b247c39..d7f5482 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -77,6 +77,8 @@
>
> #define STMMAC_ALIGN(x) L1_CACHE_ALIGN(x)
> #define JUMBO_LEN 9000
> +#define STMMAC_TX_TM 40000
> +#define STMMAC_TX_MAX_FRAMES 64 /* Max coalesced frame */
>
> /* Module parameters */
> #define TX_TIMEO 5000 /* default 5 seconds */
> @@ -695,8 +697,11 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
> static void stmmac_tx(struct stmmac_priv *priv)
> {
> unsigned int txsize = priv->dma_tx_size;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->tx_lock, flags);
>
> - spin_lock(&priv->tx_lock);
> + priv->xstats.tx_clean++;
>
> while (priv->dirty_tx != priv->cur_tx) {
> int last;
> @@ -765,7 +770,7 @@ static void stmmac_tx(struct stmmac_priv *priv)
> stmmac_enable_eee_mode(priv);
> mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_TIMER(eee_timer));
> }
> - spin_unlock(&priv->tx_lock);
> + spin_unlock_irqrestore(&priv->tx_lock, flags);
> }
>
> static inline void stmmac_enable_irq(struct stmmac_priv *priv)
> @@ -778,29 +783,16 @@ static inline void stmmac_disable_irq(struct stmmac_priv *priv)
> priv->hw->dma->disable_dma_irq(priv->ioaddr);
> }
>
> -static int stmmac_has_work(struct stmmac_priv *priv)
> +static void stmmac_txtimer(unsigned long data)
> {
> - unsigned int has_work = 0;
> - int rxret, tx_work = 0;
> + struct stmmac_priv *priv = (struct stmmac_priv *)data;
>
> - rxret = priv->hw->desc->get_rx_owner(priv->dma_rx +
> - (priv->cur_rx % priv->dma_rx_size));
> + priv->xstats.txtimer++;
>
> if (priv->dirty_tx != priv->cur_tx)
> - tx_work = 1;
> -
> - if (likely(!rxret || tx_work))
> - has_work = 1;
> + stmmac_tx(priv);
>
> - return has_work;
> -}
> -
> -static inline void _stmmac_schedule(struct stmmac_priv *priv)
> -{
> - if (likely(stmmac_has_work(priv))) {
> - stmmac_disable_irq(priv);
> - napi_schedule(&priv->napi);
> - }
> + return;
> }
>
> /**
> @@ -824,7 +816,7 @@ static void stmmac_tx_err(struct stmmac_priv *priv)
> netif_wake_queue(priv->dev);
> }
>
> -static inline void stmmac_rx_schedule(struct stmmac_priv *priv)
> +static void stmmac_rx_schedule(struct stmmac_priv *priv)
> {
> if (likely(napi_schedule_prep(&priv->napi))) {
> stmmac_disable_irq(priv);
> @@ -1001,6 +993,36 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
> priv->dma_rx_phy);
> }
>
> +static int stmmac_check_coal(int size, int max_coal_frames)
> +{
> + int ret = 0;
> +
> + if (max_coal_frames >= size)
> + return ret;
> +
> + return max_coal_frames;
> +}
Not sure this makes sense. You're limiting the number of frames to be
coalesced to the size of the TX DMA ring. But each frame can consume
multiple DMA descriptors, so it doesn't make sense to compare these
numbers.
It looks like patch 6 reverts this, but why do it in the first place?
[...]
> @@ -1213,10 +1240,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> return NETDEV_TX_BUSY;
> }
>
> - spin_lock(&priv->tx_lock);
> -
> - if (priv->tx_path_in_lpi_mode)
> - stmmac_disable_eee_mode(priv);
Why are you removing the call to stmmac_disable_eee_mode()?
> + spin_lock_irqsave(&priv->tx_lock, flags);
>
> entry = priv->cur_tx % txsize;
>
> @@ -1272,7 +1296,14 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> /* Interrupt on completition only for the latest segment */
> priv->hw->desc->close_tx_desc(desc);
Comment above this is now incorrect.
> - wmb();
Why are you removing this barrier?
> + /* Do not set the IC according to the coalesce patameters */
> + priv->tx_count_frames++;
> + if (priv->tx_coal_frames > priv->tx_count_frames) {
> + priv->hw->desc->clear_tx_ic(desc);
> + priv->xstats.tx_reset_ic_bit++;
> + mod_timer(&priv->txtimer, priv->tx_coal_timer);
> + } else
> + priv->tx_count_frames = 0;
>
> /* To avoid raise condition */
> priv->hw->desc->set_tx_owner(first);
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: kernel BUG at kernel/timer.c:748!
From: Lin Ming @ 2012-09-05 16:04 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20120905043523.GA12988@redhat.com>
On Wed, Sep 5, 2012 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
> Just hit this bug on 3.6-rc4.
>
> The BUG is..
>
> BUG_ON(!timer->function);
TCP keepalive timer is setup when the socket is created.
__sock_create
inet_create
tcp_v4_init_sock
tcp_init_sock
tcp_init_xmit_timers
inet_csk_init_xmit_timers
timer->function should not be NULL when set keepalive option.
Strange...have bug somewhere.
Lin Ming
>
>
> Not much to go on... Any thoughts on what I could add to get
> more debug info on which protocol etc this was ?
>
> Dave
>
>
> kernel BUG at kernel/timer.c:748!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: tun fuse ipt_ULOG binfmt_misc nfnetlink nfc caif_socket caif phonet can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 nfsv3 nfs_acl nfs fscache lockd sunrpc bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr i2c_i801 e1000e uinput i915 video i2c_algo_bit drm_kms_helper drm i2c_core
> CPU 3
> Pid: 12330, comm: trinity-child3 Not tainted 3.6.0-rc4+ #36
> RIP: 0010:[<ffffffff810813f5>] [<ffffffff810813f5>] mod_timer+0x2c5/0x2f0
> RSP: 0018:ffff88000dfd7e08 EFLAGS: 00010246
> RAX: 000000000000001a RBX: ffff880122d62948 RCX: 000000000000001a
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88000dfd7e10
> RBP: ffff88000dfd7e48 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000001517000 R11: 0000000000000246 R12: 000000016c000000
> R13: 000000016c12bcb1 R14: ffff8801236cee00 R15: 00000000ffffff01
> FS: 00007fa96745f740(0000) GS:ffff880148200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000100ff000 CR3: 0000000099344000 CR4: 00000000001407e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process trinity-child3 (pid: 12330, threadinfo ffff88000dfd6000, task ffff880090890000)
> Stack:
> ffffffff8154cb6d 0000000007b5edf7 ffff88000dfd7e28 ffff880122d62520
> 0000000000000009 0000000000000004 ffff8801236cee00 00000000ffffff01
> ffff88000dfd7e68 ffffffff8154c79c ffffffff81550e6c ffff880122d62520
> Call Trace:
> [<ffffffff8154cb6d>] ? lock_sock_nested+0x8d/0xa0
> [<ffffffff8154c79c>] sk_reset_timer+0x1c/0x30
> [<ffffffff81550e6c>] ? sock_setsockopt+0x8c/0x960
> [<ffffffff815a84a0>] inet_csk_reset_keepalive_timer+0x20/0x30
> [<ffffffff815c018d>] tcp_set_keepalive+0x3d/0x50
> [<ffffffff81551703>] sock_setsockopt+0x923/0x960
> [<ffffffff810ddf76>] ? trace_hardirqs_on_caller+0x16/0x1e0
> [<ffffffff811db0ac>] ? fget_light+0x24c/0x520
> [<ffffffff8154af86>] sys_setsockopt+0xc6/0xe0
> [<ffffffff816a50ed>] system_call_fastpath+0x1a/0x1f
> Code: 00 74 43 9c 58 0f 1f 44 00 00 f6 c4 02 0f 84 14 ff ff ff eb 93 48 c7 c7 20 48 c3 81 e8 f5 70 05 00 85 c0 0f 85 fe fe ff ff eb b7 <0f> 0b 48 8b 75 08 48 89 df e8 3d f6 ff ff e9 b2 fd ff ff 4d 89
> RIP [<ffffffff810813f5>] mod_timer+0x2c5/0x2f0
> RSP <ffff88000dfd7e08>
> ---[ end trace 7e7b5910138e49a3 ]---
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* О чём думаешь
From: Варенникова Томуля @ 2012-09-04 20:16 UTC (permalink / raw)
To: netdev
Хай а ты красивый, если скучно и не против подружиться заходи ко мне на страничку http://pics.lancespinnie.com/media.php
^ permalink raw reply
* Re: NULL pointer dereference in xt_register_target()
From: Eric Dumazet @ 2012-09-05 15:55 UTC (permalink / raw)
To: Cong Wang; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVUZ50RYLUgEHbcm7ua996hgE7Gj-P-bWNJutuvm1nUoQ@mail.gmail.com>
On Wed, 2012-09-05 at 23:43 +0800, Cong Wang wrote:
> Hi, folks,
>
> The latest net-next tree can't boot due to a NULL ptr def
> bug in the kernel, the full backtrack is:
>
> http://img1.douban.com/view/photo/photo/public/p1697139550.jpg
>
> the kernel .config file is:
>
> http://pastebin.com/9YTnkqKN
>
> I don't have time to look into the issue. If you need other info,
> please let me know.
It seems xt_nat_init() is called before xt_init(), so xt array is not
yet setup.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox