- 05 Jan, 2015 20 commits
-
-
Vitaly Kuznetsov authored
commit 31d4ea1a upstream. An attempt to fix fcopy on i586 (bc5a5b02 Drivers: hv: util: Properly pack the data for file copy functionality) led to a regression on x86_64 (and actually didn't fix i586 breakage). Fcopy messages from Hyper-V host come in the following format: struct do_fcopy_hdr | 36 bytes 0000 | 4 bytes offset | 8 bytes size | 4 bytes data | 6144 bytes On x86_64 struct hv_do_fcopy matched this format without ' __attribute__((packed))' and on i586 adding ' __attribute__((packed))' to it doesn't change anything. Keep the structure packed and add padding to match re reality. Tested both i586 and x86_64 on Hyper-V Server 2012 R2. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Richard Weinberger authored
commit f38aed97 upstream. The logic of vfree()'ing vol->upd_buf is tied to vol->updating. In ubi_start_update() vol->updating is set long before vmalloc()'ing vol->upd_buf. If we encounter a write failure in ubi_start_update() before vmalloc() the UBI device release function will try to vfree() vol->upd_buf because vol->updating is set. Fix this by allocating vol->upd_buf directly after setting vol->updating. Fixes: [ 31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, volume is damaged [ 31.559340] ------------[ cut here ]------------ [ 31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 __vunmap+0xe3/0x110() [ 31.559344] Trying to vfree() nonexistent vm area (ffffc90001f2b000) [ 31.559345] Modules linked in: [ 31.565620] 0000000000000bba ffff88002a0cbdb0 ffffffff818f0497 ffff88003b9ba148 [ 31.566347] ffff88002a0cbde0 ffffffff8156f515 ffff88003b9ba148 0000000000000bba [ 31.567073] 0000000000000000 0000000000000000 ffff88002a0cbe88 ffffffff8156c10a [ 31.567793] Call Trace: [ 31.568034] [<ffffffff818f0497>] dump_stack+0x4e/0x7a [ 31.568510] [<ffffffff8156f515>] ubi_io_write_vid_hdr+0x155/0x160 [ 31.569084] [<ffffffff8156c10a>] ubi_eba_write_leb+0x23a/0x870 [ 31.569628] [<ffffffff81569b36>] vol_cdev_write+0x226/0x380 [ 31.570155] [<ffffffff81179265>] vfs_write+0xb5/0x1f0 [ 31.570627] [<ffffffff81179f8a>] SyS_pwrite64+0x6a/0xa0 [ 31.571123] [<ffffffff818fde12>] system_call_fastpath+0x16/0x1b Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Richard Weinberger authored
commit aa5ad3b6 upstream. If the erase worker is unable to erase a PEB it will free the ubi_wl_entry itself. The failing ubi_wl_entry must not free()'d again after do_sync_erase() returns. Signed-off-by:
-
Christian Borntraeger authored
commit 2dca485f upstream. some control register changes will flush some aspects of the CPU, e.g. POP explicitely mentions that for CR9-CR11 "TLBs may be cleared". Instead of trying to be clever and only flush on specific CRs, let play safe and flush on all lctl(g) as future machines might define new bits in CRs. Load control intercept should not happen that often. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
Christian Borntraeger authored
commit 1365039d upstream. ipte_unlock_siif uses cmpxchg to replace the in-memory data of the ipte lock together with ACCESS_ONCE for the intial read. union ipte_control { unsigned long val; struct { unsigned long k : 1; unsigned long kh : 31; unsigned long kg : 32; }; }; [...] static void ipte_unlock_siif(struct kvm_vcpu *vcpu) { union ipte_control old, new, *ic; ic = &vcpu->kvm->arch.sca->ipte_control; do { new = old = ACCESS_ONCE(*ic); new.kh--; if (!new.kh) new.k = 0; } while (cmpxchg(&ic->val, old.val, new.val) != old.val); if (!new.kh) wake_up(&vcpu->kvm->arch.ipte_wq); } The new value, is loaded twice from memory with gcc 4.7.2 of fedora 18, despite the ACCESS_ONCE: ---> l %r4,0(%r3) <--- load first 32 bit of lock (k and kh) in r4 alfi %r4,2147483647 <--- add -1 to r4 llgtr %r4,%r4 <--- zero out the sign bit of r4 lg %r1,0(%r3) <--- load all 64 bit of lock into new lgr %r2,%r1 <--- load the same into old risbg %r1,%r4,1,31,32 <--- shift and insert r4 into the bits 1-31 of new llihf %r4,2147483647 ngrk %r4,%r1,%r4 jne aa0 <ipte_unlock+0xf8> nihh %r1,32767 lgr %r4,%r2 csg %r4,%r1,0(%r3) cgr %r2,%r4 jne a70 <ipte_unlock+0xc8> If the memory value changes between the first load (l) and the second load (lg) we are broken. If that happens VCPU threads will hang (unkillable) in handle_ipte_interlock. Andreas Krebbel analyzed this and tracked it down to a compiler bug in that version: "while it is not that obvious the C99 standard basically forbids duplicating the memory access also in that case. For an argumentation of a similiar case please see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278#c43 For the implementation-defined cases regarding volatile there are some GCC-specific clarifications which can be found here: https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html#Volatiles I've tracked down the problem with a reduced testcase. The problem was that during a tree level optimization (SRA - scalar replacement of aggregates) the volatile marker is lost. And an RTL level optimizer (CSE - common subexpression elimination) then propagated the memory read into its second use introducing another access to the memory location. So indeed Christian's suspicion that the union access has something to do with it is correct (since it triggered the SRA optimization). This issue has been reported and fixed in the GCC 4.8 development cycle: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145" This patch replaces the ACCESS_ONCE scheme with a barrier() based scheme that should work for all supported compilers. Signed-off-by:
-
Kazuya Mizuguchi authored
commit 11432050 upstream. This patch fixes an issue that the NULL pointer dereference happens when we uses g_audio driver. Since the g_audio driver will call usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(), the uep->pipe of renesas usbhs driver will be NULL. So, this patch adds a condition to avoid the oops. Signed-off-by:
Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: 2f98382d (usb: renesas_usbhs: Add Renesas USBHS Gadget) Signed-off-by:
Felipe Balbi <balbi@ti.com> [ luis: backported to 3.16: replaced pipe by uep->pipe ] Signed-off-by:
-
Tejun Heo authored
commit 9c6ac78e upstream. After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and tests inode->i_state locklessly to see whether it already has all the necessary I_DIRTY bits set. The comment above the barrier doesn't contain any useful information - memory barriers can't ensure "changes are seen by all cpus" by itself. And it sure enough was broken. Please consider the following scenario. CPU 0 CPU 1 ------------------------------------------------------------------------------- enters __writeback_single_inode() grabs inode->i_lock tests PAGECACHE_TAG_DIRTY which is clear enters __set_page_dirty() grabs mapping->tree_lock sets PAGECACHE_TAG_DIRTY releases mapping->tree_lock leaves __set_page_dirty() enters __mark_inode_dirty() smp_mb() sees I_DIRTY_PAGES set leaves __mark_inode_dirty() clears I_DIRTY_PAGES releases inode->i_lock Now @inode has dirty pages w/ I_DIRTY_PAGES clear. This doesn't seem to lead to an immediately critical problem because requeue_inode() later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when deciding whether the inode needs to be requeued for IO and there are enough unintentional memory barriers inbetween, so while the inode ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the IO list. The lack of explicit barrier may also theoretically affect the other I_DIRTY bits which deal with metadata dirtiness. There is no guarantee that a strong enough barrier exists between I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied inode. Filesystem inode writeout path likely has enough stuff which can behave as full barrier but it's theoretically possible that the writeout may not see all the updates from ->dirty_inode(). Fix it by adding an explicit smp_mb() after I_DIRTY clearing. Note that I_DIRTY_PAGES needs a special treatment as it always needs to be cleared to be interlocked with the lockless test on __mark_inode_dirty() side. It's cleared unconditionally and reinstated after smp_mb() if the mapping still has dirty pages. Also add comments explaining how and why the barriers are paired. Lightly tested. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Frank Schaefer authored
commit 22799487 upstream. This patches fixes an ancient bug in the dvb_usb_af9005 driver, which has been reported at least in the following threads: https://lkml.org/lkml/2009/2/4/350 https://lkml.org/lkml/2014/9/18/558 If the driver is compiled in without any IR support (neither DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in af9005_usb_module_init() return pointers != NULL although the IR symbols are not available. This leads to the following oops: ... [ 8.529751] usbcore: registered new interface driver dvb_usb_af9005 [ 8.531584] BUG: unable to handle kernel paging request at 02e00000 [ 8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d [ 8.535613] *pde = 00000000 [ 8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC [ 8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075cf #1 [ 8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000 [ 8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0 [ 8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d [ 8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000 [ 8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c [ 8.541519] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690 [ 8.541519] Stack: [ 8.541519] 7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968 [ 8.541519] 89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200 [ 8.541519] 7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6 [ 8.541519] Call Trace: [ 8.541519] [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16 [ 8.541519] [<7d992a49>] do_one_initcall+0x77/0x106 [ 8.541519] [<7be3a800>] ? parameqn+0x2/0x35 [ 8.541519] [<7be3a966>] ? parse_args+0x113/0x25c [ 8.541519] [<7d992bc2>] kernel_init_freeable+0xea/0x167 [ 8.541519] [<7cf01070>] kernel_init+0x8/0xb8 [ 8.541519] [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30 [ 8.541519] [<7cf01068>] ? rest_init+0x10c/0x10c [ 8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb [ 8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c [ 8.541519] CR2: 0000000002e00000 [ 8.541519] ---[ end trace 768b6faf51370fc7 ]--- The prefered fix would be to convert the whole IR code to use the kernel IR infrastructure (which wasn't available at the time this driver had been created). Until anyone who still has this old hardware steps up an does the conversion, fix it by not calling the symbol_request calls if the driver is compiled in without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE). Due to the IR related pointers beeing NULL by default, IR support will then be disabled. The downside of this solution is, that it will no longer be possible to compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in. Please note that this patch has NOT been tested with all possible cases. I don't have the hardware and could only verify that it fixes the reported bug. Reported-by:
Fengguag Wu <fengguang.wu@intel.com> Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by:
Luca Olivetti <luca@ventoso.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 678fa12f upstream. The au0828 quirks table is currently not in sync with the au0828 media driver. Syncronize it and put them on the same order as found at au0828 driver, as all the au0828 devices with analog TV need the same quirks. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 5d1f00a2 upstream. Add a macro to simplify au0828 quirk table. That makes easier to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c. Signed-off-by:
-
Johan Hedberg authored
commit 980ffc0a upstream. The le_conn_timeout() may call hci_le_conn_failed() which in turn may call hci_conn_del(). Trying to use the _sync variant for cancelling the conn timeout from hci_conn_del() could therefore result in a deadlock. This patch converts hci_conn_del() to use the non-sync variant so the deadlock is not possible. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Sakari Ailus authored
commit bc47150a upstream. The PLL flags were not used correctly. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
commit f85698cd upstream. The mutex does not serialise anything in this case but avoids a lockdep warning from the control framework. Signed-off-by:
-
Thomas Huth authored
commit a36c5393 upstream. The monitor-class number field is only 16 bits, so we have to use a u16 pointer to access it. Signed-off-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Reviewed-by:
-
Markus Pargmann authored
commit fe08be3e upstream. The code reads the default voltage selector from its register. If the bootloader disables the regulator, the default voltage selector will be 0 which results in faulty behaviour of this regulator driver. This patch sets a default voltage selector for vddpu if it is not set in the register. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Mark Fasheh authored
commit 0b4699dc upstream. btrfs_drop_snapshot() leaves subvolume qgroup items on disk after completion. This can cause problems with snapshot creation. If a new snapshot tries to claim the deleted subvolumes id, btrfs will get -EEXIST from add_qgroup_item() and go read-only. The following commands will reproduce this problem (assume btrfs is on /dev/sda and is mounted at /btrfs) mkfs.btrfs -f /dev/sda mount -t btrfs /dev/sda /btrfs/ btrfs quota enable /btrfs/ btrfs su sna /btrfs/ /btrfs/snap btrfs su de /btrfs/snap sleep 45 umount /btrfs/ mount -t btrfs /dev/sda /btrfs/ We can fix this by catching -EEXIST in add_qgroup_item() and initializing the existing items. We have the problem of orphaned relation items being on disk from an old snapshot but that is outside the scope of this patch. Signed-off-by:
Mark Fasheh <mfasheh@suse.de> Signed-off-by:
Chris Mason <clm@fb.com> Cc: Sebastiaan L. Zoutendijk <baszoutendijk@gmail.com> Signed-off-by:
-
Martin Schwidefsky authored
commit e512d56c upstream. git commit 37f81fa1 "n_tty: do O_ONLCR translation as a single write" surfaced a bug in the 3215 device driver. In combination this broke tab expansion for tty ouput. The cause is an asymmetry in the behaviour of tty3215_ops->write vs tty3215_ops->put_char. The put_char function scans for '\t' but the write function does not. As the driver has logic for the '\t' expansion remove XTABS from c_oflag of the initial termios as well. Reported-by:
Stephen Powell <zlinuxman@wowway.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Martin Schwidefsky authored
commit 26d766c6 upstream. The ccw_device_start in raw3215_start_io can fail. raw3215_try_io does not check if the request could be started and removes any pending timer. This can leave the system in a hanging state. Check for pending request after raw3215_start_io and start a timer if necessary. Signed-off-by:
-
Jesse Gross authored
commit cfdf1e1b upstream. When doing GRO processing for UDP tunnels, we never add SKB_GSO_UDP_TUNNEL to gso_type - only the type of the inner protocol is added (such as SKB_GSO_TCPV4). The result is that if the packet is later resegmented we will do GSO but not treat it as a tunnel. This results in UDP fragmentation of the outer header instead of (i.e.) TCP segmentation of the inner header as was originally on the wire. Signed-off-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> [ luis: backported to 3.16: - dropped changes to net/ipv4/fou.c - inlined call to udp_tunnel_gro_complete() in drivers/net/vxlan.c ] Signed-off-by:
-
Jani Nikula authored
commit 7809a611 upstream. Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by:
Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte <tprevite@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Cc: Ben Hutchings <ben@decadent.org.uk> [ luis: backported to 3.16: - use dev instead of dev_priv in IS_HASWELL() and INTEL_INFO() ] Signed-off-by:
-
- 30 Dec, 2014 1 commit
-
-
Scot Doyle authored
commit 813008cd upstream. BIOS or firmware can modify hardware state during suspend/resume, for example on the Toshiba CB35 or Lenovo T400, so log a debug message instead of a warning if the backlight is unexpectedly enabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80930 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Scot Doyle <lkml14@scotdoyle.com> Signed-off-by:
-
- 19 Dec, 2014 1 commit
-
-
Luis Henriques authored
Signed-off-by:
-
- 15 Dec, 2014 17 commits
-
-
Todd Fujinaka authored
commit aec653c4 upstream. Call igb_setup_link() when the PHY is powered up. Signed-off-by:
Todd Fujinaka <todd.fujinaka@intel.com> Reported-by:
Jeff Westfahl <jeff.westfahl@ni.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Vincent Donnefort <vdonnefort@gmail.com> Signed-off-by:
-
Andreas Noever authored
commit bceee4a9 upstream. pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's secondary bus, exists. But we do not create that bus if we run out of bus numbers during enumeration. This leads to a NULL dereference in init_slot() (and other places). Change pciehp_probe() to return -ENODEV when no secondary bus is present. Signed-off-by:
Andreas Noever <andreas.noever@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
-
Joonyoung Shim authored
commit 526a4045 upstream. The usb device will autoresume from choose_wakeup() if it is autosuspended with the wrong wakeup setting, but below errors occur because usb3503 misc driver will switch to standby mode when suspended. As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from autosuspend_check(). [ 7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 7.854658] usb 1-3: device descriptor read/64, error -71 [ 8.079657] usb 1-3: device descriptor read/64, error -71 [ 8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 8.414658] usb 1-3: device descriptor read/64, error -71 [ 8.639657] usb 1-3: device descriptor read/64, error -71 [ 8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.264598] usb 1-3: device not accepting address 3, error -71 [ 9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.784601] usb 1-3: device not accepting address 3, error -71 [ 9.784838] usb usb1-port3: device 1-3 not suspended yet Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
-
Andy Lutomirski authored
commit 7ddc6a21 upstream. These functions can be executed on the int3 stack, so kprobes are dangerous. Tracing is probably a bad idea, too. Fixes: b645af2d ("x86_64, traps: Rework bad_iret") Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Alexander Kochetkov authored
commit ccfc8663 upstream. commit 6d9939f6 (i2c: omap: split out [XR]DR and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly Set) get handled. 6d9939f6 code doesn't correspond to workaround provided by errata. According to errata ISR must filter out spurious RDR before data read not after. ISR must read RXSTAT to get number of bytes available to read. Because RDR could be set while there could no data in the receive FIFO. Restored pre 6d9939f6 way of handling errata. Found by code review. Real impact haven't seen. Tested on Beagleboard XM C. Signed-off-by:
Alexander Kochetkov <al.kochet@gmail.com> Fixes: 6d9939f6 i2c: omap: split out [XR]DR and [XR]RDY Tested-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Daniel Borkmann authored
commit 9772b54c upstream. To accomodate for enough headroom for tunnels, use MAX_HEADER instead of LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs of trinity an skb_under_panic() via SCTP output path (see reference). I couldn't reproduce it from here, but not using MAX_HEADER as elsewhere in other protocols might be one possible cause for this. In any case, it looks like accounting on chunks themself seems to look good as the skb already passed the SCTP output path and did not hit any skb_over_panic(). Given tunneling was enabled in his .config, the headroom would have been expanded by MAX_HEADER in this case. Reported-by:
Robert Święcki <robert@swiecki.net> Reference: https://lkml.org/lkml/2014/12/1/507 Fixes: 594ccc14 ("[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().") Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Eric Dumazet authored
commit 5f478b41 upstream. mvneta_tx() dereferences skb to get skb->len too late, as hardware might have completed the transmit and TX completion could have freed the skb from another cpu. Fixes: 71f6d1b3 ("net: mvneta: replace Tx timer with a real interrupt") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
willy tarreau authored
commit aebea2ba upstream. The mvneta driver sets the amount of Tx coalesce packets to 16 by default. Normally that does not cause any trouble since the driver uses a much larger Tx ring size (532 packets). But some sockets might run with very small buffers, much smaller than the equivalent of 16 packets. This is what ping is doing for example, by setting SNDBUF to 324 bytes rounded up to 2kB by the kernel. The problem is that there is no documented method to force a specific packet to emit an interrupt (eg: the last of the ring) nor is it possible to make the NIC emit an interrupt after a given delay. In this case, it causes trouble, because when ping sends packets over its raw socket, the few first packets leave the system, and the first 15 packets will be emitted without an IRQ being generated, so without the skbs being freed. And since the socket's buffer is small, there's no way to reach that amount of packets, and the ping ends up with "send: no buffer available" after sending 6 packets. Running with 3 instances of ping in parallel is enough to hide the problem, because with 6 packets per instance, that's 18 packets total, which is enough to grant a Tx interrupt before all are sent. The original driver in the LSP kernel worked around this design flaw by using a software timer to clean up the Tx descriptors. This timer was slow and caused terrible network performance on some Tx-bound workloads (such as routing) but was enough to make tools like ping work correctly. Instead here, we simply set the packet counts before interrupt to 1. This ensures that each packet sent will produce an interrupt. NAPI takes care of coalescing interrupts since the interrupt is disabled once generated. No measurable performance impact nor CPU usage were observed on small nor large packets, including when saturating the link on Tx, and this fixes tools like ping which rely on too small a send buffer. If one wants to increase this value for certain workloads where it is safe to do so, "ethtool -C $dev tx-frames" will override this default setting. This fix needs to be applied to stable kernels starting with 3.10. Tested-By:
Maggie Mae Roxas <maggie.mae.roxas@gmail.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Denis Kirjanov authored
commit 2e46477a upstream. Remove optimize_div() from BPF_MOD | BPF_K case since we don't know the dividend and fix the emit_mod() by reading the mod operation result from HI register Signed-off-by:
Denis Kirjanov <kda@linux-powerpc.org> Reviewed-by:
Markos Chandras <markos.chandras@imgtec.com> Signed-off-by:
-
Tom Herbert authored
commit 6fb2a756 upstream. Set the inner mac header to point to the GRE payload when doing GRO. This is needed if we proceed to send the packet through GRE GSO which now uses the inner mac header instead of inner network header to determine the length of encapsulation headers. Fixes: 14051f04 ("gre: Use inner mac length when computing tunnel length") Reported-by:
Wolfgang Walter <linux@stwm.de> Signed-off-by:
Tom Herbert <therbert@google.com> Signed-off-by:
-
Nicolas Dichtel authored
commit e0ebde0e upstream. rtnl_link_get_net() holds a reference on the 'struct net', we need to release it in case of error. CC: Eric W. Biederman <ebiederm@xmission.com> Fixes: b51642f6 ("net: Enable a userns root rtnl calls that are safe for unprivilged users") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Thomas Graf authored
commit f6c6fda4 upstream. Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support") Reported-by:
John Fastabend <john.fastabend@gmail.com> Cc: Scott Feldman <sfeldma@cumulusnetworks.com> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Acked-by:
John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
-
Jack Morgenstein authored
commit 2d5c57d7 upstream. Some VF drivers use the upper byte of "param1" (the qp count field) in mlx4_qp_reserve_range() to pass flags which are used to optimize the range allocation. Under the current code, if any of these flags are set, the 32-bit count field yields a count greater than 2^24, which is out of range, and this VF fails. As these flags represent a "best-effort" allocation hint anyway, they may safely be ignored. Therefore, the PF driver may simply mask out the bits. Fixes: c82e9aa0 "mlx4_core: resource tracking for HCA resources used by guests" Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
commit a620a6bc upstream. If TX channels are set to 4 and RX channels are set to less than 4, using ethtool -L, the driver will try to initialize more RX channels than it has allocated, causing an oops. This fix only initializes the RX ring if it has been allocated. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Marcelo Leitner authored
commit 00c83b01 upstream. Currently, when trying to reuse a socket, vxlan_sock_add will grab vn->sock_lock, locate a reusable socket, inc refcount and release vn->sock_lock. But vxlan_sock_release() will first decrement refcount, and then grab that lock. refcnt operations are atomic but as currently we have deferred works which hold vs->refcnt each, this might happen, leading to a use after free (specially after vxlan_igmp_leave): CPU 1 CPU 2 deferred work vxlan_sock_add ... ... spin_lock(&vn->sock_lock) vs = vxlan_find_sock(); vxlan_sock_release dec vs->refcnt, reaches 0 spin_lock(&vn->sock_lock) vxlan_sock_hold(vs), refcnt=1 spin_unlock(&vn->sock_lock) hlist_del_rcu(&vs->hlist); vxlan_notify_del_rx_port(vs) spin_unlock(&vn->sock_lock) So when we look for a reusable socket, we check if it wasn't freed already before reusing it. Signed-off-by:
Marcelo Ricardo Leitner <mleitner@redhat.com> Fixes: 7c47cedf ("vxlan: move IGMP join/leave to work queue") Signed-off-by:
-
Yuri Chislov authored
commit be6572fd upstream. When using GRE redirection in WCCP, it sets the wrong skb->protocol, that is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic. Fixes: c12b395a ("gre: Support GRE over IPv6") Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by:
Yuri Chislov <yuri.chislov@gmail.com> Tested-by:
-
lucien authored
commit 20ea60ca upstream. Now the vti_link_ops do not point the .dellink, for fb tunnel device (ip_vti0), the net_device will be removed as the default .dellink is unregister_netdevice_queue,but the tunnel still in the tunnel list, then if we add a new vti tunnel, in ip_tunnel_find(): hlist_for_each_entry_rcu(t, head, hash_node) { if (local == t->parms.iph.saddr && remote == t->parms.iph.daddr && link == t->parms.link && ==> type == t->dev->type && ip_tunnel_key_match(&t->parms, flags, key)) break; } the panic will happen, cause dev of ip_tunnel *t is null: [ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel] [ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0 [ 3835.073008] Oops: 0000 [#1] SMP ..... [ 3835.073008] Stack: [ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0 [ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858 [ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000 [ 3835.073008] Call Trace: [ 3835.073008] [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel] [ 3835.073008] [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti] [ 3835.073008] [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0 [ 3835.073008] [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70 [ 3835.073008] [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60 [ 3835.073008] [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0 [ 3835.073008] [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270 [ 3835.073008] [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90 [ 3835.073008] [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30 [ 3835.073008] [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0 [ 3835.073008] [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30 .... modprobe ip_vti ip link del ip_vti0 type vti ip link add ip_vti0 type vti rmmod ip_vti do that one or more times, kernel will panic. fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in which we skip the unregister of fb tunnel device. do the same on ip6_vti. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Cong Wang <cwang@twopensource.com> Signed-off-by:
-
- 10 Dec, 2014 1 commit
-
-
Christian König authored
commit 86b27638 upstream. Not just the userspace relocs, otherwise we won't wait for a swapped out page tables to be swapped in again. v2: rebased on Alex current drm-fixes-3.18 Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> [ luis: backported to 3.16: used Christian's backport to 3.17 ] Signed-off-by:
-
