- 29 Aug, 2016 10 commits
-
-
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:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
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:
AceLan Kao <acelan.kao@canonical.com> Acked-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 14 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:
Rafael J. Wysocki <rafael.j.wysocki@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:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 3ef06653 upstream. At first, we prefer to use mips clockevent device, so we decrease the rating of hpet clockevent device. For hpet, if HPET_MIN_PROG_DELTA (minimum delta of hpet programming) is too small and HPET_MIN_CYCLES (threshold of -ETIME checking) is too large, then hpet_next_event() can easily return -ETIME. After commit c6eb3f70 ("hrtimer: Get rid of hrtimer softirq") this will cause a RCU stall. So, HPET_MIN_PROG_DELTA must be sufficient that we don't re-trip the -ETIME check -- if we do, we will return -ETIME, forward the next event time, try to set it, return -ETIME again, and basically lock the system up. Meanwhile, HPET_MIN_CYCLES doesn't need to be too large, 16 cycles is enough. This solution is similar to commit f9eccf24 ("clocksource/drivers /vt8500: Increase the minimum delta"). By the way, this patch ensures hpet count/compare to be 32-bit long. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J . Hill <Steven.Hill@imgtec.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13819/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Huacai Chen authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 07d69579 upstream. Don't register r4k sched clock when CPUFREQ enabled because sched clock need a constant frequency. Signed-off-by:
-
Matt Redfearn authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 4f53989b upstream. Commit a168b8f1 ("MIPS: mm: Add MIPS R6 instruction encodings") added an incorrect definition of the redefined MIPSr6 cache instruction. Executing any kernel code including this instuction results in a reserved instruction exception and kernel panic. Fix the instruction definition. Fixes: a168b8f1Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13663/Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit db1bb44c upstream. We're always tracing IPv4 or IPv6 addresses, so we can save a lot of space on the ringbuffer by allocating the correct sockaddr size. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Fixes: 83a712e0 "sunrpc: add some tracepoints around ..." Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
KT Liao authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 2de4fcc6 upstream. Some ASUS laptops were shipped with touchpads that require to be woken up first, before trying to switch them into absolute reporting mode, otherwise touchpad would fail to work while flooding the logs with: elan_i2c i2c-ELAN1000:00: invalid report id data (1) Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and others. We detect such devices by checking the IC type and product ID numbers and adjusting order of operations accordingly. Signed-off-by:
KT Liao <kt.liao@emc.com.tw> Reported-by:
Chris Chiu <chiu@endlessm.com> Reported-by:
Vlad Glagolev <stealth@vaygr.net> Tested-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1615620 commit 410c29df upstream. If a Simple command is sent with a failure, target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE or TCM_INVALID_CDB_FIELD. So in the cases where target_setup_cmd_from_cdb returns an error, we never get far enough to call target_execute_cmd to increment simple_cmds. Since simple_cmds isn't incremented, the result of the failure from target_setup_cmd_from_cdb causes transport_generic_request_failure to decrement simple_cmds, due to call to transport_complete_task_attr. With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0. So when a subsequent command with an Ordered Task is sent, it causes a hang, since dev->simple_cmds is at -1. Tested-by:
-
