- 06 Apr, 2016 40 commits
-
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1557994Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Gal Pressman authored
BugLink: http://bugs.launchpad.net/bugs/1557950 Calling mlx5e_set_coalesce while the interface is down will result in modifying CQs that don't exist. Fixes: f62b8bb8 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by:
Gal Pressman <galp@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from linux-next commit 2fcb92fb) Signed-off-by:
-
Gal Pressman authored
BugLink: http://bugs.launchpad.net/bugs/1557950 If CQ moderation is not supported by the device, print a warning on netdevice load, and return error when trying to modify/query cq moderation via ethtool. Fixes: f62b8bb8 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by:
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1520454 A card can be removed while it is runtime suspended. Do not print an error message. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> (back ported from commit 520322d9) Signed-off-by:
-
Fu, Zhonghui authored
BugLink: http://bugs.launchpad.net/bugs/1520454 Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch enables MMC/SD/SDIO card and SDIO function devices to suspend/resume asynchronously. This will take advantage of multicore and improve system suspend/resume speed. After applying this patch and enabling all SDIO function's child devices to suspend/resume asynchronously on ASUS T100TA, the system suspend-to-idle time is reduced from 1645ms to 1108ms, and the system resume time is reduced from 940ms to 918ms. Signed-off-by:
Zhonghui Fu <zhonghui.fu@linux.intel.com> Signed-off-by:
-
Adrian Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1520454 The driver may not be able to set the power correctly but that is not a reason to BUG(). Signed-off-by:
Venu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1557689Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1557690Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Andreas Schwab authored
Since binutils 2.26 BFD is doing suffix merging on STRTAB sections. But dedotify modifies the symbol names in place, which can also modify unrelated symbols with a name that matches a suffix of a dotted name. To remove the leading dot of a symbol name we can just increment the pointer into the STRTAB section instead. Backport to all stables to avoid breakage when people update their binutils - mpe. Cc: stable@vger.kernel.org Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (backported from commit f15838e9) BugLink: http://bugs.launchpad.net/bugs/1557130Signed-off-by:
Andy Whitcroft <apw@canonical.com>
-
Paul Dagnelie authored
BugLink: http://bugs.launchpad.net/bugs/1557151 6370 ZFS send fails to transmit some holes Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Chris Williamson <chris.williamson@delphix.com> Reviewed by: Stefan Ring <stefanrin@gmail.com> Reviewed by: Steven Burgess <sburgess@datto.com> Reviewed by: Arne Jansen <sensille@gmx.net> Approved by: Robert Mustacchi <rm@joyent.com> References: https://www.illumos.org/issues/6370 https://github.com/illumos/illumos-gate/commit/286ef71 In certain circumstances, "zfs send -i" (incremental send) can produce a stream which will result in incorrect sparse file contents on the target. The problem manifests as regions of the received file that should be sparse (and read a zero-filled) actually contain data from a file that was deleted (and which happened to share this file's object ID). Note: this can happen only with filesystems (not zvols, because they do not free (and thus can not reuse) object IDs). Note: This can happen only if, since the incremental source (FromSnap), a file was deleted and then another file was created, and the new file is sparse (i.e. has areas that were never written to and should be implicitly zero-filled). We suspect that this was introduced by 4370 (applies only if hole_birth feature is enabled), and made worse by 5243 (applies if hole_birth feature is disabled, and we never send any holes). The bug is caused by the hole birth feature. When an object is deleted and replaced, all the holes in the object have birth time zero. However, zfs send cannot tell that the holes are new since the file was replaced, so it doesn't send them in an incremental. As a result, you can end up with invalid data when you receive incremental send streams. As a short-term fix, we can always send holes with birth time 0 (unless it's a zvol or a dataset where we can guarantee that no objects have been reused). Ported-by:
Steven Burgess <sburgess@datto.com> Signed-off-by:
Brian Behlendorf <behlendorf1@llnl.gov> Closes #4369 Closes #4050 cherry-picked from c352ec27d5c5ecea8f6af066258dfd106085eaac https://github.com/zfsonlinux/zfs.gitSigned-off-by:
-
Aviv Greenberg authored
BugLink: http://bugs.launchpad.net/bugs/1557138 Add support for Intel DS4 depth camera in uvc driver. This includes adding new uvc GUIDs for the new pixel formats, adding new V4L pixel format definition to user api headers, and updating the uvc driver GUID-to-4cc tables with the new formats. Change-Id: If240d95a7d4edc8dcc3e02d58cd8267a6bbf6fcb Tested-by:
Greenberg, Aviv D <aviv.d.greenberg@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 120c41d3) Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
Gavin Guo authored
BugLink: http://bugs.launchpad.net/bugs/1527643 The following message can be observed on the Ubuntu v3.13.0-65 with KASan backported: ================================================================== BUG: KASan: use after free in task_numa_find_cpu+0x64c/0x890 at addr ffff880dd393ecd8 Read of size 8 by task qemu-system-x86/3998900 ============================================================================= BUG kmalloc-128 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in task_numa_fault+0xc1b/0xed0 age=41980 cpu=18 pid=3998890 __slab_alloc+0x4f8/0x560 __kmalloc+0x1eb/0x280 task_numa_fault+0xc1b/0xed0 do_numa_page+0x192/0x200 handle_mm_fault+0x808/0x1160 __do_page_fault+0x218/0x750 do_page_fault+0x1a/0x70 page_fault+0x28/0x30 SyS_poll+0x66/0x1a0 system_call_fastpath+0x1a/0x1f INFO: Freed in task_numa_free+0x1d2/0x200 age=62 cpu=18 pid=0 __slab_free+0x2ab/0x3f0 kfree+0x161/0x170 task_numa_free+0x1d2/0x200 finish_task_switch+0x1d2/0x210 __schedule+0x5d4/0xc60 schedule_preempt_disabled+0x40/0xc0 cpu_startup_entry+0x2da/0x340 start_secondary+0x28f/0x360 Call Trace: [<ffffffff81a6ce35>] dump_stack+0x45/0x56 [<ffffffff81244aed>] print_trailer+0xfd/0x170 [<ffffffff8124ac36>] object_err+0x36/0x40 [<ffffffff8124cbf9>] kasan_report_error+0x1e9/0x3a0 [<ffffffff8124d260>] kasan_report+0x40/0x50 [<ffffffff810dda7c>] ? task_numa_find_cpu+0x64c/0x890 [<ffffffff8124bee9>] __asan_load8+0x69/0xa0 [<ffffffff814f5c38>] ? find_next_bit+0xd8/0x120 [<ffffffff810dda7c>] task_numa_find_cpu+0x64c/0x890 [<ffffffff810de16c>] task_numa_migrate+0x4ac/0x7b0 [<ffffffff810de523>] numa_migrate_preferred+0xb3/0xc0 [<ffffffff810e0b88>] task_numa_fault+0xb88/0xed0 [<ffffffff8120ef02>] do_numa_page+0x192/0x200 [<ffffffff81211038>] handle_mm_fault+0x808/0x1160 [<ffffffff810d7dbd>] ? sched_clock_cpu+0x10d/0x160 [<ffffffff81068c52>] ? native_load_tls+0x82/0xa0 [<ffffffff81a7bd68>] __do_page_fault+0x218/0x750 [<ffffffff810c2186>] ? hrtimer_try_to_cancel+0x76/0x160 [<ffffffff81a6f5e7>] ? schedule_hrtimeout_range_clock.part.24+0xf7/0x1c0 [<ffffffff81a7c2ba>] do_page_fault+0x1a/0x70 [<ffffffff81a772e8>] page_fault+0x28/0x30 [<ffffffff8128cbd4>] ? do_sys_poll+0x1c4/0x6d0 [<ffffffff810e64f6>] ? enqueue_task_fair+0x4b6/0xaa0 [<ffffffff810233c9>] ? sched_clock+0x9/0x10 [<ffffffff810cf70a>] ? resched_task+0x7a/0xc0 [<ffffffff810d0663>] ? check_preempt_curr+0xb3/0x130 [<ffffffff8128b5c0>] ? poll_select_copy_remaining+0x170/0x170 [<ffffffff810d3bc0>] ? wake_up_state+0x10/0x20 [<ffffffff8112a28f>] ? drop_futex_key_refs.isra.14+0x1f/0x90 [<ffffffff8112d40e>] ? futex_requeue+0x3de/0xba0 [<ffffffff8112e49e>] ? do_futex+0xbe/0x8f0 [<ffffffff81022c89>] ? read_tsc+0x9/0x20 [<ffffffff8111bd9d>] ? ktime_get_ts+0x12d/0x170 [<ffffffff8108f699>] ? timespec_add_safe+0x59/0xe0 [<ffffffff8128d1f6>] SyS_poll+0x66/0x1a0 [<ffffffff81a830dd>] system_call_fastpath+0x1a/0x1f As commit 1effd9f1 ("sched/numa: Fix unsafe get_task_struct() in task_numa_assign()") points out, the rcu_read_lock() cannot protect the task_struct from being freed in the finish_task_switch(). And the bug happens in the process of calculation of imp which requires the access of p->numa_faults being freed in the following path: do_exit() current->flags |= PF_EXITING; release_task() ~~delayed_put_task_struct()~~ schedule() ... ... rq->curr = next; context_switch() finish_task_switch() put_task_struct() __put_task_struct() task_numa_free() The fix here to get_task_struct() early before end of dst_rq->lock to protect the calculation process and also put_task_struct() in the corresponding point if finally the dst_rq->curr somehow cannot be assigned. Additional credit to Liang Chen who helped fix the error logic and add the put_task_struct() to the place it missed. Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hughd@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: jay.vosburgh@canonical.com Cc: liang.chen@canonical.com Link: http://lkml.kernel.org/r/1453264618-17645-1-git-send-email-gavin.guo@canonical.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 1dff76b9) Signed-off-by:
-
Konstantin Khlebnikov authored
Overlayfs must update uid/gid after chown, otherwise functions like inode_owner_or_capable() will check user against stale uid. Catched by xfstests generic/087, it chowns file and calls utimes. Signed-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Cc: <stable@vger.kernel.org> (backported from commit b81de061) BugLink: http://bugs.launchpad.net/bugs/1555997Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1556141 The fork of a process with four page table levels is broken since git commit 6252d702 "[S390] dynamic page tables." All new mm contexts are created with three page table levels and an asce limit of 4TB. If the parent has four levels dup_mmap will add vmas to the new context which are outside of the asce limit. The subsequent call to copy_page_range will walk the three level page table structure of the new process with non-zero pgd and pud indexes. This leads to memory clobbers as the pgd_index *and* the pud_index is added to the mm->pgd pointer without a pgd_deref in between. The init_new_context() function is selecting the number of page table levels for a new context. The function is used by mm_init() which in turn is called by dup_mm() and mm_alloc(). These two are used by fork() and exec(). The init_new_context() function can distinguish the two cases by looking at mm->context.asce_limit, for fork() the mm struct has been copied and the number of page table levels may not change. For exec() the mm_alloc() function set the new mm structure to zero, in this case a three-level page table is created as the temporary stack space is located at STACK_TOP_MAX = 4TB. This fixes CVE-2016-2143. Reported-by:
Marcin Kościelnicki <koriakin@0x04.net> Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Cc: stable@vger.kernel.org Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 3446c13b git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git) Signed-off-by:
-
sixiao@microsoft.com authored
BugLink: http://bugs.launchpad.net/bugs/1556037 1. Adding NETIF_F_TSO6 feature flag; 2. Adding NETIF_F_HW_CSUM. NETIF_F_IPV6_CSUM and NETIF_F_IP_CSUM are being deprecated; 3. Cleanup the coding style of flag assignment by using macro. Signed-off-by:
Simon Xiao <sixiao@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1556037 Recent changes to 'struct flow_keys' (e.g commit d34af823 ("net: Add VLAN ID to flow_keys")) introduced a performance regression in netvsc driver. Is problem is, however, not the above mentioned commit but the fact that netvsc_set_hash() function did some assumptions on the struct flow_keys data layout and this is wrong. Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change will also imply switching to Jenkins hash from the currently used Toeplitz but it seems there is no good excuse for Toeplitz to stay. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Tim Gardner authored
UBUNTU: SAUCE: (noup) megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure BugLink: http://bugs.launchpad.net/bugs/1552903 http://marc.info/?l=linux-scsi&m=145760492231010&w=2 There are few MFI adapters which do not support MR_DCMD_PD_LIST_QUERY so if MFI adapters fail this DCMD, it should not be considered as FATAL and driver should not issue kill adapter and set per controller's instance variable- pd_list_not_supported so that same variable can be used inside functions- slave_alloc and slave_configure to allow firmware scan. Killing adapter because of DCMD failure when this DCMD is not supported causes driver's probe getting failed. This issue got introduced because of below commit when MFI IO timeout handling was introduced- 6d40afbc megaraid_sas: MFI IO timeout handling Killing adapter in case of this DCMD failure should be limited to Fusion adapters only. Per controller's instance variable allow_fw_scan is removed as pd_list_not_supported better reflect the purpose. Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Libin Yang authored
BugLink: http://bugs.launchpad.net/bugs/1556002 This patch adds codec ID (0x8086280b) for Kabylake display codec and apply the hsw fix-ups to Kabylake. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 91815d8a) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 Unregister the notifiers if cpufreq_driver_register() fails in powernv_cpufreq_init(). Re-arrange the unregistration and cleanup routines in powernv_cpufreq_exit() to free all the resources after the driver has unregistered. Signed-off-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 Currently we use printk message to notify the throttle event. But this can flood the console if the cpu is throttled frequently. So replace the printk with the tracepoint to notify the throttle event. And also events like throttle below nominal frequency and OCC_RESET are reduced to pr_warn/pr_warn_once as pointed by MFG to not mark them as critical messages. This patch adds 'throttle_reason' to struct chip to store the throttle reason. Signed-off-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from linux-next commit c89f2682) Signed-off-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 This patch adds the powernv_throttle tracepoint to trace the CPU frequency throttling event, which is used by the powernv-cpufreq driver in POWER8. Signed-off-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 cpu_to_chip_id() does a DT walk through to find out the chip id by taking a contended device tree lock. This adds an unnecessary overhead in a hot path. So instead of calling cpu_to_chip_id() everytime cache the chip ids for all cores in the array 'core_to_chip_map' and use it in the hotpath. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 In the kworker_thread powernv_cpufreq_work_fn(), we can end up sending an IPI to a cpu going offline. This is a rare corner case which is fixed using {get/put}_online_cpus(). Along with this fix, this patch adds changes to do oneshot cpumask_{clear/and} operation. Suggested-by:
Shreyas B Prabhu <shreyas@linux.vnet.ibm.com> Suggested-by:
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 This will free the dynamically allocated memory of 'chips' on module exit. Signed-off-by:
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1555338 Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that xt_entry_foreach() macro stops iterating once e->next_offset is out of bounds, assuming this is the last entry. With malformed data thats not necessarily the case so we can write outside of allocated area later as we might not have walked the entire blob. Fix this by simplifying mark_source_chains -- it already has to check if nextoff is in range to catch invalid jumps, so just do the check when we move to a next entry as well. Also, check that the offset meets the xtables_entry alignment. Reported-by:
Ben Hawkes <hawkes@google.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Chris J. Arges <chris.j.arges@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1555353 http://marc.info/?l=netfilter-devel&m=145757136822750&w=2 Ben Hawkes says: integer overflow in xt_alloc_table_info, which on 32-bit systems can lead to small structure allocation and a copy_from_user based heap corruption. Reported-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555543Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555543Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1555543Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1555640Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1555640 When upstream commit 429c45de was applied to 4.4 as d60703ca it applied incorrectly to the tonga_ip_blocks array rather than the topaz_ip_blocks array. Fix that up here. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=113951Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Rusty Russell authored
BugLink: http://bugs.launchpad.net/bugs/1555640 For CONFIG_KALLSYMS, we keep two symbol tables and two string tables. There's one full copy, marked SHF_ALLOC and laid out at the end of the module's init section. There's also a cut-down version that only contains core symbols and strings, and lives in the module's core section. After module init (and before we free the module memory), we switch the mod->symtab, mod->num_symtab and mod->strtab to point to the core versions. We do this under the module_mutex. However, kallsyms doesn't take the module_mutex: it uses preempt_disable() and rcu tricks to walk through the modules, because it's used in the oops path. It's also used in /proc/kallsyms. There's nothing atomic about the change of these variables, so we can get the old (larger!) num_symtab and the new symtab pointer; in fact this is what I saw when trying to reproduce. By grouping these variables together, we can use a carefully-dereferenced pointer to ensure we always get one or the other (the free of the module init section is already done in an RCU callback, so that's safe). We allocate the init one at the end of the module init section, and keep the core one inside the struct module itself (it could also have been allocated at the end of the module core, but that's probably overkill). Reported-by:
Weilong Chen <chenweilong@huawei.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541 Cc: stable@kernel.org Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> (cherry picked from commit 8244062e) Signed-off-by:
-
Gerd Hoffmann authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit f2e30510 upstream. The test for the qemu q35 south bridge added by commit "39bfcd52 drm/i915: more virtual south bridge detection" also matches on real hardware. Having the check for virtual systems last in the list is not enough to avoid that ... Refine the check by additionally verifying the pci subsystem id to see whenever it *really* is qemu. [ v2: fix subvendor tyops ] Reported-and-tested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Tested-by:
Bruno Wolff III <bruno@wolff.to> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453719748-10944-1-git-send-email-kraxel@redhat.com (cherry picked from commit 1e859111) Signed-off-by:
-
Gerd Hoffmann authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 39bfcd52 upstream. Commit "30c964a6 drm/i915: Detect virtual south bridge" detects and handles the southbridge emulated by vmware esx. Add the ich9 south bridge emulated by 'qemu -M q35'. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1555640 commit 25e71a99 upstream. This patch applies the two introduced helpers to figure out the 1st and last bvec, and fixes the original way after bio splitting. Reported-by:
Sagi Grimberg <sagig@dev.mellanox.co.il> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
