- 17 Jul, 2009 4 commits
-
-
Moni Shoua authored
Bonding device forbids slave device of different types under the same master. However, it is possible for a bonding master to change type during its lifetime. This can be either from ARPHRD_ETHER to ARPHRD_INFINIBAND or the other way arround. The change of type requires device level multicast address cleanup because device level multicast addresses depend on the device type. The patch adds a call to dev_close() before the bonding master changes type and dev_open() just after that. In the example below I enslaved an IPoIB device (ib0) under bond0. Since each bonding master starts as device of type ARPHRD_ETHER by default, a change of type occurs when ib0 is enslaved. This is how /proc/net/dev_mcast looks like without the patch 5 bond0 1 0 00ffffffff12601bffff000000000001ff96ca05 5 bond0 1 0 01005e000116 5 bond0 1 0 01005e7ffffd 5 bond0 1 0 01005e000001 5 bond0 1 0 333300000001 6 ib0 1 0 00ffffffff12601bffff000000000001ff96ca05 6 ib0 1 0 333300000001 6 ib0 1 0 01005e000001 6 ib0 1 0 01005e7ffffd 6 ib0 1 0 01005e000116 6 ib0 1 0 00ffffffff12401bffff00000000000000000001 6 ib0 1 0 00ffffffff12601bffff00000000000000000001 and this is how it looks like after the patch. 5 bond0 1 0 00ffffffff12601bffff000000000001ff96ca05 5 bond0 1 0 00ffffffff12601bffff00000000000000000001 5 bond0 1 0 00ffffffff12401bffff0000000000000ffffffd 5 bond0 1 0 00ffffffff12401bffff00000000000000000116 5 bond0 1 0 00ffffffff12401bffff00000000000000000001 6 ib0 1 0 00ffffffff12601bffff000000000001ff96ca05 6 ib0 1 0 00ffffffff12401bffff00000000000000000116 6 ib0 1 0 00ffffffff12401bffff0000000000000ffffffd 6 ib0 2 0 00ffffffff12401bffff00000000000000000001 6 ib0 2 0 00ffffffff12601bffff00000000000000000001 Signed-off-by:
Moni Shoua <monis@voltaire.com> Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
roel kluin authored
Fix misplaced parenthesis Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
roel kluin authored
Parentheses are required or the comparison occurs before the bitand. Signed-off-by:
-
-
- 16 Jul, 2009 2 commits
-
-
Eric Dumazet authored
When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating objects, since slab allocator could give a freed object still used by lockless readers. In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next being always valid (ie containing a valid 'nulls' value, or a valid pointer to next object in hash chain.) kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid for ct->tuplehash[xxx].hnnode.next. Fix is to call kmem_cache_alloc() and do the zeroing ourself. As spotted by Patrick, we also need to make sure lookup keys are committed to memory before setting refcount to 1, or a lockless reader could get a reference on the old version of the object. Its key re-check could then pass the barrier. Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Patrick McHardy <kaber@trash.net>
-
Patrick McHardy authored
The first argument is the address family, the second one the hook number. Signed-off-by:
-
- 15 Jul, 2009 2 commits
-
-
Lothar Waßmann authored
Add appropriate MODULE_ALIAS() to facilitate autoloading of can protocol drivers Signed-off-by:
Lothar Wassmann <LW@KARO-electronics.de> Acked-by:
Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by:
-
Lothar Waßmann authored
Fix a use after free bug in can protocol drivers The release functions of the can protocol drivers lack a call to sock_orphan() which leads to referencing freed memory under certain circumstances. This patch fixes a bug reported here: https://lists.berlios.de/pipermail/socketcan-users/2009-July/000985.htmlSigned-off-by:
-
- 14 Jul, 2009 5 commits
-
-
David S. Miller authored
This reverts commit adeab1af. As Alan Cox explained, the TTY layer changes that went recently to get rid of the tty->low_latency stuff fixes this already, and even for -stable it's the ->low_latency changes that should go in to fix this, rather than this patch. Signed-off-by:
-
Tobias Klauser authored
Use the correct function call for skb_reserve in the comment for NET_IP_ALIGN. Signed-off-by:
Tobias Klauser <klto@zhaw.ch> Signed-off-by:
-
Dongdong Deng authored
spin_unlock_irq() will enable interrupt in net_send_packet(), this patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that it doesn't enable interrupts when already disabled, and netconsole would work properly over cs89x0/isa-skeleton. Call trace: netconsole write_msg() { ... -> spin_lock_irqsave(); -> netpoll_send_udp() -> netpoll_send_skb() -> net_send_packet() ->... -> spin_unlock_irqrestore(); ... } Signed-off-by:Dongdong Deng <dongdong.deng@windriver.com> Signed-off-by:
-
Jiri Slaby authored
Don't forget to unlock a mutex in phy_scan_fixups on a fail path. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Andreas Jaggi authored
Fixes two bugs: - ToS/DiffServ inheritance was unintentionally activated when using impair fixed ToS values - ECN bit was lost during ToS/DiffServ inheritance Signed-off-by:
Andreas Jaggi <aj@open.ch> Signed-off-by:
-
- 13 Jul, 2009 3 commits
-
-
Eric Dumazet authored
forward declaration of inline function should be avoided, or old gcc cannot compile. Reported-by:
Teck Choon Giam <giamteckchoon@gmail.com> Signed-off-by:
-
roel kluin authored
Fix duplicate testing of MCAST flag Signed-off-by:
Jay Cliburn <jcliburn@gmail.com> Signed-off-by:
-
Ralf Baechle authored
Guido Trentalancia reports: I am trying to use the kiss driver in the Linux kernel that is being shipped with Fedora 10 but unfortunately I get the following oops: mkiss: AX.25 Multikiss, Hans Albas PE1AYX mkiss: ax0: crc mode is auto. ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready ------------[ cut here ]------------ WARNING: at kernel/softirq.c:77 __local_bh_disable+0x2f/0x83() (Not tainted) [...] unloaded: microcode] Pid: 0, comm: swapper Not tainted 2.6.27.25-170.2.72.fc10.i686 #1 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<c043255b>] __local_bh_disable+0x2f/0x83 [<c04325ba>] local_bh_disable+0xb/0xd [<c06ab4e2>] _spin_lock_bh+0xb/0x16 [<f8b6f600>] mkiss_receive_buf+0x2fb/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- ------------[ cut here ]------------ WARNING: at kernel/softirq.c:136 _local_bh_enable_ip+0x3d/0xc4() [...] Pid: 0, comm: swapper Tainted: G W 2.6.27.25-170.2.72.fc10.i686 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<f8b6f642>] ? mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c04325f9>] _local_bh_enable_ip+0x3d/0xc4 [<c0432688>] local_bh_enable_ip+0x8/0xa [<c06ab54d>] _spin_unlock_bh+0x11/0x13 [<f8b6f642>] mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- mkiss: ax0: Trying crc-smack mkiss: ax0: Trying crc-flexnet The issue was, that the locking code in mkiss was assuming it was only ever being called in process or bh context. Fixed by converting the involved locking code to use irq-safe locks. Review of other networking line disciplines shows that 6pack, both sync and async PPP and STRIP have similar issues. The ppp_async one is the most interesting one as it sorts out half of the issue as far back as 2004 in commit http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=2996d8deaeddd01820691a872550dc0cfba0c37dSigned-off-by:
Ralf Baechle <ralf@linux-mips.org> Reported-by:
Guido Trentalancia <guido@trentalancia.com> Signed-off-by:
-
- 12 Jul, 2009 5 commits
-
-
Ben Hutchings authored
alloc_etherdev() used to install a default implementation of this operation, but it must now be explicitly installed in struct net_device_ops. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
alloc_etherdev() used to install default implementations of these operations, but they must now be explicitly installed in struct net_device_ops. Signed-off-by:
-
Sascha Hlusiak authored
The sit module makes use of skb->dst in it's xmit function, so since 93f154b5 ("net: release dst entry in dev_hard_start_xmit()") sit tunnels are broken, because the flag IFF_XMIT_DST_RELEASE is not unset. This patch unsets that flag for sit devices to fix this regression. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Acked-by:
-
Eric Dumazet authored
After commit 2b85a34e (net: No more expensive sock_hold()/sock_put() on each tx) we do not take any more references on sk->sk_refcnt on outgoing packets. I forgot to delete two __sock_put() from ip_push_pending_frames() and ip6_push_pending_frames(). Reported-by:
Emil S Tantilov <emils.tantilov@gmail.com> Signed-off-by:
-
Eric Dumazet authored
Some sockets use SLAB_DESTROY_BY_RCU, and our RCU code correctness depends on sk->sk_nulls_node.next being always valid. A NULL value is not allowed as it might fault a lockless reader. Current sk_prot_alloc() implementation doesnt respect this hypothesis, calling kmem_cache_alloc() with __GFP_ZERO. Just call memset() around the forbidden field. Signed-off-by:
-
- 10 Jul, 2009 4 commits
-
-
Roland Dreier authored
Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how cxgb3 looks up the netdev_queue it stashes away in a qset during initialization. For multiport devices, the TX queue index it uses is offset by the first_qset index of each port. This leads to a crash once LLTX is removed, since hard_start_xmit is called with one TX queue lock held, while the TX reclaim timer task grabs a different (wrong) TX queue lock when it frees skbs. Fix this by removing the first_qset offset used to look up the TX queue passed into t3_sge_alloc_qset() from setup_sge_qsets(). Signed-off-by:
Roland Dreier <rolandd@cisco.com> Acked-by:
Divy Le Ray <divy@chelsio.com> Signed-off-by:
-
Yi Zou authored
Fix coexistence of Fiber Channel over Ethernet (FCoE) and Flow Director (FDIR) in 82599 and remove the disabling of FDIR when FCoE is enabled. Currently, FDIR is turned off when FCoE is enabled under the assumption that FCoE is always enabled with DCB being turned on. However, FDIR does not have to be turned off all the time when FCoE is enabled since FCoE can be enabled without DCB being turned on, e.g., use link pause only. This patch makes sure that when DCB is turned on or off, FDIR is turned on or off correspondingly; and when FCoE is enabled, it does not disable FDIR, rather, it will have FDIR set up properly so FCoE and FDIR can coexist regardless of DCB being on or off. Signed-off-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Jiri Olsa authored
Adding smp_mb__after_lock define to be used as a smp_mb call after a lock. Making it nop for x86, since {read|write|spin}_lock() on x86 are full memory barriers. Signed-off-by:Jiri Olsa <jolsa@redhat.com> Signed-off-by:
-
Jiri Olsa authored
Adding memory barrier after the poll_wait function, paired with receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper to wrap the memory barrier. Without the memory barrier, following race can happen. The race fires, when following code paths meet, and the tp->rcv_nxt and __add_wait_queue updates stay in CPU caches. CPU1 CPU2 sys_select receive packet ... ... __add_wait_queue update tp->rcv_nxt ... ... tp->rcv_nxt check sock_def_readable ... { schedule ... if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) wake_up_interruptible(sk->sk_sleep) ... } If there was no cache the code would work ok, since the wait_queue and rcv_nxt are opposit to each other. Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already passed the tp->rcv_nxt check and sleeps, or will get the new value for tp->rcv_nxt and will return with new data mask. In both cases the process (CPU1) is being added to the wait queue, so the waitqueue_active (CPU2) call cannot miss and will wake up CPU1. The bad case is when the __add_wait_queue changes done by CPU1 stay in its cache, and so does the tp->rcv_nxt update on CPU2 side. The CPU1 will then endup calling schedule and sleep forever if there are no more data on the socket. Calls to poll_wait in following modules were ommited: net/bluetooth/af_bluetooth.c net/irda/af_irda.c net/irda/irnet/irnet_ppp.c net/mac80211/rc80211_pid_debugfs.c net/phonet/socket.c net/rds/af_rds.c net/rfkill/core.c net/sunrpc/cache.c net/sunrpc/rpc_pipe.c net/tipc/socket.c Signed-off-by:
-
- 09 Jul, 2009 2 commits
-
-
Anton Vorontsov authored
Using early netconsole and gianfar driver this error pops up: netconsole: timeout waiting for carrier It appears that net/core/netpoll.c:netpoll_setup() is using cond_resched() in a loop waiting for a carrier. The thing is that cond_resched() is a no-op when system_state != SYSTEM_RUNNING, and so drivers/net/phy/phy.c's state_queue is never scheduled, therefore link detection doesn't work. I belive that the main problem is in cond_resched()[1], but despite how the cond_resched() story ends, it might be a good idea to call msleep(1) instead of cond_resched(), as suggested by Andrew Morton. [1] http://lkml.org/lkml/2009/7/7/463Signed-off-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
-
-
- 08 Jul, 2009 13 commits
-
-
Jaswinder Singh Rajput authored
fix the following 'make includecheck' warning: include/linux/rfkill.h: linux/types.h is included more than once. Signed-off-by:
Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
In the mainline kernel, p54usb will fail because the TX queue length can become < 0. This problem has been reported as Bugzilla #13725. The failure is expressed by the following message in the logs: WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x23c/0x298 [mac80211]() Hardware name: HP Pavilion dv2700 Notebook PC tx refused but queue active This problem has been recently observed in the wireless-testing tree, where a full solution is being tested. That fix is too invasive for 2.6.31-rcX, but the simple change supplied here will prevent the failure. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Jay Sternberg authored
Atheros top level menu needs a "depends WLAN_80211" to properly indent within menuconfig and xconfig interfaces. This is purely a visual issue but it effects all subsequent drivers. The issue is the top level menu does not include a dependency on WLAN_80211 so within the tree structure, Atheros is at the same level as WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with all subsequent drives, so it is really a subordinate. Signed-off-by:
Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by:
-
Johannes Berg authored
These two functions no longer exist in mac80211, so trying to insert them generates warnings in the document. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Johannes Berg authored
There's a race condition -- started can be set to true before channel is set due to the way mac80211 callbacks currently work (->start should probably pass the channel we would like to have initially). For now simply add a check to hwsim to avoid dereferencing the NULL channel pointer. Signed-off-by:
-
Clyde McPherson authored
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 4318E can do 802.11A/B/G, only B and G mode are supported in b43. Signed-off-by:
Clyde McPherson <ccmcphe@verizon.net> Signed-off-by:
-
Clyde McPherson authored
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 4318E can do 802.11A/B/G, only B and G mode are supported in b43. Signed-off-by:
-
Hin-Tak Leung authored
Yevgen Kotikov reported success on the sourceforge zd1211-devs list with the following details: Brand/retail: SONY IFU-WLM2 USB-IDs: Vendor: 0x054C Device: 0x0257 chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 ----- FCC ID: unknown Signed-off-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Tested-by:
Yevgen Kotikov <yevgen.kotikov@gmail.com> Signed-off-by:
-
Pascal Terjan authored
On a shuttle machine here we got 07b8:6001 device, handled by zd1211rw, which does not work. Scanning is OK but association does not work, we get "direct probe to AP xxx timed out" It appears that this simple patch makes the device work perfectly. This id was already there in initial import of the driver so I don't know if it has ever been working as ZD1211 (which would mean they changed it and kept the id :( ). Signed-off-by:
Pascal Terjan <pterjan@mandriva.com> Signed-off-by:
-
Florian Fainelli authored
Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Florian Fainelli authored
When the r6040 device IRQ line is shared we will enter the driver interrupt service routine, mask off the device interrupt enable register (MIER) and return with IRQ_NONE, we would then leave the device with interrupts disabled, this patch fixes that issue. Reported-by:
Steve Holland <sdh4@iastate.edu> Signed-off-by:
Joe Chou <joe.chou@rdc.com.tw> Signed-off-by:
-
Jarek Poplawski authored
Pawel Staszewski wrote: <blockquote> Some time ago i report this: http://bugzilla.kernel.org/show_bug.cgi?id=6648 and now with 2.6.29 / 2.6.29.1 / 2.6.29.3 and 2.6.30 it back dmesg output: oprofile: using NMI interrupt. Fix inflate_threshold_root. Now=15 size=11 bits ... Fix inflate_threshold_root. Now=15 size=11 bits cat /proc/net/fib_triestat Basic info: size of leaf: 40 bytes, size of tnode: 56 bytes. Main: Aver depth: 2.28 Max depth: 6 Leaves: 276539 Prefixes: 289922 Internal nodes: 66762 1: 35046 2: 13824 3: 9508 4: 4897 5: 2331 6: 1149 7: 5 9: 1 18: 1 Pointers: 691228 Null ptrs: 347928 Total size: 35709 kB </blockquote> It seems, the current threshold for root resizing is too aggressive, and it causes misleading warnings during big updates, but it might be also responsible for memory problems, especially with non-preempt configs, when RCU freeing is delayed long after call_rcu. It should be also mentioned that because of non-atomic changes during resizing/rebalancing the current lookup algorithm can miss valid leaves so it's additional argument to shorten these activities even at a cost of a minimally longer searching. This patch restores values before the patch "[IPV4]: fib_trie root node settings", commit: 965ffea4 from v2.6.22. Pawel's report: <blockquote> I dont see any big change of (cpu load or faster/slower routing/propagating routes from bgpd or something else) - in avg there is from 2% to 3% more of CPU load i dont know why but it is - i change from "preempt" to "no preempt" 3 times and check this my "mpstat -P ALL 1 30" always avg cpu load was from 2 to 3% more compared to "no preempt" [...] cat /proc/net/fib_triestat Basic info: size of leaf: 20 bytes, size of tnode: 36 bytes. Main: Aver depth: 2.44 Max depth: 6 Leaves: 277814 Prefixes: 291306 Internal nodes: 66420 1: 32737 2: 14850 3: 10332 4: 4871 5: 2313 6: 942 7: 371 8: 3 17: 1 Pointers: 599098 Null ptrs: 254865 Total size: 18067 kB </blockquote> According to this and other similar reports average depth is slightly increased (~0.2), and root nodes are shorter (log 17 vs. 18), but there is no visible performance decrease. So, until memory handling is improved or added parameters for changing this individually, this patch resets to safer defaults. Reported-by:
Pawel Staszewski <pstaszewski@itcare.pl> Reported-by:
Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Tested-by:
-
Pablo Bitton authored
Check that network interface is running before changing its MAC address. Otherwise, rxch is accessed when it's NULL - causing a kernel oops. Moreover, check that the new MAC address is valid. Signed-off-by:
Pablo Bitton <pablo.bitton@gmail.com> Signed-off-by:
Chaithrika U S <chaithrika@ti.com> Tested-by:
-
