- 01 Aug, 2014 3 commits
-
-
David Vrabel authored
Since netfront may reconnect to a backend with a different number of queues, all per-queue Rx and Tx resources (skbs and grant references) should be freed when disconnecting. Without this fix, the Tx and Rx grant refs are not released and netfront will exhaust them after only a few reconnections. netfront will fail to connect when no free grant references are available. Since all Rx bufs are freed and reallocated instead of reused this will add some additional delay to the reconnection but this is expected to be small compared to the time taken by any backend hotplug scripts etc. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Vrabel authored
If no queues could be created when connecting to the backend, one of the error paths would deadlock. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vlad Yasevich authored
Macvlan devices do not initialize vlan_features. As a result, any vlan devices configured on top of macvlans perform very poorly. Initialize vlan_features based on the vlan features of the lower-level device. Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 31 Jul, 2014 5 commits
-
-
Toshiaki Makita authored
An FDB entry with vlan_id 0 doesn't mean it is used in vlan 0, but used when vlan_filtering is disabled. There is inconsistency around NDA_VLAN whose payload is 0 - even if we add an entry by RTM_NEWNEIGH without any NDA_VLAN, and even though adding an entry with NDA_VLAN 0 is prohibited, we get an entry with NDA_VLAN 0 by RTM_GETNEIGH. Dumping an FDB entry with vlan_id 0 shouldn't include NDA_VLAN. Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Veaceslav Falico authored
Otherwise the name of the kobject isn't getting freed and other stuff from kobject_cleanup() isn't getting called. kobject_put() will call kobject_del() on its own in kobject_cleanup(). CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Veaceslav Falico <vfalico@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
The recent commit "e29aa339 bna: Enable Multi Buffer RX" is causing a performance regression. It does not properly update 'cmpl' pointer at the end of the loop in NAPI handler bnad_cq_process(). The result is only one packet / per NAPI-schedule is processed. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Christoph Paasch authored
In vegas we do a multiplication of the cwnd and the rtt. This may overflow and thus their result is stored in a u64. However, we first need to cast the cwnd so that actually 64-bit arithmetic is done. Then, we need to do do_div to allow this to be used on 32-bit arches. Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Neal Cardwell <ncardwell@google.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Doug Leith <doug.leith@nuim.ie> Fixes: 8d3a564d (tcp: tcp_vegas cong avoid fix) Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Christoph Paasch authored
In veno we do a multiplication of the cwnd and the rtt. This may overflow and thus their result is stored in a u64. However, we first need to cast the cwnd so that actually 64-bit arithmetic is done. A first attempt at fixing 76f10177 ([TCP]: TCP Veno congestion control) was made by 15913114 (tcp: Overflow bug in Vegas), but it failed to add the required cast in tcp_veno_cong_avoid(). Fixes: 76f10177 ([TCP]: TCP Veno congestion control) Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 30 Jul, 2014 12 commits
-
-
Dmitry Popov authored
Ipv4 tunnels created with "local any remote $ip" didn't work properly since 7d442fab (ipv4: Cache dst in tunnels). 99% of packets sent via those tunnels had src addr = 0.0.0.0. That was because only dst_entry was cached, although fl4.saddr has to be cached too. Every time ip_tunnel_xmit used cached dst_entry (tunnel_rtable_get returned non-NULL), fl4.saddr was initialized with tnl_params->saddr (= 0 in our case), and wasn't changed until iptunnel_xmit(). This patch adds saddr to ip_tunnel->dst_cache, fixing this issue. Reported-by: Sergey Popov <pinkbyte@gentoo.org> Signed-off-by: Dmitry Popov <ixaphire@qrator.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
A driver should fill magic field of ethtool_eeprom struct in .get_eeprom and validate it in .set_eeprom. The bna incorrectly validates it in both and this makes its .get_eeprom interface unusable. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.secretlab.ca/git/linuxLinus Torvalds authored
Pull Exynos platform DT fix from Grant Likely: "Device tree Exynos bug fix for v3.16-rc7 This bug fix has been brewing for a while. I hate sending it to you so late, but I only got confirmation that it solves the problem this past weekend. The diff looks big for a bug fix, but the majority of it is only executed in the Exynos quirk case. Unfortunately it required splitting early_init_dt_scan() in two and adding quirk handling in the middle of it on ARM. Exynos has buggy firmware that puts bad data into the memory node. Commit 1c2f87c2 ("ARM: Get rid of meminfo") exposed the bug by dropping the artificial upper bound on the number of memory banks that can be added. Exynos fails to boot after that commit. This branch fixes it by splitting the early DT parse function and inserting a fixup hook. Exynos uses the hook to correct the DT before parsing memory regions" * tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux: arm: Add devicetree fixup machine function of: Add memory limiting function for flattened devicetrees of: Split early_init_dt_scan into two parts
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull Xen fix from David Vrabel: "Fix BUG when trying to expand the grant table. This seems to occur often during boot with Ubuntu 14.04 PV guests" * tag 'stable/for-linus-3.16-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: safely map and unmap grant frames when in atomic context
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM fix from Paolo Bonzini: "Fix a bug which allows KVM guests to bring down the entire system on some 64K enabled ARM64 hosts" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform
-
Linus Torvalds authored
This reverts commit 20fbe3ae. As reported by Stephen Rothwell, it causes compile failures in certain configurations: drivers/net/usb/cdc_subset.c:360:15: error: 'dummy_prereset' undeclared here (not in a function) .pre_reset = dummy_prereset, ^ drivers/net/usb/cdc_subset.c:361:16: error: 'dummy_postreset' undeclared here (not in a function) .post_reset = dummy_postreset, ^ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: David Miller <davem@davemloft.net> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Make fragmentation IDs less predictable, from Eric Dumazet. 2) TSO tunneling can crash in bnx2x driver, fix from Dmitry Kravkov. 3) Don't allow NULL msg->msg_name just because msg->msg_namelen is non-zero, from Andrey Ryabinin. 4) ndm->ndm_type set using wrong macros, from Jun Zhao. 5) cdc-ether devices can come up with entries in their address filter, so explicitly clear the filter after the device initializes. From Oliver Neukum. 6) Forgotten refcount bump in xfrm_lookup(), from Steffen Klassert. 7) Short packets not padded properly, exposing random data, in bcmgenet driver. Fix from Florian Fainelli. 8) xgbe_probe() doesn't return an error code, but rather zero, when netif_set_real_num_tx_queues() fails. Fix from Wei Yongjun. 9) USB speed not probed properly in r8152 driver, from Hayes Wang. 10) Transmit logic choosing the outgoing port in the sunvnet driver needs to consider a) is the port actually up and b) whether it is a switch port. Fix from David L Stevens. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits) net: phy: re-apply PHY fixups during phy_register_device cdc-ether: clean packet filter upon probe cdc_subset: deal with a device that needs reset for timeout net: sendmsg: fix NULL pointer dereference isdn/bas_gigaset: fix a leak on failure path in gigaset_probe() ip: make IP identifiers less predictable neighbour : fix ndm_type type error issue sunvnet: only use connected ports when sending can: c_can_platform: Fix raminit, use devm_ioremap() instead of devm_ioremap_resource() bnx2x: fix crash during TSO tunneling r8152: fix the checking of the usb speed net: phy: Ensure the MDIO bus module is held net: phy: Set the driver when registering an MDIO bus device bnx2x: fix set_setting for some PHYs hyperv: Fix error return code in netvsc_init_buf() amd-xgbe: Fix error return code in xgbe_probe() ath9k: fix aggregation session lockup net: bcmgenet: correctly pad short packets net: sctp: inherit auth_capable on INIT collisions mac80211: fix crash on getting sta info with uninitialized rate control ...
-
David Vrabel authored
arch_gnttab_map_frames() and arch_gnttab_unmap_frames() are called in atomic context but were calling alloc_vm_area() which might sleep. Also, if a driver attempts to allocate a grant ref from an interrupt and the table needs expanding, then the CPU may already by in lazy MMU mode and apply_to_page_range() will BUG when it tries to re-enable lazy MMU mode. These two functions are only used in PV guests. Introduce arch_gnttab_init() to allocates the virtual address space in advance. Avoid the use of apply_to_page_range() by using saving and using the array of PTE addresses from the alloc_vm_area() call (which ensures that the required page tables are pre-allocated). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Will Deacon authored
If the physical address of GICV isn't page-aligned, then we end up creating a stage-2 mapping of the page containing it, which causes us to map neighbouring memory locations directly into the guest. As an example, consider a platform with GICV at physical 0x2c02f000 running a 64k-page host kernel. If qemu maps this into the guest at 0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will map host physical region 0x2c020000 - 0x2c02efff. Accesses to these physical regions may cause UNPREDICTABLE behaviour, for example, on the Juno platform this will cause an SError exception to EL3, which brings down the entire physical CPU resulting in RCU stalls / HYP panics / host crashing / wasted weeks of debugging. SBSA recommends that systems alias the 4k GICV across the bounding 64k region, in which case GICV physical could be described as 0x2c020000 in the above scenario. This patch fixes the problem by failing the vgic probe if the physical base address or the size of GICV aren't page-aligned. Note that this generated a warning in dmesg about freeing enabled IRQs, so I had to move the IRQ enabling later in the probe. Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Joel Schopp <joel.schopp@amd.com> Cc: Don Dutile <ddutile@redhat.com> Acked-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Joel Schopp <joel.schopp@amd.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
-
Laura Abbott authored
Commit 1c2f87c2 (ARM: 8025/1: Get rid of meminfo) dropped the upper bound on the number of memory banks that can be added as there was no technical need in the kernel. It turns out though, some bootloaders (specifically the arndale-octa exynos boards) may pass invalid memory information and rely on the kernel to not parse this data. This is a bug in the bootloader but we still need to work around this. Work around this by introducing a dt_fixup function. This function gets called before the flattened devicetree is scanned for memory and the like. In this fixup function for exynos, limit the maximum number of memory regions in the devicetree. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Tested-by: Andreas Färber <afaerber@suse.de> [glikely: Added a comment and fixed up function name] Signed-off-by: Grant Likely <grant.likely@linaro.org>
-
Laura Abbott authored
Buggy bootloaders may pass bogus memory entries in the devicetree. Add of_fdt_limit_memory to add an upper bound on the number of entries that can be present in the devicetree. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Tested-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Grant Likely <grant.likely@linaro.org>
-
Laura Abbott authored
Currently, early_init_dt_scan validates the header, sets the boot params, and scans for chosen/memory all in one function. Split this up into two separate functions (validation/setting boot params in one, scanning in another) to allow for additional setup between boot params and scanning the memory. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Tested-by: Andreas Färber <afaerber@suse.de> [glikely: s/early_init_dt_scan_all/early_init_dt_scan_nodes/] Signed-off-by: Grant Likely <grant.likely@linaro.org>
-
- 29 Jul, 2014 14 commits
-
-
Florian Fainelli authored
Commit 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()") moved the call to phy_scan_fixups() in phy_init_hw() after a software reset is performed. By the time phy_init_hw() is called in phy_device_register(), no driver has been bound to this PHY yet, so all the checks in phy_init_hw() against the PHY driver and the PHY driver's config_init function will return 0. We will therefore never call phy_scan_fixups() as we should. Fix this by calling phy_scan_fixups() and check for its return value to restore the intended functionality. This broke PHY drivers which do register an early PHY fixup callback to intercept the PHY probing and do things like changing the 32-bits unique PHY identifier when a pseudo-PHY address has been used, as well as board-specific PHY fixups that need to be applied during driver probe time. Reported-by: Hauke Merthens <hauke-m@hauke-m.de> Reported-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Oliver Neukum authored
There are devices that don't do reset all the way. So the packet filter should be set to a sane initial value. Failure to do so leads to intermittent failures of DHCP on some systems under some conditions. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Oliver Neukum authored
This device needs to be reset to recover from a timeout. Unfortunately this can be handled only at the level of the subdrivers. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrey Ryabinin authored
Sasha's report: > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel with the KASAN patchset, I've stumbled on the following spew: > > [ 4448.949424] ================================================================== > [ 4448.951737] AddressSanitizer: user-memory-access on address 0 > [ 4448.952988] Read of size 2 by thread T19638: > [ 4448.954510] CPU: 28 PID: 19638 Comm: trinity-c76 Not tainted 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813 > [ 4448.956823] ffff88046d86ca40 0000000000000000 ffff880082f37e78 ffff880082f37a40 > [ 4448.958233] ffffffffb6e47068 ffff880082f37a68 ffff880082f37a58 ffffffffb242708d > [ 4448.959552] 0000000000000000 ffff880082f37a88 ffffffffb24255b1 0000000000000000 > [ 4448.961266] Call Trace: > [ 4448.963158] dump_stack (lib/dump_stack.c:52) > [ 4448.964244] kasan_report_user_access (mm/kasan/report.c:184) > [ 4448.965507] __asan_load2 (mm/kasan/kasan.c:352) > [ 4448.966482] ? netlink_sendmsg (net/netlink/af_netlink.c:2339) > [ 4448.967541] netlink_sendmsg (net/netlink/af_netlink.c:2339) > [ 4448.968537] ? get_parent_ip (kernel/sched/core.c:2555) > [ 4448.970103] sock_sendmsg (net/socket.c:654) > [ 4448.971584] ? might_fault (mm/memory.c:3741) > [ 4448.972526] ? might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3740) > [ 4448.973596] ? verify_iovec (net/core/iovec.c:64) > [ 4448.974522] ___sys_sendmsg (net/socket.c:2096) > [ 4448.975797] ? put_lock_stats.isra.13 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254) > [ 4448.977030] ? lock_release_holdtime (kernel/locking/lockdep.c:273) > [ 4448.978197] ? lock_release_non_nested (kernel/locking/lockdep.c:3434 (discriminator 1)) > [ 4448.979346] ? check_chain_key (kernel/locking/lockdep.c:2188) > [ 4448.980535] __sys_sendmmsg (net/socket.c:2181) > [ 4448.981592] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600) > [ 4448.982773] ? trace_hardirqs_on (kernel/locking/lockdep.c:2607) > [ 4448.984458] ? syscall_trace_enter (arch/x86/kernel/ptrace.c:1500 (discriminator 2)) > [ 4448.985621] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2600) > [ 4448.986754] SyS_sendmmsg (net/socket.c:2201) > [ 4448.987708] tracesys (arch/x86/kernel/entry_64.S:542) > [ 4448.988929] ================================================================== This reports means that we've come to netlink_sendmsg() with msg->msg_name == NULL and msg->msg_namelen > 0. After this report there was no usual "Unable to handle kernel NULL pointer dereference" and this gave me a clue that address 0 is mapped and contains valid socket address structure in it. This bug was introduced in f3d33426 (net: rework recvmsg handler msg_name and msg_namelen logic). Commit message states that: "Set msg->msg_name = NULL if user specified a NULL in msg_name but had a non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't affect sendto as it would bail out earlier while trying to copy-in the address." But in fact this affects sendto when address 0 is mapped and contains socket address structure in it. In such case copy-in address will succeed, verify_iovec() function will successfully exit with msg->msg_namelen > 0 and msg->msg_name == NULL. This patch fixes it by setting msg_namelen to 0 if msg_name == NULL. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Eric Dumazet <edumazet@google.com> Cc: <stable@vger.kernel.org> Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexey Khoroshilov authored
There is a lack of usb_put_dev(udev) on failure path in gigaset_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Arnd Bergmann: "A nice small set of bug fixes for arm-soc: - two incorrect register addresses in DT files on shmobile and hisilicon - one revert for a regression on omap - one bug fix for a newly introduced pin controller binding - one regression fix for the memory controller on omap - one patch to avoid a harmless WARN_ON" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: Revert enabling of twl configuration for n900 ARM: dts: fix L2 address in Hi3620 ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable() pinctrl: dra: dt-bindings: Fix pull enable/disable ARM: shmobile: r8a7791: Fix SD2CKCR register address ARM: OMAP2+: l2c: squelch warning dump on power control setting
-
David Howells authored
Correctly assemble the client UUID by OR'ing in the flags rather than assigning them over the other components. Reported-by: Himangi Saraogi <himangi774@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
Fix kernel-doc warnings and function name in mm/page_alloc.c: Warning(..//mm/page_alloc.c:6074): No description found for parameter 'pfn' Warning(..//mm/page_alloc.c:6074): No description found for parameter 'mask' Warning(..//mm/page_alloc.c:6074): Excess function parameter 'start_bitidx' description in 'get_pfnblock_flags_mask' Warning(..//mm/page_alloc.c:6102): No description found for parameter 'pfn' Warning(..//mm/page_alloc.c:6102): No description found for parameter 'mask' Warning(..//mm/page_alloc.c:6102): Excess function parameter 'start_bitidx' description in 'set_pfnblock_flags_mask' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
Merge tag 'omap-for-v3.16/n900-regression' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "omap n900 regression fix for v3.16 rc series" from Tony Lindgren: Minimal regression fix for n900 display that got broken with enabling of twl4030 PM features. Turns out more work is needed before we can enable twl4030 PM on n900. I did not notice this earlier as I have my n900 in a rack and the display did not get enabled for device tree based booting until for v3.16. * tag 'omap-for-v3.16/n900-regression' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Revert enabling of twl configuration for n900 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Tony Lindgren authored
Commit 9188883f (ARM: dts: Enable twl4030 off-idle configuration for selected omaps) allowed n900 to cut off core voltages during off-idle. This however caused a regression where twl regulator vaux1 was not getting enabled for the LCD panel as we are not requesting it for the panel. Turns out quite a few devices on n900 are using vaux1, and we need to either stop idling it, or add proper regulator_get calls for all users. But until we have a proper solution implemented and tested, let's just disable the twl off-idle configuration for now for n900. Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Fixes: 9188883f (ARM: dts: Enable twl4030 off-idle configuration for selected omaps) Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Eric Dumazet authored
In "Counting Packets Sent Between Arbitrary Internet Hosts", Jeffrey and Jedidiah describe ways exploiting linux IP identifier generation to infer whether two machines are exchanging packets. With commit 73f156a6 ("inetpeer: get rid of ip_id_count"), we changed IP id generation, but this does not really prevent this side-channel technique. This patch adds a random amount of perturbation so that IP identifiers for a given destination [1] are no longer monotonically increasing after an idle period. Note that prandom_u32_max(1) returns 0, so if generator is used at most once per jiffy, this patch inserts no hole in the ID suite and do not increase collision probability. This is jiffies based, so in the worst case (HZ=1000), the id can rollover after ~65 seconds of idle time, which should be fine. We also change the hash used in __ip_select_ident() to not only hash on daddr, but also saddr and protocol, so that ICMP probes can not be used to infer information for other protocols. For IPv6, adds saddr into the hash as well, but not nexthdr. If I ping the patched target, we can see ID are now hard to predict. 21:57:11.008086 IP (...) A > target: ICMP echo request, seq 1, length 64 21:57:11.010752 IP (... id 2081 ...) target > A: ICMP echo reply, seq 1, length 64 21:57:12.013133 IP (...) A > target: ICMP echo request, seq 2, length 64 21:57:12.015737 IP (... id 3039 ...) target > A: ICMP echo reply, seq 2, length 64 21:57:13.016580 IP (...) A > target: ICMP echo request, seq 3, length 64 21:57:13.019251 IP (... id 3437 ...) target > A: ICMP echo reply, seq 3, length 64 [1] TCP sessions uses a per flow ID generator not changed by this patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jeffrey Knockel <jeffk@cs.unm.edu> Reported-by: Jedidiah R. Crandall <crandall@cs.unm.edu> Cc: Willy Tarreau <w@1wt.eu> Cc: Hannes Frederic Sowa <hannes@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jun Zhao authored
ndm_type means L3 address type, in neighbour proxy and vxlan, it's RTN_UNICAST. NDA_DST is for netlink TLV type, hence it's not right value in this context. Signed-off-by: Jun Zhao <mypopydev@gmail.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David L Stevens authored
The sunvnet driver doesn't check whether or not a port is connected when transmitting packets, which results in failures if a port fails to connect (e.g., due to a version mismatch). The original code also assumes unnecessarily that the first port is up and a switch, even though there is a flag for switch ports. This patch only matches a port if it is connected, and otherwise uses the switch_port flag to send the packet to a switch port that is up. Signed-off-by: David L Stevens <david.stevens@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://gitorious.org/linux-can/linux-canDavid S. Miller authored
Marc Kleine-Budde says: ==================== pull-request: can 2014-07-25 this is a pull request of one patch for the net tree, hoping to get into the 3.16 release. The patch by George Cherian fixes a regression in the c_can platform driver. When using two interfaces the regression leads to a non function second interface. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 28 Jul, 2014 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull ARM AES crypto fixes from Herbert Xu: "This push fixes a regression on ARM where odd-sized blocks supplied to AES may cause crashes" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: arm-aes - fix encryption of unaligned data crypto: arm64-aes - fix encryption of unaligned data
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
Pull powerpc fixes from Ben Herrenschmidt: "Here are 3 more small powerpc fixes that should still go into .16. One is a recent regression (MMCR2 business), the other is a trivial endian fix without which FW updates won't work on LE in IBM machines, and the 3rd one turns a BUG_ON into a WARN_ON which is definitely a LOT more friendly especially when the whole thing is about retrieving error logs ..." * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: Fix endianness of flash_block_list in rtas_flash powerpc/powernv: Change BUG_ON to WARN_ON in elog code powerpc/perf: Fix MMCR2 handling for EBB
-
Mikulas Patocka authored
Fix the same alignment bug as in arm64 - we need to pass residue unprocessed bytes as the last argument to blkcipher_walk_done. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # 3.13+ Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Mikulas Patocka authored
cryptsetup fails on arm64 when using kernel encryption via AF_ALG socket. See https://bugzilla.redhat.com/show_bug.cgi?id=1122937 The bug is caused by incorrect handling of unaligned data in arch/arm64/crypto/aes-glue.c. Cryptsetup creates a buffer that is aligned on 8 bytes, but not on 16 bytes. It opens AF_ALG socket and uses the socket to encrypt data in the buffer. The arm64 crypto accelerator causes data corruption or crashes in the scatterwalk_pagedone. This patch fixes the bug by passing the residue bytes that were not processed as the last parameter to blkcipher_walk_done. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Thomas Falcon authored
The function rtas_flash_firmware passes the address of a data structure, flash_block_list, when making the update-flash-64-and-reboot rtas call. While the endianness of the address is handled correctly, the endianness of the data is not. This patch ensures that the data in flash_block_list is big endian when passed to rtas on little endian hosts. Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Vasant Hegde authored
We can continue to read the error log (up to MAX size) even if we get the elog size more than MAX size. Hence change BUG_ON to WARN_ON. Also updated error message. Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Acked-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com> Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-