- 29 Aug, 2016 35 commits
-
-
Hubert Chrzaniuk authored
BugLink: http://bugs.launchpad.net/bugs/1591802 Following changes have been made: - changed MSR_NHM_TURBO_RATIO_LIMIT to MSR_TURBO_RATIO_LIMIT in debug print for consistency with Developer Manual - updated definition of bitfields in MSR_TURBO_RATIO_LIMIT and appropriate parsing code - added x200 to list of architectures that do not support Nahlem compatible definition of MSR_TURBO_RATIO_LIMIT register (x200 has the register but bits definition is custom) - fixed typo in code that parses MSR_TURBO_RATIO_LIMIT (logical instead of bitwise operator) - changed MSR_TURBO_RATIO_LIMIT parsing algorithm so the print out had the same order as implementations for other platforms Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> (cherry picked from commit cbf97aba) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com>
-
Chrzaniuk, Hubert authored
BugLink: http://bugs.launchpad.net/bugs/1591802 x200 does not enable any way to programmatically obtain bus clock speed. Bclk for the architecture has a fixed value of 100 MHz. At the same time x200 cannot be included in has_snb_msrs since it does not support C7 idle state. prior to this patch, MHz values reported on this chip were erroneously calculated using bclk of 133MHz, causing MHz values to be reported 33% higher than actual. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 turbostat -i interval_sec will sample and display statistics every interval_sec. interval_sec used to be a whole number of seconds, but now we accept a decimal, as small as 0.001 sec (1 ms). Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This MSR is helpful to show if P-state HW coordination is enabled or disabled. Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 # turbostat --debug ... CPUID(6): ... HWP, HWPnotify, HWPwindow, HWPepp, HWPpkg ... ... cpu0: MSR_PM_ENABLE: 0x00000001 (HWP) cpu0: MSR_HWP_CAPABILITIES: 0x01050916 (high 0x16 guar 0x9 eff 0x5 low 0x1) cpu0: MSR_HWP_REQUEST: 0x80001604 (min 0x4 max 0x16 des 0x0 epp 0x80 window 0x0 pkg 0x0) cpu0: MSR_HWP_INTERRUPT: 0x00000001 (EN_Guaranteed_Perf_Change, Dis_Excursion_Min) cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min) Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 This CPUID leaf is available on Skylake: CPUID(0x16): base_mhz: 1500 max_mhz: 2200 bus_mhz: 100 Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1591802 for debugging, dump a few more fields: CPUID(1): SSE3 MONITOR EIST TM2 TSC MSR ACPI-TM TM cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MONITOR) Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get their display to turn on. For instance; if we boot a Valleyview system without any monitors connected, it won't need any of it's power wells and thus shut them off. Since this causes us to lose HPD, this means that unless the user knows how to ssh into their machine and do a manual reprobe for monitors, none of the monitors they connect after booting will actually work. Eventually we should come up with a better fix then having to enable polling for this, since this makes rpm a lot less useful, but for now the infrastructure in i915 just isn't there yet to get hpd in these situations. Changes since v1: - Add comment explaining the addition of the if (!mode_config->poll_running) in intel_hpd_init() - Remove unneeded if (!dev->mode_config.poll_enabled) in i915_hpd_poll_init_work() - Call to drm_helper_hpd_irq_event() after we disable polling - Add cancel_work_sync() call to intel_hpd_cancel_work() Changes since v2: - Apparently dev->mode_config.poll_running doesn't actually reflect whether or not a poll is currently in progress, and is actually used for dynamic module paramter enabling/disabling. So now we instead keep track of our own poll_running variable in dev_priv->hotplug - Clean i915_hpd_poll_init_work() a little bit Changes since v3: - Remove the now-redundant connector loop in intel_hpd_init(), just rely on intel_hpd_poll_enable() for setting connector->polled correctly on each connector - Get rid of poll_running - Don't assign enabled in i915_hpd_poll_init_work before we actually lock dev->mode_config.mutex - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE() for doc purposes - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in intel_hpd_poll_enable() - Add some comments about racing not mattering in intel_hpd_poll_enable Changes since v4: - Rename intel_hpd_poll_enable() to intel_hpd_poll_init() - Drop the bool argument from intel_hpd_poll_init() - Remove redundant calls to intel_hpd_poll_init() - Rename poll_enable_work to poll_init_work - Add some kerneldoc for intel_hpd_poll_init() - Cross-reference intel_hpd_poll_init() in intel_hpd_init() - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init() Changes since v5: - Minor kerneldoc nitpicks Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 One of the things preventing us from using polling is the fact that calling valleyview_crt_detect_hotplug() when there's a VGA cable connected results in sending another hotplug. With polling enabled when HPD is disabled, this results in a scenario like this: - We enable power wells and reset the ADPA - output_poll_exec does force probe on VGA, triggering a hpd - HPD handler waits for poll to unlock dev->mode_config.mutex - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex - HPD handler runs, resets ADPA and brings us back to the start This results in an endless irq storm getting sent from the ADPA whenever a VGA connector gets detected in the middle of polling. Somewhat based off of the "drm/i915: Disable CRT HPD around force trigger" patch Ville Syrjälä sent a while back Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA get cleared and consequently VGA hotplugging gets disabled. This causes bugs such as one we found on an Intel NUC, where doing the following sequence of hotplugs: - Disconnect all monitors - Connect VGA - Disconnect VGA - Connect HDMI Would result in VGA hotplugging becoming disabled, due to the powerwells getting toggled in the process of connecting HDMI. Changes since v3: - Expose intel_crt_reset() through intel_drv.h and call that in vlv_display_power_well_init() instead of encoder->base.funcs->reset(&encoder->base); Changes since v2: - Use intel_encoder structs instead of drm_encoder structs Changes since v1: - Instead of handling the register writes ourself, we just reuse intel_crt_detect() - Instead of resetting the ADPA during display IRQ installation, we now reset them in vlv_display_power_well_init() Cc: stable@vger.kernel.org Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Rebase over dev_priv/drm_device embedding.] Signed-off-by:
-
Lyude authored
BugLink: http://bugs.launchpad.net/bugs/1616894 This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1520446 Broxton has all the HSW C-states, except C3. BXT C-state timing is slightly different. Here we trust the IRTL MSRs as authority on maximum C-state latency, and override the driver's tables with the values found in the associated IRTL MSRs. Further we set the target_residency to 1x maximum latency, trusting the hardware demotion logic. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 5dcef694) Signed-off-by:
-
Tony Luck authored
BugLink: http://bugs.launchpad.net/bugs/1591815 This is an entirely new driver instead of yet another set of patches to sb_edac.c because: 1) Mapping from PCI devices to socket/memory controller is significantly different. Skylake scatters devices on a socket across a number of PCI buses. 2) There is an extra level of interleaving via the "mcroute" register that would be a little messy to squeeze into the old driver. 3) Validation is getting too expensive. Changes to sb_edac need to be checked against Sandy Bridge, Ivy Bridge, Haswell, Broadwell and Knights Landing. Acked-by:
Aristeu Rozanski <aris@redhat.com> Acked-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 4ec656bd) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1591815Signed-off-by:
-
Tedd Ho-Jeong An authored
BugLink: http://bugs.launchpad.net/bugs/1591648 This patch adds support for Intel Bluetooth device 3168 also known as Sandy Peak (SdP). T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0aa7 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit 439e65d3) Signed-off-by:
-
Chen Yu authored
BugLink: http://bugs.launchpad.net/bugs/1587714 People reported that they can not do a poweroff nor a suspend to ram on their Mac Pro 11. After some investigations it was found that, once the PCI bridge 0000:00:1c.0 reassigns its mm windows to ([mem 0x7fa00000-0x7fbfffff] and [mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI io resource 0x1804 becomes unaccessible immediately, where the ACPI Sleep register is located, as a result neither poweroff(S5) nor suspend to ram(S3) works. As suggested by Bjorn, further testing shows that, there is an unreported device may be (using) conflict with above aperture, which brings unpredictable result such as the failure of accessing the io port, which blocks the poweroff(S5). Besides if we reassign the memory aperture to the other place, the poweroff works again. As we do not find any resource declared in _CRS which contain above memory aperture, and Mac OS does not use this pci bridge neither, we choose a simple workaround to clear the hotplug flag(suggested by Yinghai Lu), thus do not allocate any resource for this pci bridge, and thereby no conflict anymore. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211 Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Reference: https://patchwork.kernel.org/patch/9289777/Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1512999 Since DMI IDs may be different between models while subsystem IDs of host bridge will stay the same, use pci_get_subsys() instead of dmi_match() to identify Edge Gateways. Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
-
Masaki Ota authored
Remove an unnecessary codes. Change input_ivent() function to appropriate function. Add the device ID of "HID_DEVICE_ID_ALPS_U1_DUAL". [jkosina@suse.cz: removed unnecessary bitshifts of values passed input_report_key() as spotted by Dmitry] Signed-off-by:
Masaki Ota <masaki.ota@jp.alps.com> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> BugLink: https://bugs.launchpad.net/bugs/1616813 (cherry picked from commit 819d64e5) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
-
Jiri Kosina authored
All devices with ALPS_JP VID are handled by hid-alps driver, hence they require an entry in hid_have_special_driver[]. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Jiri Kosina authored
Calculating size of the report as sizeof(pointer) always passess the length corresponding to the pointer type, not the underlying data report. BugLink: https://bugs.launchpad.net/bugs/1616813Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Jiri Kosina authored
... and therefore should be marked static. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Masaki Ota authored
Add support Alps I2C HID Touchpad and Stick device. BugLink: https://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1616813Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: https://bugs.launchpad.net/bugs/1616781 Logan Gunthorpe reports that hibernation stopped working reliably for him after commit ab76f7b4 (x86/mm: Set NX on gap between __ex_table and rodata). That turns out to be a consequence of a long-standing issue with the 64-bit image restoration code on x86, which is that the temporary page tables set up by it to avoid page tables corruption when the last bits of the image kernel's memory contents are copied into their original page frames re-use the boot kernel's text mapping, but that mapping may very well get corrupted just like any other part of the page tables. Of course, if that happens, the final jump to the image kernel's entry point will go to nowhere. The exact reason why commit ab76f7b4 matters here is that it sometimes causes a PMD of a large page to be split into PTEs that are allocated dynamically and get corrupted during image restoration as described above. To fix that issue note that the code copying the last bits of the image kernel's memory contents to the page frames occupied by them previoulsy doesn't use the kernel text mapping, because it runs from a special page covered by the identity mapping set up for that code from scratch. Hence, the kernel text mapping is only needed before that code starts to run and then it will only be used just for the final jump to the image kernel's entry point. Accordingly, the temporary page tables set up in swsusp_arch_resume() on x86-64 need to contain the kernel text mapping too. That mapping is only going to be used for the final jump to the image kernel, so it only needs to cover the image kernel's entry point, because the first thing the image kernel does after getting control back is to switch over to its own original page tables. Moreover, the virtual address of the image kernel's entry point in that mapping has to be the same as the one mapped by the image kernel's page tables. With that in mind, modify the x86-64's arch_hibernation_header_save() and arch_hibernation_header_restore() routines to pass the physical address of the image kernel's entry point (in addition to its virtual address) to the boot kernel (a small piece of assembly code involved in passing the entry point's virtual address to the image kernel is not necessary any more after that, so drop it). Update RESTORE_MAGIC too to reflect the image header format change. Next, in set_up_temporary_mappings(), use the physical and virtual addresses of the image kernel's entry point passed in the image header to set up a minimum kernel text mapping (using memory pages that won't be overwritten by the image kernel's memory contents) that will map those addresses to each other as appropriate. This makes the concern about the possible corruption of the original boot kernel text mapping go away and if the the minimum kernel text mapping used for the final jump marks the image kernel's entry point memory as executable, the jump to it is guaraneed to succeed. Fixes: ab76f7b4 (x86/mm: Set NX on gap between __ex_table and rodata) Link: http://marc.info/?l=linux-pm&m=146372852823760&w=2Reported-by:
Logan Gunthorpe <logang@deltatee.com> Reported-and-tested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Jan Beulich authored
This should really only be done for XS_TRANSACTION_END messages, or else at least some of the xenstore-* tools don't work anymore. Fixes: 0beef634 ("xenbus: don't BUG() on user mode induced condition") Reported-by:
Richard Schütz <rschuetz@uni-koblenz.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Tested-by:
David Vrabel <david.vrabel@citrix.com> BugLink: http://bugs.launchpad.net/bugs/1611833 (cherry-picked from commit 9a035a40 upstream) Signed-off-by:
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1615665 This driver is a pick up of the old IBM VIO scsi Target Driver that was started by Nick and Fujita 2-4 years ago. http://comments.gmane.org/gmane.linux.scsi/90119 The driver provides a virtual SCSI device on IBM Power Servers. This patch contains the fifth version for an initial merge of the tcm ibmvscsis driver. More information on this driver and config can be found: https://github.com/powervm/ibmvscsis/wiki/Configuration http://www.linux-iscsi.org/wiki/IBM_vSCSI (Drop extra libsrp review breakage + Fix kconfig typo - nab) Signed-off-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Cc: FUJITA Tomonori <tomof@acm.org> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> (cherry picked from commit 88a678bb) Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615665 Based on HCH's original patch, this adds a full version to support percpu-ida tag pre-allocation and callback function pointer into fabric driver code to complete session setup. Reported-by:
Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1615665Signed-off-by:
-
Herbert Xu authored
BugLink: http://bugs.launchpad.net/bugs/1613295 We use _GLOBAL so there is no need to do the manual alignment, in fact it causes a build failure. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 16dee780) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
Leonidas S. Barbosa authored
BugLink: http://bugs.launchpad.net/bugs/1613295 This patch add XTS support using VMX-crypto driver. Signed-off-by:
Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com> Signed-off-by:
Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com> Signed-off-by:
-
Stephan Mueller authored
BugLink: http://bugs.launchpad.net/bugs/1613295 The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementations. With this, the XTS implementations in ARM, ARM64, PPC and S390 have now a sanity check for the XTS keys similar to the other arches. In addition, this service function received a check to ensure that the key != the tweak key which is mandated by FIPS 140-2 IG A.9. As the check is not present in the standards defining XTS, it is only enforced in FIPS mode of the kernel. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Paulo Flabiano Smorigo authored
BugLink: http://bugs.launchpad.net/bugs/1613295 This patch add XTS subroutines using VMX-crypto driver. It gives a boost of 20 times using XTS. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov <appro@openssl.org>). Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1613295 The enable_kernel_*() functions leave the relevant MSR bits enabled until we exit the kernel sometime later. Create disable versions that wrap the kernel use of FP, Altivec VSX or SPE. While we don't want to disable it normally for performance reasons (MSR writes are slow), it will be used for a debug boot option that does this and catches bad uses in other areas of the kernel. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (back ported from commit dc4fbba1) Signed-off-by:
-
Anton Blanchard authored
BugLink: http://bugs.launchpad.net/bugs/1613295 With the recent change to enable_kernel_vsx(), we no longer need to call enable_kernel_fp() and enable_kernel_altivec(). Signed-off-by:
-
Stephan Mueller authored
BugLink: http://bugs.launchpad.net/bugs/1613295 Commit 28856a9e missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by:
-
- 24 Aug, 2016 2 commits
-
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1616318 The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Chung-Geol Kim <chunggeol.kim@samsung.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ab2a4bf8) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1602724 When nvme_delete_queue fails in the first pass of the nvme_disable_io_queues() loop, we return early, failing to suspend all of the IO queues. Later, on the nvme_pci_disable path, this causes us to disable MSI without actually having freed all the IRQs, which triggers the BUG_ON in free_msi_irqs(), as show below. This patch refactors nvme_disable_io_queues to suspend all queues before start submitting delete queue commands. This way, we ensure that we have at least returned every IRQ before continuing with the removal path. [ 487.529200] kernel BUG at ../drivers/pci/msi.c:368! cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650] pc: c000000000627a50: free_msi_irqs+0x90/0x200 lr: c000000000627a40: free_msi_irqs+0x80/0x200 sp: c0000078c5b838d0 msr: 9000000100029033 current = 0xc0000078c5b40000 paca = 0xc000000002bd7600 softe: 0 irq_happened: 0x01 pid = 1376, comm = kworker/70:1H kernel BUG at ../drivers/pci/msi.c:368! Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016 enter ? for help [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme] [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme] [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110 [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170 [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110 [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0 [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590 [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660 [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130 [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: linux-nvme@lists.infradead.org Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit c21377f8) Signed-off-by:
-
- 23 Aug, 2016 3 commits
-
-
John Johansen authored
change_hat using probing to find and transition to the first available hat. Hats missing as part of this probe are expected and should not be logged except in complain mode. BugLink: http://bugs.launchpad.net/bugs/1615893Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615892Signed-off-by:
-
John Johansen authored
when viewing a stack involving unconfined from across a ns boundary the mode is reported as mixed. Eg. lxc-container-default//&:lxdns1://unconfined (mixed) This is because the unconfined profile is in the special unconfined mode. Which will result in a (mixed) mode for any stack with profiles in enforcing or complain mode. This can however lead to confusion as to what mode is being used as mixed is also used for enforcing stacked with complain. Since unconfined doesn't affect the stack just special case it. BugLink: http://bugs.launchpad.net/bugs/1615890Signed-off-by:
-
