- 07 Sep, 2016 37 commits
-
-
Alan Stern authored
commit ca5cbc8b upstream. The early-exit pathway in hub_activate, added by commit e50293ef ("USB: fix invalid memory access in hub_activate()") needs improvement. It duplicates code that is already present at the end of the subroutine, and it neglects to undo the effect of a usb_autopm_get_interface_no_resume() call. This patch fixes both problems by making the early-exit pathway jump directly to the end of the subroutine. It simplifies the code at the end by merging two conditionals that actually test the same condition although they appear different: If type < HUB_INIT3 then type must be either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that case the subroutine would have exited earlier. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reviewed-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Viresh Kumar authored
commit 6bb47e8a upstream. Memory leak and unbalanced reference count: If the hub gets disconnected while the core is still activating it, this can result in leaking memory of few USB structures. This will happen if we have done a kref_get() from hub_activate() and scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect() gets called before the delayed work expires, then we will cancel the work from hub_quiesce(), but wouldn't do a kref_put(). And so the unbalance. kmemleak reports this as (with the commit e50293ef backported to 3.10 kernel with other changes, though the same is true for mainline as well): unreferenced object 0xffffffc08af5b800 (size 1024): comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s) hex dump (first 32 bytes): 30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff 0h.............. 01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff ..........}@.... backtrace: [<ffffffc0003079ec>] create_object+0x148/0x2a0 [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac [<ffffffc0006fa610>] hub_probe+0x120/0xb84 [<ffffffc000702b20>] usb_probe_interface+0x1ec/0x298 [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374 [<ffffffc0005d5308>] __device_attach+0x28/0x4c [<ffffffc0005d3164>] bus_for_each_drv+0x78/0xac [<ffffffc0005d4ee0>] device_attach+0x6c/0x9c [<ffffffc0005d42b8>] bus_probe_device+0x28/0xa0 [<ffffffc0005d23a4>] device_add+0x324/0x604 [<ffffffc000700fcc>] usb_set_configuration+0x660/0x6cc [<ffffffc00070a350>] generic_probe+0x44/0x84 [<ffffffc000702914>] usb_probe_device+0x54/0x74 [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374 [<ffffffc0005d5308>] __device_attach+0x28/0x4c Deadlocks: If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are finished and the init_work is still queued), the core may call hub_quiesce() after acquiring interface device locks and it will wait for the work to be cancelled synchronously. But if the work handler is already running in parallel, it may try to acquire the same interface device lock and this may result in deadlock. Fix both the issues by removing the call to cancel_delayed_work_sync(). Fixes: e50293ef ("USB: fix invalid memory access in hub_activate()") Reported-by:
Manu Gautam <mgautam@codeaurora.org> Signed-off-by:
-
Felipe Balbi authored
commit 7c705dfe upstream. If we stop earlier due to short packet, we will not be able to giveback all TRBs. Cc: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
commit e5b36ae2 upstream. DWC3 has one interesting peculiarity with chained transfers. If we setup N chained transfers and we get a short packet before processing all N TRBs, DWC3 will (conditionally) issue a XferComplete or XferInProgress event and retire all TRBs from the one which got a short packet to the last without clearing their HWO bits. This means SW must clear HWO bit manually, which this patch is doing. Cc: Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by:
-
Felipe Balbi authored
commit c7de5734 upstream. When using SG lists, we would end up setting request->actual to: num_mapped_sgs * (request->length - count) Let's fix that up by incrementing request->actual only once. Reported-by:
Brian E Rogers <brian.e.rogers@intel.com> Signed-off-by:
-
Heikki Krogerus authored
commit 4491ed50 upstream. Intel Kabylake PCH has the same DWC3 than Intel Sunrisepoint. Add the new ID to the supported devices. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Peter Chen authored
commit 528d2813 upstream. For case 14 and case 21, their correct return value is the number of bytes transferred, so it is a positive integer. But in usbtest_ioctl, it takes non-zero as false return value for usbtest_do_ioctl, so it will treat the correct test as wrong test, then the time on tests will be the minus value. Signed-off-by:
Peter Chen <peter.chen@nxp.com> Fixes: 18fc4ebd ("usb: misc: usbtest: Remove timeval usage") Signed-off-by:
-
Lu Baolu authored
commit 53958751 upstream. In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang whenever transfer time out is triggered. This patch fixes this issue. It could be backported to stable kernel with version later than v3.15. Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Suggested-by:
-
Jiri Slaby authored
commit 70f7ca9a upstream. usbdev_mmap allocates a buffer. The size of the buffer is determined by a user. So with this code (no need to be root): int fd = open("/dev/bus/usb/001/001", O_RDONLY); mmap(NULL, 0x800000, PROT_READ, MAP_SHARED, fd, 0); we can see a warning: WARNING: CPU: 0 PID: 21771 at ../mm/page_alloc.c:3563 __alloc_pages_slowpath+0x1036/0x16e0() ... Call Trace: [<ffffffff8117a3ae>] ? warn_slowpath_null+0x2e/0x40 [<ffffffff815178b6>] ? __alloc_pages_slowpath+0x1036/0x16e0 [<ffffffff81516880>] ? warn_alloc_failed+0x250/0x250 [<ffffffff8151226b>] ? get_page_from_freelist+0x75b/0x28b0 [<ffffffff815184e3>] ? __alloc_pages_nodemask+0x583/0x6b0 [<ffffffff81517f60>] ? __alloc_pages_slowpath+0x16e0/0x16e0 [<ffffffff810565d4>] ? dma_generic_alloc_coherent+0x104/0x220 [<ffffffffa0269e56>] ? hcd_buffer_alloc+0x1d6/0x3e0 [usbcore] [<ffffffffa0269c80>] ? hcd_buffer_destroy+0xa0/0xa0 [usbcore] [<ffffffffa0228f05>] ? usb_alloc_coherent+0x65/0x90 [usbcore] [<ffffffffa0275c05>] ? usbdev_mmap+0x1a5/0x770 [usbcore] ... Allocations like this one should be marked as __GFP_NOWARN. So do so. The size could be also clipped by something like: if (size >= (1 << (MAX_ORDER + PAGE_SHIFT - 1))) return -ENOMEM; But I think the overall limit of 16M (by usbfs_increase_memory_usage) is enough, so that we only silence the warning here. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Steinar H. Gunderson <sesse@google.com> Cc: Markus Rechberger <mrechberger@gmail.com> Fixes: f7d34b44 (USB: Add support for usbfs zerocopy.) Signed-off-by:
-
Marc Ohlf authored
commit bc337b51 upstream. In ehci_turn_off_all_ports() all EHCI port registers are cleared to zero. On some hardware, this can lead to an system hang, when ehci_port_power() accesses the already cleared registers. This patch changes the order of cleanup. First call ehci_port_power() which respects the current bits in port status registers and afterwards cleanup the hard way by setting everything to zero. Signed-off-by:
Marc Ohlf <ohlf@mkt-sys.de> Acked-by:
-
Helge Deller authored
commit ae141830 upstream. Commit 54b66800 (parisc: Add native high-resolution sched_clock() implementation) added support to use the CPU-internal cr16 counters as reliable clocksource with the help of HAVE_UNSTABLE_SCHED_CLOCK. Sadly the commit missed to remove the hack which prevented cr16 to become the default clocksource even on SMP systems. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Horia Geantă authored
commit 2fdea258 upstream. To be able to generate shared descriptors for AEAD, the authentication size needs to be known. However, there is no imposed order of calling .setkey, .setauthsize callbacks. Thus, in case authentication size is not known at .setkey time, defer it until .setauthsize is called. The authsize != 0 check was incorrectly removed when converting the driver to the new AEAD interface. Fixes: 479bcc7c ("crypto: caam - Convert authenc to new AEAD interface") Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Horia Geantă authored
commit 1d2d87e8 upstream. There are a few things missed by the conversion to the new AEAD interface: 1 - echainiv(authenc) encrypt shared descriptor The shared descriptor is incorrect: due to the order of operations, at some point in time MATH3 register is being overwritten. 2 - buffer used for echainiv(authenc) encrypt shared descriptor Encrypt and givencrypt shared descriptors (for AEAD ops) are mutually exclusive and thus use the same buffer in context state: sh_desc_enc. However, there's one place missed by s/sh_desc_givenc/sh_desc_enc, leading to errors when echainiv(authenc(...)) algorithms are used: DECO: desc idx 14: Header Error. Invalid length or parity, or certain other problems. While here, also fix a typo: dma_mapping_error() is checking for validity of sh_desc_givenc_dma instead of sh_desc_enc_dma. Fixes: 479bcc7c ("crypto: caam - Convert authenc to new AEAD interface") Signed-off-by:
-
Russell King authored
commit a0118c8b upstream. Since 6de62f15 ("crypto: algif_hash - Require setkey before accept(2)"), the AF_ALG interface requires userspace to provide a key to any algorithm that has a setkey method. However, the non-HMAC algorithms are not keyed, so setting a key is unnecessary. Fix this by removing the setkey method from the non-keyed hash algorithms. Fixes: 6de62f15 ("crypto: algif_hash - Require setkey before accept(2)") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Marc Zyngier authored
commit f3b0946d upstream. Bharat Kumar Gogada reported issues with the generic MSI code, where the end-point ended up with garbage in its MSI configuration (both for the vector and the message). It turns out that the two MSI paths in the kernel are doing slightly different things: generic MSI: disable MSI -> allocate MSI -> enable MSI -> setup EP PCI MSI: disable MSI -> allocate MSI -> setup EP -> enable MSI And it turns out that end-points are allowed to latch the content of the MSI configuration registers as soon as MSIs are enabled. In Bharat's case, the end-point ends up using whatever was there already, which is not what you want. In order to make things converge, we introduce a new MSI domain flag (MSI_FLAG_ACTIVATE_EARLY) that is unconditionally set for PCI/MSI. When set, this flag forces the programming of the end-point as soon as the MSIs are allocated. A consequence of this is that we have an extra activate in irq_startup, but that should be without much consequence. tglx: - Several people reported a VMWare regression with PCI/MSI-X passthrough. It turns out that the patch also cures that issue. - We need to have a look at the MSI disable interrupt path, where we write the msg to all zeros without disabling MSI in the PCI device. Is that correct? Fixes: 52f518a3 "x86/MSI: Use hierarchical irqdomains to manage MSI interrupts" Reported-and-tested-by:
Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> Reported-and-tested-by:
Foster Snowhill <forst@forstwoof.ru> Reported-by:
Matthias Prager <linux@matthiasprager.de> Reported-by:
Jason Taylor <jason.taylor@simplivity.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/1468426713-31431-1-git-send-email-marc.zyngier@arm.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
commit b6140914 upstream. No user and we definitely don't want to grow one. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Christoph Hellwig <hch@lst.de> Cc: linux-block@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: linux-nvme@lists.infradead.org Cc: axboe@fb.com Cc: agordeev@redhat.com Link: http://lkml.kernel.org/r/1467621574-8277-2-git-send-email-hch@lst.deSigned-off-by:
-
Andrey Ryabinin authored
commit dad22328 upstream. Commit e41f501d ("vmlinux.lds: account for destructor sections") added '.text.exit' to EXIT_TEXT which is discarded at link time by default. This breaks compilation of UML: `.text.exit' referenced in section `.fini_array' of /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o): defined in discarded section `.text.exit' of /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o) Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT sections in .exit.text. Fixes: e41f501d ("vmlinux.lds: account for destructor sections") Reported-by:
Stefan Traby <stefan@hello-penguin.com> Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Hoan Tran authored
commit 2324d154 upstream. When CPPC fails to request a PCC channel, the CPC data is freed and cpc_desc_ptr points to the invalid data. Avoid this issue by moving the cpc_desc_ptr assignment after the PCC channel request. Signed-off-by:
Hoan Tran <hotran@apm.com> Acked-by:
Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hoan Tran authored
commit 8343c40d upstream. Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform supports CPPC, the _CPC object must exist under all processor objects. If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map() should return error and CPPC cpufreq driver can not be registered. Signed-off-by:
Prashanth Prakash <pprakash@codeaurora.org> Signed-off-by:
-
Ross Zwisler authored
commit 68202c9f upstream. The "NVDIMM Block Window Driver Writer's Guide": http://pmem.io/documents/NVDIMM_DriverWritersGuide-July-2016.pdf ...defines the layout of the block window status register. For the July 2016 version of the spec linked to above, this happens in Figure 4 on page 26. The only bits defined in this spec are bits 31, 5, 4, 2, 1 and 0. The rest of the bits in the status register are reserved, and there is a warning following the diagram that says: Note: The driver cannot assume the value of the RESERVED bits in the status register are zero. These reserved bits need to be masked off, and the driver must avoid checking the state of those bits. This change ensures that for hardware implementations that set these reserved bits in the status register, the driver won't incorrectly fail the block I/Os. Reviewed-by:
Lee, Chun-Yi <jlee@suse.com> Signed-off-by:
Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Adrian Hunter authored
commit 3d918fb1 upstream. In order to successfully decode Intel PT traces, context switch events are needed from the moment the trace starts. Currently that is ensured by using the 'immediate' flag which enables the switch event when it is opened. However, since commit 86c27869 ("perf intel-pt: Add support for PERF_RECORD_SWITCH") that might not always happen. When tracing system-wide the context switch event is added to the tracking event which was not set as 'immediate'. Change that so it is. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Fixes: 86c27869 ("perf intel-pt: Add support for PERF_RECORD_SWITCH") Link: http://lkml.kernel.org/r/1471245784-22580-1-git-send-email-adrian.hunter@intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit c87edb36 upstream. The symbols used in the tick_stop tracepoint were not being converted properly into integers in the trace_stop format file. Instead we had this: print fmt: "success=%d dependency=%s", REC->success, __print_symbolic(REC->dependency, { 0, "NONE" }, { (1 << TICK_DEP_BIT_POSIX_TIMER), "POSIX_TIMER" }, { (1 << TICK_DEP_BIT_PERF_EVENTS), "PERF_EVENTS" }, { (1 << TICK_DEP_BIT_SCHED), "SCHED" }, { (1 << TICK_DEP_BIT_CLOCK_UNSTABLE), "CLOCK_UNSTABLE" }) User space tools have no idea how to parse "TICK_DEP_BIT_SCHED" or the other symbols used to do the bit shifting. The reason is that the conversion was done with using the TICK_DEP_MASK_* symbols which are just macros that convert to the BIT shift itself (with the exception of NONE, which was converted properly, because it doesn't use bits, and is defined as zero). The TICK_DEP_BIT_* needs to be denoted by TRACE_DEFINE_ENUM() in order to have this properly converted for user space tools to parse this event. Cc: Frederic Weisbecker <fweisbec@gmail.com> Fixes: e6e6cc22 ("nohz: Use enum code for tick stop failure tracing message") Reported-by:
Luiz Capitulino <lcapitulino@redhat.com> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Alex Williamson authored
commit c8952a70 upstream. There are multiple cases in vfio_pci_set_ctx_trigger_single() where we assume we can safely read from our data pointer without actually checking whether the user has passed any data via the count field. VFIO_IRQ_SET_DATA_NONE in particular is entirely broken since we attempt to pull an int32_t file descriptor out before even checking the data type. The other data types assume the data pointer contains one element of their type as well. In part this is good news because we were previously restricted from doing much sanitization of parameters because it was missed in the past and we didn't want to break existing users. Clearly DATA_NONE is completely broken, so it must not have any users and we can fix it up completely. For DATA_BOOL and DATA_EVENTFD, we'll just protect ourselves, returning error when count is zero since we previously would have oopsed. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Reported-by:
Chris Thompson <the_cartographer@hotmail.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
-
Chris Wilson authored
commit 60398923 upstream. With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a kmem_cache_node is destroyed the call_rcu() may trigger a slab allocation to fill the debug object pool (__debug_object_init:fill_pool). Everywhere but during kmem_cache_destroy(), discard_slab() is performed outside of the kmem_cache_node->list_lock and avoids a lockdep warning about potential recursion: ============================================= [ INFO: possible recursive locking detected ] 4.8.0-rc1-gfxbench+ #1 Tainted: G U --------------------------------------------- rmmod/8895 is trying to acquire lock: (&(&n->list_lock)->rlock){-.-...}, at: [<ffffffff811c80d7>] get_partial_node.isra.63+0x47/0x430 but task is already holding lock: (&(&n->list_lock)->rlock){-.-...}, at: [<ffffffff811cbda4>] __kmem_cache_shutdown+0x54/0x320 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&n->list_lock)->rlock); lock(&(&n->list_lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by rmmod/8895: #0: (&dev->mutex){......}, at: driver_detach+0x42/0xc0 #1: (&dev->mutex){......}, at: driver_detach+0x50/0xc0 #2: (cpu_hotplug.dep_map){++++++}, at: get_online_cpus+0x2d/0x80 #3: (slab_mutex){+.+.+.}, at: kmem_cache_destroy+0x3c/0x220 #4: (&(&n->list_lock)->rlock){-.-...}, at: __kmem_cache_shutdown+0x54/0x320 stack backtrace: CPU: 6 PID: 8895 Comm: rmmod Tainted: G U 4.8.0-rc1-gfxbench+ #1 Hardware name: Gigabyte Technology Co., Ltd. H87M-D3H/H87M-D3H, BIOS F11 08/18/2015 Call Trace: __lock_acquire+0x1646/0x1ad0 lock_acquire+0xb2/0x200 _raw_spin_lock+0x36/0x50 get_partial_node.isra.63+0x47/0x430 ___slab_alloc.constprop.67+0x1a7/0x3b0 __slab_alloc.isra.64.constprop.66+0x43/0x80 kmem_cache_alloc+0x236/0x2d0 __debug_object_init+0x2de/0x400 debug_object_activate+0x109/0x1e0 __call_rcu.constprop.63+0x32/0x2f0 call_rcu+0x12/0x20 discard_slab+0x3d/0x40 __kmem_cache_shutdown+0xdb/0x320 shutdown_cache+0x19/0x60 kmem_cache_destroy+0x1ae/0x220 i915_gem_load_cleanup+0x14/0x40 [i915] i915_driver_unload+0x151/0x180 [i915] i915_pci_remove+0x14/0x20 [i915] pci_device_remove+0x34/0xb0 __device_release_driver+0x95/0x140 driver_detach+0xb6/0xc0 bus_remove_driver+0x53/0xd0 driver_unregister+0x27/0x50 pci_unregister_driver+0x25/0x70 i915_exit+0x1a/0x1e2 [i915] SyS_delete_module+0x193/0x1f0 entry_SYSCALL_64_fastpath+0x1c/0xac Fixes: 52b4b950 ("mm: slab: free kmem_cache_node after destroy sysfs file") Link: http://lkml.kernel.org/r/1470759070-18743-1-git-send-email-chris@chris-wilson.co.ukReported-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Vladimir Davydov <vdavydov@virtuozzo.com> Acked-by:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Wei Yongjun authored
commit 58625edf upstream. When using the indirect buffers feature, 'desc' is allocated in virtqueue_add() but isn't freed before leaving on a ring full error, causing a memory leak. For example, it seems rather clear that this can trigger with virtio net if mergeable buffers are not used. Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Helge Deller authored
commit 3eb53b20 upstream. When building gccgo in userspace, errno.h gets parsed and the go include file sysinfo.go is generated. Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED is defined later on in errno.h, this leads to go complaining that EREFUSED isn't defined yet. Fix this trivial problem by moving the define of EREFUSED down after ECONNREFUSED in errno.h (and clean up the indenting while touching this line). Signed-off-by:
-
Austin Christ authored
commit 6862e6ad upstream. According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this functionality, the kernel driver needs to vmap the entire capsule at the time it is made available to firmware. The virtual allocation of the capsule update has been changed from kmap, which was only allocating the first page of the update, to vmap, and allocates the entire data payload. Signed-off-by:
Austin Christ <austinwc@codeaurora.org> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
James Hogan authored
commit 3146bc64 upstream. AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for arm64 at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for AT_BASE_PLATFORM which arm64 doesn't use, but lets define it now and add the comment above ARCH_DLINFO as found in several other architectures to remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to date. Fixes: f668cd16 ("arm64: ELF definitions") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Takashi Iwai authored
commit a52ff34e upstream. For SKL and later Intel chips, we control the power well per codec basis via link_power callback since the commit [03b135ce: ALSA: hda - remove dependency on i915 power well for SKL]. However, there are a few exceptional cases where the gfx registers are accessed from the audio driver: namely the wakeup override bit toggling at (both system and runtime) resume. This seems causing a kernel warning when accessed during the power well down (and likely resulting in the bogus register accesses). This patch puts the proper power up / down sequence around the resume code so that the wakeup bit is fiddled properly while the power is up. (The other callback, sync_audio_rate, is used only in the PCM callback, so it's guaranteed in the power-on.) Also, by this proper power up/down, the instantaneous flip of wakeup bit in the resume callback that was introduced by the commit [033ea349: ALSA: hda - Fix Skylake codec timeout] becomes superfluous, as snd_hdac_display_power() already does it. So we can clean it up together. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214 Fixes: 03b135ce ('ALSA: hda - remove dependency on i915 power well for SKL') Tested-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Vittorio Gambaletta (VittGam) authored
commit 41f5e3bd upstream. The ELP HD USB Camera (05a3:9420) needs this quirk for suppressing the unsupported sample rate inquiry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=98481Signed-off-by:
Vittorio Gambaletta <linuxbugs@vittgam.net> Signed-off-by:
-
Piotr Karasinski authored
commit 7627e40c upstream. VF0610 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x82". This patch adds the USB ID (0x041E:4080) to snd_usb_get_sample_rate_quirk() list. Signed-off-by:
Piotr Karasinski <peter.karasinski@gmail.com> Signed-off-by:
-
Olga Kornievskaia authored
commit 9130b8db upstream. It's possible to have simultaneous upcalls for the same UIDs but different GSS service. In that case, we need to allow for the upcall to gssd to proceed so that not the same context is used by two different GSS services. Some servers lock the use of context to the GSS service. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 1f4c17a0 upstream. If the connect attempt immediately fails with an EADDRNOTAVAIL error, then that means our choice of source port number was bad. This error is expected when we set the SO_REUSEPORT socket option and we have 2 sockets sharing the same source and destination address and port combinations. Signed-off-by:
-
Dan Williams authored
commit d8d378fa upstream. The unit tests crash when hotplug races the previous probe. This race requires that the loading of the nfit_test module be terminated with SIGTERM, and the module to be unloaded while the ars scan is still running. In contrast to the normal nfit driver, the unit test calls acpi_nfit_init() twice to simulate hotplug, whereas the nominal case goes through the acpi_nfit_notify() event handler. The acpi_nfit_notify() path is careful to flush the previous region registration before servicing the hotplug event. The unit test was missing this guarantee. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810cdce7>] pwq_activate_delayed_work+0x47/0x170 [..] Call Trace: [<ffffffff810ce186>] pwq_dec_nr_in_flight+0x66/0xa0 [<ffffffff810ce490>] process_one_work+0x2d0/0x680 [<ffffffff810ce331>] ? process_one_work+0x171/0x680 [<ffffffff810ce88e>] worker_thread+0x4e/0x480 [<ffffffff810ce840>] ? process_one_work+0x680/0x680 [<ffffffff810ce840>] ? process_one_work+0x680/0x680 [<ffffffff810d5343>] kthread+0xf3/0x110 [<ffffffff8199846f>] ret_from_fork+0x1f/0x40 [<ffffffff810d5250>] ? kthread_create_on_node+0x230/0x230 Signed-off-by:
-
Alex Thorlton authored
commit f72075c9 upstream. This problem has actually been in the UV code for a while, but we didn't catch it until recently, because we had been relying on EFI_OLD_MEMMAP to allow our systems to boot for a period of time. We noticed the issue when trying to kexec a recent community kernel, where we hit this NULL pointer dereference in efi_sync_low_kernel_mappings(): [ 0.337515] BUG: unable to handle kernel NULL pointer dereference at 0000000000000880 [ 0.346276] IP: [<ffffffff8105df8d>] efi_sync_low_kernel_mappings+0x5d/0x1b0 The problem doesn't show up with EFI_OLD_MEMMAP because we skip the chunk of setup_efi_state() that sets the efi_loader_signature for the kexec'd kernel. When the kexec'd kernel boots, it won't set EFI_BOOT in setup_arch, so we completely avoid the bug. We always kexec with noefi on the command line, so this shouldn't be an issue, but since we're not actually checking for efi_runtime_disabled in uv_bios_init(), we end up trying to do EFI runtime callbacks when we shouldn't be. This patch just adds a check for efi_runtime_disabled in uv_bios_init() so that we don't map in uv_systab when runtime_disabled == true. Signed-off-by:
Alex Thorlton <athorlton@sgi.com> Signed-off-by:
-
Denys Vlasenko authored
commit 68187872 upstream. Since instruction decoder now supports EVEX-encoded instructions, two fixes are needed to correctly handle them in uprobes. Extended bits for MODRM.rm field need to be sanitized just like we do it for VEX3, to avoid encoding wrong register for register-relative access. EVEX has _two_ extended bits: b and x. Theoretically, EVEX.x should be ignored by the CPU (since GPRs go only up to 15, not 31), but let's be paranoid here: proper encoding for register-relative access should have EVEX.x = 1. Secondly, we should fetch vex.vvvv for EVEX too. This is now super easy because instruction decoder populates vex_prefix.bytes[2] for all flavors of (e)vex encodings, even for VEX2. Signed-off-by:
Denys Vlasenko <dvlasenk@redhat.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jim Keniston <jkenisto@us.ibm.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: linux-kernel@vger.kernel.org Fixes: 8a764a87 ("x86/asm/decoder: Create artificial 3rd byte for 2-byte VEX") Link: http://lkml.kernel.org/r/20160811154521.20469-1-dvlasenk@redhat.comSigned-off-by:
-
Sebastian Andrzej Siewior authored
commit 5cf0791d upstream. There's a subtle preemption race on UP kernels: Usually current->mm (and therefore mm->pgd) stays the same during the lifetime of a task so it does not matter if a task gets preempted during the read and write of the CR3. But then, there is this scenario on x86-UP: TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by: -> mmput() -> exit_mmap() -> tlb_finish_mmu() -> tlb_flush_mmu() -> tlb_flush_mmu_tlbonly() -> tlb_flush() -> flush_tlb_mm_range() -> __flush_tlb_up() -> __flush_tlb() -> __native_flush_tlb() At this point current->mm is NULL but current->active_mm still points to the "old" mm. Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its own mm so CR3 has changed. Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's mm and so CR3 remains unchanged. Once taskA gets active it continues where it was interrupted and that means it writes its old CR3 value back. Everything is fine because userland won't need its memory anymore. Now the fun part: Let's preempt taskA one more time and get back to taskB. This time switch_mm() won't do a thing because oldmm (->active_mm) is the same as mm (as per context_switch()). So we remain with a bad CR3 / PGD and return to userland. The next thing that happens is handle_mm_fault() with an address for the execution of its code in userland. handle_mm_fault() realizes that it has a PTE with proper rights so it returns doing nothing. But the CPU looks at the wrong PGD and insists that something is wrong and faults again. And again. And one more time… This pagefault circle continues until the scheduler gets tired of it and puts another task on the CPU. It gets little difficult if the task is a RT task with a high priority. The system will either freeze or it gets fixed by the software watchdog thread which usually runs at RT-max prio. But waiting for the watchdog will increase the latency of the RT task which is no good. Fix this by disabling preemption across the critical code section. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Rik van Riel <riel@redhat.com> Acked-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/1470404259-26290-1-git-send-email-bigeasy@linutronix.de [ Prettified the changelog. ] Signed-off-by:
-
- 20 Aug, 2016 3 commits
-
-
Greg Kroah-Hartman authored
-
Yoshihiro Shimoda authored
commit c14f8a40 upstream. This patch fixes an issue that the extcon_set_cable_state_() is possible to cause "BUG: scheduling while atomic" because this driver calls extcon_set_cable_state_() in the interrupt handler and mutex_lock() is possible to be called by like the following call trace. So, this patch adds a workqueue function to resolve this issue. [ 9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303 [ 9.714569] Modules linked in: [ 9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ #86 [ 9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT) [ 9.731624] Call trace: [ 9.734077] [<ffff0000080889f0>] dump_backtrace+0x0/0x1a8 [ 9.739470] [<ffff000008088bac>] show_stack+0x14/0x20 [ 9.744520] [<ffff000008348ab4>] dump_stack+0x94/0xb8 [ 9.749568] [<ffff0000080da18c>] __schedule_bug+0x44/0x58 [ 9.754966] [<ffff0000087c6394>] __schedule+0x4e4/0x598 [ 9.760185] [<ffff0000087c6484>] schedule+0x3c/0xa8 [ 9.765057] [<ffff0000087c6928>] schedule_preempt_disabled+0x20/0x38 [ 9.771408] [<ffff0000080f20dc>] mutex_optimistic_spin+0x18c/0x1d0 [ 9.777583] [<ffff0000087c7ef0>] __mutex_lock_slowpath+0x38/0x140 [ 9.783669] [<ffff0000087c803c>] mutex_lock+0x44/0x60 [ 9.788717] [<ffff00000834ca48>] kobject_uevent_env+0x250/0x500 [ 9.794634] [<ffff0000086ae8c0>] extcon_update_state+0x220/0x298 [ 9.800634] [<ffff0000086ae9d8>] extcon_set_cable_state_+0x78/0x88 [ 9.806812] [<ffff000008376004>] rcar_gen3_device_recognition+0x5c/0xe0 [ 9.813420] [<ffff0000083761bc>] rcar_gen3_phy_usb2_irq+0x3c/0x48 [ 9.819509] [<ffff0000080fae94>] handle_irq_event_percpu+0x94/0x140 [ 9.825769] [<ffff0000080faf88>] handle_irq_event+0x48/0x78 [ 9.831334] [<ffff0000080fe620>] handle_fasteoi_irq+0xb8/0x1b0 [ 9.837162] [<ffff0000080fa3c4>] generic_handle_irq+0x24/0x38 [ 9.842900] [<ffff0000080fa6fc>] __handle_domain_irq+0x5c/0xb8 [ 9.848727] [<ffff000008081520>] gic_handle_irq+0x58/0xb0 Reported-by:
Simon Horman <horms@verge.net.au> Fixes: 2b38543c ("phy: rcar-gen3-usb2: add extcon support") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Ben Hutchings authored
commit b8612e51 upstream. Signing a module should only make it trusted by the specific kernel it was built for, not anything else. If a module signing key is used for multiple ABI-incompatible kernels, the modules need to include enough version information to distinguish them. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
