* Re: SO_BINDTODEVICE inconsistency between IPv4 and IPv6
From: David Woodhouse @ 2011-05-27 23:07 UTC (permalink / raw)
To: netdev; +Cc: Yuniverg, Michael, Yedvab, Nadav
In-Reply-To: <1300357750.2589.46.camel@macbook.infradead.org>
On Thu, 2011-03-17 at 10:29 +0000, David Woodhouse wrote:
> We've discovered strange behaviour when we listen on in6addr_any and use
> SO_BINDTODEVICE to bind to the lo device.
>
> We can connect to any IPv4 address that is local to the machine, on any
> interface. (This is true whether we listen on AF_INET6/in6addr_any and
> accept IPv4 connections on the IPv6 socket, or whether we just listen on
> AF_INET/INADDR_ANY).
>
> The IPv6 behaviour is different — the only IPv6 address that we can
> connect to is ::1.
Michael, Nadav ― did you ever get any further with this?
--
dwmw2
^ permalink raw reply
* Re: Section conflict compile failures in net
From: James Bottomley @ 2011-05-27 23:04 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David Miller
In-Reply-To: <20110527080728.GA2108@rere.qmqm.pl>
On Fri, 2011-05-27 at 10:07 +0200, Michał Mirosław wrote:
> On Thu, May 26, 2011 at 04:39:53PM -0500, James Bottomley wrote:
> > I'm now getting a ton of errors like this in git head:
> >
> > CC [M] drivers/net/3c59x.o
> > CC [M] drivers/net/hp100.o
> > CC [M] drivers/net/ne3210.o
> > CC [M] drivers/net/3c509.o
> > CC [M] drivers/net/depca.o
> > drivers/net/ne3210.c:83: error: irq_map causes a section type conflict
> > drivers/net/ne3210.c:85: error: shmem_map causes a section type conflict
> > drivers/net/ne3210.c:89: error: ifmap_val causes a section type conflict
> > drivers/net/ne3210.c:319: error: ne3210_ids causes a section type conflict
> > make[2]: *** [drivers/net/ne3210.o] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> > drivers/net/hp100.c:198: error: hp100_eisa_tbl causes a section type conflict
> > drivers/net/hp100.c:211: error: hp100_pci_tbl causes a section type conflict
> > make[2]: *** [drivers/net/hp100.o] Error 1
> > drivers/net/depca.c:544: error: de1xx_irq causes a section type conflict
> > drivers/net/depca.c:545: error: de2xx_irq causes a section type conflict
> > drivers/net/depca.c:546: error: de422_irq causes a section type conflict
> [...]
>
> Those three are only used in depca_hw_init() marked __devinit. What compiler
> [flags] do you use to build this?
It's a standard debian one.
jejb@ion> hppa64-linux-gnu-gcc -v
Using built-in specs.
Target: hppa64-linux-gnu
Configured with: ../src/configure --enable-languages=c --prefix=/usr
--libexecdir=/usr/lib --disable-shared --disable-nls --disable-threads
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libssp
--with-as=/usr/bin/hppa64-linux-gnu-as
--with-ld=/usr/bin/hppa64-linux-gnu-ld
--includedir=/usr/hppa64-linux-gnu/include --host=hppa-linux-gnu
--build=hppa-linux-gnu --target=hppa64-linux-gnu
Thread model: single
gcc version 4.2.4 (Debian 4.2.4-6)
the problem is definitely the depca_irq[i] in the loop ... replace that
with a constant and the error goes away.
James
^ permalink raw reply
* Re: [Bugme-new] [Bug 36012] New: Kernel oops in __pskb_pull_tail
From: Andrew Morton @ 2011-05-27 22:34 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: e1000-devel, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110527223030.GA5081@uio.no>
On Sat, 28 May 2011 00:30:30 +0200
"Steinar H. Gunderson" <sgunderson@bigfoot.com> wrote:
> On Fri, May 27, 2011 at 03:17:15PM -0700, Andrew Morton wrote:
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
>
> Just for reference; this happens to me every time I file a bug. Should I just
> send it right to netdev@ the next time?
Yes please.
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [Bugme-new] [Bug 36012] New: Kernel oops in __pskb_pull_tail
From: Steinar H. Gunderson @ 2011-05-27 22:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, e1000-devel
In-Reply-To: <20110527151715.a9888b74.akpm@linux-foundation.org>
On Fri, May 27, 2011 at 03:17:15PM -0700, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
Just for reference; this happens to me every time I file a bug. Should I just
send it right to netdev@ the next time?
> Steinar's kernel went splat. e1000 might be implicated. It's a
> 2.6.38->2.6.39 regression.
af_packet might also be implicated (it shows up there in the background).
There's always a tcpdump running in the background (for
http://tcpmeasure.sesse.net/), which might be why I see this and nobody else
seems to have done yet.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: [Bugme-new] [Bug 35992] New: Regression: oops when using a bridge interface with tg3
From: Andrew Morton @ 2011-05-27 22:21 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, bzed, Stephen Hemminger, bridge
In-Reply-To: <bug-35992-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
2.6.38->2.6.39 regression, appears to be bridge-related. There's a
partial screencap of the oops linked below.
Bernd, it would be helpful if you could set the screen to more rows
(50?) and then retake that photo. Documentation/svga.txt might help
out. Thanks.
On Fri, 27 May 2011 15:28:17 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=35992
>
> Summary: Regression: oops when using a bridge interface with
> tg3
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.39
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: bzed@debian.org
> Regression: Yes
>
>
> Created an attachment (id=59712)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=59712)
> backtrace image
>
> Using a bridge interface with
> - eth0 from a Tigeon3 card (Broadcom Corporation NetXtreme BCM5704 Gigabit
> Ethernet [14e4:1648] (rev 10))
> - 3 veth interfaces from LXC
> results in a kernel oops on 2.6.39. Up and until 2.6.38.7 I did not run into
> the issue.
>
> Unfortunately I'm only able to provide a screenshot or a part of the backtrace
> as I don't have a proper serial console available.
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
^ permalink raw reply
* Re: [Bugme-new] [Bug 36012] New: Kernel oops in __pskb_pull_tail
From: Andrew Morton @ 2011-05-27 22:17 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, sgunderson, bugzilla-daemon, bugme-daemon
In-Reply-To: <bug-36012-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
Steinar's kernel went splat. e1000 might be implicated. It's a
2.6.38->2.6.39 regression.
On Fri, 27 May 2011 18:21:35 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=36012
>
> Summary: Kernel oops in __pskb_pull_tail
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.39
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: sgunderson@bigfoot.com
> Regression: Yes
>
>
> Hi,
>
> After upgrade from 2.6.38 to 2.6.39, my machine oopses several times a day. It
> doesn't actually _store_ the oops anywhere, but I was able to grab the
> following off the serial console:
>
>
> login: [ 251.133115] k_sesse: Features changed: 0x00006800 -> 0x00006000
> [ 251.350035] k_magne: Features changed: 0x00006800 -> 0x00006000
> [ 251.390897] k_trygve: Features changed: 0x00006800 -> 0x00006000
> [ 251.430429] k_klette: Features changed: 0x00006800 -> 0x00006000
> [ 251.471081] k_berge: Features changed: 0x00006800 -> 0x00006000
> [ 251.521415] k_sessesveits: Features changed: 0x00006800 -> 0x00006000
> [ 309.602872] ------------[ cut here ]------------
> [ 309.607739] kernel BUG at net/core/skbuff.c:1192!
> [ 309.612687] invalid opcode: 0000 [#1] SMP
> [ 309.617143] last sysfs file:
> /sys/devices/system/cpu/cpu15/cache/index2/shared_cpu_map
> [ 309.625499] CPU 0
> [ 309.627380] Modules linked in: sha256_generic cryptd aes_x86_64 aes_generic
> af_packet microcode ext4 jbd2 crc16 ext2 fuse dm_crypt coretemp w83627ehf
> hwmon_vid ip_gre gre ide_generic ide_gd_mod ide_cd_mod cdrom forcedeth psmouse
> rtc_cmos pcspkr serio_raw rtc_core i2c_i801 rtc_lib ghes evdev i2c_core hed
> ext3 jbd mbcache dm_mod raid456 async_pq async_xor xor async_memcpy
> async_raid6_recov raid6_pq async_tx raid1 md_mod usbhid ide_pci_generic
> ide_core uhci_hcd ata_piix e1000e ehci_hcd sd_mod unix [last unloaded:
> scsi_wait_scan]
> [ 309.679212]
> [ 309.685934] Pid: 0, comm: swapper Not tainted 2.6.39 #1 Supermicro
> X8DTL/X8DTL
> [ 309.693763] RIP: 0010:[<ffffffff8126ca5f>] [<ffffffff8126ca5f>]
> __pskb_pull_tail+0x82/0x29d
> [ 309.702700] RSP: 0018:ffff88063fa03610 EFLAGS: 00010282
> [ 309.708249] RAX: 00000000fffffff2 RBX: ffff8805e53e32e0 RCX:
> ffff880604310a00
> [ 309.715622] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> ffff8805e53e32e0
> [ 309.722986] RBP: ffff88063fa03650 R08: ffffffff8126c070 R09:
> ffff88060431090a
> [ 309.730356] R10: ffff880638a9afc0 R11: ffff880638a9afc0 R12:
> 0000000000000004
> [ 309.737723] R13: 000000000000000c R14: ffff880638030640 R15:
> ffff880638030000
> [ 309.745098] FS: 0000000000000000(0000) GS:ffff88063fa00000(0000)
> knlGS:0000000000000000
> [ 309.753624] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 309.759609] CR2: 00007fa662685788 CR3: 0000000001549000 CR4:
> 00000000000006f0
> [ 309.766979] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 309.774350] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 309.781728] Process swapper (pid: 0, threadinfo ffffffff814f6000, task
> ffffffff81551020)
> [ 309.790255] Stack:
> [ 309.792510] ffff880600000000 ffffffffa00baa20 0000005600000056
> ffff8805e53e32e0
> [ 309.800581] 0000000000000036 000000000000000c ffff880638030640
> ffff880638030000
> [ 309.808642] ffff88063fa03700 ffffffffa00b3acb ffff88063fa03680
> ffffffff8126c070
> [ 309.816708] Call Trace:
> [ 309.819394] <IRQ>
> [ 309.821810] [<ffffffffa00b3acb>] e1000_xmit_frame+0xce/0x9ff [e1000e]
> [ 309.828575] [<ffffffff8126c070>] ? __kfree_skb+0x78/0x7c
> [ 309.834213] [<ffffffff8126c0d1>] ? consume_skb+0x5d/0x62
> [ 309.839850] [<ffffffffa02d530e>] ? packet_rcv+0x309/0x31b [af_packet]
> [ 309.846615] [<ffffffff81274e31>] dev_hard_start_xmit+0x419/0x58e
> [ 309.852952] [<ffffffff8128ac8d>] sch_direct_xmit+0x67/0x18d
> [ 309.858846] [<ffffffff812752d2>] dev_queue_xmit+0x32c/0x4ec
> [ 309.864741] [<ffffffff812a1e92>] ip_finish_output+0x250/0x293
> [ 309.870811] [<ffffffff812a1f73>] ip_output+0x9e/0xa5
> [ 309.876100] [<ffffffff812a1312>] ip_local_out+0x24/0x28
> [ 309.881655] [<ffffffff812a186f>] ip_queue_xmit+0x2d8/0x31e
> [ 309.887467] [<ffffffff8126a7cd>] ? __skb_clone+0x29/0xf2
> [ 309.893102] [<ffffffff812b2f1b>] tcp_transmit_skb+0x76c/0x7aa
> [ 309.899176] [<ffffffff812b568f>] tcp_write_xmit+0x806/0x8f5
> [ 309.905068] [<ffffffff812b2377>] ? tcp_established_options+0x2e/0xa9
> [ 309.911750] [<ffffffff812b57cf>] __tcp_push_pending_frames+0x20/0x7c
> [ 309.918430] [<ffffffff812b19be>] tcp_rcv_established+0x104/0x5fe
> [ 309.924762] [<ffffffff810ce02d>] ? kfree+0x55/0xf1
> [ 309.929881] [<ffffffff812b88d6>] tcp_v4_do_rcv+0x1b0/0x380
> [ 309.935689] [<ffffffff810ce02d>] ? kfree+0x55/0xf1
> [ 309.940807] [<ffffffff810cdea2>] ? kmem_cache_free+0x1b/0xcf
> [ 309.946793] [<ffffffff81140064>] ? security_sock_rcv_skb+0x11/0x13
> [ 309.953297] [<ffffffff812b8f7b>] tcp_v4_rcv+0x4d5/0x7fc
> [ 309.958851] [<ffffffff812c1f94>] ? icmp_rcv+0x214/0x255
> [ 309.964407] [<ffffffff8129d3f4>] ip_local_deliver_finish+0xfb/0x1a6
> [ 309.971002] [<ffffffff8129d511>] ip_local_deliver+0x72/0x79
> [ 309.976898] [<ffffffff8129d06f>] ip_rcv_finish+0x27f/0x2a9
> [ 309.982703] [<ffffffff8129d2d3>] ip_rcv+0x23a/0x260
> [ 309.987907] [<ffffffff81273a79>] __netif_receive_skb+0x4e2/0x514
> [ 309.994237] [<ffffffff81273db5>] netif_receive_skb+0x67/0x6e
> [ 310.000220] [<ffffffff81273e9a>] napi_skb_finish+0x24/0x3c
> [ 310.006032] [<ffffffff8127437e>] napi_gro_receive+0xa8/0xad
> [ 310.011929] [<ffffffffa00b4cb3>] e1000_receive_skb+0x62/0x6d [e1000e]
> [ 310.018699] [<ffffffffa00b4eec>] e1000_clean_rx_irq+0x22e/0x2c3 [e1000e]
> [ 310.025723] [<ffffffffa00b649a>] e1000_clean+0x75/0x23b [e1000e]
> [ 310.032052] [<ffffffff8105e5e1>] ? clockevents_program_event+0x75/0x7e
> [ 310.038908] [<ffffffff812744b7>] net_rx_action+0xa7/0x215
> [ 310.044634] [<ffffffff8103e950>] __do_softirq+0xc1/0x180
> [ 310.050276] [<ffffffff8101a22e>] ? ack_apic_level+0x6d/0x1af
> [ 310.056262] [<ffffffff8133a5cc>] call_softirq+0x1c/0x30
> [ 310.061817] [<ffffffff81002feb>] do_softirq+0x33/0x68
> [ 310.067196] [<ffffffff8103e6da>] irq_exit+0x3f/0x88
> [ 310.072399] [<ffffffff810028d1>] do_IRQ+0x98/0xaf
> [ 310.077435] [<ffffffff81333353>] common_interrupt+0x13/0x13
> [ 310.083335] <EOI>
> [ 310.085739] [<ffffffff81335f30>] ? notifier_call_chain+0x32/0x5e
> [ 310.092073] [<ffffffff8102a0fc>] ? update_rq_clock+0x1d/0x39
> [ 310.098062] [<ffffffff8119aca9>] ? intel_idle+0xc3/0xe9
> [ 310.103615] [<ffffffff8119ac8c>] ? intel_idle+0xa6/0xe9
> [ 310.109174] [<ffffffff81259912>] cpuidle_idle_call+0x112/0x1b4
> [ 310.115333] [<ffffffff810012d4>] cpu_idle+0x5a/0x91
> [ 310.120538] [<ffffffff81320fa4>] rest_init+0x68/0x6a
> [ 310.125826] [<ffffffff815afb80>] start_kernel+0x345/0x350
> [ 310.131551] [<ffffffff815af2a8>] x86_64_start_reservations+0xb8/0xbc
> [ 310.138227] [<ffffffff815af399>] x86_64_start_kernel+0xed/0xf4
> [ 310.144382] Code: ff 85 c0 0f 85 2c 02 00 00 8b 93 c0 00 00 00 8b 73 68 48
> 03 93 c8 00 00 00 2b 73 6c 44 89 e1 48 89 df e8 19 e0 ff ff 85 c0 74 04 <0f> 0b
> eb fe 8b 83 c4 00 00 00 48 03 83 c8 00 00 00 4c 8b 68 10
> [ 310.167752] RIP [<ffffffff8126ca5f>] __pskb_pull_tail+0x82/0x29d
> [ 310.174141] RSP <ffff88063fa03610>
> [ 310.178190] ---[ end trace bc3a706445eef1e2 ]---
> [ 310.183223] Kernel panic - not syncing: Fatal exception in interrupt
> [ 310.190105] Pid: 0, comm: swapper Tainted: G D 2.6.39 #1
> [ 310.196683] Call Trace:
> [ 310.199565] <IRQ> [<ffffffff81330476>] panic+0x8c/0x188
> [ 310.205910] [<ffffffff81333fa6>] oops_end+0x81/0x8e
> [ 310.211368] [<ffffffff81004051>] die+0x55/0x5e
> [ 310.216423] [<ffffffff81333a85>] do_trap+0x11c/0x12b
> [ 310.222024] [<ffffffff810023e4>] do_invalid_op+0x91/0x9a
> [ 310.227981] [<ffffffff8126ca5f>] ? __pskb_pull_tail+0x82/0x29d
> [ 310.234424] [<ffffffff8126ca5b>] ? __pskb_pull_tail+0x7e/0x29d
> [ 310.240902] [<ffffffff8133a355>] invalid_op+0x15/0x20
> [ 310.246607] [<ffffffff8126c070>] ? __kfree_skb+0x78/0x7c
> [ 310.252565] [<ffffffff8126ca5f>] ? __pskb_pull_tail+0x82/0x29d
> [ 310.259033] [<ffffffffa00b3acb>] e1000_xmit_frame+0xce/0x9ff [e1000e]
> [ 310.266104] [<ffffffff8126c070>] ? __kfree_skb+0x78/0x7c
> [ 310.272054] [<ffffffff8126c0d1>] ? consume_skb+0x5d/0x62
> [ 310.278005] [<ffffffffa02d530e>] ? packet_rcv+0x309/0x31b [af_packet]
> [ 310.285083] [<ffffffff81274e31>] dev_hard_start_xmit+0x419/0x58e
> [ 310.291739] [<ffffffff8128ac8d>] sch_direct_xmit+0x67/0x18d
> [ 310.297954] [<ffffffff812752d2>] dev_queue_xmit+0x32c/0x4ec
> [ 310.304160] [<ffffffff812a1e92>] ip_finish_output+0x250/0x293
> [ 310.310552] [<ffffffff812a1f73>] ip_output+0x9e/0xa5
> [ 310.316152] [<ffffffff812a1312>] ip_local_out+0x24/0x28
> [ 310.322015] [<ffffffff812a186f>] ip_queue_xmit+0x2d8/0x31e
> [ 310.328134] [<ffffffff8126a7cd>] ? __skb_clone+0x29/0xf2
> [ 310.334083] [<ffffffff812b2f1b>] tcp_transmit_skb+0x76c/0x7aa
> [ 310.340468] [<ffffffff812b568f>] tcp_write_xmit+0x806/0x8f5
> [ 310.346681] [<ffffffff812b2377>] ? tcp_established_options+0x2e/0xa9
> [ 310.353674] [<ffffffff812b57cf>] __tcp_push_pending_frames+0x20/0x7c
> [ 310.360664] [<ffffffff812b19be>] tcp_rcv_established+0x104/0x5fe
> [ 310.367273] [<ffffffff810ce02d>] ? kfree+0x55/0xf1
> [ 310.372686] [<ffffffff812b88d6>] tcp_v4_do_rcv+0x1b0/0x380
> [ 310.378794] [<ffffffff810ce02d>] ? kfree+0x55/0xf1
> [ 310.384218] [<ffffffff810cdea2>] ? kmem_cache_free+0x1b/0xcf
> [ 310.390459] [<ffffffff81140064>] ? security_sock_rcv_skb+0x11/0x13
> [ 310.397284] [<ffffffff812b8f7b>] tcp_v4_rcv+0x4d5/0x7fc
> [ 310.403119] [<ffffffff812c1f94>] ? icmp_rcv+0x214/0x255
> [ 310.408983] [<ffffffff8129d3f4>] ip_local_deliver_finish+0xfb/0x1a6
> [ 310.415893] [<ffffffff8129d511>] ip_local_deliver+0x72/0x79
> [ 310.422097] [<ffffffff8129d06f>] ip_rcv_finish+0x27f/0x2a9
> [ 310.428222] [<ffffffff8129d2d3>] ip_rcv+0x23a/0x260
> [ 310.433742] [<ffffffff81273a79>] __netif_receive_skb+0x4e2/0x514
> [ 310.440390] [<ffffffff81273db5>] netif_receive_skb+0x67/0x6e
> [ 310.446619] [<ffffffff81273e9a>] napi_skb_finish+0x24/0x3c
> [ 310.452664] [<ffffffff8127437e>] napi_gro_receive+0xa8/0xad
> [ 310.458823] [<ffffffffa00b4cb3>] e1000_receive_skb+0x62/0x6d [e1000e]
> [ 310.465843] [<ffffffffa00b4eec>] e1000_clean_rx_irq+0x22e/0x2c3 [e1000e]
> [ 310.473124] [<ffffffffa00b649a>] e1000_clean+0x75/0x23b [e1000e]
> [ 310.479701] [<ffffffff8105e5e1>] ? clockevents_program_event+0x75/0x7e
> [ 310.486800] [<ffffffff812744b7>] net_rx_action+0xa7/0x215
> [ 310.492785] [<ffffffff8103e950>] __do_softirq+0xc1/0x180
> [ 310.498668] [<ffffffff8101a22e>] ? ack_apic_level+0x6d/0x1af
> [ 310.504897] [<ffffffff8133a5cc>] call_softirq+0x1c/0x30
> [ 310.510694] [<ffffffff81002feb>] do_softirq+0x33/0x68
> [ 310.516324] [<ffffffff8103e6da>] irq_exit+0x3f/0x88
> [ 310.521764] [<ffffffff810028d1>] do_IRQ+0x98/0xaf
> [ 310.527035] [<ffffffff81333353>] common_interrupt+0x13/0x13
> [ 310.533170] <EOI> [<ffffffff81335f30>] ? notifier_call_chain+0x32/0x5e
> [ 310.540639] [<ffffffff8102a0fc>] ? update_rq_clock+0x1d/0x39
> [ 310.546874] [<ffffffff8119aca9>] ? intel_idle+0xc3/0xe9
> [ 310.552662] [<ffffffff8119ac8c>] ? intel_idle+0xa6/0xe9
> [ 310.558455] [<ffffffff81259912>] cpuidle_idle_call+0x112/0x1b4
> [ 310.564878] [<ffffffff810012d4>] cpu_idle+0x5a/0x91
> [ 310.570327] [<ffffffff81320fa4>] rest_init+0x68/0x6a
> [ 310.575862] [<ffffffff815afb80>] start_kernel+0x345/0x350
> [ 310.581848] [<ffffffff815af2a8>] x86_64_start_reservations+0xb8/0xbc
> [ 310.588787] [<ffffffff815af399>] x86_64_start_kernel+0xed/0xf4
> [ 310.595456] Rebooting in 60 seconds..
>
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Kernel crash after using new Intel NIC (igb)
From: Arun Sharma @ 2011-05-27 21:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arun Sharma, David Miller, Maximilian Engelhardt, linux-kernel,
netdev, StuStaNet Vorstand, Yann Dupont, Denys Fedoryshchenko,
Ingo Molnar, Thomas Gleixner
In-Reply-To: <1306526219.2533.3.camel@edumazet-laptop>
On Fri, May 27, 2011 at 09:56:59PM +0200, Eric Dumazet wrote:
> >
> > This looks very similar to atomic_add_unless(). If we had a
> >
> > __atomic_add_unless() that returned "old", we could then do:
> >
> > atomic_add_unless() { return __atomic_add_unless() != u }
> > atomic_add_unless_return() { return __atomic_add_unless() + a}
> >
>
> Sure !
>
> I preferred to not touch lot of files in kernel (atomic_add_unless() is
> defined in several files) because its a stable candidate patch (2.6.36+)
>
> So a cleanup patch for 2.6.40+ is certainly doable, do you want to do
> this ?
The attached works for me for x86_64. Cc'ing Ingo/Thomas for comment.
-Arun
atomic: Refactor atomic_add_unless
Commit 686a7e3 (inetpeer: fix race in unused_list manipulations)
in net-2.6 added a atomic_add_unless_return() variant that tries
to detect 0->1 transitions of an atomic reference count.
This sounds like a generic functionality that could be expressed
in terms of an __atomic_add_unless() that returned the old value
instead of a bool.
Signed-off-by: Arun Sharma <asharma@fb.com>
---
arch/x86/include/asm/atomic.h | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index 952a826..bbdbffe 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -221,15 +221,15 @@ static inline int atomic_xchg(atomic_t *v, int new)
}
/**
- * atomic_add_unless - add unless the number is already a given value
+ * __atomic_add_unless - add unless the number is already a given value
* @v: pointer of type atomic_t
* @a: the amount to add to v...
* @u: ...unless v is equal to u.
*
* Atomically adds @a to @v, so long as @v was not already @u.
- * Returns non-zero if @v was not @u, and zero otherwise.
+ * Returns the old value of v
*/
-static inline int atomic_add_unless(atomic_t *v, int a, int u)
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
{
int c, old;
c = atomic_read(v);
@@ -241,7 +241,21 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)
break;
c = old;
}
- return c != (u);
+ return c;
+}
+
+/**
+ * atomic_add_unless - add unless the number is already a given value
+ * @v: pointer of type atomic_t
+ * @a: the amount to add to v...
+ * @u: ...unless v is equal to u.
+ *
+ * Atomically adds @a to @v, so long as @v was not already @u.
+ * Returns non-zero if @v was not @u, and zero otherwise.
+ */
+static inline int atomic_add_unless(atomic_t *v, int a, int u)
+{
+ return __atomic_add_unless(v, a, u) != u;
}
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
--
1.7.4
^ permalink raw reply related
* Re: [PATCHv4] ethtool: Added FW dump support
From: Ben Hutchings @ 2011-05-27 20:47 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: netdev, David Miller
In-Reply-To: <DA112A8D-1B47-4826-AC58-772C88FF21FC@qlogic.com>
On Fri, 2011-05-27 at 13:31 -0700, Anirban Chakraborty wrote:
> On May 12, 2011, at 3:48 PM, Anirban Chakraborty wrote:
>
> > Added support to take FW dump via ethtool.
> >
> > Changes since v3:
> > Updated documentation for ethtool_dump data structure
> >
> > Changes from v2:
> > Folded get dump flag and data into one option
> > Added man page support
> >
> > Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> > ---
> > ethtool-copy.h | 24 +++++++++++-
> > ethtool.8.in | 23 +++++++++++
> > ethtool.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > 3 files changed, 156 insertions(+), 3 deletions(-)
> >
> > diff --git a/ethtool-copy.h b/ethtool-copy.h
> > <snip>
>
> Ben,
>
> I was wondering if you'd applied the above patch. Thanks.
No, but it's at the front of my queue and I'll probably get to it next
week.
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: [PATCHv4] ethtool: Added FW dump support
From: Anirban Chakraborty @ 2011-05-27 20:31 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: netdev, Ben Hutchings, David Miller
In-Reply-To: <1305240515-29237-1-git-send-email-anirban.chakraborty@qlogic.com>
On May 12, 2011, at 3:48 PM, Anirban Chakraborty wrote:
> Added support to take FW dump via ethtool.
>
> Changes since v3:
> Updated documentation for ethtool_dump data structure
>
> Changes from v2:
> Folded get dump flag and data into one option
> Added man page support
>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> ---
> ethtool-copy.h | 24 +++++++++++-
> ethtool.8.in | 23 +++++++++++
> ethtool.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 156 insertions(+), 3 deletions(-)
>
> diff --git a/ethtool-copy.h b/ethtool-copy.h
> <snip>
Ben,
I was wondering if you'd applied the above patch. Thanks.
Anirban
^ permalink raw reply
* Re: [GIT PULL] Namespace file descriptors for 2.6.40
From: C Anthony Risinger @ 2011-05-27 20:18 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Serge E. Hallyn, Linux Containers, netdev, linux-kernel
In-Reply-To: <m17h9e1h9e.fsf@fess.ebiederm.org>
On Wed, May 25, 2011 at 6:40 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> C Anthony Risinger <anthony@xtfx.me> writes:
>
>> On Wed, May 25, 2011 at 4:38 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
>>> Quoting C Anthony Risinger (anthony@xtfx.me):
>>>> On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
>>>> <ebiederm@xmission.com> wrote:
>>>> >
>>>> > This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
>>>> > /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
>>>> > process at the time those files are opened, and can be bind mounted to
>>>> > keep the specified namespace alive without a process.
>>>> >
>>>> > This tree adds the setns system call that can be used to change the
>>>> > specified namespace of a process to the namespace specified by a system
>>>> > call.
>>>>
>>>> i just have a quick question regarding these, apologies if wrong place
>>>> to respond -- i trimmed to lists only.
>>>>
>>>> if i understand correctly, mount namespaces (for example), allow one
>>>> to build such constructs as "private /tmp" and similar that even
>>>> `root` cannot access ... and there are many reasons `root` does not
>>>> deserve to completely know/interact with user processes (FUSE makes a
>>>> good example ... just because i [user] have SSH access to a machine,
>>>> why should `root`?)
>>>>
>>>> would these /proc additions break such guarantees? IOW, would it now
>>>> become possible for `root` to inject stuff into my private namespaces,
>>>> and/or has these guarantees never existed and i am mistaken? is there
>>>> any kind of ACL mechanism that endows the origin process (or similar)
>>>> with the ability to dictate who can hold and/or interact with these
>>>> references?
>>>
>>> If for instance you have a file open in your private /tmp, then root
>>> in another mounts ns can open the file through /proc/$$/fd/N anyway.
>>> If it's a directory, he can now traverse the whole fs.
>>
>> aaah right :-( ... there's always another way isn't there ... curse
>> you Linux for being so flexible! (just kidding baby i love you)
>
> Even more significant the access to the new files is guarded by the
> ptrace access checks. And if root can ptrace your process root
> can remote control your process.
>
>> this seems like a more fundamental issue then? or should i not expect
>> to be able to achieve separation like this? i ask in the context of
>> OS virt via cgroups + namespaces, eg. LXC et al, because i'm about to
>> perform a massive overhaul to our crusty sub-2.6.18 infrastructure and
>> i've used/followed these technologies for couple years now ... and
>> it's starting to feel like "the right time".
>
> I don't think anything really new is allowed, but we haven't designed
> anything that radically reduces the power of root either.
>
> At some point we may have the user namespace done and that should
> give you a root like user with vastly reduced powers, but we aren't
> there yet.
ok -- i knew there was some user namespace work still left for a
namespaced root -- i was specifically thinking of the root user in the
host. i was under the impression that namespaces could achieve
separation even from the host (save the kernel itself) ... but it
seems i was mistaken ... still much to learn about Linux i suppose,
even though i use it everyday for years and years :-) it kind of
makes sense i guess, since maybe the host needs supervisory powers
over the guests? could be some merit for real separation in the
future (not only malevolent root host user, but say an attacker/script
that manages to break thru container?), though how possible i dont
know. i wouldnt expect the root user to be prevented from killing/etc
the container, but maybe only prevented from snooping, eg. the
container looks like a black box that he may only resource control or
kill completely. either way, what we have is just fine for my (and
likely many other's) uses.
anyways, thanks for all the answers and all the work on
namespacing/cgroups ... very useful constructs for a wide array of
problems.
--
C Anthony
^ permalink raw reply
* Re: [PATCH 1/2 v2] af-packet: Use existing netdev reference for bound sockets.
From: Ben Greear @ 2011-05-27 20:18 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110527.161542.568477840432205227.davem@davemloft.net>
On 05/27/2011 01:15 PM, David Miller wrote:
> From: Eric Dumazet<eric.dumazet@gmail.com>
> Date: Fri, 27 May 2011 22:08:41 +0200
>
>> Le jeudi 26 mai 2011 à 21:11 -0700, Ben Greear a écrit :
>>> On 05/26/2011 08:42 PM, Eric Dumazet wrote:
>>>> Le jeudi 26 mai 2011 à 16:55 -0700, greearb@candelatech.com a écrit :
>>>
>>>>> out_free:
>>>>> kfree_skb(skb);
>>>>> out_unlock:
>>>>> - if (dev)
>>>>> + if (dev&& need_rls_dev)
>>>>> dev_put(dev);
>>>>> out:
>>>>> return err;
>>>>
>>>> Hmmm, I wonder why you want this Ben.
>>>>
>>>> IMHO this is buggy, because we can sleep in this function.
>>>>
>>>> We must take a ref on device (its really cheap these days, now we have a
>>>> percpu device refcnt)
>>>
>>> Why must you take the reference? And if we must, why isn't the
>>> current code that assigns the prot_hook.dev without taking a
>>> reference OK?
>>>
>>
>> If we sleep, device can disappear under us.
>>
>> The only way to not take a reference is to hold rcu_read_lock(), but
>> you're not allowed to sleep under rcu_read_lock().
>
> You still have not addresses Ben's point.
>
> Why is it ok for the po->prot_hook.dev handling to not take a
> reference? It's been doing this forever. Ben is just borrowing this
> behavior for his uses.
>
> After some more research I think it happens to be OK because
> ->prot_hook.dev is used _only_ for pointer comparisons, it is never
> actually dereferenced or used in any other way. Probably, we should
> just use ->ifindex for this.
It's easy enough to add a dev_hold() when I assign the skb instead
of looking it up in my patch, but perhaps it would be cleaner over all to
just hold a ref on the prot_hook.dev when it is originally assigned?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/2 v2] af-packet: Use existing netdev reference for bound sockets.
From: David Miller @ 2011-05-27 20:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <1306526921.2533.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 May 2011 22:08:41 +0200
> Le jeudi 26 mai 2011 à 21:11 -0700, Ben Greear a écrit :
>> On 05/26/2011 08:42 PM, Eric Dumazet wrote:
>> > Le jeudi 26 mai 2011 à 16:55 -0700, greearb@candelatech.com a écrit :
>>
>> >> out_free:
>> >> kfree_skb(skb);
>> >> out_unlock:
>> >> - if (dev)
>> >> + if (dev&& need_rls_dev)
>> >> dev_put(dev);
>> >> out:
>> >> return err;
>> >
>> > Hmmm, I wonder why you want this Ben.
>> >
>> > IMHO this is buggy, because we can sleep in this function.
>> >
>> > We must take a ref on device (its really cheap these days, now we have a
>> > percpu device refcnt)
>>
>> Why must you take the reference? And if we must, why isn't the
>> current code that assigns the prot_hook.dev without taking a
>> reference OK?
>>
>
> If we sleep, device can disappear under us.
>
> The only way to not take a reference is to hold rcu_read_lock(), but
> you're not allowed to sleep under rcu_read_lock().
You still have not addresses Ben's point.
Why is it ok for the po->prot_hook.dev handling to not take a
reference? It's been doing this forever. Ben is just borrowing this
behavior for his uses.
After some more research I think it happens to be OK because
->prot_hook.dev is used _only_ for pointer comparisons, it is never
actually dereferenced or used in any other way. Probably, we should
just use ->ifindex for this.
^ permalink raw reply
* Re: [PATCH 1/2 v2] af-packet: Use existing netdev reference for bound sockets.
From: Eric Dumazet @ 2011-05-27 20:08 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4DDF2463.3020001@candelatech.com>
Le jeudi 26 mai 2011 à 21:11 -0700, Ben Greear a écrit :
> On 05/26/2011 08:42 PM, Eric Dumazet wrote:
> > Le jeudi 26 mai 2011 à 16:55 -0700, greearb@candelatech.com a écrit :
>
> >> out_free:
> >> kfree_skb(skb);
> >> out_unlock:
> >> - if (dev)
> >> + if (dev&& need_rls_dev)
> >> dev_put(dev);
> >> out:
> >> return err;
> >
> > Hmmm, I wonder why you want this Ben.
> >
> > IMHO this is buggy, because we can sleep in this function.
> >
> > We must take a ref on device (its really cheap these days, now we have a
> > percpu device refcnt)
>
> Why must you take the reference? And if we must, why isn't the
> current code that assigns the prot_hook.dev without taking a
> reference OK?
>
If we sleep, device can disappear under us.
The only way to not take a reference is to hold rcu_read_lock(), but
you're not allowed to sleep under rcu_read_lock().
> It seems a waste to do the lookup and free if we don't have to,
> and with thousands of devices, the lookup might take a reasonable
> amount of effort?
I understand you want to avoid the lookup, this part is fine for me, but
you need to take a reference on the device before eventual sleep.
Nowadays its a single "inc" instruction on x86, without even a lock
prefix (this on a percpu integer)
^ permalink raw reply
* Re: Kernel crash after using new Intel NIC (igb)
From: Eric Dumazet @ 2011-05-27 19:56 UTC (permalink / raw)
To: Arun Sharma
Cc: David Miller, Maximilian Engelhardt, linux-kernel, netdev,
StuStaNet Vorstand, Yann Dupont, Denys Fedoryshchenko
In-Reply-To: <4DDFE4D6.4010000@fb.com>
Le vendredi 27 mai 2011 à 10:52 -0700, Arun Sharma a écrit :
> On 5/26/11 8:27 PM, Eric Dumazet wrote:
>
> Looks good. Thanks for taking care of this.
>
> > +static bool atomic_add_unless_return(atomic_t *ptr, int a, int u, int *newv)
> > +{
> > + int cur, old = atomic_read(ptr);
> > +
> > + while (old != u) {
> > + *newv = old + a;
> > + cur = atomic_cmpxchg(ptr, old, *newv);
> > + if (cur == old)
> > + return true;
> > + old = cur;
> > + }
> > + return false;
> > +}
>
> This looks very similar to atomic_add_unless(). If we had a
>
> __atomic_add_unless() that returned "old", we could then do:
>
> atomic_add_unless() { return __atomic_add_unless() != u }
> atomic_add_unless_return() { return __atomic_add_unless() + a}
>
Sure !
I preferred to not touch lot of files in kernel (atomic_add_unless() is
defined in several files) because its a stable candidate patch (2.6.36+)
So a cleanup patch for 2.6.40+ is certainly doable, do you want to do
this ?
Thanks
^ permalink raw reply
* pull request: wireless-2.6 2011-05-27
From: John W. Linville @ 2011-05-27 19:50 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
This is a quick batch of fixes intended for 2.6.40. They are all
small(-ish), and several of them fix either build breakage or some
sort of regression. At least one fixes an uninitialized variable
that could potentially cause a crash.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit c5c177b4aca83338781e72be2e6dd1601c560cb3:
net: Kill ratelimit.h dependency in linux/net.h (2011-05-27 13:41:33 -0400)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git for-davem
Adrian Chadd (1):
ath9k: Fix AR9287 calibration
Eliad Peller (1):
mac80211: clear local->ps_data on disassoc
Jesper Juhl (1):
mac80211: Remove duplicate linux/slab.h include from net/mac80211/scan.c
John W. Linville (1):
Merge git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Larry Finger (2):
rtlwifi: Fix kernel panic resulting from RX buffer allocation failure
rtlwifi: Use order 2 RX buffer allocation only if necessary
Luciano Coelho (1):
nl80211: fix check for valid SSID size in scan operations
Rafał Miłecki (1):
b43: N-PHY: initialize last var in calibration function
Rajkumar Manoharan (4):
ath9k: Reset chip on baseband hang
ath9k_hw: disable phy restart on baseband panic caused by RXSM
ath9k: set 40 Mhz rate only if hw is configured in ht40
mac80211: stop queues before rate control updation
Stanislaw Gruszka (1):
iwl4965: fix 5GHz operation
Tao Ma (1):
wireless: Default to 'n' for 2 new added devices in Kconfig.
Yogesh Ashok Powar (1):
mwifiex: correct event header length
drivers/net/wireless/ath/ath9k/Kconfig | 1 -
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 22 +++++++++++++++
drivers/net/wireless/ath/ath9k/hw.c | 5 +++-
drivers/net/wireless/ath/ath9k/hw.h | 2 +
drivers/net/wireless/ath/ath9k/main.c | 4 ++-
drivers/net/wireless/ath/ath9k/rc.c | 3 +-
drivers/net/wireless/b43/phy_n.c | 2 +-
drivers/net/wireless/iwlegacy/iwl-4965-lib.c | 4 +-
drivers/net/wireless/mwifiex/sdio.h | 4 +-
drivers/net/wireless/rt2x00/Kconfig | 1 -
drivers/net/wireless/rtlwifi/pci.c | 35 +++++++++++++++---------
net/mac80211/mlme.c | 7 +++++
net/mac80211/scan.c | 1 -
net/wireless/nl80211.c | 4 +-
15 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index d9ff841..d9c08c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -26,7 +26,6 @@ config ATH9K
config ATH9K_PCI
bool "Atheros ath9k PCI/PCIe bus support"
depends on ATH9K && PCI
- default PCI
---help---
This option enables the PCI bus support in ath9k.
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 015d974..2d4c091 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -829,7 +829,7 @@ static bool ar9002_hw_init_cal(struct ath_hw *ah, struct ath9k_channel *chan)
if (AR_SREV_9271(ah)) {
if (!ar9285_hw_cl_cal(ah, chan))
return false;
- } else if (AR_SREV_9285_12_OR_LATER(ah)) {
+ } else if (AR_SREV_9285(ah) && AR_SREV_9285_12_OR_LATER(ah)) {
if (!ar9285_hw_clc(ah, chan))
return false;
} else {
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index eee23ec..892c48b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1381,3 +1381,25 @@ void ar9003_hw_bb_watchdog_dbg_info(struct ath_hw *ah)
"==== BB update: done ====\n\n");
}
EXPORT_SYMBOL(ar9003_hw_bb_watchdog_dbg_info);
+
+void ar9003_hw_disable_phy_restart(struct ath_hw *ah)
+{
+ u32 val;
+
+ /* While receiving unsupported rate frame rx state machine
+ * gets into a state 0xb and if phy_restart happens in that
+ * state, BB would go hang. If RXSM is in 0xb state after
+ * first bb panic, ensure to disable the phy_restart.
+ */
+ if (!((MS(ah->bb_watchdog_last_status,
+ AR_PHY_WATCHDOG_RX_OFDM_SM) == 0xb) ||
+ ah->bb_hang_rx_ofdm))
+ return;
+
+ ah->bb_hang_rx_ofdm = true;
+ val = REG_READ(ah, AR_PHY_RESTART);
+ val &= ~AR_PHY_RESTART_ENA;
+
+ REG_WRITE(ah, AR_PHY_RESTART, val);
+}
+EXPORT_SYMBOL(ar9003_hw_disable_phy_restart);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 72543ce..1be7c8b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1555,9 +1555,12 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
if (ah->btcoex_hw.enabled)
ath9k_hw_btcoex_enable(ah);
- if (AR_SREV_9300_20_OR_LATER(ah))
+ if (AR_SREV_9300_20_OR_LATER(ah)) {
ar9003_hw_bb_watchdog_config(ah);
+ ar9003_hw_disable_phy_restart(ah);
+ }
+
ath9k_hw_apply_gpio_override(ah);
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 57435ce..4b157c5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -842,6 +842,7 @@ struct ath_hw {
u32 bb_watchdog_last_status;
u32 bb_watchdog_timeout_ms; /* in ms, 0 to disable */
+ u8 bb_hang_rx_ofdm; /* true if bb hang due to rx_ofdm */
unsigned int paprd_target_power;
unsigned int paprd_training_power;
@@ -990,6 +991,7 @@ void ar9002_hw_enable_wep_aggregation(struct ath_hw *ah);
void ar9003_hw_bb_watchdog_config(struct ath_hw *ah);
void ar9003_hw_bb_watchdog_read(struct ath_hw *ah);
void ar9003_hw_bb_watchdog_dbg_info(struct ath_hw *ah);
+void ar9003_hw_disable_phy_restart(struct ath_hw *ah);
void ar9003_paprd_enable(struct ath_hw *ah, bool val);
void ar9003_paprd_populate_single_table(struct ath_hw *ah,
struct ath9k_hw_cal_data *caldata,
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a198ee3..2ca351f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -670,7 +670,8 @@ void ath9k_tasklet(unsigned long data)
u32 status = sc->intrstatus;
u32 rxmask;
- if (status & ATH9K_INT_FATAL) {
+ if ((status & ATH9K_INT_FATAL) ||
+ (status & ATH9K_INT_BB_WATCHDOG)) {
ath_reset(sc, true);
return;
}
@@ -737,6 +738,7 @@ irqreturn_t ath_isr(int irq, void *dev)
{
#define SCHED_INTR ( \
ATH9K_INT_FATAL | \
+ ATH9K_INT_BB_WATCHDOG | \
ATH9K_INT_RXORN | \
ATH9K_INT_RXEOL | \
ATH9K_INT_RX | \
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 1754221..ba7f36a 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -689,7 +689,8 @@ static void ath_rc_rate_set_series(const struct ath_rate_table *rate_table,
if (WLAN_RC_PHY_HT(rate_table->info[rix].phy)) {
rate->flags |= IEEE80211_TX_RC_MCS;
- if (WLAN_RC_PHY_40(rate_table->info[rix].phy))
+ if (WLAN_RC_PHY_40(rate_table->info[rix].phy) &&
+ conf_is_ht40(&txrc->hw->conf))
rate->flags |= IEEE80211_TX_RC_40_MHZ_WIDTH;
if (WLAN_RC_PHY_SGI(rate_table->info[rix].phy))
rate->flags |= IEEE80211_TX_RC_SHORT_GI;
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 9ed6515..05960dd 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3093,7 +3093,7 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev *dev,
int freq;
bool avoid = false;
u8 length;
- u16 tmp, core, type, count, max, numb, last, cmd;
+ u16 tmp, core, type, count, max, numb, last = 0, cmd;
const u16 *table;
bool phy6or5x;
diff --git a/drivers/net/wireless/iwlegacy/iwl-4965-lib.c b/drivers/net/wireless/iwlegacy/iwl-4965-lib.c
index 7e5e85a..a7a4739 100644
--- a/drivers/net/wireless/iwlegacy/iwl-4965-lib.c
+++ b/drivers/net/wireless/iwlegacy/iwl-4965-lib.c
@@ -628,11 +628,11 @@ void iwl4965_rx_reply_rx(struct iwl_priv *priv,
/* rx_status carries information about the packet to mac80211 */
rx_status.mactime = le64_to_cpu(phy_res->timestamp);
+ rx_status.band = (phy_res->phy_flags & RX_RES_PHY_FLAGS_BAND_24_MSK) ?
+ IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
rx_status.freq =
ieee80211_channel_to_frequency(le16_to_cpu(phy_res->channel),
rx_status.band);
- rx_status.band = (phy_res->phy_flags & RX_RES_PHY_FLAGS_BAND_24_MSK) ?
- IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
rx_status.rate_idx =
iwl4965_hwrate_to_mac80211_idx(rate_n_flags, rx_status.band);
rx_status.flag = 0;
diff --git a/drivers/net/wireless/mwifiex/sdio.h b/drivers/net/wireless/mwifiex/sdio.h
index a0e9bc5..4e97e90 100644
--- a/drivers/net/wireless/mwifiex/sdio.h
+++ b/drivers/net/wireless/mwifiex/sdio.h
@@ -167,8 +167,8 @@
/* Rx unit register */
#define CARD_RX_UNIT_REG 0x63
-/* Event header Len*/
-#define MWIFIEX_EVENT_HEADER_LEN 8
+/* Event header len w/o 4 bytes of interface header */
+#define MWIFIEX_EVENT_HEADER_LEN 4
/* Max retry number of CMD53 write */
#define MAX_WRITE_IOMEM_RETRY 2
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 9def1e5..b2f8b8f 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -166,7 +166,6 @@ config RT2800USB_RT35XX
config RT2800USB_RT53XX
bool "rt2800usb - Include support for rt53xx devices (EXPERIMENTAL)"
depends on EXPERIMENTAL
- default y
---help---
This adds support for rt53xx wireless chipset family to the
rt2800pci driver.
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index a409528..89100e7 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -669,11 +669,6 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
&rx_status,
(u8 *) pdesc, skb);
- pci_unmap_single(rtlpci->pdev,
- *((dma_addr_t *) skb->cb),
- rtlpci->rxbuffersize,
- PCI_DMA_FROMDEVICE);
-
skb_put(skb, rtlpriv->cfg->ops->get_desc((u8 *) pdesc,
false,
HW_DESC_RXPKT_LEN));
@@ -690,6 +685,21 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
hdr = rtl_get_hdr(skb);
fc = rtl_get_fc(skb);
+ /* try for new buffer - if allocation fails, drop
+ * frame and reuse old buffer
+ */
+ new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
+ if (unlikely(!new_skb)) {
+ RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV),
+ DBG_DMESG,
+ ("can't alloc skb for rx\n"));
+ goto done;
+ }
+ pci_unmap_single(rtlpci->pdev,
+ *((dma_addr_t *) skb->cb),
+ rtlpci->rxbuffersize,
+ PCI_DMA_FROMDEVICE);
+
if (!stats.crc || !stats.hwerror) {
memcpy(IEEE80211_SKB_RXCB(skb), &rx_status,
sizeof(rx_status));
@@ -758,15 +768,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
rtl_lps_leave(hw);
}
- new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
- if (unlikely(!new_skb)) {
- RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV),
- DBG_DMESG,
- ("can't alloc skb for rx\n"));
- goto done;
- }
skb = new_skb;
- /*skb->dev = dev; */
rtlpci->rx_ring[rx_queue_idx].rx_buf[rtlpci->
rx_ring
@@ -1113,6 +1115,13 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
rtlpci->rx_ring[rx_queue_idx].idx = 0;
+ /* If amsdu_8k is disabled, set buffersize to 4096. This
+ * change will reduce memory fragmentation.
+ */
+ if (rtlpci->rxbuffersize > 4096 &&
+ rtlpriv->rtlhal.disable_amsdu_8k)
+ rtlpci->rxbuffersize = 4096;
+
for (i = 0; i < rtlpci->rxringcount; i++) {
struct sk_buff *skb =
dev_alloc_skb(rtlpci->rxbuffersize);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 4f6b267..456cccf 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -232,6 +232,9 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
WARN_ON(!ieee80211_set_channel_type(local, sdata, channel_type));
}
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+
/* channel_type change automatically detected */
ieee80211_hw_config(local, 0);
@@ -245,6 +248,9 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
rcu_read_unlock();
}
+ ieee80211_wake_queues_by_reason(&sdata->local->hw,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+
ht_opmode = le16_to_cpu(hti->operation_mode);
/* if bss configuration changed store the new one */
@@ -1089,6 +1095,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
local->hw.conf.flags &= ~IEEE80211_CONF_PS;
config_changed |= IEEE80211_CONF_CHANGE_PS;
}
+ local->ps_sdata = NULL;
ieee80211_hw_config(local, config_changed);
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 27af672..58ffa7d 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -15,7 +15,6 @@
#include <linux/if_arp.h>
#include <linux/rtnetlink.h>
#include <linux/pm_qos_params.h>
-#include <linux/slab.h>
#include <net/sch_generic.h>
#include <linux/slab.h>
#include <net/mac80211.h>
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ec83f41..88a565f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3406,12 +3406,12 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
i = 0;
if (info->attrs[NL80211_ATTR_SCAN_SSIDS]) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS], tmp) {
+ request->ssids[i].ssid_len = nla_len(attr);
if (request->ssids[i].ssid_len > IEEE80211_MAX_SSID_LEN) {
err = -EINVAL;
goto out_free;
}
memcpy(request->ssids[i].ssid, nla_data(attr), nla_len(attr));
- request->ssids[i].ssid_len = nla_len(attr);
i++;
}
}
@@ -3572,6 +3572,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
if (info->attrs[NL80211_ATTR_SCAN_SSIDS]) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS],
tmp) {
+ request->ssids[i].ssid_len = nla_len(attr);
if (request->ssids[i].ssid_len >
IEEE80211_MAX_SSID_LEN) {
err = -EINVAL;
@@ -3579,7 +3580,6 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
}
memcpy(request->ssids[i].ssid, nla_data(attr),
nla_len(attr));
- request->ssids[i].ssid_len = nla_len(attr);
i++;
}
}
--
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 related
* [GIT] Networking
From: David Miller @ 2011-05-27 18:10 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Last networking pull request for this merge window:
1) Fix build regressions in some configurations due to the ratelimited
WARN interfaces, reported by Ingo.
And Ingo also pointed out the ugly ratelimit.h dependency that
linux/net.h has, get rid of that too.
2) Fix races that cause ugly crashes in inetpeer cleanups, from Eric
Dumazet.
3) Namespace fix in IPVS from Hans Schillstrom.
4) ipset bug fixes from Jozsef Kadlecsik, mostly return code corrections
and fixing timeout comparisons with jiffies.
5) ->set_features vs. ->set_flags compatability would accidently truncate
flag values down to a bool, fix from Michał Mirosław.
6) Missing %pK conversions in CAN socket layer from Oliver Hartkopp.
Please pull, thanks a lot!
The following changes since commit a74b81b0aff4a01e0816df5915c854fb52c5e87f:
Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2 (2011-05-26 10:55:15 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Andy Gospodarek (1):
bonding: cleanup module option descriptions
Dan Williams (1):
atm: expose ATM device index in sysfs
David Miller (1):
netfilter: Fix several warnings in compat_mtw_from_user().
David S. Miller (5):
bug.h: Move ratelimit warn interfaces to ratelimit.h
Merge branch 'pablo/nf-2.6-updates' of git://1984.lsi.us.es/net-2.6
net: Kill ether_table[] declaration.
net: Add linux/sysctl.h includes where needed.
net: Kill ratelimit.h dependency in linux/net.h
Eric Dumazet (1):
inetpeer: fix race in unused_list manipulations
Hans Schillstrom (1):
IPVS: bug in ip_vs_ftp, same list heaad used in all netns.
Johan Hovold (1):
net: davinci_emac: fix dev_err use at probe
Jozsef Kadlecsik (3):
netfilter: ipset: Use proper timeout value to jiffies conversion
netfilter: ipset: remove unused variable from type_pf_tdel()
netfilter: ipset: fix ip_set_flush return code
Justin Mattock (1):
net:8021q:vlan.c Fix pr_info to just give the vlan fullname and version.
Michał Mirosław (1):
net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
Oliver Hartkopp (1):
can: convert to %pK for kptr_restrict support
drivers/net/bonding/bond_main.c | 34 ++++++++++++-------
drivers/net/davinci_emac.c | 22 ++++++------
include/asm-generic/bug.h | 40 ----------------------
include/linux/if_ether.h | 4 --
include/linux/net.h | 6 ---
include/linux/netfilter.h | 1 +
include/linux/netfilter/ipset/ip_set_ahash.h | 4 +-
include/linux/netfilter/ipset/ip_set_timeout.h | 18 ++++++----
include/linux/ratelimit.h | 40 ++++++++++++++++++++++
include/net/ip_vs.h | 3 +-
include/net/net_namespace.h | 1 +
include/net/net_ratelimit.h | 8 ++++
net/8021q/vlan.c | 5 +--
net/atm/atm_sysfs.c | 10 ++++++
net/bridge/netfilter/ebtables.c | 6 ++-
net/can/proc.c | 7 ++--
net/core/ethtool.c | 25 +++++++++++++-
net/core/filter.c | 1 +
net/core/sysctl_net_core.c | 1 +
net/core/utils.c | 1 +
net/ipv4/inetpeer.c | 42 +++++++++++++++--------
net/netfilter/ipset/ip_set_core.c | 2 +-
net/netfilter/ipvs/ip_vs_ftp.c | 27 +++++++++++----
23 files changed, 189 insertions(+), 119 deletions(-)
create mode 100644 include/net/net_ratelimit.h
^ permalink raw reply
* Re: Kernel crash after using new Intel NIC (igb)
From: Arun Sharma @ 2011-05-27 17:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Maximilian Engelhardt, linux-kernel, netdev,
StuStaNet Vorstand, Yann Dupont, Denys Fedoryshchenko
In-Reply-To: <1306466831.2543.58.camel@edumazet-laptop>
On 5/26/11 8:27 PM, Eric Dumazet wrote:
Looks good. Thanks for taking care of this.
> +static bool atomic_add_unless_return(atomic_t *ptr, int a, int u, int *newv)
> +{
> + int cur, old = atomic_read(ptr);
> +
> + while (old != u) {
> + *newv = old + a;
> + cur = atomic_cmpxchg(ptr, old, *newv);
> + if (cur == old)
> + return true;
> + old = cur;
> + }
> + return false;
> +}
This looks very similar to atomic_add_unless(). If we had a
__atomic_add_unless() that returned "old", we could then do:
atomic_add_unless() { return __atomic_add_unless() != u }
atomic_add_unless_return() { return __atomic_add_unless() + a}
-Arun
^ permalink raw reply
* Re: Kernel crash after using new Intel NIC (igb)
From: David Miller @ 2011-05-27 17:40 UTC (permalink / raw)
To: eric.dumazet
Cc: asharma, maxi, linux-kernel, netdev, vorstand, Yann.Dupont, denys
In-Reply-To: <1306466831.2543.58.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 May 2011 05:27:11 +0200
> Sure, here is a formal submission I cooked.
>
> Thanks
>
> [PATCH] inetpeer: fix race in unused_list manipulations
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] sctp: fixed missing fixup of sctp_local_addr_free
From: Neil Horman @ 2011-05-27 17:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, vladislav.yasevich, sri, linux-sctp
In-Reply-To: <20110527.134004.1654129007987862831.davem@davemloft.net>
On Fri, May 27, 2011 at 01:40:04PM -0400, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Fri, 27 May 2011 13:37:00 -0400
>
> > commit 1231f0baa547a541a7481119323b7f964dda4788 Converted sctp to use
> > kfree_rcu from sctp_local_addr_free but missed this one call point. Fix it up
> > accordingly.
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> This has been fixed for several days now.
>
> If you're using the net-next-2.6 tree, don't, when it's not active
> it's just a dummy tree for Stephen Rothwell to pull into -next
> and it will be rebuilt as soon as the merge window is over.
>
Ok, copy that, thanks
^ permalink raw reply
* Re: [PATCH 3/3] net: Kill ratelimit.h dependency in linux/net.h
From: David Miller @ 2011-05-27 17:42 UTC (permalink / raw)
To: mingo; +Cc: netdev
In-Reply-To: <20110527084403.GD21386@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Date: Fri, 27 May 2011 10:44:03 +0200
>> diff --git a/include/linux/net.h b/include/linux/net.h
>> index 1da55e9..b299230 100644
>> --- a/include/linux/net.h
>> +++ b/include/linux/net.h
>> @@ -289,11 +289,5 @@ extern int kernel_sock_shutdown(struct socket *sock,
>> MODULE_ALIAS("net-pf-" __stringify(pf) "-proto-" __stringify(proto) \
>> "-type-" __stringify(type))
>>
>> -#ifdef CONFIG_SYSCTL
>> -#include <linux/sysctl.h>
>> -#include <linux/ratelimit.h>
>> -extern struct ratelimit_state net_ratelimit_state;
>> -#endif
>> -
>
> Assuming that this moved into net_ratelimit.h with a guard define
> this looks good to me:
>
> Acked-by: Ingo Molnar <mingo@elte.hu>
Yep, thanks for reviewing!
^ permalink raw reply
* Re: [PATCH] sctp: fixed missing fixup of sctp_local_addr_free
From: David Miller @ 2011-05-27 17:40 UTC (permalink / raw)
To: nhorman; +Cc: netdev, vladislav.yasevich, sri, linux-sctp
In-Reply-To: <1306517820-4793-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 27 May 2011 13:37:00 -0400
> commit 1231f0baa547a541a7481119323b7f964dda4788 Converted sctp to use
> kfree_rcu from sctp_local_addr_free but missed this one call point. Fix it up
> accordingly.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
This has been fixed for several days now.
If you're using the net-next-2.6 tree, don't, when it's not active
it's just a dummy tree for Stephen Rothwell to pull into -next
and it will be rebuilt as soon as the merge window is over.
^ permalink raw reply
* [PATCH] sctp: fixed missing fixup of sctp_local_addr_free
From: Neil Horman @ 2011-05-27 17:37 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, Vlad Yasevich, Sridhar Samudrala, David S. Miller,
linux-sctp
commit 1231f0baa547a541a7481119323b7f964dda4788 Converted sctp to use
kfree_rcu from sctp_local_addr_free but missed this one call point. Fix it up
accordingly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vladislav.yasevich@hp.com>
CC: Sridhar Samudrala <sri@us.ibm.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: linux-sctp@vger.kernel.org
---
net/sctp/bind_addr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
index 6338413..83e3011 100644
--- a/net/sctp/bind_addr.c
+++ b/net/sctp/bind_addr.c
@@ -145,7 +145,7 @@ static void sctp_bind_addr_clean(struct sctp_bind_addr *bp)
/* Empty the bind address list. */
list_for_each_entry_safe(addr, temp, &bp->address_list, list) {
list_del_rcu(&addr->list);
- call_rcu(&addr->rcu, sctp_local_addr_free);
+ kfree_rcu(addr, rcu);
SCTP_DBG_OBJCNT_DEC(addr);
}
}
--
1.7.5.2
^ permalink raw reply related
* Re: [PATCH v2] atm: expose ATM device index in sysfs
From: David Miller @ 2011-05-27 17:07 UTC (permalink / raw)
To: dwmw2; +Cc: eric.dumazet, dcbw, netdev, chas
In-Reply-To: <1306508748.2029.124.camel@i7.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Fri, 27 May 2011 16:05:41 +0100
> On Fri, 2011-05-27 at 16:57 +0200, Eric Dumazet wrote:
>> Le vendredi 27 mai 2011 à 09:51 -0500, Dan Williams a écrit :
>> > It's currently exposed only through /proc which, besides requiring
>> > screen-scraping, doesn't allow userspace to distinguish between two
>> > identical ATM adapters with different ATM indexes. The ATM device index
>> > is required when using PPPoATM on a system with multiple ATM adapters.
>> >
>> > Signed-off-by: Dan Williams <dcbw@redhat.com>
>> > ---
>> >
>>
>> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Tested-by: David Woodhouse <dwmw2@infradead.org>
> Cc: stable@kernel.org
>
> [root@solos atm]# grep ^ /sys/class/atm/*/atmindex
> /sys/class/atm/solos-pci0/atmindex:0
> /sys/class/atm/solos-pci1/atmindex:1
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Michał Mirosław @ 2011-05-27 16:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1306511150.2759.17.camel@bwh-desktop>
On Fri, May 27, 2011 at 04:45:50PM +0100, Ben Hutchings wrote:
> On Fri, 2011-05-27 at 17:28 +0200, Michał Mirosław wrote:
> > On Fri, May 27, 2011 at 03:13:46PM +0100, Ben Hutchings wrote:
> > > On Tue, 2011-05-24 at 23:59 +0200, Michał Mirosław wrote:
> > > > On Tue, May 24, 2011 at 03:39:30PM -0400, David Miller wrote:
> > > > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > > Date: Tue, 24 May 2011 11:14:37 +0200
> > > > > > On Thu, May 19, 2011 at 12:03:31PM +0200, Michał Mirosław wrote:
> > > > > >> On Mon, May 16, 2011 at 02:09:58PM -0400, David Miller wrote:
> > > > > >> > You guys really need to sort this out properly.
> > > > > >> > Please resubmit whatever final solution is agreed upon.
> > > > > >> I noticed that v2.6.39 was tagged today. We should definitely remove
> > > > > >> NETIF_F_COMPAT so it won't bite us in the future. The other patch that
> > > > > >> fixes ethtool_ops->set_flags compatibility is a bugfix, so it should go
> > > > > >> in - if we decide that the SFEATURES compatibility should be removed
> > > > > >> it won't matter.
> > [...]
> > > > We could just wait for 2.6.40 and pretend this code part never existed. ;-)
> > > I think I will make ethtool check for a minimum kernel version of 2.6.40
> > > before using ETHTOOL_{G,S}FEATURES.
> >
> > > > I'll rebase the first patch tomorrow. Without it the compatibility in
> > > > ETHTOOL_SFEATURES for non-converted drivers is busted wrt set_flags.
> > > This is an improvement, but I still think the fallback is fundamentally
> > > broken - there's no good way for userland to tell what (if anything)
> > > went wrong when the return value has ETHTOOL_F_COMPAT set.
> >
> > The same situation happens with ETHTOOL_F_WISH (userspace needs to reread
> > the features to find out what happened) and with old ETHTOOL_S{TSO,SG,...}
> > (those return success if any of the features in the group changes and also
> > posibly disable other features when one is disabled). This wasn't really
> > checked before.
> >
> > Ben, I think I commented on your proposal of the userspace part, but I might
> > have missed some of your arguments about mine. Let's sum those up:
> >
> > Your version:
> > - reimplements ETHTOOL_Sxx via ETHTOOL_SFEATURES in userspace for kernels
> > supporting the latter
> No, it implements 'ethtool -K' using ETHTOOL_SFEATURES. Maybe you
> consider the ethtool utility to be a thin wrapper over the ethtool API,
> but that is not my intent.
You're right. I assumed just that. -K and other modes of operation look
like they are adapting the ETHTOOL_* calls for human consumption.
There's some additional code for analysing register and other dumps,
but I see it as just merging two tools for convenience.
> > (note: ETHTOOL_S{SG,...} are not ever going away)
> > - causes NETIF_F_* to be an ABI
> If feature flag numbers are not stable then what is the point of
> /sys/class/net/<name>/features? Also, I'm not aware that features have
> ever been renumbered in the past.
Since no NETIF_F_* were exported earlier, I assume /sys/class/net/*/features
is a debugging aid. What is it used for besides that?
[...]
> > Both versions are rough at the edges, but working. Both assume that no
> > behaviour changes are to be made for old '-K' options.
> No, my changes are intended to enhance the old options.
Kernel side already enhances them to not forget other features
'wanted' state. What other enhancements are on your mind?
BTW, I just recalled that ETHTOOL_F_WISH is set only as an information
about bits in features[].valid masks. So zero return does not mean, that
other features (not in .valid masks) haven't changed. This means that
userspace needs to reread features after any SFEATURES call, not just
those returning non-zero.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Ben Hutchings @ 2011-05-27 15:45 UTC (permalink / raw)
To: Michał Mirosław; +Cc: David Miller, netdev
In-Reply-To: <20110527152809.GA7620@rere.qmqm.pl>
On Fri, 2011-05-27 at 17:28 +0200, Michał Mirosław wrote:
> On Fri, May 27, 2011 at 03:13:46PM +0100, Ben Hutchings wrote:
> > On Tue, 2011-05-24 at 23:59 +0200, Michał Mirosław wrote:
> > > On Tue, May 24, 2011 at 03:39:30PM -0400, David Miller wrote:
> > > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > Date: Tue, 24 May 2011 11:14:37 +0200
> > > > > On Thu, May 19, 2011 at 12:03:31PM +0200, Michał Mirosław wrote:
> > > > >> On Mon, May 16, 2011 at 02:09:58PM -0400, David Miller wrote:
> > > > >> > You guys really need to sort this out properly.
> > > > >> > Please resubmit whatever final solution is agreed upon.
> > > > >> I noticed that v2.6.39 was tagged today. We should definitely remove
> > > > >> NETIF_F_COMPAT so it won't bite us in the future. The other patch that
> > > > >> fixes ethtool_ops->set_flags compatibility is a bugfix, so it should go
> > > > >> in - if we decide that the SFEATURES compatibility should be removed
> > > > >> it won't matter.
> [...]
> > > We could just wait for 2.6.40 and pretend this code part never existed. ;-)
> > I think I will make ethtool check for a minimum kernel version of 2.6.40
> > before using ETHTOOL_{G,S}FEATURES.
>
> > > I'll rebase the first patch tomorrow. Without it the compatibility in
> > > ETHTOOL_SFEATURES for non-converted drivers is busted wrt set_flags.
> > This is an improvement, but I still think the fallback is fundamentally
> > broken - there's no good way for userland to tell what (if anything)
> > went wrong when the return value has ETHTOOL_F_COMPAT set.
>
> The same situation happens with ETHTOOL_F_WISH (userspace needs to reread
> the features to find out what happened) and with old ETHTOOL_S{TSO,SG,...}
> (those return success if any of the features in the group changes and also
> posibly disable other features when one is disabled). This wasn't really
> checked before.
>
> Ben, I think I commented on your proposal of the userspace part, but I might
> have missed some of your arguments about mine. Let's sum those up:
>
> Your version:
> - reimplements ETHTOOL_Sxx via ETHTOOL_SFEATURES in userspace for kernels
> supporting the latter
No, it implements 'ethtool -K' using ETHTOOL_SFEATURES. Maybe you
consider the ethtool utility to be a thin wrapper over the ethtool API,
but that is not my intent.
> (note: ETHTOOL_S{SG,...} are not ever going away)
> - causes NETIF_F_* to be an ABI
If feature flag numbers are not stable then what is the point of
/sys/class/net/<name>/features? Also, I'm not aware that features have
ever been renumbered in the past.
I think ethtool should maintain a feature bitmask rather than the
separate flags it currently does, and I previously attempted this using
a private set of flags. Shortly afterward that, you proposed to
introduce the new features interfaces, and it seemed to me to make sense
to use the net device feature flags in ethtool.
David, do you think feature flag numbers should be considered a
userspace (i.e. stable) ABI or not?
> - does not support new features
Not immediately. I intend to do that afterward.
> My version:
> - implements only new features via ETHTOOL_SFEATURES (old calls are still used)
> - makes feature names an ABI (for scripts actually, not the tool)
> - supports any new features kernel reports without code changes
Right. I definitely should incorporate your code for looking up
features by string.
> Both versions are rough at the edges, but working. Both assume that no
> behaviour changes are to be made for old '-K' options.
No, my changes are intended to enhance the old options.
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
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