* Re: [PATCH v3 net-next] net: refactor sk_page_frag_refill()
From: David Miller @ 2013-10-18 4:09 UTC (permalink / raw)
To: eric.dumazet
Cc: mwdalton, dborkman, netdev, ffusco, ycheng, ncardwell,
digitaleric
In-Reply-To: <1382052427.3284.3.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 17 Oct 2013 16:27:07 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While working on virtio_net new allocation strategy to increase
> payload/truesize ratio, we found that refactoring sk_page_frag_refill()
> was needed.
>
> This patch splits sk_page_frag_refill() into two parts, adding
> skb_page_frag_refill() which can be used without a socket.
>
> While we are at it, add a minimum frag size of 32 for
> sk_page_frag_refill()
>
> Michael will either use netdev_alloc_frag() from softirq context,
> or skb_page_frag_refill() from process context in refill_work()
> (GFP_KERNEL allocations)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 00/15] net: ethernet: remove unnecessary pci_set_drvdata() part 1
From: David Miller @ 2013-10-18 4:04 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Fri, 18 Oct 2013 09:16:19 +0900
> Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound),
> the driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: David Miller @ 2013-10-18 3:48 UTC (permalink / raw)
To: rusty; +Cc: mst, netdev, linux-kernel, virtualization, gregkh
In-Reply-To: <87d2n3s89s.fsf@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 18 Oct 2013 11:30:15 +1030
> Asking people to express 'CC: stable' in words is error-prone; if Dave
> wants to filter it, he's quite capable.
Filtering it one time is one thing.
Potentially acting on that filter 100 or so times a day...
That's completely another.
^ permalink raw reply
* [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: Seif Mazareeb @ 2013-10-18 3:33 UTC (permalink / raw)
To: paul, davem; +Cc: seif, netdev
From: Seif Mazareeb <seif@marvell.com>
When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop
forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel
crash in an SMP system, since the CPU executing this function will
stall /not respond to IPIs.
This problem can be reproduced by running the IP Stack Integrity Checker
(http://isic.sourceforge.net) using the following command on a Linux machine
connected to DUT:
"icmpsic -s rand -d <DUT IP address> -r 123456"
wait (1-2 min)
Signed-off-by: Seif Mazareeb <seif@marvell.com>
---
include/net/cipso_ipv4.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h
index a7a683e..a8c2ef6 100644
--- a/include/net/cipso_ipv4.h
+++ b/include/net/cipso_ipv4.h
@@ -290,6 +290,7 @@ static inline int cipso_v4_validate(const struct sk_buff *skb,
unsigned char err_offset = 0;
u8 opt_len = opt[1];
u8 opt_iter;
+ u8 tag_len;
if (opt_len < 8) {
err_offset = 1;
@@ -302,11 +303,12 @@ static inline int cipso_v4_validate(const struct sk_buff *skb,
}
for (opt_iter = 6; opt_iter < opt_len;) {
- if (opt[opt_iter + 1] > (opt_len - opt_iter)) {
+ tag_len = opt[opt_iter + 1];
+ if ((tag_len == 0) || (opt[opt_iter + 1] > (opt_len - opt_iter))) {
err_offset = opt_iter + 1;
goto out;
}
- opt_iter += opt[opt_iter + 1];
+ opt_iter += tag_len;
}
out:
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v4 net 0/3] sctp: Use software checksum under certain
From: David Miller @ 2013-10-18 3:33 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, linux-sctp, fan.du
In-Reply-To: <526046CB.6020506@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Thu, 17 Oct 2013 16:21:31 -0400
> Could you please queue this to stable as well.
Done.
^ permalink raw reply
* Re: IPv6 path discovery oddities - flushing the routing cache resolves
From: Hannes Frederic Sowa @ 2013-10-18 3:04 UTC (permalink / raw)
To: Valentijn Sessink; +Cc: netdev
In-Reply-To: <525FC1C4.3070605@blub.net>
On Thu, Oct 17, 2013 at 12:53:56PM +0200, Valentijn Sessink wrote:
> Hi,
>
> Thanks for your fast response, please see below. Sorry for the rather
> long mail, due to the routing tables. Even though they're really short,
> the output of ipv6_route is extensive...
>
> On 16-10-13 17:48, Hannes Frederic Sowa wrote:
> >I do think these two issues are connected. Could you send me a the
> >corresponding ip route output and /proc/net/ipv6_route output for when it
> >works and mtus are correctly handled and when it does not work?
>
> When it works (please note that the routing cache at first doesn't show
> an MTU, that only happens after a "too big" has been received, hence the
> difference before and after a "ps uaxww"), I have the following - this
> is from last night:
Thanks, I needed this to verify I am on the right track replicating this.
2001:1af8:ff03:3:219:66ff:fe26:6dd is the other end of the connection, I
guess?
Greetings,
Hannes
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Hannes Frederic Sowa @ 2013-10-18 2:10 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <alpine.LFD.2.03.1310180153250.4554@ssi.bg>
On Fri, Oct 18, 2013 at 02:03:27AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> Here is a solution that should work not only for IPVS.
> If the change looks correct I'll send it in a separate message.
>
> [PATCH net] ipv6: always prefer rt6i_gateway if present
>
> From: Julian Anastasov <ja@ssi.bg>
>
> In v3.9 6fd6ce2056de2709 ("ipv6: Do not depend on rt->n in
> ip6_finish_output2()." changed the behaviour of ip6_finish_output2()
> such that the recently introduced rt6_nexthop() is used
> instead of an assigned neighbor.
>
> As rt6_nexthop() prefers rt6i_gateway only for gatewayed
> routes this causes a problem for users like IPVS, xt_TEE and
> RAW(hdrincl) if they want to use different address for routing
> compared to the destination address.
>
> Fix it by considering the rt6i_gateway address in all
> cases, so that traffic routed to address on local subnet is
> not wrongly diverted to the destination address.
>
> Thanks to Simon Horman and Phil Oester for spotting the
> problematic commit.
I played around with your patch and tested xt_TEE. I added a TEE rule to
mangle/OUTPUT and pinged. This happend, I have not yet analyzed it:
[ 101.126649] ------------[ cut here ]------------
[ 101.128436] BUG: unable to handle kernel paging request at fffffffb8a2fda88
[ 101.129421] IP: [<ffffffff810c9737>] cpuacct_charge+0x97/0x200
[ 101.129421] PGD 1c0f067 PUD 0
[ 101.129421] Thread overran stack, or stack corrupted
[ 101.129421] Oops: 0000 [#1] SMP
[ 101.129421] Modules linked in: xt_TEE nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables joydev serio_raw virtio_balloon i2c_piix4 i2c_core nfsd auth_rpcgss nfs_acl lockd sunrpc virtio_blk virtio_net ata_generic pata_acpi
[ 101.129421] CPU: 1 PID: 1190 Comm: ping6 Not tainted 3.12.0-rc3+ #2
[ 101.129421] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 101.129421] task: ffff8800c30a4590 ti: ffff8801193ce000 task.ti: ffff8801193ce000
[ 101.129421] RIP: 0010:[<ffffffff810c9737>] [<ffffffff810c9737>] cpuacct_charge+0x97/0x200
[ 101.129421] RSP: 0018:ffff88011b403d60 EFLAGS: 00010002
[ 101.129421] RAX: 000000000000e5d8 RBX: 0000000000244314 RCX: ffffffff810b87bd
[ 101.129421] RDX: ffffffff81c4dce0 RSI: ffffffff81c47e00 RDI: 0000000000000046
[ 101.129421] RBP: ffff88011b403d88 R08: ffff8800c30a5308 R09: 0000000000000001
[ 101.129421] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8800c30a4590
[ 101.129421] R13: 00000000810b87bd R14: ffff880117d5b450 R15: 0000000000000000
[ 101.129421] FS: 00007f79260bc740(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
[ 101.129421] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 101.129421] CR2: fffffffb8a2fda88 CR3: 0000000117e40000 CR4: 00000000000006e0
[ 101.129421] Stack:
[ 101.129421] ffffffff810c96a5 ffff8800c30a45f8 ffff8800c8d1da40 ffff8800c30a4590
[ 101.129421] 0000000000244314 ffff88011b403dc8 ffffffff810bce9c 000000003264e993
[ 101.129421] ffff8800c30a45f8 0000000000000001 ffff8800c8d1da40 ffff88011b5d5240
[ 101.129421] Call Trace:
[ 101.129421] <IRQ>
[ 101.129421] [<ffffffff810c96a5>] ? cpuacct_charge+0x5/0x200
[ 101.129421] [<ffffffff810bce9c>] update_curr+0xcc/0x210
[ 101.129421] [<ffffffff810beb19>] task_tick_fair+0x2b9/0x680
[ 101.129421] [<ffffffff810b8948>] ? sched_clock_cpu+0xa8/0x100
[ 101.129421] [<ffffffff810b3564>] scheduler_tick+0x64/0xe0
[ 101.129421] [<ffffffff810866a6>] update_process_times+0x66/0x80
[ 101.129421] [<ffffffff810e7a15>] tick_sched_handle.isra.15+0x25/0x60
[ 101.129421] [<ffffffff810e7a91>] tick_sched_timer+0x41/0x60
[ 101.129421] [<ffffffff810a5146>] __run_hrtimer+0x86/0x490
[ 101.129421] [<ffffffff810e7a50>] ? tick_sched_handle.isra.15+0x60/0x60
[ 101.129421] [<ffffffff810a5fc7>] hrtimer_interrupt+0xf7/0x240
[ 101.129421] [<ffffffff8104a877>] local_apic_timer_interrupt+0x37/0x60
[ 101.129421] [<ffffffff8173dcbf>] smp_apic_timer_interrupt+0x3f/0x60
[ 101.129421] [<ffffffff8173c6b2>] apic_timer_interrupt+0x72/0x80
[ 101.129421] <EOI>
[ 101.129421] [<ffffffff810d5bdd>] ? vprintk_emit+0x1dd/0x5e0
[ 101.129421] [<ffffffff8107afe4>] ? __local_bh_disable+0x94/0xa0
[ 101.129421] [<ffffffff81723dbf>] printk+0x67/0x69
[ 101.129421] [<ffffffff810ed07c>] ? trace_hardirqs_on_caller+0xac/0x1c0
[ 101.129421] [<ffffffff8107afe4>] ? __local_bh_disable+0x94/0xa0
[ 101.129421] [<ffffffff81075394>] warn_slowpath_common+0x34/0xa0
[ 101.129421] [<ffffffff81600309>] ? dst_alloc+0x139/0x170
[ 101.129421] [<ffffffff810754ba>] warn_slowpath_null+0x1a/0x20
[ 101.129421] [<ffffffff8107afe4>] __local_bh_disable+0x94/0xa0
[ 101.129421] [<ffffffff8107b007>] local_bh_disable+0x17/0x20
[ 101.129421] [<ffffffff81600309>] dst_alloc+0x139/0x170
[ 101.129421] [<ffffffff816d4e47>] icmp6_dst_alloc+0xf7/0x430
[ 101.129421] [<ffffffff816d4d55>] ? icmp6_dst_alloc+0x5/0x430
[ 101.129421] [<ffffffff816dde26>] ndisc_send_skb+0x3e6/0x540
[ 101.129421] [<ffffffff816df81c>] ndisc_send_ns+0xdc/0x140
[ 101.129421] [<ffffffff816d394b>] rt6_probe+0x31b/0x380
[ 101.129421] [<ffffffff816d3690>] ? rt6_probe+0x60/0x380
[ 101.129421] [<ffffffff816d1b93>] ? rt6_score_route+0xa3/0x380
[ 101.129421] [<ffffffff816d471c>] ip6_pol_route.isra.47+0x2fc/0x4f0
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d496a>] ip6_pol_route_output+0x2a/0x30
[ 101.129421] [<ffffffff8170516e>] fib6_rule_action+0xbe/0x200
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816142e5>] fib_rules_lookup+0x145/0x390
[ 101.129421] [<ffffffff816141a5>] ? fib_rules_lookup+0x5/0x390
[ 101.129421] [<ffffffff81705464>] fib6_rule_lookup+0x44/0x80
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d1263>] ip6_route_output+0x73/0xb0
[ 101.129421] [<ffffffffa01df54f>] tee_tg6+0x15f/0x228 [xt_TEE]
[ 101.129421] [<ffffffffa012413f>] ip6t_do_table+0x26f/0x435 [ip6_tables]
[ 101.129421] [<ffffffff8107b09a>] ? local_bh_enable+0x8a/0xf0
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffffa01c10e8>] ip6table_mangle_hook+0xe8/0x170 [ip6table_mangle]
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162ab5a>] nf_iterate+0xca/0x180
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162acf4>] nf_hook_slow+0xe4/0x290
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff816dddb2>] ndisc_send_skb+0x372/0x540
[ 101.129421] [<ffffffff816df81c>] ndisc_send_ns+0xdc/0x140
[ 101.129421] [<ffffffff816d394b>] rt6_probe+0x31b/0x380
[ 101.129421] [<ffffffff816d3690>] ? rt6_probe+0x60/0x380
[ 101.129421] [<ffffffff816d1b93>] ? rt6_score_route+0xa3/0x380
[ 101.129421] [<ffffffff816d471c>] ip6_pol_route.isra.47+0x2fc/0x4f0
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d496a>] ip6_pol_route_output+0x2a/0x30
[ 101.129421] [<ffffffff8170516e>] fib6_rule_action+0xbe/0x200
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816142e5>] fib_rules_lookup+0x145/0x390
[ 101.129421] [<ffffffff816141a5>] ? fib_rules_lookup+0x5/0x390
[ 101.129421] [<ffffffff81705464>] fib6_rule_lookup+0x44/0x80
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d1263>] ip6_route_output+0x73/0xb0
[ 101.129421] [<ffffffffa01df54f>] tee_tg6+0x15f/0x228 [xt_TEE]
[ 101.129421] [<ffffffffa012413f>] ip6t_do_table+0x26f/0x435 [ip6_tables]
[ 101.129421] [<ffffffff8107b09a>] ? local_bh_enable+0x8a/0xf0
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffffa01c10e8>] ip6table_mangle_hook+0xe8/0x170 [ip6table_mangle]
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162ab5a>] nf_iterate+0xca/0x180
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162acf4>] nf_hook_slow+0xe4/0x290
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff816dddb2>] ndisc_send_skb+0x372/0x540
[ 101.129421] [<ffffffff816df81c>] ndisc_send_ns+0xdc/0x140
[ 101.129421] [<ffffffff816d394b>] rt6_probe+0x31b/0x380
[ 101.129421] [<ffffffff816d3690>] ? rt6_probe+0x60/0x380
[ 101.129421] [<ffffffff816d1b93>] ? rt6_score_route+0xa3/0x380
[ 101.129421] [<ffffffff816d471c>] ip6_pol_route.isra.47+0x2fc/0x4f0
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d496a>] ip6_pol_route_output+0x2a/0x30
[ 101.129421] [<ffffffff8170516e>] fib6_rule_action+0xbe/0x200
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816142e5>] fib_rules_lookup+0x145/0x390
[ 101.129421] [<ffffffff816141a5>] ? fib_rules_lookup+0x5/0x390
[ 101.129421] [<ffffffff81705464>] fib6_rule_lookup+0x44/0x80
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d1263>] ip6_route_output+0x73/0xb0
[ 101.129421] [<ffffffffa01df54f>] tee_tg6+0x15f/0x228 [xt_TEE]
[ 101.129421] [<ffffffffa012413f>] ip6t_do_table+0x26f/0x435 [ip6_tables]
[ 101.129421] [<ffffffff8107b09a>] ? local_bh_enable+0x8a/0xf0
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffffa01c10e8>] ip6table_mangle_hook+0xe8/0x170 [ip6table_mangle]
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162ab5a>] nf_iterate+0xca/0x180
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162acf4>] nf_hook_slow+0xe4/0x290
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff816dddb2>] ndisc_send_skb+0x372/0x540
[ 101.129421] [<ffffffff816df81c>] ndisc_send_ns+0xdc/0x140
[ 101.129421] [<ffffffff816d394b>] rt6_probe+0x31b/0x380
[ 101.129421] [<ffffffff816d3690>] ? rt6_probe+0x60/0x380
[ 101.129421] [<ffffffff816d1b93>] ? rt6_score_route+0xa3/0x380
[ 101.129421] [<ffffffff816d471c>] ip6_pol_route.isra.47+0x2fc/0x4f0
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d496a>] ip6_pol_route_output+0x2a/0x30
[ 101.129421] [<ffffffff8170516e>] fib6_rule_action+0xbe/0x200
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816142e5>] fib_rules_lookup+0x145/0x390
[ 101.129421] [<ffffffff816141a5>] ? fib_rules_lookup+0x5/0x390
[ 101.129421] [<ffffffff81705464>] fib6_rule_lookup+0x44/0x80
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d1263>] ip6_route_output+0x73/0xb0
[ 101.129421] [<ffffffffa01df54f>] tee_tg6+0x15f/0x228 [xt_TEE]
[ 101.129421] [<ffffffffa012413f>] ip6t_do_table+0x26f/0x435 [ip6_tables]
[ 101.129421] [<ffffffff8107b09a>] ? local_bh_enable+0x8a/0xf0
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffffa01c10e8>] ip6table_mangle_hook+0xe8/0x170 [ip6table_mangle]
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162ab5a>] nf_iterate+0xca/0x180
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff8162acf4>] nf_hook_slow+0xe4/0x290
[ 101.129421] [<ffffffff816dd6e0>] ? ndisc_alloc_skb+0x110/0x110
[ 101.129421] [<ffffffff816dddb2>] ndisc_send_skb+0x372/0x540
[ 101.129421] [<ffffffff816df81c>] ndisc_send_ns+0xdc/0x140
[ 101.129421] [<ffffffff816d394b>] rt6_probe+0x31b/0x380
[ 101.129421] [<ffffffff816d3690>] ? rt6_probe+0x60/0x380
[ 101.129421] [<ffffffff816d1b93>] ? rt6_score_route+0xa3/0x380
[ 101.129421] [<ffffffff816d471c>] ip6_pol_route.isra.47+0x2fc/0x4f0
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d496a>] ip6_pol_route_output+0x2a/0x30
[ 101.129421] [<ffffffff8170516e>] fib6_rule_action+0xbe/0x200
[ 101.129421] [<ffffffff810ea057>] ? __lock_is_held+0x57/0x80
[ 101.129421] [<ffffffff816142e5>] fib_rules_lookup+0x145/0x390
[ 101.129421] [<ffffffff816141a5>] ? fib_rules_lookup+0x5/0x390
[ 101.129421] [<ffffffff81705464>] fib6_rule_lookup+0x44/0x80
[ 101.129421] [<ffffffff816d4940>] ? ip6_pol_route_input+0x30/0x30
[ 101.129421] [<ffffffff816d1263>] ip6_route_output+0x73/0xb0
[ 101.129421] [<ffffffff816bfd13>] ip6_dst_lookup_tail+0x373/0x4a0
[ 101.129421] [<ffffffff8105768f>] ? kvm_clock_read+0x2f/0x50
[ 101.129421] [<ffffffff81021b89>] ? sched_clock+0x9/0x10
[ 101.129421] [<ffffffff810b87bd>] ? sched_clock_local+0x1d/0x80
[ 101.129421] [<ffffffff816bfe93>] ip6_dst_lookup_flow+0x33/0x90
[ 101.129421] [<ffffffff816f94bd>] ip6_datagram_connect+0x16d/0x510
[ 101.129421] [<ffffffff810ed0cd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 101.129421] [<ffffffff810ed19d>] ? trace_hardirqs_on+0xd/0x10
[ 101.129421] [<ffffffff81678dde>] inet_dgram_connect+0x2e/0x80
[ 101.129421] [<ffffffff815da25a>] SYSC_connect+0xea/0x130
[ 101.129421] [<ffffffff81732818>] ? retint_swapgs+0x13/0x1b
[ 101.129421] [<ffffffff810ed0cd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 101.129421] [<ffffffff8137b67e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 101.129421] [<ffffffff815db75e>] SyS_connect+0xe/0x10
[ 101.129421] [<ffffffff8173ba29>] system_call_fastpath+0x16/0x1b
[ 101.129421] Code: 00 00 4d 8b b4 24 e0 13 00 00 e8 e5 3d fd ff 85 c0 74 09 80 3d d0 4a c5 00 00 74 78 49 8b 56 48 49 63 cd 90 48 8b 82 b8 00 00 00 <48> 03 04 cd a0 9c d3 81 48 01 18 48 8b 52 40 48 85 d2 75 e5 e8
[ 101.129421] RIP [<ffffffff810c9737>] cpuacct_charge+0x97/0x200
[ 101.129421] RSP <ffff88011b403d60>
[ 101.129421] CR2: fffffffb8a2fda88
[ 101.129421] ---[ end trace 68ce790414632b74 ]---
[ 101.129421] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [Xen-devel] [PATCH net] xen-netback: add the scenario which now beyond the range time_after_eq().
From: annie li @ 2013-10-18 1:59 UTC (permalink / raw)
To: Wei Liu
Cc: Jan Beulich, jianhai luan, david.vrabel, ian.campbell, xen-devel,
netdev
In-Reply-To: <20131017164127.GA11894@zion.uk.xensource.com>
On 2013-10-18 0:41, Wei Liu wrote:
> On Fri, Oct 18, 2013 at 12:38:12AM +0800, annie li wrote:
>> On 2013-10-17 17:26, Jan Beulich wrote:
>>>> Yes, the issue only can be reproduced in 32-bit Dom0 (Beyond
>>>> MAX_ULONG/2 in 64-bit will need long long time)
>>>>
>>>> I think the gap should be think all environment even now extending 480+.
>>>> if now fall in the gap, one timer will be pending and replenish will be
>>>> in time. Please run the attachment test program.
>>> Not sure what this is supposed to tell me. I recognize that there
>>> are overflow conditions not handled properly, but (a) I have a
>>> hard time thinking of a sensible guest that sits idle for over 240
>>> days (host uptime usually isn't even coming close to that due to
>>> maintenance requirements) and (b) if there is such a sensible
>>> guest, then I can't see why dealing with one being idle for over
>>> 480 days should be required too.
>>>
>> If the guest contains multiple NICs, that situation probably happens
>> when one NIC keeps idle and others work under load. BTW, how do you
>> get the 240?
>>
> I think Jan got this number with HZ=100. It take ~240 days for jiffies
> to overflow in 32 bit machine when HZ=100.
If HZ is larger then the days would be less, for example, HZ=250, the
days would be ~99. It is possible to hit overflow in environment where
multiple NICs coexist and one NIC keeps idle all the time. Moreover,
this patch does not extend to the days doubled, the timer is set with
value based on next_credit.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: Paul Moore @ 2013-10-18 1:20 UTC (permalink / raw)
To: seif; +Cc: David Miller, netdev, thomas.petazzoni, dima
In-Reply-To: <20131017.154742.370913034142395176.davem@davemloft.net>
On Thursday, October 17, 2013 03:47:42 PM David Miller wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Mon, 14 Oct 2013 11:12:47 -0400
>
> > On Saturday, October 12, 2013 10:21:50 PM Seif Mazareeb wrote:
> >> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could
> >> loop forever in the main loop if opt[opt_iter +1] == 0, this will causing
> >> a
> >> kernel crash in an SMP system, since the CPU executing this function will
> >> stall /not respond to IPIs.
> >>
> >> This problem can be reproduced by running the IP Stack Integrity Checker
> >> (http://isic.sourceforge.net) using the following command on a Linux
> >> machine connected to DUT:
> >>
> >> "icmpsic -s rand -d <DUT IP address> -r 123456"
> >> wait (1-2 min)
> >>
> >> Signed-off-by: Seif Mazareeb <seif@marvell.com>
> >
> > Thanks for sticking with this.
> >
> > Acked-by: Paul Moore <paul@paul-moore.com>
>
> This patch, like all the others Seif submitted, has been corrupted by
> his email client and is this unusable.
Seif, please fix this. If I don't see a new patch by tomorrow I'll go ahead
and resubmit.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next] {selinux, af_key} Rework pfkey_sadb2xfrm_user_sec_ctx
From: Paul Moore @ 2013-10-18 1:18 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Fan Du, davem, netdev
In-Reply-To: <20131017095148.GC7660@secunet.com>
On Thursday, October 17, 2013 11:51:48 AM Steffen Klassert wrote:
> On Thu, Oct 17, 2013 at 09:34:53AM +0800, Fan Du wrote:
> > On 2013年10月16日 23:15, Paul Moore wrote:
> > >The fact that you are now changing sadb_x_sec_ctx->sadb_x_sec_len
> > >whenever
> > >pfkey_sadb2xfrm_user_sec_ctx() is called raises an eyebrow. Can you
> > >elaborate on why this is not a problem?
> >
> > Thanks for your attention, Paul.
> >
> > sadb_x_sec_ctx is extra headers passed down from user space, the usage of
> > of this data structure falls down to one of pfkey_funcs function only for
> > one time, more specifically speaking, it's only used by SELINUX for
> > security checking for each operation. In other words, sadb_x_sec_ctx
> > involves with a one shot business here. So the original codes seems do a
> > lots of extra job which could easily be avoid using casting operation.
>
> Since the selinux people have to live with that change in the fist place,
> I'd like to see an ack of one of the selinux maintainers before I take
> in into ipsec-next, Paul?
Well, my earlier concern over modifying the length field probably isn't a
major concern as was pointed out so I could maybe look the other way on that
point. However, while looking a bit closer at the structs and how they are
used, I noticed that PFKEY structs are all explicitly packed (sadb_x_sec_ctx)
and the LSM struct is not (xfrm_user_sec_ctx). I'm not enough of a compiler
guru across all the different architectures to know if this is significant or
not given the structure, but it does make me pause.
Any compiler gurus care to weigh in on this?
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-18 1:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: Steven Rostedt, netdev, linux-kernel, Peter Zijlstra
In-Reply-To: <20131018005057.GL2592@two.firstfloor.org>
On Fri, Oct 18, 2013 at 02:50:57AM +0200, Andi Kleen wrote:
> On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> > On Thu, 17 Oct 2013 07:31:57 +0200
> > Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> >
> > > Based on a patch from Andi Kleen.
> >
> > I'm fine with the patch, but the change log needs a lot more work.
> > Like, why is this needed? I know, but does anyone else?
>
> Or just merge the orininal patch. While being less verbose
> in the warning it had a full changelog.
I don't care that much which patch gets merged but I just want to
point out another difference: I added WARN_ONs on code paths without
architecture support for static_keys to help developers on platforms
without support for that.
Greetings,
Hannes
^ permalink raw reply
* Re: Any suggestions for a 40G Ethernet NIC?
From: Ben Greear @ 2013-10-18 1:08 UTC (permalink / raw)
To: Ding Tianhong; +Cc: netdev
In-Reply-To: <526088B6.7070503@huawei.com>
On 10/17/2013 06:02 PM, Ding Tianhong wrote:
> On 2013/10/18 1:55, Ben Greear wrote:
>> I'd like to start playing around with 40G, but doesn't seem to be too
>> many such NICs available. Does anyone have any suggestions for 40G NICs
>> that work well with Linux?
>>
>> Thanks,
>> Ben
>>
>
> I have the situation for test 40G for Linux, which consist of 4 82599 NICs,
> and I use bonding LACP mode to test the performance, when turn on the iommu for
> kernel, the performance is up to 30G, when close it, the performance is up to 38G,
> what do you think about it?
Nice performance!
But, for my purposes, I need a real 40g port to test some other 40g
equipment.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Any suggestions for a 40G Ethernet NIC?
From: Ding Tianhong @ 2013-10-18 1:02 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <5260248B.3090400@candelatech.com>
On 2013/10/18 1:55, Ben Greear wrote:
> I'd like to start playing around with 40G, but doesn't seem to be too
> many such NICs available. Does anyone have any suggestions for 40G NICs
> that work well with Linux?
>
> Thanks,
> Ben
>
I have the situation for test 40G for Linux, which consist of 4 82599 NICs,
and I use bonding LACP mode to test the performance, when turn on the iommu for
kernel, the performance is up to 30G, when close it, the performance is up to 38G,
what do you think about it?
Thanks.
Ding
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: Rusty Russell @ 2013-10-18 1:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, virtualization, Greg Kroah-Hartman
In-Reply-To: <20131017050710.GA12141@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote:
>> Jason Wang <jasowang@redhat.com> writes:
>> > We're trying to re-configure the affinity unconditionally in cpu hotplug
>> > callback. This may lead the issue during resuming from s3/s4 since
>> >
>> > - virt queues haven't been allocated at that time.
>> > - it's unnecessary since thaw method will re-configure the affinity.
>> >
>> > Fix this issue by checking the config_enable and do nothing is we're not ready.
>> >
>> > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
>> > (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>> >
>> > Cc: Rusty Russell <rusty@rustcorp.com.au>
>> > Cc: Michael S. Tsirkin <mst@redhat.com>
>> > Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
>> > Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>> > ---
>> > The patch is need for 3.8 and above.
>>
>> Please put 'CC: stable@kernel.org # 3.8+' in the commit.
>
> Not if this is going in through the net tree.
WTF? Wow, there really *is* an FAQ: https://lwn.net/Articles/561669/
DaveM is the best maintainer I've ever known, but I abhor the idea that
every subsystem has its own incompatible variant on workflow and style.
Asking people to express 'CC: stable' in words is error-prone; if Dave
wants to filter it, he's quite capable.
Rusty.
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called
From: Andi Kleen @ 2013-10-18 0:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: Hannes Frederic Sowa, netdev, linux-kernel, Peter Zijlstra,
Andi Kleen
In-Reply-To: <20131017171940.173bab09@gandalf.local.home>
On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 07:31:57 +0200
> Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>
> > Based on a patch from Andi Kleen.
>
> I'm fine with the patch, but the change log needs a lot more work.
> Like, why is this needed? I know, but does anyone else?
Or just merge the orininal patch. While being less verbose
in the warning it had a full changelog.
-Andi
^ permalink raw reply
* [PATCH 14/15] net: cxgb4vf: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:24 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Casey Leedom'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index 40c22e7..43bb012 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2782,11 +2782,9 @@ err_unmap_bar:
err_free_adapter:
kfree(adapter);
- pci_set_drvdata(pdev, NULL);
err_release_regions:
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
pci_clear_master(pdev);
err_disable_device:
@@ -2851,7 +2849,6 @@ static void cxgb4vf_pci_remove(struct pci_dev *pdev)
}
iounmap(adapter->regs);
kfree(adapter);
- pci_set_drvdata(pdev, NULL);
}
/*
--
1.7.10.4
^ permalink raw reply related
* [PATCH 15/15] net: enic: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:25 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Christian Benvenuti',
'Sujith Sankar', 'Govindarajulu Varadarajan',
'Neel Patel', 'Nishank Trivedi'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/cisco/enic/enic_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 7b756cf9..ff78dfa 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2309,7 +2309,6 @@ err_out_release_regions:
err_out_disable_device:
pci_disable_device(pdev);
err_out_free_netdev:
- pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
return err;
@@ -2338,7 +2337,6 @@ static void enic_remove(struct pci_dev *pdev)
enic_iounmap(enic);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 13/15] net: cxgb2: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:24 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev, 'Jingoo Han'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
index d7048db..1d02105 100644
--- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
+++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
@@ -1168,7 +1168,6 @@ out_free_dev:
pci_release_regions(pdev);
out_disable_pdev:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -1347,7 +1346,6 @@ static void remove_one(struct pci_dev *pdev)
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
t1_sw_reset(pdev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/15] net: cxgb3: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:23 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Divy Le Ray'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index b650951..45d7733 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3374,7 +3374,6 @@ out_release_regions:
pci_release_regions(pdev);
out_disable_device:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
out:
return err;
}
@@ -3415,7 +3414,6 @@ static void remove_one(struct pci_dev *pdev)
kfree(adapter);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/15] net: cxgb4: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:23 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Dimitris Michailidis'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 85d0cda..8b929ee 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -6075,7 +6075,6 @@ sriov:
pci_disable_device(pdev);
out_release_regions:
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -6123,7 +6122,6 @@ static void remove_one(struct pci_dev *pdev)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
} else
pci_release_regions(pdev);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/15] net: bna: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:22 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Rasesh Mody'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..f276433 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3212,7 +3212,6 @@ bnad_init(struct bnad *bnad,
bnad->bar0 = ioremap_nocache(bnad->mmio_start, bnad->mmio_len);
if (!bnad->bar0) {
dev_err(&pdev->dev, "ioremap for bar0 failed\n");
- pci_set_drvdata(pdev, NULL);
return -ENOMEM;
}
pr_info("bar0 mapped to %p, len %llu\n", bnad->bar0,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/15] net: tg3: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Nithin Nayak Sujir',
'Michael Chan'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/tg3.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 498569e..819d87c 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -17701,7 +17701,6 @@ err_out_free_res:
err_out_disable_pdev:
if (pci_is_enabled(pdev))
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return err;
}
@@ -17733,7 +17732,6 @@ static void tg3_remove_one(struct pci_dev *pdev)
free_netdev(dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/15] net: bnx2x: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Eilon Greenstein'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e53ff1e..8fd3432 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12297,7 +12297,6 @@ err_out_release:
err_out_disable:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_out:
return rc;
@@ -12840,7 +12839,6 @@ init_one_exit:
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
return rc;
}
@@ -12923,7 +12921,6 @@ static void __bnx2x_remove(struct pci_dev *pdev,
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
static void bnx2x_remove_one(struct pci_dev *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/15] net: bnx2: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:21 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Michael Chan'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 6111870..d9980ad 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -8413,7 +8413,6 @@ err_out_release:
err_out_disable:
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_out:
return rc;
@@ -8546,7 +8545,6 @@ error:
pci_iounmap(pdev, bp->regview);
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
err_free:
free_netdev(dev);
return rc;
@@ -8578,7 +8576,6 @@ bnx2_remove_one(struct pci_dev *pdev)
pci_release_regions(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
}
static int
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/15] net: alx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-10-18 0:20 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Jay Cliburn',
'Chris Snook'
In-Reply-To: <00ae01cecb97$44d45770$ce7d0650$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/net/ethernet/atheros/alx/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
index fc95b23..5aa5e81 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1367,7 +1367,6 @@ static void alx_remove(struct pci_dev *pdev)
pci_disable_pcie_error_reporting(pdev);
pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
free_netdev(alx->dev);
}
--
1.7.10.4
^ permalink raw reply related
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