- 07 Apr, 2013 4 commits
-
-
hayeswang authored
Add the new settings and correct the wrong settings. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
hayeswang authored
Replace the current settings with rtl_writephy and rtl_readphy. For the hardware, the settings are same with previous ones. This make the setting method like the previous chips. Signed-off-by:
-
hayeswang authored
Some codes are belong to binary codes and should be removed. Signed-off-by:
-
git://1984.lsi.us.es/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== The following patchset contains Netfilter and IPVS updates for your net-next tree, most relevantly they are: * Add net namespace support to NFLOG, ULOG and ebt_ulog and NFQUEUE. The LOG and ebt_log target has been also adapted, but they still depend on the syslog netnamespace that seems to be missing, from Gao Feng. * Don't lose indications of congestion in IPv6 fragmentation handling, from Hannes Frederic Sowa.i * IPVS conversion to use RCU, including some code consolidation patches and optimizations, also some from Julian Anastasov. * cpu fanout support for NFQUEUE, from Holger Eitzenberger. * Better error reporting to userspace when dropping packets from all our _*_[xfrm|route]_me_harder functions, from Patrick McHardy. ==================== Signed-off-by:
-
- 06 Apr, 2013 1 commit
-
-
Hannes Frederic Sowa authored
This change brings netfilter reassembly logic on par with reassembly.c. The corresponding change in net-next is (eec2e618 ipv6: implement RFC3168 5.3 (ecn protection) for ipv6 fragmentation handling) Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jesper Dangaard Brouer <jbrouer@redhat.com> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
- 05 Apr, 2013 10 commits
-
-
Pablo Neira Ayuso authored
Now that this supports net namespace for nflog and nfqueue, we can remove the global proc_net_netfilter which has no clients anymore. Based on patch from Gao feng. Signed-off-by: -
Gao feng authored
This patch makes /proc/net/netfilter/nfnetlink_queue pernet. Moreover, there's a pernet instance table and lock. Signed-off-by:
Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by:
-
Gao feng authored
After this patch, all nf_loggers support net namespace. Still xt_LOG and ebt_log require syslog netns support. Signed-off-by:
-
Gao feng authored
This patch makes /proc/net/netfilter/nfnetlink_log pernet. Moreover, there's a pernet instance table and lock. Signed-off-by:
-
Gao feng authored
Add pernet support to ipt_ULOG by means of the new nf_log_set function added in (30e0c6a6 netfilter: nf_log: prepare net namespace support for loggers). This patch also make ulog_buffers and netlink socket nflognl per netns. Signed-off-by:
-
Gao feng authored
Add pernet support to ebt_ulog by means of the new nf_log_set function added in (30e0c6a6 netfilter: nf_log: prepare net namespace support for loggers). This patch also make ulog_buffers and netlink socket ebtulognl per netns. Signed-off-by:
-
Gao feng authored
Add pernet support to xt_LOG by means of the new nf_log_set function added in (30e0c6a6 netfilter: nf_log: prepare net namespace support for loggers). Since syslog ns has yet not been implemented, we don't want the containers to DDOS host's syslogd. So only enable ebt_log only from init_net and wait for syslog ns support Signed-off-by:
-
Gao feng authored
Add pernet support to ebt_log by means of the new nf_log_set function added in (30e0c6a6 netfilter: nf_log: prepare net namespace support for loggers). Since syslog ns has yet not been implemented, we don't want the containers to DDOS host's syslogd. So only enable ebt_log only from init_net and wait for syslog ns support. Signed-off-by:
-
Gao feng authored
This patch adds netns support to nf_log and it prepares netns support for existing loggers. It is composed of four major changes. 1) nf_log_register has been split to two functions: nf_log_register and nf_log_set. The new nf_log_register is used to globally register the nf_logger and nf_log_set is used for enabling pernet support from nf_loggers. Per netns is not yet complete after this patch, it comes in separate follow up patches. 2) Add net as a parameter of nf_log_bind_pf. Per netns is not yet complete after this patch, it only allows to bind the nf_logger to the protocol family from init_net and it skips other cases. 3) Adapt all nf_log_packet callers to pass netns as parameter. After this patch, this function only works for init_net. 4) Make the sysctl net/netfilter/nf_log pernet. Signed-off-by:
-
Gao feng authored
This patch makes this proc dentry pernet. So far only init_net had a /proc/net/netfilter directory. Signed-off-by:
-
- 04 Apr, 2013 1 commit
-
-
Jesper Dangaard Brouer authored
This patch implements per hash bucket locking for the frag queue hash. This removes two write locks, and the only remaining write lock is for protecting hash rebuild. This essentially reduce the readers-writer lock to a rebuild lock. This patch is part of "net: frag performance followup" http://thread.gmane.org/gmane.linux.network/263644 of which two patches have already been accepted: Same test setup as previous: (http://thread.gmane.org/gmane.linux.network/257155) Two 10G interfaces, on seperate NUMA nodes, are under-test, and uses Ethernet flow-control. A third interface is used for generating the DoS attack (with trafgen). Notice, I have changed the frag DoS generator script to be more efficient/deadly. Before it would only hit one RX queue, now its sending packets causing multi-queue RX, due to "better" RX hashing. Test types summary (netperf UDP_STREAM): Test-20G64K == 2x10G with 65K fragments Test-20G3F == 2x10G with 3x fragments (3*1472 bytes) Test-20G64K+DoS == Same as 20G64K with frag DoS Test-20G3F+DoS == Same as 20G3F with frag DoS Test-20G64K+MQ == Same as 20G64K with Multi-Queue frag DoS Test-20G3F+MQ == Same as 20G3F with Multi-Queue frag DoS When I rebased this-patch(03) (on top of net-next commit a210576c) and removed the _bh spinlock, I saw a performance regression. BUT this was caused by some unrelated change in-between. See tests below. Test (A) is what I reported before for patch-02, accepted in commit 1b5ab0de. Test (B) verifying-retest of commit 1b5ab0de corrospond to patch-02. Test (C) is what I reported before for this-patch Test (D) is net-next master HEAD (commit a210576c), which reveals some (unknown) performance regression (compared against test (B)). Test (D) function as a new base-test. Performance table summary (in Mbit/s): (#) Test-type: 20G64K 20G3F 20G64K+DoS 20G3F+DoS 20G64K+MQ 20G3F+MQ ---------- ------- ------- ---------- --------- -------- ------- (A) Patch-02 : 18848.7 13230.1 4103.04 5310.36 130.0 440.2 (B) 1b5ab0de : 18841.5 13156.8 4101.08 5314.57 129.0 424.2 (C) Patch-03v1: 18838.0 13490.5 4405.11 6814.72 196.6 461.6 (D) a210576c : 18321.5 11250.4 3635.34 5160.13 119.1 405.2 (E) with _bh : 17247.3 11492.6 3994.74 6405.29 166.7 413.6 (F) without bh: 17471.3 11298.7 3818.05 6102.11 165.7 406.3 Test (E) and (F) is this-patch(03), with(V1) and without(V2) the _bh spinlocks. I cannot explain the slow down for 20G64K (but its an artificial "lab-test" so I'm not worried). But the other results does show improvements. And test (E) "with _bh" version is slightly better. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> ---- V2: - By analysis from Hannes Frederic Sowa and Eric Dumazet, we don't need the spinlock _bh versions, as Netfilter currently does a local_bh_disable() before entering inet_fragment. - Fold-in desc from cover-mail V3: - Drop the chain_len counter per hash bucket. Signed-off-by:
-
- 03 Apr, 2013 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Pull net into net-next to get the synchronize_net() bug fix in bonding. Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix VSOCK layer handling of context ID changes, from Reilly Grant. 2) Now that we have a synchronize_net() in netdev_rx_handler_unregister(), we can't let any call sites hold locks. Unfortunately bonding does, so we have to drop the rwlock there a little bit earlier, fix from Veaceslav Falico. 3) MAC address setting loop exits one iteration too early in mlx4 driver, from Yan Burman. 4) Restore ipv6 routes properly upon ifdown/ifup of loopback, from Balakumaran Kannan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: VSOCK: Handle changes to the VMCI context ID. net IPv6 : Fix broken IPv6 routing table after loopback down-up cbq: incorrect processing of high limits net/mlx4_en: Fix setting initial MAC address bonding: get netdev_rx_handler_unregister out of locks -
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmapLinus Torvalds authored
Pull regmap fixes from Mark Brown: "A small collection of fixes. The most important ones are those from Stephen and Lars-Peter both of which fix cache issues that have been lurking for a while but not manifesting noticably enough for anyone to report them." * tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: async: Add missing return regmap: don't corrupt work buffer in _regmap_raw_write() regmap: cache Fix regcache-rbtree sync regmap: Initialize `map->debugfs' before regcache
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull DRM fixes from Dave Airlie: "Two core fixes, both regressions, along with some intel and some nouveau fixes for regressions and oopses" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm: correctly restore mappings if drm_open fails drm/nouveau: fix NULL ptr dereference from nv50_disp_intr() drm/nouveau: fix handling empty channel list in ioctl's drm: don't unlock in the addfb error paths drm/i915: Fix build failure drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2) drm/i915: duct-tape locking when eDP init fails
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull MIPS fixes from Ralf Baechle: "A collection of fixes pretty much across the MIPS code. Even the change to include/linux/signal.h by David Howells' 2a148698 ("Fix breakage in MIPS siginfo handling") should be considered MIPS-specific as it touches an ifdefed segment that is only relevant to MIPS and which unfortunately can't be made to go away entirely." * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: Fix breakage in MIPS siginfo handling Revert "MIPS: BCM63XX: Call board_register_device from device_initcall()" MIPS: BCM63XX: Make nvram checksum failure non fatal MIPS: Fix code generation for non-DSP capable CPUs MIPS: Fix inconsistent formatting inside /proc/cpuinfo MIPS: SEAD3: Enable LL/SC. MIPS: Get rid of CONFIG_CPU_HAS_LLSC again MIPS: Add dependencies for HAVE_ARCH_TRANSPARENT_HUGEPAGE MIPS: VR4133: Fix probe for LL/SC. MIPS: Fix logic errors in bitops.c MIPS: Use CONFIG_CPU_MIPSR2 in csum_partial.S MIPS: compat: Return same error ENOSYS as native for invalid operation.
-
- 02 Apr, 2013 19 commits
-
-
Jacob Keller authored
Commit 7d4c04fc ("net: add option to enable error queue packets waking select") has an issue due to operator precedence causing the bit-wise OR to bind to the sock_flags call instead of the result of the terniary conditional. This fixes the *_poll functions to work properly. The old code results in "mask |= POLLPRI" instead of what was intended, which is to only include POLLPRI when the socket option is enabled. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Ilija Hadzic authored
If first drm_open fails, the error-handling path will incorrectly restore inode's mapping to NULL. This can cause the crash later on. Fix by separately storing away mapping pointers that drm_open can touch and restore each from its own respective variable if the call fails. Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850 (thanks to Michal Hocko for investigating investigating and finding the root cause of the bug) Reference: http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html v2: Use one variable to store file and inode mapping since they are the same at the function entry. Fix spelling mistakes in commit message. v3: Add reference to the original bug report. Reported-by:
Marco Munderloh <munderl@tnt.uni-hannover.de> Tested-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: stable@vger.kernel.org Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Oops fixers. * 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau: fix NULL ptr dereference from nv50_disp_intr() drm/nouveau: fix handling empty channel list in ioctl's
-
Guenter Roeck authored
Since of_get_mac_address() is now declared even if CONFIG_OF_NET is not configured, the ifdef is no longer necessary and can be removed. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
Since of_get_mac_address() is now defined even if CONFIG_OF_NET is not configured, the ifdef around the code calling it is no longer necessary and can be removed. Similar, since of_get_phy_mode() is now defined as dummy function if OF_NET is not configured, it is no longer necessary to provide an OF dependent function as front-end. Also, the function depends on OF_NET, not on OF, so the conditional code was not correct anyway. Drop the front-end function and call of_get_phy_mode() directly. Signed-off-by:
-
Guenter Roeck authored
With of_get_mac_address() and of_get_phy_mode() now defined as dummy functions if OF_NET is not configured, it is no longer necessary to provide OF dependent functions as front-end. Also, the two functions depend on OF_NET, not on OF, so the conditional code was not correct anyway. Drop the front-end functions and call of_get_mac_address() and of_get_phy_mode() directly instead. Signed-off-by:
-
Guenter Roeck authored
With of_get_mac_address() and of_get_phy_mode() now defined as dummy functions if OF_NET is not configured, it is no longer necessary to provide OF dependent functions as front-end. Also, the two functions depend on OF_NET, not on OF, so the conditional code was not correct anyway. Drop the front-end functions and call of_get_mac_address() and of_get_phy_mode() directly instead. Signed-off-by:
-
Guenter Roeck authored
of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET is configured. While most callers check for the define, not all do, and those who do require #ifdef around the code. For those who don't, the missing check can result in errors such as arch/powerpc/sysdev/tsi108_dev.c:107:3: error: implicit declaration of function 'of_get_mac_address' [-Werror=implicit-function-declaration] arch/powerpc/sysdev/mv64x60_dev.c:253:2: error: implicit declaration of function 'of_get_mac_address' [-Werror=implicit-function-declaration] Provide empty functions if OF_NET is not configured. This is safe because all callers do check the return values. Cc: David Daney <david.daney@cavium.com> Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
One locking regression fix, and a couple of other i915 ones. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm: don't unlock in the addfb error paths drm/i915: Fix build failure drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2) drm/i915: duct-tape locking when eDP init fails
-
Reilly Grant authored
The VMCI context ID of a virtual machine may change at any time. There is a VMCI event which signals this but datagrams may be processed before this is handled. It is therefore necessary to be flexible about the destination context ID of any datagrams received. (It can be assumed to be correct because it is provided by the hypervisor.) The context ID on existing sockets should be updated to reflect how the hypervisor is currently referring to the system. Signed-off-by:
Reilly Grant <grantr@vmware.com> Acked-by:
Andy King <acking@vmware.com> Signed-off-by:
-
Balakumaran Kannan authored
IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo) interface. After down-up, routes of other interface's IPv6 addresses through 'lo' are lost. IPv6 addresses assigned to all interfaces are routed through 'lo' for internal communication. Once 'lo' is down, those routing entries are removed from routing table. But those removed entries are not being re-created properly when 'lo' is brought up. So IPv6 addresses of other interfaces becomes unreachable from the same machine. Also this breaks communication with other machines because of NDISC packet processing failure. This patch fixes this issue by reading all interface's IPv6 addresses and adding them to IPv6 routing table while bringing up 'lo'. ==Testing== Before applying the patch: $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ sudo ifdown lo $ sudo ifup lo $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ After applying the patch: $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ sudo ifdown lo $ sudo ifup lo $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ Signed-off-by:
Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com> Signed-off-by:
Maruthi Thotad <Maruthi.Thotad@ap.sony.com> Signed-off-by:
-
Paul Gortmaker authored
Commit 3fb72f1e ("ipconfig wait for carrier") added a "wait for carrier on at least one interface" policy, with a worst case maximum wait of two minutes. However, if you encounter this, you won't get any feedback from the console as to the nature of what is going on. You just see the booting process hang for two minutes and then continue. Here we add a message so the user knows what is going on, and hence can take action to rectify the situation (e.g. fix network cable or whatever.) After the 1st 10s pause, output now begins that looks like this: Waiting up to 110 more seconds for network. Waiting up to 100 more seconds for network. Waiting up to 90 more seconds for network. Waiting up to 80 more seconds for network. ... Since most systems will have no problem getting link/carrier in the 1st 10s, the only people who will see these messages are people with genuine issues that need to be resolved. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Neil Horman authored
This backtrace was recently reported on a 3.9 kernel: Actual results: from syslog /var/log/messsages: kernel: [17539.340285] ------------[ cut here ]------------ kernel: [17539.341012] WARNING: at lib/dma-debug.c:937 check_unmap+0x493/0x960() kernel: [17539.341012] Hardware name: MS-7125 kernel: [17539.341012] forcedeth 0000:00:0a.0: DMA-API: device driver failed to check map error[device address=0x0000000013c88000] [size=544 bytes] [mapped as page] kernel: [17539.341012] Modules linked in: fuse ebtable_nat ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack bnep bluetooth rfkill ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_hdmi snd_cmipci snd_mpu401_uart snd_hda_intel snd_intel8x0 snd_opl3_lib snd_ac97_codec gameport snd_hda_codec snd_rawmidi ac97_bus snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd k8temp soundcore serio_raw i2c_nforce2 forcedeth ata_generic pata_acpi nouveau video mxm_wmi wmi i2c_algo_bit drm_kms_helper ttm drm i2c_core sata_sil pata_amd sata_nv uinput kernel: [17539.341012] Pid: 17340, comm: sshd Not tainted 3.9.0-0.rc4.git0.1.fc19.i686.PAE #1 kernel: [17539.341012] Call Trace: kernel: [17539.341012] [<c045573c>] warn_slowpath_common+0x6c/0xa0 kernel: [17539.341012] [<c0701953>] ? check_unmap+0x493/0x960 kernel: [17539.341012] [<c0701953>] ? check_unmap+0x493/0x960 kernel: [17539.341012] [<c04557a3>] warn_slowpath_fmt+0x33/0x40 kernel: [17539.341012] [<c0701953>] check_unmap+0x493/0x960 kernel: [17539.341012] [<c049238f>] ? sched_clock_cpu+0xdf/0x150 kernel: [17539.341012] [<c0701e87>] debug_dma_unmap_page+0x67/0x70 kernel: [17539.341012] [<f7eae8f2>] nv_unmap_txskb.isra.32+0x92/0x100 Its pretty plainly the result of an skb fragment getting unmapped without having its initial mapping operation checked for errors. This patch corrects that. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Chen Gang authored
delete useless 'break' after 'return'. let 'return 0' instead of 'return (0)' also give a comment for 'break' to let readers notice it. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Vasily Averin authored
currently cbq works incorrectly for limits > 10% real link bandwidth, and practically does not work for limits > 50% real link bandwidth. Below are results of experiments taken on 1 Gbit link In shaper | Actual Result -----------+--------------- 100M | 108 Mbps 200M | 244 Mbps 300M | 412 Mbps 500M | 893 Mbps This happen because of q->now changes incorrectly in cbq_dequeue(): when it is called before real end of packet transmitting, L2T is greater than real time delay, q_now gets an extra boost but never compensate it. To fix this problem we prevent change of q->now until its synchronization with real time. Signed-off-by:
Vasily Averin <vvs@openvz.org> Reviewed-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Acked-by:
-
Rajesh Borundia authored
Signed-off-by:
Rajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by:
-
Rajesh Borundia authored
warning: 'pf_info.max_tx_ques' may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by:
-
Rajesh Borundia authored
o Fix for smatch tool reported error drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c:2029 qlcnic_probe() error: potential NULL dereference 'adapter'. o While returning from an error path in probe, adapter is not initialized. So do not access adapter in cleanup path. Signed-off-by:
-
Rajesh Borundia authored
[net-next:master 301/302] drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c:563 qlcnic_set_multi() error: potential null dereference 'cur'. (kzalloc returns null) o Break out of the loop after memory allocation failure. Program all the MAC addresses that were cached in the return path. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
