- 29 Aug, 2016 16 commits
-
-
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 <jkosina@suse.cz> (cherry picked from commit 63b3a7d0) Signed-off-by:
Ying-Chun Liu (PaulLiu) <paul.liu@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
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:
Masaki Ota <masaki.ota@jp.alps.com> Signed-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:
Borislav Petkov <bp@suse.de> Tested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 65c0554b) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com>
-
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:
Stefan Bader <stefan.bader@canonical.com> Acked-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 14 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:
-
John Johansen authored
the policy_lock parameter is a one way switch that prevents policy from being further modified. Unfortunately some of the module parameters can effectively modify policy by turning off enforcement. split policy_admin_capable into a view check and a full admin check, and update the admin check to test the policy_lock parameter. BugLink: http://bugs.launchpad.net/bugs/1615895Signed-off-by:
-
John Johansen authored
the vec_unique path for large vectors is broken, leading to oopses when a file handle is shared between 8 different security domains, and then a profile replacement/removal causing a label invalidation (ie. not all replacements) is done. BugLink: http://bugs.launchpad.net/bugs/1579135Signed-off-by:
-
John Johansen authored
If the result of a merge/update/parse is a vec with a single entry we should not be returning a reference label, but just the label it self. BugLink: http://bugs.launchpad.net/bugs/1615889Signed-off-by:
-
John Johansen authored
When the ns hierarchy a//foo and b//foo are compared the are incorrectly identified as being the same as they have the same depth and the same basename. Instead make sure to compare the full hname to distinguish this case. BugLink: http://bugs.launchpad.net/bugs/1615887Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1592547 If unpack_dfa() returns NULL due to the dfa not being present, profile_unpack() is not checking if the dfa is not present (NULL). Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615885Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1615882Signed-off-by:
-
John Johansen authored
The label build for onexec when crossing a namespace boundry is not quite correct. The label needs to be built per profile and not based on the whole label because the onexec transition only applies to profiles within the ns. Where merging against the label could include profile that are transitioned via the profile_transition callback and should not be in the final label. BugLink: http://bugs.launchpad.net/bugs/1615881Signed-off-by:
-
John Johansen authored
For the purposes of inherit we should be treating a profile/label transition to its replacement as if the replacement is the profile/label. So make the comparison based off of the label proxy, not the label itself. BugLink: http://bugs.launchpad.net/bugs/1615880Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1593874Signed-off-by:
-
John Johansen authored
The comparing the proxy pointer, not the address of the labels proxy pointer. BugLink: http://bugs.launchpad.net/bugs/1615878Signed-off-by:
-
- 22 Aug, 2016 8 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1615620Signed-off-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1615620 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:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit bca014ca upstream. Signing a module should only make it trusted by the specific kernel it was built for, not anything else. Loading a signed module meant for a kernel with a different ABI could have interesting effects. Therefore, treat all signatures as invalid when a module is force-loaded. Signed-off-by:
-
Mike Snitzer authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 99f3c90d upstream. When the corrupt_bio_byte feature was introduced it caused READ bios to no longer be errored with -EIO during the down_interval. This had to do with the complexity of needing to submit READs if the corrupt_bio_byte feature was used. Fix it so READ bios are properly errored with -EIO; doing so early in flakey_map() as long as there isn't a match for the corrupt_bio_byte feature. Fixes: a3998799 ("dm flakey: add corrupt_bio_byte feature") Reported-by:
Akira Hayakawa <ruby.wktk@gmail.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Alim Akhtar authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 70c96dfa upstream. As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which results in a kernel crash on exynos7 platform while probing rtc driver. Below is code flow: s3c_rtc_probe() clk_prepare_enable(info->rtc_clk) // rtc clock enabled s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit s3c_rtc_setfreq() //then this will be called with clk disabled This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq(). Fixes: 24e14554 ("drivers/rtc/rtc-s3c.c: delete duplicate clock control") Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by:
Pankaj Dubey <pankaj.dubey@samsung.com> Tested-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Lv Zheng authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit e1191bd4 upstream. A regression is caused by the following commit: Commit: 02b771b6 Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations In this commit, using system workqueue causes that the maximum parallel executions of _Qxx can exceed 255. This violates the method reentrancy limit in ACPICA and generates the following error log: ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341) This patch creates a seperate workqueue and limits the number of parallel _Qxx evaluations down to a configurable value (can be tuned against number of online CPUs). Since EC events are handled after driver probe, we can create the workqueue in acpi_ec_init(). Fixes: 02b771b6 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations) Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691Reported-and-tested-by:
Helen Buus <ubuntu@hbuus.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit bb275705 upstream. On Intel Merrifield platform several PCI devices have a bogus configuration, i.e. the IRQ0 had been assigned to few of them. These are PCI root bridge, eMMC0, HS UART common registers, PWM, and HDMI. The actual interrupt line can be allocated to one device exclusively, in our case to eMMC0, the rest should cope without it and basically known drivers for them are not using interrupt line at all. Rework IRQ0 workaround, which was previously done to avoid conflict between eMMC0 and HS UART common registers, to behave differently based on the device in question, i.e. allocate interrupt line to eMMC0, but silently skip interrupt allocation for the rest except HS UART common registers which are not used anyway. With this rework IOSF MBI driver in particular would be used. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 39d9b77b ("x86/pci/intel_mid_pci: Work around for IRQ0 assignment") Link: http://lkml.kernel.org/r/1465842481-136852-1-git-send-email-andriy.shevchenko@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Chris Blake authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 9ac0108c upstream. Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have the same quirk for the Bus Reset. Fixes: c3e59ee4 ("PCI: Mark Atheros AR93xx to avoid bus reset") Signed-off-by:
Chris Blake <chrisrblake93@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
