- 29 Mar, 2008 9 commits
-
-
Ingo Molnar authored
While using netconsole on forcedeth, lockdep noticed the following locking bug: ================================= [ INFO: inconsistent lock state ] 2.6.24-rc6 #6 Signed-off-by: Ingo Molnar <mingo@elte.hu> --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. udevd/719 [HC0[0]:SC1[1]:HE1:SE0] takes: (_xmit_ETHER){-+..}, at: [<c043062e>] dev_watchdog+0x1c/0xb9 {softirq-on-W} state was registered at: [<c0147f67>] mark_held_locks+0x4e/0x66 [<c014810e>] trace_hardirqs_on+0xfe/0x136 [<c048ae63>] _spin_unlock_irq+0x22/0x42 [<c02ec617>] nv_start_xmit_optimized+0x347/0x37a [<c042c80d>] netpoll_send_skb+0xa4/0x147 [<c042d4a6>] netpoll_send_udp+0x238/0x242 [<c02f44f6>] write_msg+0x6d/0x9b [<c012c129>] __call_console_drivers+0x4e/0x5a [<c012c18c>] _call_console_drivers+0x57/0x5b [<c012c2dd>] release_console_sem+0x11c/0x1b9 [<c012caeb>] register_console+0x1eb/0x1f3 [<c06ae673>] init_netconsole+0x119/0x15f [<c069149b>] kernel_init+0x147/0x294 [<c01058cb>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff irq event stamp: 950 hardirqs last enabled at (950): [<c048ae63>] _spin_unlock_irq+0x22/0x42 hardirqs last disabled at (949): [<c048aaf7>] _spin_lock_irq+0xc/0x38 softirqs last enabled at (0): [<c012a29c>] copy_process+0x375/0x126d softirqs last disabled at (947): [<c0106d43>] do_softirq+0x61/0xc6 other info that might help us debug this: no locks held by udevd/719. stack backtrace: Pid: 719, comm: udevd Not tainted 2.6.24-rc6 #6 [<c0105c46>] show_trace_log_lvl+0x12/0x25 [<c01063ec>] show_trace+0xd/0x10 [<c010670c>] dump_stack+0x57/0x5f [<c0147505>] print_usage_bug+0x10a/0x117 [<c0147c38>] mark_lock+0x121/0x402 [<c01488b6>] __lock_acquire+0x3d1/0xb64 [<c0149405>] lock_acquire+0x4e/0x6a [<c048a99b>] _spin_lock+0x23/0x32 [<c043062e>] dev_watchdog+0x1c/0xb9 [<c0133e4a>] run_timer_softirq+0x133/0x193 [<c0130907>] __do_softirq+0x78/0xed [<c0106d43>] do_softirq+0x61/0xc6 ======================= eth1: link down The fix is to disable/restore irqs instead of disable/enable. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Ayaz Abdulla <aabdulla@nvidia.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Mike Frysinger authored
The asix usb driver currently depends on NET_ETHERNET which means you cannot enable this driver if you only have 1000mbit enabled in your kernel. Since there is no real dependency between the NET_ETHERNET portion and the asix driver, simply drop it. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Cc: Greg KH <greg@kroah.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Valentine Barshak authored
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of emac_has_feature parameters. Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Michael Ellerman authored
drivers/net/pasemi_mac.c is enabled by CONFIG_PASEMI_MAC, which depends on PPC64 && PCI. However pasemi_mac.c uses several routines that are only built when PPC_PASEMI is selected. This can lead to an unbuildable config: ERROR: ".pasemi_dma_start_chan" [drivers/net/pasemi_mac.ko] undefined! So make CONFIG_PASEMI_MAC depend on PPC_PASEMI instead of PPC64. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Sreenivasa Honnur authored
- Updated version number. - Resubmitting with correct version update. - this patch to be applied for upstream-davem branch Signed-off-by: Surjit Reang <surjit.reang@neterion.com> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
David Brownell authored
Remove superfluous in-atomic() check; ethtool MII ops are called from task context. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Greg KH <greg@kroah.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Peter Korsgaard authored
The loop forgot to walk the net->mc_list list, so only the first multicast address was programmed into the hash table. Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Grant Grundler authored
If "location" is > "addr_len" bits, the high bits of location would interfere with the READ_CMD sent to the eeprom controller. A patch was submitted to bug: http://bugzilla.kernel.org/show_bug.cgi?id=4420 which simply truncated the "location", read whatever was in "location modulo addr_len", and returned that value. That avoids confusing the eeprom but seems like the wrong solution to me. Correct would be to not read beyond "1 << addr_len" address of the eeprom. I am submitting two changes to implement this: 1) tulip_read_eeprom will return zero (since we can't return -EINVAL) if this is attempted (defensive programming). 2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't iterate past addr_len bits and make sure the entire tp->eeprom[] array is cleared. I konw we don't strictly need both. I would prefer both in the tree since it documents the issue and provides a second "defense" from the bug from creeping back in. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
- 28 Mar, 2008 3 commits
-
-
Patrick McHardy authored
LLC currently allows users to inject raw frames, including IP packets encapsulated in SNAP. While Linux doesn't handle IP over SNAP, other systems do. Restrict LLC sockets to root similar to packet sockets. [ Modified Patrick's patch to use CAP_NEW_RAW --DaveM ] Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Based upon a lockdep report. Since ->poll() can be invoked from netpoll with interrupts disabled, we must not unconditionally enable interrupts in napi_complete(). Instead we must use local_irq_{save,restore}(). Noticed by Peter Zijlstra: <irqs disabled> netpoll_poll() poll_napi() spin_trylock(&napi->poll_lock) poll_one_napi() napi->poll() := sky2_poll() napi_complete() local_irq_disable() local_irq_enable() <--- *BUG* <irq> irq_exit() do_softirq() net_rx_action() spin_lock(&napi->poll_lock) <--- Deadlock! Because we still hold the lock.... Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 27 Mar, 2008 5 commits
-
-
Denis V. Lunev authored
This elliminates infamous race during module loading when one could lookup proc entry without proc_fops assigned. Signed-off-by: Denis V. Lunev <den@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thomas Graf authored
ESP does not account for the IV size when calling pskb_may_pull() to ensure everything it accesses directly is within the linear part of a potential fragment. This results in a BUG() being triggered when the both the IPv4 and IPv6 ESP stack is fed with an skb where the first fragment ends between the end of the esp header and the end of the IV. This bug was found by Dirk Nehring <dnehring@gmx.net> . Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivo van Doorn authored
Some hardware never seem to accept the "goto sleep" command, since the legacy drivers don't have suspend and resume handlers the entire code for it was basically a educated guess (based on the "enable radio" code). This patch will only print a warning when the "goto sleep" command fails, and just continues as usual. Perhaps that means the device will not reach a sleep state and consumes more power then it should, but it is equally possible it simply needs some seconds longer to sleep. Anyway, by making the command non-fatal it will not block the rest of the suspend procedure. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Julia Lawall authored
In commit e6bafba5, a bug was fixed that involved converting !x & y to !(x & y). The code below shows the same pattern, and thus should perhaps be fixed in the same way. This is not tested and clearly changes the semantics, so it is only something to consider. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E1,E2; @@ ( !E1 & !E2 | - !E1 & E2 + !(E1 & E2) ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Guy Cohen <guy.cohen@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
This fixes a bug detected by CONFIG_DEBUG_SPINLOCK: if_cs_get_int_status() is only called from lbs_thread(), via priv->hw_get_int_status. However, lbs_thread() has already taken the priv->driver_lock. So it's a fault to take the same lock again here. Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 26 Mar, 2008 23 commits
-
-
Herbert Xu authored
The IPv6 BEET output function is incorrectly including the inner header in the payload to be protected. This causes a crash as the packet doesn't actually have that many bytes for a second header. The IPv4 BEET output on the other hand is broken when it comes to handling an inner IPv6 header since it always assumes an inner IPv4 header. This patch fixes both by making sure that neither BEET output function touches the inner header at all. All access is now done through the protocol-independent cb structure. Two new attributes are added to make this work, the IP header length and the IPv4 option length. They're filled in by the inner mode's output function. Thanks to Joakim Koskela for finding this problem. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Commit 8b7817f3 ([IPSEC]: Add ICMP host relookup support) introduced some dst leaks on error paths: the rt pointer can be forgotten to be put. Fix it bu going to a proper label. Found after net namespace's lo refused to unregister :) Many thanks to Den for valuable help during debugging. Herbert pointed out, that xfrm_lookup() will put the rtable in case of error itself, so the first goto fix is redundant. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Denis V. Lunev <den@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert P. J. Day authored
Given that there are no apparent calls to lock_kernel() or unlock_kernel() under net/ax25, delete the TODO reference related to that. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
SIOCADDMULTI/SIOCDELMULTI check whether the driver has a set_multicast_list method to determine whether it supports multicast. Drivers implementing secondary unicast support use set_rx_mode however. Check for both dev->set_multicast_mode and dev->set_rx_mode to determine multicast capabilities. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
It should be a "struct ktermios" not a "struct termios". Based upon a build warning reported by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
IFF_ALLMULTI is an indication from the network stack to the driver to disable multicast filters, drivers should never set it directly. Since the UML networking device doesn't have any filtering capabilites, it doesn't the set_multicast_list function at all, it is kept so userspace can still issue SIOCADDMULTI/SIOCDELMULTI ioctls however. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Patrick McHardy authored
Changing these flags requires to use dev_set_allmulti/dev_set_promiscuity or dev_change_flags. Setting it directly causes two unwanted effects: - the next dev_change_flags call will notice a difference between dev->gflags and the actual flags, enable promisc/allmulti mode and incorrectly update dev->gflags - this keeps the underlying device in promisc/allmulti mode until the VLAN device is deleted Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jeff Garzik authored
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Sreenivasa Honnur authored
- Handling TX completions on the same cpu as the sender. Signed-off-by: Surjit Reang <surjit.reang@neterion.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Michael Buesch authored
Some ROMs on embedded devices store incorrect values for the PHY address of the ethernet device. It looks like the number is sign-extended. Truncate the value by applying the PHY-address mask to it. The patch was tested on a bcm47xx embedded system (where the bug triggers) and a bcm4400 PCI card. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Marin Mitov authored
According to: Documentation/networking/netdevices.txt: <cite> napi->poll: .......... Context: softirq will be called with interrupts disabled by netconsole. </cite> napi->poll() could be called either with interrupts enabled (in softirq context) or disabled (by netconsole), so the irq flag should be preserved. Inspired by Ingo's resent forcedeth patch :-) Signed-off-by: Marin Mitov <mitov@issp.bas.bg> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Jussi Kivilinna authored
When query for OID_GEN_PHYSICAL_MEDIUM fails, uninitialized pointer 'phym' is being accessed in generic_rndis_bind(), resulting OOPS. Patch fixes phym to be initialized and setup correctly when rndis_query() for physical medium fails. Bug was introduced by following commit: commit 039ee17d Author: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Date: Sun Jan 27 23:34:33 2008 +0200 Reported-by: Dmitri Monakhov <dmonakhov@openvz.org> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Roland Dreier authored
Using iWARP with a Chelsio T3 NIC generates the following lockdep warning: ================================= [ INFO: inconsistent lock state ] 2.6.25-rc6 #50 --------------------------------- inconsistent {softirq-on-W} -> {in-softirq-W} usage. swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes: (&adap->sge.reg_lock){-+..}, at: [<ffffffff880e5ee2>] cxgb_offload_ctl+0x3af/0x507 [cxgb3] The problem is that reg_lock is used with plain spin_lock() in drivers/net/cxgb3/sge.c but is used with spin_lock_irqsave() in drivers/net/cxgb3/cxgb3_offload.c. This is technically a false positive, since the uses in sge.c are only in the initialization and cleanup paths and cannot overlap with any use in interrupt context. The best fix is probably just to use spin_lock_irq() with reg_lock in sge.c. Even though it's not strictly required for correctness, it avoids triggering lockdep and the extra overhead of disabling interrupts is not important at all in the initialization and cleanup slow paths. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Thomas Klein authored
Indicate that HEA calculates IPv4 checksums only Signed-off-by: Thomas Klein <tklein@de.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Peter Korsgaard authored
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Peter Korsgaard authored
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Peter Korsgaard authored
The Hirose USB-100 adapter uses a dm9601 chip. Reported by Robert Brockway. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Alexandr Smirnov authored
Marvell PHY m88e1111 (not sure about other models, but think they too) works in two modes: fiber and copper. In Marvell PHY driver (that we have in current community kernels) code supported only copper mode, and this is not configurable, bits for copper mode are simply written in registers during PHY initialization. This patch adds support for both modes. Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com> Acked-by: Andy Fleming <afleming@freescale.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Dhananjay Phadke authored
Don't count rx dropped packets based on return value of netif_receive_skb(), which is misleading. Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Tested-by: Vernon Mauery <mauery@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Dhananjay Phadke authored
o eliminate tx lock in netxen adapter struct, instead pound on netdev tx lock appropriately. o remove old "concurrent transmit" code that unnecessarily drops and reacquires tx lock in hard_xmit_frame(), this is already serialized the netdev xmit lock. o reduce scope of tx lock in tx cleanup. tx cleanup operates on different section of the ring than transmitting cpus and is guarded by producer and consumer indices. This fixes a race caused by rx softirq preemption on realtime kernels. Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Tested-by: Vernon Mauery <mauery@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Dhananjay Phadke authored
o separate and simpler irq handler for msi interrupts, avoids few checks than legacy mode. o avoid redudant tx_has_work() and rx_has_work() checks in interrupt and napi, which can uncork irq based on racy (lockless) access to tx and rx ring indices. If we get interrupt, there's sufficient reason to schedule napi. o replenish rx ring more often, remove self-imposed threshold rcv_free that prevents posting rx desc to card. This improves performance in low memory. Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Tested-by: Vernon Mauery <mauery@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Dhananjay Phadke authored
Recent netxen firmware has new scheme of generating MSI interrupts, it raises interrupt and blocks itself, waiting for driver to unmask. This reduces chance of spurious interrupts. The driver will be able to deal with older firmware as well. Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Tested-by: Vernon Mauery <mauery@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-