* Re: [PATCH net-next-2.6 v2] can: convert protocol handling to RCU
From: Oliver Hartkopp @ 2011-04-06 14:39 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: David Miller, Linux Netdev List, Eric Dumazet, Urs Thuermann
In-Reply-To: <20110406092727.GC342@kurt.e-circ.dyndns.org>
On 06.04.2011 11:27, Kurt Van Dijck wrote:
> On Tue, Apr 05, 2011 at 08:01:16PM +0200, Oliver Hartkopp wrote:
>>
>> +static struct can_proto *can_try_module_get(int protocol)
>> +{
>> + struct can_proto *cp;
>> +
>> + rcu_read_lock();
>> + cp = rcu_dereference(proto_tab[protocol]);
>> + if (cp && !try_module_get(cp->prot->owner))
> After the xxx_get, is the 'cp' pointer persistent?
try_module_get() increases the usage counter of the module - therefore it is.
It is protected until module_put(cp->prot->owner) at the end of can_create() .
>> /* check for available protocol and correct usage */
>>
>> if (!cp)
>> return -EPROTONOSUPPORT;
>>
>> if (cp->type != sock->type) {
> I don't see how this will evaluate to true?
> can_proto_register takes care of it.
This check compares the type of the socket that is to be created with the type
that's defined for this protocol.
E.g. if you would give
s = socket(PF_CAN, SOCK_STREAM, CAN_RAW);
instead of the correct
s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
you will get this error.
>> - err = -EPROTONOSUPPORT;
>> + err = -EPROTOTYPE;
>> goto errout;
>> }
>>
Regards,
Oliver
^ permalink raw reply
* RE
From: BARCLAYS @ 2011-04-06 15:01 UTC (permalink / raw)
Attention:This is the second time we are notifying you about your fund worth
US$27M, with this Bank. Yours sincerely,Mr. Frank Brown.
^ permalink raw reply
* Re: [Patch] iwlwifi: remove obsoleted module alias and parameters
From: John W. Linville @ 2011-04-06 15:14 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Cong Wang, Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Intel Linux Wireless, Wey-Yi Guy,
Meenakshi Venkataraman, Larry Finger
In-Reply-To: <20110406125728.GA2197-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Apr 06, 2011 at 02:57:29PM +0200, Stanislaw Gruszka wrote:
> On Wed, Apr 06, 2011 at 06:42:48PM +0800, Cong Wang wrote:
> > 于 2011年04月06日 18:09, Johannes Berg 写道:
> > >On Wed, 2011-04-06 at 17:49 +0800, Amerigo Wang wrote:
> > >>As scheduled in Documentation/feature-removal-schedule.txt,
> > >>remove "*50", "disable_hw_scan" module parameters and MODULE_ALIAS("iwl4965").
> > >
> > >Mostly fine, but for iwlegacy Stanislaw we want to keep hw scan (and it
> > >was actually made default now)
>
> Indeed, disable_hw_scan should be removed in iwlwifi but leaved in iwlegacy.
>
> > Ok, I will wait for Stanislaw's response and then send an updated patch.
>
> Have it now :-)
Maybe the MODULE_ALIAS("iwl4965") should go to iwlegacy too?
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Fw: [Bug 32772] New: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
From: Stephen Hemminger @ 2011-04-06 15:18 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 6 Apr 2011 07:39:54 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 32772] New: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
https://bugzilla.kernel.org/show_bug.cgi?id=32772
Summary: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
Product: Networking
Version: 2.5
Kernel Version: 2.6.38
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: dimetrios@gmail.com
Regression: No
Kernel oopses periodically with 'kernel BUG at net/ipv4/inetpeer.c:386'
message. Machine is used as BGP router and runs Quagga. Nonordinary kernel
config option set: CONFIG_IP_FIB_TRIE=y.
Two traces:
--------------------trace begin--------------
[625279.329241] kernel BUG at net/ipv4/inetpeer.c:386!
[625279.329241] invalid opcode: 0000 [#1] SMP
[625279.329241] last sysfs file: /sys/module/ip_tables/initstate
[625279.329241] Modules linked in: nf_nat_pptp nf_nat_proto_gre
nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ipt_REJECT
xt_state xt_tcpudp xt_multiport ip_set iptable_filter iptable_mangle
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables
x_tables act_police cls_u32 sch_ingress sch_tbf 8021q garp bridge ipv6 stp llc
loop i2c_i801 intel_agp parport_pc i2c_core intel_gtt rng_core agpgart
processor parport button evdev pcspkr thermal_sys serio_raw tpm_tis tpm
tpm_bios ext3 jbd mbcache sd_mod crc_t10dif ata_generic ata_piix libata
scsi_mod uhci_hcd ide_pci_generic e1000e ehci_hcd r8169 ide_core igb dca mii
usbcore nls_base [last unloaded: scsi_wait_scan]
[625279.329241]
[625279.329241] Pid: 0, comm: kworker/0:0 Not tainted 2.6.38-demyan-1.1demyan
#1 Gigabyte Technology Co., Ltd. G41MT-ES2L/G41MT-ES2L
[625279.329241] EIP: 0060:[<c11e0caa>] EFLAGS: 00010283 CPU: 1
[625279.329241] EIP is at unlink_from_pool+0x85/0x14a
[625279.329241] EAX: c125ff04 EBX: ed21cd40 ECX: c351ce70 EDX: e8db5b40
[625279.329241] ESI: c1333338 EDI: f4c91ca0 EBP: c351b55e ESP: f4c91c48
[625279.329241] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[625279.329241] Process kworker/0:0 (pid: 0, ti=f4c90000 task=f4c6a400
task.ti=f4c8c000)
[625279.329241] Stack:
[625279.329241] f1be9b00 00000001 c351ce70 c133333c c1333338 ed21a684 f11a3f84
f0146f00
[625279.329241] ed2dca80 ed21a900 f0146644 ec4c2f40 f0146280 ec701dc0 f0467fc0
eea79604
[625279.329241] f16c12c0 ef727900 ec865784 e721a3c0 ee859cc4 e8db5b40 00000640
00000014
[625279.329241] Call Trace:
[625279.329241] [<c11ea34a>] ? tcp_tso_segment+0x24d/0x25c
[625279.329241] [<f820048a>] ? tcp_packet+0xb8e/0xbb8 [nf_conntrack]
[625279.329241] [<c11e0de9>] ? cleanup_once+0x7a/0x7f
[625279.329241] [<c11e0fa9>] ? inet_getpeer+0x1bb/0x1dc
[625279.329241] [<c11d0001>] ? store_xps_map+0xa1/0x2b8
[625279.329241] [<c11c3477>] ? dev_hard_start_xmit+0x36f/0x454
[625279.329241] [<c1021ef1>] ? get_nohz_timer_target+0x47/0x64
[625279.329241] [<c11e1cb0>] ? ip4_frag_init+0x66/0x71
[625279.329241] [<c120bb54>] ? inet_frag_find+0x80/0x18d
[625279.329241] [<c11e1dec>] ? ip_defrag+0x131/0x955
[625279.329241] [<f81be0b1>] ? ipv4_conntrack_defrag+0xb0/0xd3
[nf_defrag_ipv4]
[625279.329241] [<c11dc036>] ? nf_iterate+0x32/0x5d
[625279.329241] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625279.329241] [<c11dc13d>] ? nf_hook_slow+0x40/0xb5
[625279.329241] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625279.329241] [<c11e164c>] ? ip_rcv+0x24d/0x293
[625279.329241] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625279.329241] [<c11c1b3c>] ? __netif_receive_skb+0x405/0x42c
[625279.329241] [<c11c1a63>] ? __netif_receive_skb+0x32c/0x42c
[625279.329241] [<c1047585>] ? ktime_get_real+0x10/0x2d
[625279.329241] [<c11c2547>] ? netif_receive_skb+0x5a/0x5f
[625279.329241] [<c11c25ff>] ? napi_skb_finish+0x1b/0x30
[625279.329241] [<f80a9723>] ? igb_poll+0x649/0x94a [igb]
[625279.329241] [<c1007765>] ? sched_clock+0x9/0xd
[625279.329241] [<c1030582>] ? do_exit+0x2e/0x60c
[625279.329241] [<c104438f>] ? sched_clock_local+0x17/0x13d
[625279.329241] [<c11c2b7b>] ? net_rx_action+0x90/0x150
[625279.329241] [<c1031f12>] ? __do_softirq+0x75/0x10e
[625279.329241] [<c1031e9d>] ? __do_softirq+0x0/0x10e
[625279.329241] <IRQ>
[625279.329241] [<c1031df3>] ? irq_exit+0x31/0x64
[625279.329241] [<c1004397>] ? do_IRQ+0x73/0x84
[625279.329241] [<c1003429>] ? common_interrupt+0x29/0x30
[625279.329241] [<c10089b4>] ? mwait_idle+0x4f/0x59
[625279.329241] [<c10021ef>] ? cpu_idle+0x46/0x63
[625279.329241] Code: 24 08 39 cd 75 09 42 3b 54 24 04 7c e9 eb 18 3b 6c 24 08
8d 50 04 0f 42 d0 89 17 83 c7 04 8b 02 3d 04 ff 25 c1 75 bb 39 d8 74 04 <0f> 0b
eb fe 8d 6f fc 81 3b 04 ff 25 c1 89 6c 24 08 75 0d 8b 47
[625279.329241] EIP: [<c11e0caa>] unlink_from_pool+0x85/0x14a SS:ESP
0068:f4c91c48
[625280.416294] ---[ end trace b75ce593ad6cbee7 ]---
[625280.430422] Kernel panic - not syncing: Fatal exception in interrupt
[625280.449739] Pid: 0, comm: kworker/0:0 Tainted: G D
2.6.38-demyan-1.1demyan #1
[625280.473762] Call Trace:
[625280.481380] [<c1231f71>] ? panic+0x4d/0x137
[625280.494457] [<c1005722>] ? oops_end+0x8e/0x99
[625280.508054] [<c1003a0e>] ? do_invalid_op+0x0/0x75
[625280.522693] [<c1003a7a>] ? do_invalid_op+0x6c/0x75
[625280.537588] [<c11e0caa>] ? unlink_from_pool+0x85/0x14a
[625280.553527] [<c11e0bbd>] ? inet_putpeer+0x15/0x47
[625280.568165] [<c11e0d64>] ? unlink_from_pool+0x13f/0x14a
[625280.584367] [<f80a9ed6>] ? igb_xmit_frame_ring_adv+0x4b2/0x795 [igb]
[625280.603941] [<c1007765>] ? sched_clock+0x9/0xd
[625280.617797] [<c123464e>] ? error_code+0x5a/0x60
[625280.631913] [<c1003a0e>] ? do_invalid_op+0x0/0x75
[625280.646552] [<c11e0caa>] ? unlink_from_pool+0x85/0x14a
[625280.662490] [<c11ea34a>] ? tcp_tso_segment+0x24d/0x25c
[625280.678427] [<f820048a>] ? tcp_packet+0xb8e/0xbb8 [nf_conntrack]
[625280.696964] [<c11e0de9>] ? cleanup_once+0x7a/0x7f
[625280.711600] [<c11e0fa9>] ? inet_getpeer+0x1bb/0x1dc
[625280.726758] [<c11d0001>] ? store_xps_map+0xa1/0x2b8
[625280.741916] [<c11c3477>] ? dev_hard_start_xmit+0x36f/0x454
[625280.758894] [<c1021ef1>] ? get_nohz_timer_target+0x47/0x64
[625280.775870] [<c11e1cb0>] ? ip4_frag_init+0x66/0x71
[625280.790768] [<c120bb54>] ? inet_frag_find+0x80/0x18d
[625280.806184] [<c11e1dec>] ? ip_defrag+0x131/0x955
[625280.820562] [<f81be0b1>] ? ipv4_conntrack_defrag+0xb0/0xd3
[nf_defrag_ipv4]
[625280.841961] [<c11dc036>] ? nf_iterate+0x32/0x5d
[625280.856078] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625280.870975] [<c11dc13d>] ? nf_hook_slow+0x40/0xb5
[625280.885612] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625280.900510] [<c11e164c>] ? ip_rcv+0x24d/0x293
[625280.914107] [<c11e10e0>] ? ip_rcv_finish+0x0/0x31f
[625280.929005] [<c11c1b3c>] ? __netif_receive_skb+0x405/0x42c
[625280.945982] [<c11c1a63>] ? __netif_receive_skb+0x32c/0x42c
[625280.962960] [<c1047585>] ? ktime_get_real+0x10/0x2d
[625280.978121] [<c11c2547>] ? netif_receive_skb+0x5a/0x5f
[625280.994055] [<c11c25ff>] ? napi_skb_finish+0x1b/0x30
[625281.009473] [<f80a9723>] ? igb_poll+0x649/0x94a [igb]
[625281.025150] [<c1007765>] ? sched_clock+0x9/0xd
[625281.039005] [<c1030582>] ? do_exit+0x2e/0x60c
[625281.052603] [<c104438f>] ? sched_clock_local+0x17/0x13d
[625281.068800] [<c11c2b7b>] ? net_rx_action+0x90/0x150
[625281.083958] [<c1031f12>] ? __do_softirq+0x75/0x10e
[625281.098857] [<c1031e9d>] ? __do_softirq+0x0/0x10e
[625281.113493] <IRQ> [<c1031df3>] ? irq_exit+0x31/0x64
[625281.128963] [<c1004397>] ? do_IRQ+0x73/0x84
[625281.142040] [<c1003429>] ? common_interrupt+0x29/0x30
[625281.157718] [<c10089b4>] ? mwait_idle+0x4f/0x59
[625281.171836] [<c10021ef>] ? cpu_idle+0x46/0x63
[625281.185435] Rebooting in 5 seconds..
--------------------trace end--------------
--------------------trace begin--------------
[237684.673906] kernel BUG at net/ipv4/inetpeer.c:386!
[237684.673906] invalid opcode: 0000 [#1] SMP
[237684.673906] last sysfs file: /sys/module/nf_conntrack_pptp/initstate
[237684.673906] Modules linked in: nf_nat_pptp nf_nat_proto_gre
nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ipt_REJECT
xt_state xt_tcpudp xt_multiport ip_set iptable_filter iptable_mangle
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables
x_tables act_police cls_u32 sch_ingress sch_tbf 8021q garp bridge ipv6 stp llc
loop i2c_i801 rng_core intel_agp intel_gtt agpgart i2c_core tpm_tis evdev
pcspkr parport_pc processor parport button tpm thermal_sys tpm_bios serio_raw
ext3 jbd mbcache sd_mod crc_t10dif ata_generic ata_piix libata scsi_mod
uhci_hcd ide_pci_generic r8169 ehci_hcd e1000e mii igb dca ide_core usbcore
nls_base [last unloaded: scsi_wait_scan]
[237684.673906]
[237684.673906] Pid: 0, comm: swapper Not tainted 2.6.38-demyan-1.1demyan #1
Gigabyte Technology Co., Ltd. G41MT-ES2L/G41MT-ES2L
[237684.673906] EIP: 0060:[<c11e0caa>] EFLAGS: 00010287 CPU: 0
[237684.673906] EIP is at unlink_from_pool+0x85/0x14a
[237684.673906] EAX: c125ff04 EBX: ed76d180 ECX: 75c219bc EDX: e8de9444
[237684.673906] ESI: c1333338 EDI: f4c0bbfc EBP: 75c25152 ESP: f4c0bba8
[237684.673906] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[237684.673906] Process swapper (pid: 0, ti=f4c0a000 task=c1315f20
task.ti=c1300000)
[237684.673906] Stack:
[237684.673906] ef42e49c 00000001 75c219bc c133333c c1333338 f4780d80 ed76d744
f19e3744
[237684.673906] ed71f980 f452a404 f183fc04 f452afc4 f4780ac0 f18ca680 f474fe84
f1871180
[237684.673906] ee2a9884 edef3844 f1cf3e04 edf15284 e8de9444 f4c0bcb4 ef42e49c
f4c0bc78
[237684.673906] Call Trace:
[237684.673906] [<c120f068>] ? fib4_rule_action+0x40/0x4d
[237684.673906] [<c11d1be3>] ? fib_rules_lookup+0x8d/0xe4
[237684.673906] [<c109bf68>] ? cache_alloc_refill+0x75/0x3dc
[237684.673906] [<c11e0de9>] ? cleanup_once+0x7a/0x7f
[237684.673906] [<c11e0fa9>] ? inet_getpeer+0x1bb/0x1dc
[237684.673906] [<c11dc073>] ? nf_ct_attach+0x12/0x13
[237684.673906] [<c1202404>] ? icmp_glue_bits+0x65/0x6a
[237684.673906] [<c11e4109>] ? ip_append_data+0x595/0x850
[237684.673906] [<c11e025d>] ? rt_bind_peer+0x1d/0x3d
[237684.673906] [<c11e029f>] ? __ip_select_ident+0x22/0xa6
[237684.673906] [<c11e4f60>] ? ip_push_pending_frames+0x206/0x2cb
[237684.673906] [<c120301b>] ? icmp_send+0x4fe/0x523
[237684.673906] [<f8270b09>] ? ____nf_conntrack_find+0xfa/0x142 [nf_conntrack]
[237684.673906] [<f8272069>] ? nf_conntrack_in+0x4f3/0x5e3 [nf_conntrack]
[237684.673906] [<f81ef536>] ? ipt_do_table+0x4bc/0x4eb [ip_tables]
[237684.673906] [<c11e2949>] ? ip_forward+0x2ef/0x316
[237684.673906] [<c11e13da>] ? ip_rcv_finish+0x2fa/0x31f
[237684.673906] [<c11c1b3c>] ? __netif_receive_skb+0x405/0x42c
[237684.673906] [<c11c1a63>] ? __netif_receive_skb+0x32c/0x42c
[237684.673906] [<c1047585>] ? ktime_get_real+0x10/0x2d
[237684.673906] [<c11c2547>] ? netif_receive_skb+0x5a/0x5f
[237684.673906] [<c11c25ff>] ? napi_skb_finish+0x1b/0x30
[237684.673906] [<f80e1723>] ? igb_poll+0x649/0x94a [igb]
[237684.673906] [<c1007765>] ? sched_clock+0x9/0xd
[237684.673906] [<c1030091>] ? wait_consider_task+0x974/0xa91
[237684.673906] [<c104438f>] ? sched_clock_local+0x17/0x13d
[237684.673906] [<c11c2b7b>] ? net_rx_action+0x90/0x150
[237684.673906] [<c1031f12>] ? __do_softirq+0x75/0x10e
[237684.673906] [<c1031e9d>] ? __do_softirq+0x0/0x10e
[237684.673906] <IRQ>
[237684.673906] [<c1031df3>] ? irq_exit+0x31/0x64
[237684.673906] [<c1004397>] ? do_IRQ+0x73/0x84
[237684.673906] [<c1003429>] ? common_interrupt+0x29/0x30
[237684.673906] [<c10089b4>] ? mwait_idle+0x4f/0x59
[237684.673906] [<c10021ef>] ? cpu_idle+0x46/0x63
[237684.673906] [<c133b85c>] ? start_kernel+0x2e2/0x2e5
[237684.673906] Code: 24 08 39 cd 75 09 42 3b 54 24 04 7c e9 eb 18 3b 6c 24 08
8d 50 04 0f 42 d0 89 17 83 c7 04 8b 02 3d 04 ff 25 c1 75 bb 39 d8 74 04 <0f> 0b
eb fe 8d 6f fc 81 3b 04 ff 25 c1 89 6c 24 08 75 0d 8b 47
[237684.673906] EIP: [<c11e0caa>] unlink_from_pool+0x85/0x14a SS:ESP
0068:f4c0bba8
[237685.787747] ---[ end trace e3c73323a4e3b283 ]---
[237685.801876] Kernel panic - not syncing: Fatal exception in interrupt
[237685.821194] Pid: 0, comm: swapper Tainted: G D
2.6.38-demyan-1.1demyan #1
[237685.844177] Call Trace:
[237685.851797] [<c1231f71>] ? panic+0x4d/0x137
[237685.864874] [<c1005722>] ? oops_end+0x8e/0x99
[237685.878471] [<c1003a0e>] ? do_invalid_op+0x0/0x75
[237685.893109] [<c1003a7a>] ? do_invalid_op+0x6c/0x75
[237685.908005] [<c11e0caa>] ? unlink_from_pool+0x85/0x14a
[237685.923942] [<c1007765>] ? sched_clock+0x9/0xd
[237685.937801] [<c1007765>] ? sched_clock+0x9/0xd
[237685.951658] [<c104438f>] ? sched_clock_local+0x17/0x13d
[237685.967856] [<c123464e>] ? error_code+0x5a/0x60
[237685.981973] [<c1003a0e>] ? do_invalid_op+0x0/0x75
[237685.996610] [<c11e0caa>] ? unlink_from_pool+0x85/0x14a
[237686.012548] [<c120f068>] ? fib4_rule_action+0x40/0x4d
[237686.028225] [<c11d1be3>] ? fib_rules_lookup+0x8d/0xe4
[237686.043902] [<c109bf68>] ? cache_alloc_refill+0x75/0x3dc
[237686.060359] [<c11e0de9>] ? cleanup_once+0x7a/0x7f
[237686.074997] [<c11e0fa9>] ? inet_getpeer+0x1bb/0x1dc
[237686.090156] [<c11dc073>] ? nf_ct_attach+0x12/0x13
[237686.104792] [<c1202404>] ? icmp_glue_bits+0x65/0x6a
[237686.119949] [<c11e4109>] ? ip_append_data+0x595/0x850
[237686.135626] [<c11e025d>] ? rt_bind_peer+0x1d/0x3d
[237686.150264] [<c11e029f>] ? __ip_select_ident+0x22/0xa6
[237686.166202] [<c11e4f60>] ? ip_push_pending_frames+0x206/0x2cb
[237686.183959] [<c120301b>] ? icmp_send+0x4fe/0x523
[237686.198338] [<f8270b09>] ? ____nf_conntrack_find+0xfa/0x142 [nf_conntrack]
[237686.219474] [<f8272069>] ? nf_conntrack_in+0x4f3/0x5e3 [nf_conntrack]
[237686.239311] [<f81ef536>] ? ipt_do_table+0x4bc/0x4eb [ip_tables]
[237686.257589] [<c11e2949>] ? ip_forward+0x2ef/0x316
[237686.272227] [<c11e13da>] ? ip_rcv_finish+0x2fa/0x31f
[237686.287643] [<c11c1b3c>] ? __netif_receive_skb+0x405/0x42c
[237686.304620] [<c11c1a63>] ? __netif_receive_skb+0x32c/0x42c
[237686.321599] [<c1047585>] ? ktime_get_real+0x10/0x2d
[237686.336760] [<c11c2547>] ? netif_receive_skb+0x5a/0x5f
[237686.352692] [<c11c25ff>] ? napi_skb_finish+0x1b/0x30
[237686.368111] [<f80e1723>] ? igb_poll+0x649/0x94a [igb]
[237686.383788] [<c1007765>] ? sched_clock+0x9/0xd
[237686.397645] [<c1030091>] ? wait_consider_task+0x974/0xa91
[237686.414362] [<c104438f>] ? sched_clock_local+0x17/0x13d
[237686.430559] [<c11c2b7b>] ? net_rx_action+0x90/0x150
[237686.445718] [<c1031f12>] ? __do_softirq+0x75/0x10e
[237686.460614] [<c1031e9d>] ? __do_softirq+0x0/0x10e
[237686.475251] <IRQ> [<c1031df3>] ? irq_exit+0x31/0x64
[237686.490722] [<c1004397>] ? do_IRQ+0x73/0x84
[237686.503799] [<c1003429>] ? common_interrupt+0x29/0x30
[237686.519476] [<c10089b4>] ? mwait_idle+0x4f/0x59
[237686.533593] [<c10021ef>] ? cpu_idle+0x46/0x63
[237686.547191] [<c133b85c>] ? start_kernel+0x2e2/0x2e5
[237686.562350] Rebooting in 5 seconds..
--------------------trace end--------------
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-06 15:23 UTC (permalink / raw)
To: Grant Likely
Cc: Andres Salomon, linux-kernel, Mark Brown, khali, ben-linux,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell, linux-i2c,
linux-media, netdev, spi-devel-general, Mocean Laboratories,
Greg Kroah-Hartman
In-Reply-To: <20110405030428.GB29522@ponder.secretlab.ca>
On Mon, Apr 04, 2011 at 09:04:29PM -0600, Grant Likely wrote:
> > The second step would be to get rid of mfd_get_data() and have all subdrivers
> > going back to the regular platform_data way. They would no longer be dependant
> > on the MFD code except for those who really need it. In that case they could
> > just call mfd_get_cell() and get full access to their MFD cell.
>
> The revert to platform_data needs to happen ASAP though. If this
> second step isn't ready really quickly, then the current patches
> should be reverted to give some breathing room for creating the
> replacement patches. However, it's not such a rush if the below
> patch really does eliminate all of the nastiness of the original
> series. (I haven't looked and a rolled up diff of the first series and
> this change, so I don't know for sure).
I am done reverting these changes, with a final patch getting rid of
mfd_get_data. See
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git for-linus
I still need to give it a second review before pushing it to lkml for
comments. It's 20 patches long, so I'm not entirely sure Linus would take that
at that point.
Pushing patch #1 would be enough for fixing the issues introduced by the
original patchset, so I'm leaning toward pushing it and leaving the 19 other
patches for the next merge window.
> In principle I agree with this patch. Some comments below.
Thanks for the comments. I think I addressed all of them in patch #1:
---
drivers/base/platform.c | 1 +
drivers/mfd/mfd-core.c | 15 +++++++++++++--
include/linux/device.h | 3 +++
include/linux/mfd/core.h | 7 +++++--
4 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f051cff..bde6b97 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -149,6 +149,7 @@ static void platform_device_release(struct device *dev)
of_device_node_put(&pa->pdev.dev);
kfree(pa->pdev.dev.platform_data);
+ kfree(pa->pdev.dev.mfd_cell);
kfree(pa->pdev.resource);
kfree(pa);
}
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index d01574d..99b0d6d 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -18,6 +18,18 @@
#include <linux/pm_runtime.h>
#include <linux/slab.h>
+static int mfd_platform_add_cell(struct platform_device *pdev, const struct mfd_cell *cell)
+{
+ if (!cell)
+ return 0;
+
+ pdev->dev.mfd_cell = kmemdup(cell, sizeof(*cell), GFP_KERNEL);
+ if (!pdev->dev.mfd_cell)
+ return -ENOMEM;
+
+ return 0;
+}
+
int mfd_cell_enable(struct platform_device *pdev)
{
const struct mfd_cell *cell = mfd_get_cell(pdev);
@@ -75,7 +87,7 @@ static int mfd_add_device(struct device *parent, int id,
pdev->dev.parent = parent;
- ret = platform_device_add_data(pdev, cell, sizeof(*cell));
+ ret = mfd_platform_add_cell(pdev, cell);
if (ret)
goto fail_res;
@@ -123,7 +135,6 @@ static int mfd_add_device(struct device *parent, int id,
return 0;
-/* platform_device_del(pdev); */
fail_res:
kfree(res);
fail_device:
diff --git a/include/linux/device.h b/include/linux/device.h
index ab8dfc0..cf353cf 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -33,6 +33,7 @@ struct class;
struct subsys_private;
struct bus_type;
struct device_node;
+struct mfd_cell;
struct bus_attribute {
struct attribute attr;
@@ -444,6 +445,8 @@ struct device {
struct device_node *of_node; /* associated device tree node */
const struct of_device_id *of_match; /* matching of_device_id from driver */
+ struct mfd_cell *mfd_cell; /* MFD cell pointer */
+
dev_t devt; /* dev_t, creates the sysfs "dev" */
spinlock_t devres_lock;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index ad1b19a..28f81cf 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -86,7 +86,7 @@ extern int mfd_clone_cell(const char *cell, const char **clones,
*/
static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev)
{
- return pdev->dev.platform_data;
+ return pdev->dev.mfd_cell;
}
/*
@@ -95,7 +95,10 @@ static inline const struct mfd_cell *mfd_get_cell(struct platform_device *pdev)
*/
static inline void *mfd_get_data(struct platform_device *pdev)
{
- return mfd_get_cell(pdev)->mfd_data;
+ if (pdev->dev.mfd_cell)
+ return mfd_get_cell(pdev)->mfd_data;
+ else
+ return pdev->dev.platform_data;
}
extern int mfd_add_devices(struct device *parent, int id,
--
1.7.2.3
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply related
* Re: [RFC] ixgbe: is DCA really that good ?
From: Tom Herbert @ 2011-04-06 15:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, Brattain, Jeff Kirsher, netdev
In-Reply-To: <1302097444.3209.85.camel@edumazet-laptop>
On Wed, Apr 6, 2011 at 6:44 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Hi guys
>
>
> In a forwarding [or RPS/RFS] setup, why should we populate cpu caches
> with full frames content ? We only need first cache line to perform
> routing [or RPS/RFS] decision.
>
DCA + accelerated RFS might make good. But I agree that it should be
configurable.
> -> DCA should be a knob (ethtool ?) that an admin can switch off and on,
> port by port, not a CONFIG_IXGBE_DCA thing.
>
> Thanks
>
>
> --
> 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: [Patch] iwlwifi: remove obsoleted module alias and parameters
From: John W. Linville @ 2011-04-06 15:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Cong Wang, Johannes Berg, linux-wireless, netdev,
Intel Linux Wireless, Wey-Yi Guy, Meenakshi Venkataraman,
Larry Finger
In-Reply-To: <20110406151429.GD11941@tuxdriver.com>
On Wed, Apr 06, 2011 at 11:14:29AM -0400, John W. Linville wrote:
> On Wed, Apr 06, 2011 at 02:57:29PM +0200, Stanislaw Gruszka wrote:
> > On Wed, Apr 06, 2011 at 06:42:48PM +0800, Cong Wang wrote:
> > > 于 2011年04月06日 18:09, Johannes Berg 写道:
> > > >On Wed, 2011-04-06 at 17:49 +0800, Amerigo Wang wrote:
> > > >>As scheduled in Documentation/feature-removal-schedule.txt,
> > > >>remove "*50", "disable_hw_scan" module parameters and MODULE_ALIAS("iwl4965").
> > > >
> > > >Mostly fine, but for iwlegacy Stanislaw we want to keep hw scan (and it
> > > >was actually made default now)
> >
> > Indeed, disable_hw_scan should be removed in iwlwifi but leaved in iwlegacy.
> >
> > > Ok, I will wait for Stanislaw's response and then send an updated patch.
> >
> > Have it now :-)
>
> Maybe the MODULE_ALIAS("iwl4965") should go to iwlegacy too?
Nevermind, forgot the "Internal alias support has been present in
module-init-tools" part...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: convert protocol handling to RCU
From: Kurt Van Dijck @ 2011-04-06 15:34 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, Linux Netdev List, Eric Dumazet, Urs Thuermann
In-Reply-To: <4D9C7B07.20903@hartkopp.net>
On Wed, Apr 06, 2011 at 04:39:03PM +0200, Oliver Hartkopp wrote:
> On 06.04.2011 11:27, Kurt Van Dijck wrote:
> > On Tue, Apr 05, 2011 at 08:01:16PM +0200, Oliver Hartkopp wrote:
>
> >>
> >> +static struct can_proto *can_try_module_get(int protocol)
> >> +{
> >> + struct can_proto *cp;
> >> +
> >> + rcu_read_lock();
> >> + cp = rcu_dereference(proto_tab[protocol]);
> >> + if (cp && !try_module_get(cp->prot->owner))
> > After the xxx_get, is the 'cp' pointer persistent?
>
> try_module_get() increases the usage counter of the module - therefore it is.
> It is protected until module_put(cp->prot->owner) at the end of can_create() .
Ok, I understand correctly now.
>
> >> /* check for available protocol and correct usage */
> >>
> >> if (!cp)
> >> return -EPROTONOSUPPORT;
> >>
> >> if (cp->type != sock->type) {
> > I don't see how this will evaluate to true?
> > can_proto_register takes care of it.
>
> This check compares the type of the socket that is to be created with the type
> that's defined for this protocol.
>
> E.g. if you would give
>
> s = socket(PF_CAN, SOCK_STREAM, CAN_RAW);
>
> instead of the correct
>
> s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
>
> you will get this error.
Right, I see my mistake now.
>
> >> - err = -EPROTONOSUPPORT;
> >> + err = -EPROTOTYPE;
> >> goto errout;
> >> }
> >>
>
> Regards,
> Oliver
Regards,
Kurt
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
^ permalink raw reply
* [PATCH] be2net: Fix a potential crash during shutdown.
From: Ajit Khaparde @ 2011-04-06 15:53 UTC (permalink / raw)
To: netdev, davem
adapter could remain uninitialized if probe fails for some reason.
A null pointer access could cause a crash if be_shutdown
is called after that.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a71163f..6e8e211 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -3141,12 +3141,14 @@ static int be_resume(struct pci_dev *pdev)
static void be_shutdown(struct pci_dev *pdev)
{
struct be_adapter *adapter = pci_get_drvdata(pdev);
- struct net_device *netdev = adapter->netdev;
- if (netif_running(netdev))
+ if (!adapter)
+ return;
+
+ if (netif_running(adapter->netdev))
cancel_delayed_work_sync(&adapter->work);
- netif_device_detach(netdev);
+ netif_device_detach(adapter->netdev);
be_cmd_reset_function(adapter);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Greg KH @ 2011-04-06 15:58 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Grant Likely, Andres Salomon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mark Brown, khali-PUYAD+kWke1g9hUCZPvPmw,
ben-linux-elnMNo+KYs3YtjvyW6yDsg, Peter Korsgaard,
Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <20110406152322.GA2757@sortiz-mobl>
On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -33,6 +33,7 @@ struct class;
> struct subsys_private;
> struct bus_type;
> struct device_node;
> +struct mfd_cell;
>
> struct bus_attribute {
> struct attribute attr;
> @@ -444,6 +445,8 @@ struct device {
> struct device_node *of_node; /* associated device tree node */
> const struct of_device_id *of_match; /* matching of_device_id from driver */
>
> + struct mfd_cell *mfd_cell; /* MFD cell pointer */
> +
What is a "MFD cell pointer" and why is it needed in struct device?
thanks,
greg k-h
^ permalink raw reply
* Re: Fw: [Bug 32772] New: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
From: Eric Dumazet @ 2011-04-06 16:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, dimetrios, David Miller
In-Reply-To: <20110406081818.4f0489b5@nehalam>
Le mercredi 06 avril 2011 à 08:18 -0700, Stephen Hemminger a écrit :
>
> Begin forwarded message:
>
> Date: Wed, 6 Apr 2011 07:39:54 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 32772] New: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=32772
>
> Summary: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.38
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: dimetrios@gmail.com
> Regression: No
>
>
> Kernel oopses periodically with 'kernel BUG at net/ipv4/inetpeer.c:386'
> message. Machine is used as BGP router and runs Quagga. Nonordinary kernel
> config option set: CONFIG_IP_FIB_TRIE=y.
> Two traces:
> --------------------trace begin--------------
> [625279.329241] kernel BUG at net/ipv4/inetpeer.c:386!
Hmm...
if (atomic_cmpxchg(&p->refcnt, 1, -1) == 1) {
struct inet_peer __rcu **stack[PEER_MAXDEPTH];
struct inet_peer __rcu ***stackptr, ***delp;
if (lookup(&p->daddr, stack, base) != p)
BUG();
So we cant find a peer in AVL tree, while we really should at this stage.
This reminds me a possible memory corruption (from another layer)
Could Dmitry try to boot with boot parameter "slub_nomerge" , to make sure
inetpeer layer doesnt share its kmem_cache with a corrupter ?
^ permalink raw reply
* Re: [RFC] ixgbe: is DCA really that good ?
From: Eric Dumazet @ 2011-04-06 16:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: Alexander Duyck, Brattain, Jeff Kirsher, netdev
In-Reply-To: <BANLkTimSRhuVTcOX-EHx74_y3pnDdCRi8A@mail.gmail.com>
Le mercredi 06 avril 2011 à 08:24 -0700, Tom Herbert a écrit :
> On Wed, Apr 6, 2011 at 6:44 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Hi guys
> >
> >
> > In a forwarding [or RPS/RFS] setup, why should we populate cpu caches
> > with full frames content ? We only need first cache line to perform
> > routing [or RPS/RFS] decision.
> >
> DCA + accelerated RFS might make good. But I agree that it should be
> configurable.
An IRQ affinity mismatch is fatal with dca-core current code, because
dca3_get_tag() ->
dca_common_get_tag() ->
spin_lock_irqsave(&dca_lock, flags);
Wei Gu hit this on a 64 cpus machine (but only 8 cpus servicing ixgbe
interrupts), and finding the problem took lot of time.
^ permalink raw reply
* Re: Fw: [Bug 32772] New: PROBLEM: kernel BUG at net/ipv4/inetpeer.c:386
From: Eric Dumazet @ 2011-04-06 16:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, dimetrios, David Miller
In-Reply-To: <1302105923.3209.103.camel@edumazet-laptop>
Le mercredi 06 avril 2011 à 18:05 +0200, Eric Dumazet a écrit :
>
> This reminds me a possible memory corruption (from another layer)
>
I found the reference of a past bug report, where slub_nomerge was used
too.
http://www.spinics.net/lists/netdev/msg154206.html
^ permalink raw reply
* Re: shutdown oops in xt_compat_calc_jump
From: dann frazier @ 2011-04-06 16:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Patrick McHardy, netdev, netfilter-devel@vger.kernel.org
In-Reply-To: <1301987879.3021.714.camel@edumazet-laptop>
On Tue, Apr 05, 2011 at 09:17:59AM +0200, Eric Dumazet wrote:
> Le mardi 05 avril 2011 à 08:24 +0200, Eric Dumazet a écrit :
> > Le mardi 05 avril 2011 à 00:48 +0200, Eric Dumazet a écrit :
> > > Le lundi 04 avril 2011 à 22:37 +0200, Eric Dumazet a écrit :
> > > > Le lundi 04 avril 2011 à 22:02 +0200, Patrick McHardy a écrit :
> > > > > CCed netfilter-devel.
> > > > >
> > > > > Am 04.04.2011 21:48, schrieb dann frazier:
> > > > > > fyi, noticed this oops when shutting down a system running top of git
> > > > > > (@ 78fca1be)
> > > > > >
> > > > > > [ 1169.794644] cfg80211: Calling CRDA to update world regulatory domain
> > > > > > [ 1170.490646] bluetoothd[2029]: segfault at f8ad9944 ip 00000000f77045e0 sp 00000000ffcb14e0 error 4 in bluetoothd[f76bf000+8b000]
> > > > > > [ 1170.543817] BUG: unable to handle kernel paging request at 00000001dc1be9f8
> > > > > > [ 1170.543875] IP: [<ffffffffa051e7b0>] xt_compat_calc_jump+0x25/0x6f [x_tables]
> > > > > > [ 1170.543927] PGD 1215b3067 PUD 0
> > > > > > [ 1170.543955] Oops: 0000 [#1] SMP
> > > > > > [ 1170.543982] last sysfs file: /sys/module/bridge/initstate
> > > > > > [ 1170.544017] CPU 3
> > > > > > [ 1170.544031] Modules linked in: ebtable_broute ebtable_filter vfat msdos fat ext3 jbd ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats binfmt_misc kvm(-) fuse ext2 loop snd_hda_codec_hdmi snd_hda_codec_conexant arc4 ecb snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_rawmidi i915 drm_kms_helper thinkpad_acpi snd_seq iwlagn snd_timer snd_seq_device drm snd mac80211 psmouse btusb serio_raw bluetooth evdev tpm_tis snd_page_alloc tpm i2c_i801 i2c_algo_bit cfg80211 battery soundcore nvram tpm_bios i2c_core rfkill wmi ac power_supply video button processor ext4 mbcache jbd2 crc16 sha256_generic aesni_intel cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10di
> > > > > f
> > > > > > usbhid
> > > > > > hid usb_storage ahci libahci libata ehci_hcd scsi_mod usbcore e1000e thermal thermal_sys [last unloaded: kvm_intel]
> > > > > > [ 1170.544836]
> > > > > > [ 1170.544849] Pid: 4901, comm: ebtables Not tainted 2.6.39-rc1+ #9 LENOVO 2516CTO/2516CTO
> > > > > > [ 1170.544902] RIP: 0010:[<ffffffffa051e7b0>] [<ffffffffa051e7b0>] xt_compat_calc_jump+0x25/0x6f [x_tables]
> > > > > > [ 1170.544958] RSP: 0018:ffff880121473cf8 EFLAGS: 00010217
> > > > > > [ 1170.544989] RAX: 000000003b837d3f RBX: 0000000000000090 RCX: 000000007706fa7f
> > > > > > [ 1170.545029] RDX: 0000000000000000 RSI: 0000000000000090 RDI: 000000003b837d3f
> > > > > > [ 1170.545067] RBP: ffffc900111a3000 R08: 0000000000000000 R09: dead000000200200
> > > > > > [ 1170.545104] R10: dead000000100100 R11: 0000000000001311 R12: ffff880121473d88
> > > > > > [ 1170.545147] R13: ffffc900111a6000 R14: ffffffff817de300 R15: 0000000000000000
> > > > > > [ 1170.545185] FS: 0000000000000000(0000) GS:ffff880137d80000(0063) knlGS:00000000f761b6c0
> > > > > > [ 1170.545227] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
> > > > > > [ 1170.545258] CR2: 00000001dc1be9f8 CR3: 0000000125868000 CR4: 00000000000006e0
> > > > > > [ 1170.545297] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > > [ 1170.545334] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > > > > [ 1170.545375] Process ebtables (pid: 4901, threadinfo ffff880121472000, task ffff8801322d1ac0)
> > > > > > [ 1170.545418] Stack:
> > > > > > [ 1170.545433] 0000000000000090 ffffffffa0576d46 f7007265746c6966 0000000000000054
> > > > > > [ 1170.545479] 0000000000000000 0000000000000000 000000000000000e 0000000000000090
> > > > > > [ 1170.545529] 0000000000000000 0000000008af2180 0000000008af21b0 0000000008af21e0
> > > > > > [ 1170.545579] Call Trace:
> > > > > > [ 1170.545600] [<ffffffffa0576d46>] ? compat_do_replace+0x117/0x221 [ebtables]
> > > > > > [ 1170.545639] [<ffffffffa0577392>] ? compat_do_ebt_set_ctl+0x55/0xbb [ebtables]
> > > > > > [ 1170.545688] [<ffffffff810337e3>] ? need_resched+0x1a/0x23
> > > > > > [ 1170.545723] [<ffffffff810337f1>] ? should_resched+0x5/0x24
> > > > > > [ 1170.545730] [<ffffffff81314cc5>] ? _cond_resched+0x9/0x20
> > > > > > [ 1170.545733] [<ffffffff813152fe>] ? mutex_lock_interruptible+0x18/0x32
> > > > > > [ 1170.545738] [<ffffffff8128490b>] ? nf_sockopt_find.clone.1+0xda/0xec
> > > > > > [ 1170.545742] [<ffffffff81284996>] ? compat_nf_sockopt+0x79/0xa5
> > > > > > [ 1170.545744] [<ffffffff810337f1>] ? should_resched+0x5/0x24
> > > > > > [ 1170.545747] [<ffffffff812849f3>] ? compat_nf_setsockopt+0x1a/0x1f
> > > > > > [ 1170.545751] [<ffffffff8128fb35>] ? compat_ip_setsockopt+0x80/0xa0
> > > > > > [ 1170.545756] [<ffffffff812784a2>] ? compat_sys_setsockopt+0x1d5/0x204
> > > > > > [ 1170.545759] [<ffffffff810337f1>] ? should_resched+0x5/0x24
> > > > > > [ 1170.545761] [<ffffffff81314cc5>] ? _cond_resched+0x9/0x20
> > > > > > [ 1170.545764] [<ffffffff812788a5>] ? compat_sys_socketcall+0x148/0x1a7
> > > > > > [ 1170.545768] [<ffffffff8131d2c0>] ? sysenter_dispatch+0x7/0x2e
> > > > > > [ 1170.545769] Code: 5d 41 5e 41 5f c3 40 0f b6 ff 53 31 d2 48 6b ff 70 48 03 3d 03 1b 00 00 8b 4f 6c 4c 8b 47 60 ff c9 eb 27 8d 04 11 d1 f8 48 63 f8
> > > > > > [ 1170.545787] RIP [<ffffffffa051e7b0>] xt_compat_calc_jump+0x25/0x6f [x_tables]
> > > > > > [ 1170.545792] RSP <ffff880121473cf8>
> > > > > > [ 1170.545794] CR2: 00000001dc1be9f8
> > > > > > [ 1170.654269] ---[ end trace d44667d90dcbd115 ]---
> > > > > > [ 1170.662411] fuse exit
> > > > > > Kernel logging (proc) stopped.
> > > > > > --
> > > >
> > > >
> > > > Hmm, commit 255d0dc34068a976550ce555e must have a problem for ebtables ?
> > > >
> > > > Dann, could you give us what you do with ebtables ?
> > > >
> > > > Thanks
> > > >
> > >
> > > For sure, there was a typo in above commit, but this is not enough to
> > > make ebtables work in COMPAT mode.
> > >
> > > Hmm...
> > >
> >
> > Update : xt_compat_calc_jump() misses this bit, and I still have to find
> > the ebtables problem.
> >
> > I'll provide a cumulative patch once done
> >
>
> Here is the cumulative patch
Thanks Eric. Unfortunately that didn't solve the problem I am seeing.
I rebaselined (same kernel build as before), and found that I'm able
to reproduce this 100% of the time by running only:
sudo ebtables -t filter --init-table
The backtrace I received was this:
[ 73.393223] ------------[ cut here ]------------
[ 73.394944] WARNING: at net/netfilter/x_tables.c:476 xt_compat_calc_jump+0x64/0x6f [x_tables]()
[ 73.396427] Hardware name: 2516CTO
[ 73.398079] Modules linked in: ebtable_broute ebtable_filter ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats kvm_intel kvm binfmt_misc fuse ext2 loop snd_hda_codec_hdmi snd_hda_codec_conexant arc4 ecb snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_hda_intel snd_hda_codec iwlagn snd_hwdep snd_pcm snd_seq i915 snd_rawmidi thinkpad_acpi mac80211 snd_timer snd_seq_device btusb bluetooth psmouse battery tpm_tis cfg80211 drm_kms_helper drm serio_raw nvram evdev ac tpm tpm_bios i2c_algo_bit i2c_i801 snd power_supply soundcore rfkill wmi snd_page_alloc button i2c_core video processor ext4 mbcache jbd2 crc16 sha256_generic aesni_intel cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif usbhid hid usb_storage
ahci libahci libata ehci_hcd scsi_mod usbcore e1000e thermal thermal_sys [last unloaded: scsi_wait_scan]
[ 73.412341] Pid: 2891, comm: ebtables.orig Not tainted 2.6.39-rc1+ #9
[ 73.414396] Call Trace:
[ 73.416525] [<ffffffff81041b99>] ? warn_slowpath_common+0x78/0x8c
[ 73.418631] [<ffffffffa05227ef>] ? xt_compat_calc_jump+0x64/0x6f [x_tables]
[ 73.420758] [<ffffffffa0571d46>] ? compat_do_replace+0x117/0x221 [ebtables]
[ 73.422859] [<ffffffffa0572392>] ? compat_do_ebt_set_ctl+0x55/0xbb [ebtables]
[ 73.425030] [<ffffffff810337e3>] ? need_resched+0x1a/0x23
[ 73.427110] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 73.429183] [<ffffffff81314cc5>] ? _cond_resched+0x9/0x20
[ 73.431290] [<ffffffff813152fe>] ? mutex_lock_interruptible+0x18/0x32
[ 73.433418] [<ffffffff8128490b>] ? nf_sockopt_find.clone.1+0xda/0xec
[ 73.435520] [<ffffffff81284996>] ? compat_nf_sockopt+0x79/0xa5
[ 73.437565] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 73.439612] [<ffffffff812849f3>] ? compat_nf_setsockopt+0x1a/0x1f
[ 73.441666] [<ffffffff8128fb35>] ? compat_ip_setsockopt+0x80/0xa0
[ 73.443697] [<ffffffff812784a2>] ? compat_sys_setsockopt+0x1d5/0x204
[ 73.445705] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 73.447739] [<ffffffff81314cc5>] ? _cond_resched+0x9/0x20
[ 73.449813] [<ffffffff812788a5>] ? compat_sys_socketcall+0x148/0x1a7
[ 73.451873] [<ffffffff8131d2c0>] ? sysenter_dispatch+0x7/0x2e
[ 73.453894] ---[ end trace 2285ecdee0e743d3 ]---
[ 73.745725] Ebtables v2.0 unregistered
I reliably get the same backtrace, which is slightly different than
the one I originally submitted. I've only seen that original backtrace
once.
I then applied your patch, but I'm still seeing a similar backtrace:
[ 33.143939] ------------[ cut here ]------------
[ 33.146063] WARNING: at net/netfilter/x_tables.c:479 xt_compat_calc_jump+0x6f/0x7a [x_tables]()
[ 33.148360] Hardware name: 2516CTO
[ 33.150654] Modules linked in: ebtable_filter ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc acpi_cpufreq mperf cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats kvm_intel kvm binfmt_misc fuse ext2 loop snd_hda_codec_hdmi snd_hda_codec_conexant arc4 ecb thinkpad_acpi i915 snd_hda_intel iwlagn snd_hda_codec snd_hwdep snd_pcm mac80211 drm_kms_helper drm snd_seq snd_timer psmouse i2c_i801 btusb snd_seq_device bluetooth ac cfg80211 evdev tpm_tis snd serio_raw rfkill i2c_algo_bit tpm battery power_supply nvram wmi i2c_core tpm_bios soundcore snd_page_alloc button processor video ext4 mbcache jbd2 crc16 sha256_generic aesni_intel cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ahci libahci ehci_hcd libata usbcore scsi_mod e1000e thermal thermal_sys [last unloaded: scsi_wait_scan]
[ 33.167207] Pid: 2279, comm: ebtables Not tainted 2.6.39-rc1+ #11
[ 33.169998] Call Trace:
[ 33.172814] [<ffffffff81041be9>] ? warn_slowpath_common+0x78/0x8c
[ 33.175723] [<ffffffffa04d7801>] ? xt_compat_calc_jump+0x6f/0x7a [x_tables]
[ 33.178549] [<ffffffffa0526d54>] ? compat_do_replace+0x125/0x22f [ebtables]
[ 33.181370] [<ffffffffa05273a0>] ? compat_do_ebt_set_ctl+0x55/0xb9 [ebtables]
[ 33.184240] [<ffffffff810337e3>] ? need_resched+0x1a/0x23
[ 33.187055] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 33.189805] [<ffffffff81314d25>] ? _cond_resched+0x9/0x20
[ 33.192578] [<ffffffff8131535e>] ? mutex_lock_interruptible+0x18/0x32
[ 33.195385] [<ffffffff8128496b>] ? nf_sockopt_find.clone.1+0xda/0xec
[ 33.198093] [<ffffffff812849f6>] ? compat_nf_sockopt+0x79/0xa5
[ 33.200852] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 33.203618] [<ffffffff81284a53>] ? compat_nf_setsockopt+0x1a/0x1f
[ 33.206291] [<ffffffff8128fb95>] ? compat_ip_setsockopt+0x80/0xa0
[ 33.209001] [<ffffffff81278502>] ? compat_sys_setsockopt+0x1d5/0x204
[ 33.211726] [<ffffffff810337f1>] ? should_resched+0x5/0x24
[ 33.214374] [<ffffffff81314d25>] ? _cond_resched+0x9/0x20
[ 33.217083] [<ffffffff81278905>] ? compat_sys_socketcall+0x148/0x1a7
[ 33.219811] [<ffffffff8131d340>] ? sysenter_dispatch+0x7/0x2e
[ 33.222433] ---[ end trace 96f8ae34f1f5ad81 ]---
-dann
> Thanks
>
> [PATCH] netfilter: fix ebtables
>
> commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations)
> made ebtables not working anymore.
>
> 1) xt_compat_calc_jump() is not an exact match lookup, and
> 2) compat_table_info() has a typo in xt_compat_init_offsets() call
> 3) compat_do_replace() misses a xt_compat_init_offsets() call
>
> Reported-by: dann frazier <dannf@dannf.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/bridge/netfilter/ebtables.c | 3 ++-
> net/netfilter/x_tables.c | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
> index 893669c..c66aa80 100644
> --- a/net/bridge/netfilter/ebtables.c
> +++ b/net/bridge/netfilter/ebtables.c
> @@ -1766,7 +1766,7 @@ static int compat_table_info(const struct ebt_table_info *info,
>
> newinfo->entries_size = size;
>
> - xt_compat_init_offsets(AF_INET, info->nentries);
> + xt_compat_init_offsets(NFPROTO_BRIDGE, info->nentries /* + 4*/);
> return EBT_ENTRY_ITERATE(entries, size, compat_calc_entry, info,
> entries, newinfo);
> }
> @@ -2240,6 +2240,7 @@ static int compat_do_replace(struct net *net, void __user *user,
>
> xt_compat_lock(NFPROTO_BRIDGE);
>
> + xt_compat_init_offsets(NFPROTO_BRIDGE, tmp.nentries);
> ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
> if (ret < 0)
> goto out_unlock;
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index a9adf4c..e6dbec5 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -455,6 +455,7 @@ void xt_compat_flush_offsets(u_int8_t af)
> vfree(xt[af].compat_tab);
> xt[af].compat_tab = NULL;
> xt[af].number = 0;
> + xt[af].cur = 0;
> }
> }
> EXPORT_SYMBOL_GPL(xt_compat_flush_offsets);
> @@ -473,6 +474,8 @@ int xt_compat_calc_jump(u_int8_t af, unsigned int offset)
> else
> return mid ? tmp[mid - 1].delta : 0;
> }
> + if (left)
> + return tmp[left - 1].delta;
> WARN_ON_ONCE(1);
> return 0;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: shutdown oops in xt_compat_calc_jump
From: Eric Dumazet @ 2011-04-06 16:44 UTC (permalink / raw)
To: dann frazier; +Cc: Patrick McHardy, netdev, netfilter-devel@vger.kernel.org
In-Reply-To: <20110406162547.GA3064@dannf.org>
Le mercredi 06 avril 2011 à 10:25 -0600, dann frazier a écrit :
> Thanks Eric. Unfortunately that didn't solve the problem I am seeing.
> I rebaselined (same kernel build as before), and found that I'm able
> to reproduce this 100% of the time by running only:
>
> sudo ebtables -t filter --init-table
>
> The backtrace I received was this:
Oh yeah, I forgot to remove the WARN_ON_ONCE(1) at the end of
xt_compat_calc_jump()
I focused on restoring ebtables (for example ebtables -A INPUT ...)
Just ignore the warning for the time being ;)
# ebtables -A INPUT -p arp -s 00:01:02:03:04:05 -j ACCEPT
# ebtables -A INPUT -p arp -s 00:01:02:03:04:06 -j ACCEPT
# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 2, policy: ACCEPT
-p ARP -s 0:1:2:3:4:5 -j ACCEPT
-p ARP -s 0:1:2:3:4:6 -j ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: shutdown oops in xt_compat_calc_jump
From: Eric Dumazet @ 2011-04-06 16:49 UTC (permalink / raw)
To: dann frazier; +Cc: Patrick McHardy, netdev, netfilter-devel@vger.kernel.org
In-Reply-To: <1302108258.3209.117.camel@edumazet-laptop>
Le mercredi 06 avril 2011 à 18:44 +0200, Eric Dumazet a écrit :
> Le mercredi 06 avril 2011 à 10:25 -0600, dann frazier a écrit :
>
> > Thanks Eric. Unfortunately that didn't solve the problem I am seeing.
> > I rebaselined (same kernel build as before), and found that I'm able
> > to reproduce this 100% of the time by running only:
> >
> > sudo ebtables -t filter --init-table
> >
> > The backtrace I received was this:
>
>
> Oh yeah, I forgot to remove the WARN_ON_ONCE(1) at the end of
> xt_compat_calc_jump()
>
> I focused on restoring ebtables (for example ebtables -A INPUT ...)
>
> Just ignore the warning for the time being ;)
>
>
> # ebtables -A INPUT -p arp -s 00:01:02:03:04:05 -j ACCEPT
> # ebtables -A INPUT -p arp -s 00:01:02:03:04:06 -j ACCEPT
> # ebtables -L
> Bridge table: filter
>
> Bridge chain: INPUT, entries: 2, policy: ACCEPT
> -p ARP -s 0:1:2:3:4:5 -j ACCEPT
> -p ARP -s 0:1:2:3:4:6 -j ACCEPT
>
> Bridge chain: FORWARD, entries: 0, policy: ACCEPT
>
> Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
>
[PATCH] netfilter: fix ebtables
commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations)
made ebtables not working anymore.
1) xt_compat_calc_jump() is not an exact match lookup
2) compat_table_info() has a typo in xt_compat_init_offsets() call
3) compat_do_replace() misses a xt_compat_init_offsets() call
Reported-by: dann frazier <dannf@dannf.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
V2: remove a comment from V1 (as Patrick suggested)
remove the WARN_ON_ONCE() in xt_compat_calc_jump()
net/bridge/netfilter/ebtables.c | 3 ++-
net/netfilter/x_tables.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 893669c..c66aa80 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1766,7 +1766,7 @@ static int compat_table_info(const struct ebt_table_info *info,
newinfo->entries_size = size;
- xt_compat_init_offsets(AF_INET, info->nentries);
+ xt_compat_init_offsets(NFPROTO_BRIDGE, info->nentries);
return EBT_ENTRY_ITERATE(entries, size, compat_calc_entry, info,
entries, newinfo);
}
@@ -2240,6 +2240,7 @@ static int compat_do_replace(struct net *net, void __user *user,
xt_compat_lock(NFPROTO_BRIDGE);
+ xt_compat_init_offsets(NFPROTO_BRIDGE, tmp.nentries);
ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
if (ret < 0)
goto out_unlock;
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index a9adf4c..8a025a5 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -455,6 +455,7 @@ void xt_compat_flush_offsets(u_int8_t af)
vfree(xt[af].compat_tab);
xt[af].compat_tab = NULL;
xt[af].number = 0;
+ xt[af].cur = 0;
}
}
EXPORT_SYMBOL_GPL(xt_compat_flush_offsets);
@@ -473,8 +474,7 @@ int xt_compat_calc_jump(u_int8_t af, unsigned int offset)
else
return mid ? tmp[mid - 1].delta : 0;
}
- WARN_ON_ONCE(1);
- return 0;
+ return left ? tmp[left - 1].delta : 0;
}
EXPORT_SYMBOL_GPL(xt_compat_calc_jump);
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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 related
* Re: [RFC] ixgbe: is DCA really that good ?
From: Alexander Duyck @ 2011-04-06 17:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Brattain, Ross B, Kirsher, Jeffrey T, netdev
In-Reply-To: <1302097444.3209.85.camel@edumazet-laptop>
On 4/6/2011 6:44 AM, Eric Dumazet wrote:
> Hi guys
>
>
> In a forwarding [or RPS/RFS] setup, why should we populate cpu caches
> with full frames content ? We only need first cache line to perform
> routing [or RPS/RFS] decision.
>
> -> DCA should be a knob (ethtool ?) that an admin can switch off and on,
> port by port, not a CONFIG_IXGBE_DCA thing.
>
> Thanks
The problem is the implementation essentially makes it so that DCA is
controlled by the availability of the DCA providers. What would
probably be the best solution would be for the DCA provider to have a
means of shutting down specific devices.
The quick and dirty way to disable DCA is to rmmod the ioatdma module
from the system. With that removed it will remove the DCA provider and
essentially turn off DCA.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-06 17:05 UTC (permalink / raw)
To: Greg KH
Cc: Grant Likely, Andres Salomon, linux-kernel, Mark Brown, khali,
ben-linux, Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c, linux-media, netdev, spi-devel-general,
Mocean Laboratories
In-Reply-To: <20110406155805.GA20095@suse.de>
Hi Greg,
On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -33,6 +33,7 @@ struct class;
> > struct subsys_private;
> > struct bus_type;
> > struct device_node;
> > +struct mfd_cell;
> >
> > struct bus_attribute {
> > struct attribute attr;
> > @@ -444,6 +445,8 @@ struct device {
> > struct device_node *of_node; /* associated device tree node */
> > const struct of_device_id *of_match; /* matching of_device_id from driver */
> >
> > + struct mfd_cell *mfd_cell; /* MFD cell pointer */
> > +
>
> What is a "MFD cell pointer" and why is it needed in struct device?
An MFD cell is an MFD instantiated device.
MFD (Multi Function Device) drivers instantiate platform devices. Those
devices drivers sometimes need a platform data pointer, sometimes an MFD
specific pointer, and sometimes both. Also, some of those drivers have been
implemented as MFD sub drivers, while others know nothing about MFD and just
expect a plain platform_data pointer.
We've been faced with the problem of being able to pass both MFD related data
and a platform_data pointer to some of those drivers. Squeezing the MFD bits
in the sub driver platform_data pointer doesn't work for drivers that know
nothing about MFDs. It also adds an additional dependency on the MFD API to
all MFD sub drivers. That prevents any of those drivers to eventually be used
as plain platform device drivers.
So, adding an MFD cell pointer to the device structure allows us to cleanly
pass both pieces of information, while keeping all the MFD sub drivers
independant from the MFD core if they want/can.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: mourning the loss of David Brownell
From: Tony Lindgren @ 2011-04-06 17:11 UTC (permalink / raw)
To: Jidong Xiao
Cc: Sarah Sharp, Alan Stern, Greg KH, Oliver Neukum, Bill Gatliff,
Kernel development list, USB list, linux-omap, spi-devel-general,
netdev
In-Reply-To: <BANLkTikRJ+fBRJYfH=LEJk6dt58Gdk61Zg@mail.gmail.com>
* Jidong Xiao <jidong.xiao@gmail.com> [110405 20:33]:
> >
> Me too. David and the other developers you mentioned here helped me a
> lot. So sad, he is so young.
Dave certainly contributed a lot and helped many people.
He also helped a lot with omap development.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Ben Hutchings @ 2011-04-06 17:16 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Greg KH, Grant Likely, Andres Salomon, linux-kernel, Mark Brown,
khali, ben-linux, Peter Korsgaard, Mauro Carvalho Chehab,
David Brownell, linux-i2c, linux-media, netdev, spi-devel-general,
Mocean Laboratories
In-Reply-To: <20110406170537.GB2757@sortiz-mobl>
On Wed, 2011-04-06 at 19:05 +0200, Samuel Ortiz wrote:
> Hi Greg,
>
> On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -33,6 +33,7 @@ struct class;
> > > struct subsys_private;
> > > struct bus_type;
> > > struct device_node;
> > > +struct mfd_cell;
> > >
> > > struct bus_attribute {
> > > struct attribute attr;
> > > @@ -444,6 +445,8 @@ struct device {
> > > struct device_node *of_node; /* associated device tree node */
> > > const struct of_device_id *of_match; /* matching of_device_id from driver */
> > >
> > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */
> > > +
> >
> > What is a "MFD cell pointer" and why is it needed in struct device?
> An MFD cell is an MFD instantiated device.
> MFD (Multi Function Device) drivers instantiate platform devices. Those
> devices drivers sometimes need a platform data pointer, sometimes an MFD
> specific pointer, and sometimes both. Also, some of those drivers have been
> implemented as MFD sub drivers, while others know nothing about MFD and just
> expect a plain platform_data pointer.
>
> We've been faced with the problem of being able to pass both MFD related data
> and a platform_data pointer to some of those drivers. Squeezing the MFD bits
> in the sub driver platform_data pointer doesn't work for drivers that know
> nothing about MFDs. It also adds an additional dependency on the MFD API to
> all MFD sub drivers. That prevents any of those drivers to eventually be used
> as plain platform device drivers.
> So, adding an MFD cell pointer to the device structure allows us to cleanly
> pass both pieces of information, while keeping all the MFD sub drivers
> independant from the MFD core if they want/can.
Why isn't an MFD the parent of its component devices?
Ben.
--
Ben Hutchings, Senior Software 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: [PATCH v2 net-next 3/9] tg3: Reintroduce 5717_PLUS
From: Matt Carlson @ 2011-04-06 17:33 UTC (permalink / raw)
To: Joe Perches; +Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1302067853.1683.29.camel@Joe-Laptop>
On Tue, Apr 05, 2011 at 10:30:53PM -0700, Joe Perches wrote:
> On Tue, 2011-04-05 at 17:22 -0700, Matt Carlson wrote:
> > This patch reintroduces the TG3_FLG3_5717_PLUS to identify 5717 and
> > later devices.
> []
> > @@ -13427,8 +13422,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
> []
> > + if (tp->tg3_flags3 & TG3_FLG3_5717_PLUS)
> > tp->tg3_flags3 |= TG3_FLG3_LRG_PROD_RING_CAP;
>
> This seems redundant. Maybe consolidate to just
> TG3_FLG3_5717_PLUS and remove LRG_PROD_RING_CAP?
>
> I don't know if these attributes really are linked.
>
> Another option may be to use DECLARE_BITMAP
> and set_bit/test_bit so there's no real need
> to use FLAG/FLG2/FLG3, etc.
A while back, I submitted a patch that extended the rx ring sizes for
those devices that were capable. Dave Miller commented that he didn't
think the additional buffering was benefitial and in fact had a
downside. (Larger ring sizes will result in more inefficient cache
usage.)
To fix the problem, the driver will need to be able to easily identify
which devices support the larger ring sizes. This patch represents a
step in that direction. Follow-on patches will make more use of the
flag, which should justify its existence.
For the record though, I did consider using the TG3_FLG3_5717_PLUS flag.
I'm uncomfortable with using it here because this is more of a server
class device feature. Should another mobile or desktop device be
created in the future, I'd have to devise this type of flag to identify
what feature I'm really talking about. I thought it prudent to just
take care of that now.
(Not that this is a compelling argument, but it also is a handy way to
enable and disable the feature while debugging.)
^ permalink raw reply
* Re: [PATCH 01/20] net-core: extending (hw_/wanted_/vlan_)features fields to a bitmap.
From: Mahesh Bandewar @ 2011-04-06 17:34 UTC (permalink / raw)
To: Michał Mirosław; +Cc: David Miller, netdev
In-Reply-To: <BANLkTik3Uz_zu5qev1bc=mop4fUTYGZaDQ@mail.gmail.com>
On Wed, Apr 6, 2011 at 3:29 AM, Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/4/6 Mahesh Bandewar <maheshb@google.com>:
>> Converting current use of (hw_/wanted_/vlan_)features to
>> legacy_(hw_/wanted_/vlan_)features to differntiate from the proposed usage.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> ---
>> include/linux/netdevice.h | 110 +++++++++++++++++++++++++++++++-------------
>> net/core/dev.c | 51 +++++++++++----------
>> net/core/ethtool.c | 97 ++++++++++++++++++++-------------------
>> net/core/net-sysfs.c | 4 +-
>> net/core/sock.c | 2 +-
>> 5 files changed, 155 insertions(+), 109 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 09d2624..637bf2a 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -980,6 +980,42 @@ struct net_device_ops {
>> u32 features);
>> };
>>
>> +enum netdev_features {
>> + NETIF_F_SG_BIT, /* Scatter/gather IO. */
>> + NETIF_F_IP_CSUM_BIT, /* Can checksum TCP/UDP over IPv4. */
>> + NETIF_F_NO_CSUM_BIT, /* Does not require checksum. F.e. loopack. */
>> + NETIF_F_HW_CSUM_BIT, /* Can checksum all the packets. */
>> + NETIF_F_IPV6_CSUM_BIT, /* Can checksum TCP/UDP over IPV6 */
>> + NETIF_F_HIGHDMA_BIT, /* Can DMA to high memory. */
>> + NETIF_F_FRAGLIST_BIT, /* Scatter/gather IO. */
>> + NETIF_F_HW_VLAN_TX_BIT, /* Transmit VLAN hw acceleration */
>> + NETIF_F_HW_VLAN_RX_BIT, /* Receive VLAN hw acceleration */
>> + NETIF_F_HW_VLAN_FILTER_BIT, /* Receive filtering on VLAN */
>> + NETIF_F_VLAN_CHALLENGED_BIT, /* Device cannot handle VLAN packets */
>> + NETIF_F_GSO_BIT, /* Enable software GSO. */
>> + NETIF_F_LLTX_BIT, /* LockLess TX - deprecated. Please */
>> + /* do not use LLTX in new drivers */
>> + NETIF_F_NETNS_LOCAL_BIT, /* Does not change network namespaces */
>> + NETIF_F_GRO_BIT, /* Generic receive offload */
>> + NETIF_F_LRO_BIT, /* large receive offload */
>> + /* the GSO_MASK reserves bits 16 through 23 */
>> + RESERVED1_BIT,
>> + RESERVED2_BIT,
>> + RESERVED3_BIT,
>> + RESERVED4_BIT,
>> + RESERVED5_BIT,
>> + RESERVED6_BIT,
>> + RESERVED7_BIT,
>> + RESERVED8_BIT,
>> + NETIF_F_FCOE_CRC_BIT, /* FCoE CRC32 */
>> + NETIF_F_SCTP_CSUM_BIT, /* SCTP checksum offload */
>> + NETIF_F_FCOE_MTU_BIT, /* Supports max FCoE MTU, 2158 bytes*/
>> + NETIF_F_NTUPLE_BIT, /* N-tuple filters supported */
>> + NETIF_F_RXHASH_BIT, /* Receive hashing offload */
>> + NETIF_F_RXCSUM_BIT, /* Receive checksumming offload */
>> + NETIF_F_NOCACHE_COPY_BIT, /* Use no-cache copyfromuser */
>> +};
>> +
>
> This should be a separate cleanup patch. And after that, for the
> conversion you would add as a last entry:
> NETIF_F_NUM_BITS and use it later (see below).
>
I like the idea of NETIF_F_NUM_BITS and I'll change the #defines
accordingly. Couple of bitmaps are defined in this patch and NUM_BITS
will be required to define those bitmaps. This is reason why I have
defined above enum now rather than waiting for the cleanup phase. Also
it should not change radically in that time span.
>> /*
>> * The DEVICE structure.
>> * Actually, this whole structure is a big mistake. It mixes I/O
>> @@ -1029,44 +1065,51 @@ struct net_device {
>> struct list_head napi_list;
>> struct list_head unreg_list;
>>
>> +#define DEV_FEATURE_WORDS 2
>> +#define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*sizeof(long)*BITS_PER_BYTE)
>> +#define LEGACY_FEATURE_WORD 0
>> +
>
> #define DEV_FEATURE_WORDS BITS_TO_LONGS(NETIF_F_NUM_BITS)
> #define DEV_FEATURE_BITS (DEV_FEATURE_WORDS*BITS_PER_LONG)
>
Yes, this is good!
> Though using bitmaps will make a mess for 32 versus 64 bit archs. It
> would be better to stick to u32 as the base type instead of long.
>
Once it's a bitmap; type shouldn't matter and each arch and it's
specific macros/inlines should handle them properly, no?
(I changed the base type since DECLARE_BITMAP() declares 'unsigned
long' and we can make use of readily avaialble set/test/clear_bit
macros)
> [...]
>> @@ -2376,13 +2419,13 @@ static inline void netif_tx_unlock_bh(struct net_device *dev)
>> }
>>
>> #define HARD_TX_LOCK(dev, txq, cpu) { \
>> - if ((dev->features & NETIF_F_LLTX) == 0) { \
>> + if ((dev->legacy_features & NETIF_F_LLTX) == 0) { \
> [...]
>
> For those type of conversion there is really no point in using the
> macro. Changing it to
> dev->features[0] instead of dev->legacy_features needs the same effort
> but avoids the
> cleanup later. Flags in other feature words could have names line
> NETIF_F2_xxx so that
> it would be clear in which word they belong.
>
I know! But changing all at once in zillion places is hard. This will
let us make changes progressively. I'm expecting the following
progress path -
(1) (Current patch)
+ #define legacy_feactures features
+ #define legacy_vlan_features vlan_features
Slowly make all the changes (relatively easy but a lengthy process!).
So the places where vlan_features, features fields are used will
compile and at the same time updates, where legacy_vlan_features,
legacy_features fields are used, will compile too. Once all is changes
are in place -
(2) Relatively small change
- unsigned long features;
+ DECLARE_BITMAP(feature, DEV_FEATURE_BITS);
- unsigned long vlan_features;
+ DECLARE_BITMAP(vlan_feature, DEV_FEATURE_BITS);
- #define legacy_features features
+ #define legacy_features feature[0]
- #define legacy_vlan_features vlan_features
+ #define legacy_vlan_features vlan_feature[0]
At this moment old fields are gone and are replaced by the bitmaps and
the legacy usage is indicated by the use "legacy_*" fields. This
should eventually be changed to use the (set/test/clear)_bit()
macros/inlines. So the above place should look like -
#define HARD_TX_LOCK(dev, txq, cpu) { \
- if ((dev->legacy_features & NETIF_F_LLTX) == 0) { \
+ if (!test_bit(dev->feature, NETIF_F_LLTX_BIT) { \
Thanks,
--mahesh..
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Samuel Ortiz @ 2011-04-06 17:51 UTC (permalink / raw)
To: Ben Hutchings
Cc: Greg KH, Grant Likely, Andres Salomon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Mocean Laboratories
In-Reply-To: <1302110209.2840.20.camel@bwh-desktop>
Hi Ben,
On Wed, Apr 06, 2011 at 06:16:49PM +0100, Ben Hutchings wrote:
> > So, adding an MFD cell pointer to the device structure allows us to cleanly
> > pass both pieces of information, while keeping all the MFD sub drivers
> > independant from the MFD core if they want/can.
>
> Why isn't an MFD the parent of its component devices?
It actually is. How would that help here ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Greg KH @ 2011-04-06 17:56 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Grant Likely, Andres Salomon, linux-kernel, Mark Brown, khali,
ben-linux, Peter Korsgaard, Mauro Carvalho Chehab, David Brownell,
linux-i2c, linux-media, netdev, spi-devel-general,
Mocean Laboratories
In-Reply-To: <20110406170537.GB2757@sortiz-mobl>
On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote:
> Hi Greg,
>
> On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote:
> > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -33,6 +33,7 @@ struct class;
> > > struct subsys_private;
> > > struct bus_type;
> > > struct device_node;
> > > +struct mfd_cell;
> > >
> > > struct bus_attribute {
> > > struct attribute attr;
> > > @@ -444,6 +445,8 @@ struct device {
> > > struct device_node *of_node; /* associated device tree node */
> > > const struct of_device_id *of_match; /* matching of_device_id from driver */
> > >
> > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */
> > > +
> >
> > What is a "MFD cell pointer" and why is it needed in struct device?
> An MFD cell is an MFD instantiated device.
> MFD (Multi Function Device) drivers instantiate platform devices. Those
> devices drivers sometimes need a platform data pointer, sometimes an MFD
> specific pointer, and sometimes both. Also, some of those drivers have been
> implemented as MFD sub drivers, while others know nothing about MFD and just
> expect a plain platform_data pointer.
That sounds like a bug in those drivers, why not fix them to properly
pass in the correct pointer?
> We've been faced with the problem of being able to pass both MFD related data
> and a platform_data pointer to some of those drivers. Squeezing the MFD bits
> in the sub driver platform_data pointer doesn't work for drivers that know
> nothing about MFDs. It also adds an additional dependency on the MFD API to
> all MFD sub drivers. That prevents any of those drivers to eventually be used
> as plain platform device drivers.
Then they shouldn't be "plain" platform drivers, that should only be
reserved for drivers that are the "lowest" type. Just make them MFD
devices and go from there.
> So, adding an MFD cell pointer to the device structure allows us to cleanly
> pass both pieces of information, while keeping all the MFD sub drivers
> independant from the MFD core if they want/can.
They shouldn't be "independant", make them "dependant" and go from
there.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ipv6: Enable RFS sk_rxhash tracking for ipv6 sockets
From: Neil Horman @ 2011-04-06 17:54 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
properly record sk_rxhash in ipv6 sockets
Noticed while working on another project that flows to sockets which I had open
on a test systems weren't getting steered properly when I had RFS enabled.
Looking more closely I found that:
1) The affected sockets were all ipv6
2) They weren't getting steered because sk->sk_rxhash was never set from the
incomming skbs on that socket.
This was occuring because there are several points in the IPv4 tcp and udp code
which save the rxhash value when a new connection is established. Those calls
to sock_rps_save_rxhash were never added to the corresponding ipv6 code paths.
This patch adds those calls. Tested by myself to properly enable RFS
functionalty on ipv6.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
CC: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
CC: Patrick McHardy <kaber@trash.net>
---
net/ipv6/tcp_ipv6.c | 4 +++-
net/ipv6/udp.c | 2 ++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 2b0c186..97917bb 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1621,6 +1621,7 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
opt_skb = skb_clone(skb, GFP_ATOMIC);
if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */
+ sock_rps_save_rxhash(sk, skb->rxhash);
if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len))
goto reset;
if (opt_skb)
@@ -1648,7 +1649,8 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
__kfree_skb(opt_skb);
return 0;
}
- }
+ } else
+ sock_rps_save_rxhash(sk, skb->rxhash);
if (tcp_rcv_state_process(sk, skb, tcp_hdr(skb), skb->len))
goto reset;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index d7037c0..aa3e327 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -505,6 +505,8 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
int rc;
int is_udplite = IS_UDPLITE(sk);
+ sock_rps_save_rxhash(sk, skb->rxhash);
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
--
1.7.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