- 12 Aug, 2014 40 commits
-
-
Jiri Bohac authored
On architectures with sizeof(int) < sizeof (long), the computation of mask inside apply_slack() can be undefined if the computed bit is > 32. E.g. with: expires = 0xffffe6f5 and slack = 25, we get: expires_limit = 0x20000000e bit = 33 mask = (1 << 33) - 1 /* undefined */ On x86, mask becomes 1 and and the slack is not applied properly. On s390, mask is -1, expires is set to 0 and the timer fires immediately. Use 1UL << bit to solve that issue. Suggested-by:
Deborah Townsend <dstownse@us.ibm.com> Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.czSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit 98a01e77) Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Leon Ma authored
If a cpu is idle and starts an hrtimer which is not pinned on that same cpu, the nohz code might target the timer to a different cpu. In the case that we switch the cpu base of the timer we already have a sanity check in place, which determines whether the timer is earlier than the current leftmost timer on the target cpu. In that case we enqueue the timer on the current cpu because we cannot reprogram the clock event device on the target. If the timers base is already the target CPU we do not have this sanity check in place so we enqueue the timer as the leftmost timer in the target cpus rb tree, but we cannot reprogram the clock event device on the target cpu. So the timer expires late and subsequently prevents the reprogramming of the target cpu clock event device until the previously programmed event fires or a timer with an earlier expiry time gets enqueued on the target cpu itself. Add the same target check as we have for the switch base case and start the timer on the current cpu if it would become the leftmost timer on the target. [ tglx: Rewrote subject and changelog ] Signed-off-by:
Leon Ma <xindong.ma@intel.com> Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com Cc: stable@vger.kernel.org Signed-off-by:
-
Stuart Hayes authored
If the last hrtimer interrupt detected a hang it sets hang_detected=1 and programs the clock event device with a delay to let the system make progress. If hang_detected == 1, we prevent reprogramming of the clock event device in hrtimer_reprogram() but not in hrtimer_force_reprogram(). This can lead to the following situation: hrtimer_interrupt() hang_detected = 1; program ce device to Xms from now (hang delay) We have two timers pending: T1 expires 50ms from now T2 expires 5s from now Now T1 gets canceled, which causes hrtimer_force_reprogram() to be invoked, which in turn programs the clock event device to T2 (5 seconds from now). Any hrtimer_start after that will not reprogram the hardware due to hang_detected still being set. So we effectivly block all timers until the T2 event fires and cleans up the hang situation. Add a check for hang_detected to hrtimer_force_reprogram() which prevents the reprogramming of the hang delay in the hardware timer. The subsequent hrtimer_interrupt will resolve all outstanding issues. [ tglx: Rewrote subject and changelog and fixed up the comment in hrtimer_force_reprogram() ] Signed-off-by:
Stuart Hayes <stuart.w.hayes@gmail.com> Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
-
Grant Likely authored
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Cc: Stable <stable@vger.kernel.org> # v3.4+ (cherry picked from commit 58b116bc) Signed-off-by:
-
Tyler Stachecki authored
On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which in turn calls pci_disable_device if the device is enabled prior to suspending. However, _scsih_suspend also calls pci_disable_device itself. Thus, in the event that the device is enabled prior to suspending, pci_disable_device will be called twice. This patch removes the duplicate call to pci_disable_device in _scsi_suspend as it is both unnecessary and results in a kernel oops. Signed-off-by:
Tyler Stachecki <tstache1@binghamton.edu> Cc: stable@vger.kernel.org Signed-off-by:
James Bottomley <JBottomley@Parallels.com> (cherry picked from commit af61e27c) Signed-off-by:
-
Steven Rostedt (Red Hat) authored
A race exists between module loading and enabling of function tracer. CPU 1 CPU 2 ----- ----- load_module() module->state = MODULE_STATE_COMING register_ftrace_function() mutex_lock(&ftrace_lock); ftrace_startup() update_ftrace_function(); ftrace_arch_code_modify_prepare() set_all_module_text_rw(); <enables-ftrace> ftrace_arch_code_modify_post_process() set_all_module_text_ro(); [ here all module text is set to RO, including the module that is loading!! ] blocking_notifier_call_chain(MODULE_STATE_COMING); ftrace_init_module() [ tries to modify code, but it's RO, and fails! ftrace_bug() is called] When this race happens, ftrace_bug() will produces a nasty warning and all of the function tracing features will be disabled until reboot. The simple solution is to treate module load the same way the core kernel is treated at boot. To hardcode the ftrace function modification of converting calls to mcount into nops. This is done in init/main.c there's no reason it could not be done in load_module(). This gives a better control of the changes and doesn't tie the state of the module to its notifiers as much. Ftrace is special, it needs to be treated as such. The reason this would work, is that the ftrace_module_init() would be called while the module is in MODULE_STATE_UNFORMED, which is ignored by the set_all_module_text_ro() call. Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.comReported-by:Takao Indoh <indou.takao@jp.fujitsu.com> Acked-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: stable@vger.kernel.org # 2.6.38+ Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> (cherry picked from commit a949ae56) Signed-off-by:
-
Martin Schwidefsky authored
The A register needs to be initialized to zero in the prolog if the first instruction of the BPF program is BPF_S_LDX_B_MSH to prevent leaking the content of %r5 to user space. Cc: <stable@vger.kernel.org> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 6e0de817) Signed-off-by:
-
Thomas Hellstrom authored
We already check that the buffer object we're accessing is registered with the file. Now also make sure that we can't DMA across buffer object boundaries. v2: Code commenting update. Cc: stable@vger.kernel.org Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> (cherry picked from commit cbd75e97) Signed-off-by:
-
Michael S. Tsirkin authored
skb_segment copies frags around, so we need to copy them carefully to avoid accessing user memory after reporting completion to userspace through a callback. skb_segment doesn't normally happen on datapath: TSO needs to be disabled - so disabling zero copy in this case does not look like a big deal. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 1fd819ec) Signed-off-by:
-
Julius Werner authored
We have observed a rare cycle state desync bug after Set TR Dequeue Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that doesn't fetch new TRBs and thus an unresponsive USB device). It always triggers when a previous Set TR Dequeue Pointer command has set the pointer to the final Link TRB of a segment, and then another URB gets enqueued and cancelled again before it can be completed. Further investigation showed that the xHC had returned the Link TRB in the TRB Pointer field of the Transfer Event (CC == Stopped -- Length Invalid), but when xhci_find_new_dequeue_state() later accesses the Endpoint Context's TR Dequeue Pointer field it is set to the first TRB of the next segment. The driver expects those two values to be the same in this situation, and uses the cycle state of the latter together with the address of the former. This should be fine according to the XHCI specification, since the endpoint ring should be stopped when returning the Transfer Event and thus should not advance over the Link TRB before it gets restarted. However, real-world XHCI implementations apparently don't really care that much about these details, so the driver should follow a more defensive approach to try to work around HC spec violations. This patch removes the stopped_trb variable that had been used to store the TRB Pointer from the last Transfer Event of a stopped TRB. Instead, xhci_find_new_dequeue_state() now relies only on the Endpoint Context, requiring a small amount of additional processing to find the virtual address corresponding to the TR Dequeue Pointer. Some other parts of the function were slightly rearranged to better fit into this model. This patch should be backported to kernels as old as 2.6.31 that contain the commit ae636747 "USB: xhci: URB cancellation support." Signed-off-by:
Julius Werner <jwerner@chromium.org> Cc: stable@vger.kernel.org Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> (cherry picked from commit c4bedb77) Signed-off-by:
-
Bjørn Mork authored
Dan writes: "The Dell drivers use the same configuration for PIDs: 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card These devices are all clearly Sierra devices, but are also definitely Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750. >From DellGobi5kSetup.exe from the Dell drivers: usbif0: serial/firmware loader? usbif2: nmea usbif3: modem/ppp usbif8: net/QMI" Reported-by:
AceLan Kao <acelan.kao@canonical.com> Reported-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
A number of older CMOTech modems are based on Qualcomm chips and exporting a QMI/wwan function. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
-
Bjørn Mork authored
Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by:
-
Bjørn Mork authored
Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by:
Julio Araujo <julio.araujo@wllctel.com.br> Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Aleksander Morgado authored
When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a QMI port and a WWAN interface. CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> CC: Christian Schmiedl <christian.schmiedl@gemalto.com> CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com> CC: David McCullough <david.mccullough@accelecon.com> Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> Acked-by:
-
Raymond Wanyoike authored
The driver description files give these descriptions to the vendor specific ports on this modem: VID_19D2&PID_1270&MI_00: "ZTE MF667 Diagnostics Port" VID_19D2&PID_1270&MI_01: "ZTE MF667 AT Port" VID_19D2&PID_1270&MI_02: "ZTE MF667 ATExt2 Port" VID_19D2&PID_1270&MI_03: "ZTE MF667 ATExt Port" VID_19D2&PID_1270&MI_04: "ZTE MF667 USB Modem" VID_19D2&PID_1270&MI_05: "ZTE MF667 Network Adapter" Signed-off-by:
Raymond Wanyoike <raymond.wanyoike@gmail.com> Acked-by:
-
Enrico Mioso authored
This is a QMI device, manufactured by TCT Mobile Phones. A companion patch blacklisting this device's QMI interface in the option.c driver has been sent. Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by:
Antonella Pellizzari <anto.pellizzari83@gmail.com> Tested-by:
-
Aleksander Morgado authored
Cinterion PLXX LTE devices have a 0x0060 product ID, not 0x12d1. The blacklisting in the serial/option driver does actually use the correct PID, as per commit 8ff10bdb ('USB: Blacklisted Cinterion's PLxx WWAN Interface'). CC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> CC: Christian Schmiedl <christian.schmiedl@gemalto.com> CC: Nicolaus Colberg <nicolaus.colberg@gemalto.com> Signed-off-by:
Aleksander Morgado <aleksander@lanedo.com> Acked-by:
Christian Schmiedl <christian.schmiedl@gemalto.com> Signed-off-by:
-
Fabio Porcedda authored
Newer firmware use a new pid and a different interface. Signed-off-by:
Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by:
-
Enrico Mioso authored
Another QMI-speaking device by ZTE, re-branded by ONDA! I'm connected ovr this device's QMI interface right now, so I can say I tested it! :) Note: a follow-up patch was posted to the linux-usb mailing list, to prevent the option driver from binding to the device's QMI interface, making it unusable. Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
A standard Gobi 3000 reference design module. Reported-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Bjørn Mork authored
The MC8305 module got an additional entry added based solely on information from a Windows driver *.inf file. We now have the actual descriptor layout from one of these modules, and it consists of two alternate configurations where cfg #1 is a normal Gobi 2k layout and cfg #2 is MBIM only, using interface numbers 5 and 6 for MBIM control and data. The extra Windows driver entry for interface number 5 was most likely a bug. Deleting the bogus entry to avoid unnecessary qmi_wwan probe failures when using the MBIM configuration. Reported-by:
Lana Black <sickmind@lavabit.com> Signed-off-by:
-
Eric Dumazet authored
Recycling skb always had been very tough... This time it appears GRO layer can accumulate skb->truesize adjustments made by drivers when they attach a fragment to skb. skb_gro_receive() can only subtract from skb->truesize the used part of a fragment. I spotted this problem seeing TcpExtPruneCalled and TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where TCP receive window should be sized properly to accept traffic coming from a driver not overshooting skb->truesize. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Li RongQing authored
the value of itag is a random value from stack, and may not be initiated by fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID is not set This will make the cached dst uncertainty Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Acked-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
Susant Sahani authored
The function ip6_tnl_validate assumes that the rtnl attribute IFLA_IPTUN_PROTO always be filled . If this attribute is not filled by the userspace application kernel get crashed with NULL pointer dereference. This patch fixes the potential kernel crash when IFLA_IPTUN_PROTO is missing . Signed-off-by:
Susant Sahani <susant@redhat.com> Acked-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Peter Christensen authored
Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti overflow on the underlying interface. Attempting the set IFF_ALLMULTI on the underlying interface would cause an error and the log message: "allmulti touches root, set allmulti failed." Signed-off-by:
Peter Christensen <pch@ordbogen.com> Signed-off-by:
-
Bjørn Mork authored
This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on a bogus assumption that all tagged frames will use the acceleration API because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames tagged in userspace using packet sockets. Such frames will erroneously be considered as untagged and silently dropped based on not being IP. Fix by falling back to looking into the ethernet header for a tag if no accelerated tag was found. Fixes: a82c7ce5 ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID") Cc: Greg Suarez <gsuarez@smithmicro.com> Signed-off-by:
-
Sergey Popovich authored
Increment fib_info_cnt in fib_create_info() right after successfuly alllocating fib_info structure, overwise fib_metrics allocation failure leads to fib_info_cnt incorrectly decremented in free_fib_info(), called on error path from fib_create_info(). Signed-off-by:
Sergey Popovich <popovich_sergei@mail.ru> Signed-off-by:
-
Florian Westphal authored
If conntrack defragments incoming ipv6 frags it stores largest original frag size in ip6cb and sets ->local_df. We must thus first test the largest original frag size vs. mtu, and not vice versa. Without this patch PKTTOOBIG is still generated in ip6_fragment() later in the stack, but 1) IPSTATS_MIB_INTOOBIGERRORS won't increment 2) packet did (needlessly) traverse netfilter postrouting hook. Fixes: fe6cc55f ("net: ip, ipv6: handle gso skbs in forwarding path") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Florian Westphal authored
else we may fail to forward skb even if original fragments do fit outgoing link mtu: 1. remote sends 2k packets in two 1000 byte frags, DF set 2. we want to forward but only see '2k > mtu and DF set' 3. we then send icmp error saying that outgoing link is 1500 But original sender never sent a packet that would not fit the outgoing link. Setting local_df makes outgoing path test size vs. IPCB(skb)->frag_max_size, so we will still send the correct error in case the largest original size did not fit outgoing link mtu. Reported-by:
Maxime Bizon <mbizon@freebox.fr> Suggested-by:
Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 895162b1) Signed-off-by:
-
Florian Westphal authored
local_df means 'ignore DF bit if set', so if its set we're allowed to perform ip fragmentation. This wasn't noticed earlier because the output path also drops such skbs (and emits needed icmp error) and because netfilter ip defrag did not set local_df until couple of days ago. Only difference is that DF-packets-larger-than MTU now discarded earlier (f.e. we avoid pointless netfilter postrouting trip). While at it, drop the repeated test ip_exceeds_mtu, checking it once is enough... Fixes: fe6cc55f ("net: ip, ipv6: handle gso skbs in forwarding path") Signed-off-by:
-
Liu Yu authored
commit b9f47a3a (tcp_cubic: limit delayed_ack ratio to prevent divide error) try to prevent divide error, but there is still a little chance that delayed_ack can reach zero. In case the param cnt get negative value, then ratio+cnt would overflow and may happen to be zero. As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero. In some old kernels, such as 2.6.32, there is a bug that would pass negative param, which then ultimately leads to this divide error. commit 5b35e1e6 (tcp: fix tcp_trim_head() to adjust segment count with skb MSS) fixed the negative param issue. However, it's safe that we fix the range of delayed_ack as well, to make sure we do not hit a divide by zero. CC: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
Liu Yu <allanyuliu@tencent.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Vlad Yasevich authored
This reverts commit 12a2856b. The commit above doesn't appear to be necessary any more as the checksums appear to be correctly computed/validated. Additionally the above commit breaks kvm configurations where one VM is using a device that support checksum offload (virtio) and the other VM does not. In this case, packets leaving virtio device will have CHECKSUM_PARTIAL set. The packets is forwarded to a macvtap that has offload features turned off. Since we use CHECKSUM_UNNECESSARY, the host does does not update the checksum and thus a bad checksum is passed up to the guest. CC: Daniel Lezcano <daniel.lezcano@free.fr> CC: Patrick McHardy <kaber@trash.net> CC: Andrian Nord <nightnord@gmail.com> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Michael S. Tsirkin <mst@redhat.com> CC: Jason Wang <jasowang@redhat.com> Signed-off-by:
Vlad Yasevich <vyasevic@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Xufeng Zhang authored
commit 813b3b5d (ipv4: Use caller's on-stack flowi as-is in output route lookups.) introduces another regression which is very similar to the problem of commit e6b45241 (ipv4: reset flowi parameters on route connect) wants to fix: Before we call ip_route_output_key() in sctp_v4_get_dst() to get a dst that matches a bind address as the source address, we have already called this function previously and the flowi parameters have been initialized including flowi4_oif, so when we call this function again, the process in __ip_route_output_key() will be different because of the setting of flowi4_oif, and we'll get a networking device which corresponds to the inputted flowi4_oif as the output device, this is wrong because we'll never hit this place if the previously returned source address of dst match one of the bound addresses. To reproduce this problem, a vlan setting is enough: # ifconfig eth0 up # route del default # vconfig add eth0 2 # vconfig add eth0 3 # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0 # route add default gw 10.0.1.254 dev eth0.2 # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0 # ip rule add from 10.0.0.14 table 4 # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3 # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I You'll detect that all the flow are routed to eth0.2(10.0.1.254). Signed-off-by:
Xufeng Zhang <xufeng.zhang@windriver.com> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Toshiaki Makita authored
When bridge device is created with IFLA_ADDRESS, we are not calling br_stp_change_bridge_id(), which leads to incorrect local fdb management and bridge id calculation, and prevents us from receiving frames on the bridge device. Reported-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by:
-
