- 06 Apr, 2016 40 commits
-
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 Any hardware that can potentially generate DMA has to be locked down from userspace in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by:
-
Matthew Garrett authored
BugLink: http://bugs.launchpad.net/bugs/1566221 Provide a single call to allow kernel code to determine whether the system has been configured to either disable module loading entirely or to load only modules signed with a trusted key. Bugzilla: N/A Upstream-status: Fedora mustard. Replaced by securelevels, but that was nak'd Signed-off-by:
-
Andy Whitcroft authored
Signed-off-by:Andy Whitcroft <apw@canonical.com>
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1565967 Add a new driver which exposes a root PCI bus whenever a PCI Express device is passed through to a guest VM under Hyper-V. The device can be single- or multi-function. The interrupts for the devices are managed by an IRQ domain, implemented within the driver. [bhelgaas: fold in race condition fix (http://lkml.kernel.org/r/1456340196-13717-1-git-send-email-jakeo@microsoft.com)] Signed-off-by:
Jake Oshins <jakeo@microsoft.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> (cherry picked from commit 4daace0d) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1565967Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1565967 If pci_host_bridge_msi_domain() can't find an IRQ domain through the OF tree, try to look it up directly through the fwnode_handle. [bhelgaas: changelog] Signed-off-by:
-
Jake Oshins authored
BugLink: http://bugs.launchpad.net/bugs/1565967 Add an fwnode_handle to the x86 struct pci_sysdata, which will be used to locate an IRQ domain associated with a root PCI bus. [bhelgaas: changelog] Signed-off-by:
-
Srinivas Pandruvada authored
BugLink: http://bugs.launchpad.net/bugs/1559923 There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake-based systems by the Intel P-states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts use the thermal LVT which can be handled by Linux natively, but on the affected Skylake-based systems SMM will respond to it by default. This is a problem for several reasons: - On the affected systems the SMM thermal LVT handler is broken (it will crash when invoked) and a BIOS update is necessary to fix it. - With thermal interrupt handled in SMM we lose all of the reporting features of the arch/x86/kernel/cpu/mcheck/therm_throt driver. - Some thermal drivers like x86-package-temp depend on the thermal threshold interrupts signaled via the thermal LVT. - The HWP interrupts are useful for debugging and tuning performance (if the kernel can handle them). The native handling of thermal interrupts needs to be enabled because of that. This requires some way to tell SMM that the OS can handle thermal interrupts. That can be done by using _OSC/_PDC in processor scope very early during ACPI initialization. The meaning of _OSC/_PDC bit 12 in processor scope is whether or not the OS supports native handling of interrupts for Collaborative Processor Performance Control (CPPC) notifications. Since on HWP-capable systems CPPC is a firmware interface to HWP, setting this bit effectively tells the firmware that the OS will handle thermal interrupts natively going forward. For details on _OSC/_PDC refer to: http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html To implement the _OSC/_PDC handshake as described, introduce a new function, acpi_early_processor_osc(), that walks the ACPI namespace looking for ACPI processor objects and invokes _OSC for them with bit 12 in the capabilities buffer set and terminates the namespace walk on the first success. Also modify intel_thermal_interrupt() to clear HWP status bits in the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents them from firing continuously). Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject & changelog, function rename ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit a2121167) Signed-off-by:
-
Colin Ian King authored
Fixes two issues: * Add support 32 bit FS_IOC32_{GET|SET}FLAGS compat ioctls for (powerpc64 big endian mode) * Fix aarch64 compilation, missing hrtime_t and timestruc_t types BugLink: http://bugs.launchpad.net/bugs/1564591Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on which _release variants can be built. To avoid superfluous barriers in _acquire variants, we implement these operations with assembly code rather use __atomic_op_acquire() to build them automatically. For the same reason, we keep the assembly implementation of fully ordered cmpxchg operations. However, we don't do the similar for _release, because that will require putting barriers in the middle of ll/sc loops, which is probably a bad idea. Note cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed are not compiler barriers. Signed-off-by:
Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 56c08e6d) Signed-off-by:
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 Implement xchg{,64}_relaxed and atomic{,64}_xchg_relaxed, based on these _relaxed variants, release/acquire variants and fully ordered versions can be built. Note that xchg{,64}_relaxed and atomic_{,64}_xchg_relaxed are not compiler barriers. Signed-off-by:
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 On powerpc, acquire and release semantics can be achieved with lightweight barriers("lwsync" and "ctrl+isync"), which can be used to implement __atomic_op_{acquire,release}. For release semantics, since we only need to ensure all memory accesses that issue before must take effects before the -store- part of the atomics, "lwsync" is what we only need. On the platform without "lwsync", "sync" should be used. Therefore in __atomic_op_release() we use PPC_RELEASE_BARRIER. For acquire semantics, "lwsync" is what we only need for the similar reason. However on the platform without "lwsync", we can use "isync" rather than "sync" as an acquire barrier. Therefore in __atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on UP, "lwsync" if available and "isync" otherwise. Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other variants with these helpers. Signed-off-by:
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 Some architectures may have their special barriers for acquire, release and fence semantics, so that general memory barriers(smp_mb__*_atomic()) in the default __atomic_op_*() may be too strong, so allow architectures to define their own helpers which can overwrite the default helpers. Signed-off-by:
-
David Leonard authored
Fixed invocation of dh_shlibdeps when cross-compiling with do_linux_tools=true. Without being told where to find the crossdev libs, dh_shlibdeps will emit these warnings and fail the linux-tools package: Debug: binary-acm7xxx ... dh_shlibdeps -plinux-headers-4.4.0-15-generic arm-linux-gnueabihf-objdump: .../asn1_compiler: File format not recognized arm-linux-gnueabihf-objdump: .../extract-cert: File format not recognized ... For example: archtriple=arm-linux-gnueabihf flavour=generic dpkg-architecture -t $archtriple -c fakeroot \ debian/rules \ binary-$flavour binary-perarch \ AUTOBUILD=true \ abi_suffix= \ do_linux_tools=true \ do_tools=true \ do_tools_usbip=false \ do_tools_cpupower=false \ do_tools_perf=true \ do_tools_x86=false Signed-off-by:David Leonard <david.leonard@opengear.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1564206Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1546439 The initialization of partition's percpu_ref should have been done before sending out KOBJ_ADD, which may cause userspace to read partition table. This patch should fix this issue. Reported-by:
Naveen Kaje <nkaje@codeaurora.org> Fixes: 6c71013e(block: partition: convert percpu ref) Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Serge Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1563921 our mountinfo output now shows 'nsroot='. If userspace like criu copy/pastes mount options from there into a new mount command, we should ignore it. Signed-off-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Tested-by:
Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Tim Gardner authored
cking> so, all the ZFS tests on powerpc64 pass except one test, which is ioctl FS_IOC_GETFLAGS where the cmd is being barfed up somewhere in the ioctl 32/64 thunking. I've filed a bug upstream. Since that ioctl is not frequently used, I think we should enable powerpc64 and fix up the ioctl as a SRU later on. Signed-off-by: -
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1563688 During hot add, vmbus_device_register() is called from vmbus_onoffer(), on the same workqueue as the subchannel offer message work-queue, so subchannel offer won't be processed until the vmbus_device_register()/... /netvsc_probe() is done. Also, vmbus_device_register() is called with channel_mutex locked, which prevents subchannel processing too. So the "waiting for sub-channel processing" will not success in hot add case. But, in usual module loading, the netvsc_probe() is called from different code path, and doesn't fail. This patch resolves the deadlock during NIC hot-add, and speeds up NIC loading time. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit d66ab514) Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1547231 Commit b7643757 ("procfs: mark thread stack correctly in proc/<pid>/maps") added [stack:TID] annotation to /proc/<pid>/maps. Finding the task of a stack VMA requires walking the entire thread list, turning this into quadratic behavior: a thousand threads means a thousand stacks, so the rendering of /proc/<pid>/maps needs to look at a million combinations. The cost is not in proportion to the usefulness as described in the patch. Drop the [stack:TID] annotation to make /proc/<pid>/maps (and /proc/<pid>/numa_maps) usable again for higher thread counts. The [stack] annotation inside /proc/<pid>/task/<tid>/maps is retained, as identifying the stack VMA there is an O(1) operation. Siddesh said: "The end users needed a way to identify thread stacks programmatically and there wasn't a way to do that. I'm afraid I no longer remember (or have access to the resources that would aid my memory since I changed employers) the details of their requirement. However, I did do this on my own time because I thought it was an interesting project for me and nobody really gave any feedback then as to its utility, so as far as I am concerned you could roll back the main thread maps information since the information is available in the thread-specific files" Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Cc: Shaohua Li <shli@fb.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 65376df5) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 drivers/char/tpm/tpm_tis.c:838: warning: ‘tpm_tis_resume’ defined but not used Reported-by:
James Morris <jmorris@namei.org> Fixes: 00194826 ("tpm_tis: Clean up the force=1 module parameter") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> cc: stable@vger.kernel.org (cherry picked from commit 2cb6d646) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Wrong call order. Reported-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Fixes: 74d6b3ceSigned-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 In all cases use dev_name() for the mapped resources. This is both for sake of consistency and also with some platforms resource name given by ACPI object seems to return garbage. Signed-off-by:
-
Harald Hoyer authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The commit 0cc698af ("vTPM: support little endian guests") copied the event, but without the event data, did an endian conversion on the size and tried to output the event data from the copied version, which has only have one byte of the data, resulting in garbage event data. [jarkko.sakkinen@linux.intel.com: fixed minor coding style issues and renamed the local variable tempPtr as temp_ptr now that there is an excuse to do this.] Signed-off-by:
Harald Hoyer <harald@redhat.com> Fixes: 0cc698af ("vTPM: support little endian guests") Reviewed-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Call put_device() and return error code if devm_add_action() fails. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 It's better to set the continueSession attribute for the unseal operation so that the session object is not removed as a side-effect when the operation is successful. Since a user process created the session, it should be also decide when the session is destroyed. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 If the initialization fails before tpm_chip_register(), put_device() will be not called, which causes release callback not to be called. This patch fixes the issue by adding put_device() to devres list of the parent device. Fixes: 313d21ee ("tpm: device class for tpm") Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Fixed the rollback and gave more self-documenting names for the functions. Fixes: d972b052 ("tpm: fix call order in tpm-chip.c") Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 To support the force mode in tpm_tis we need to use resource locking in tpm_crb as well, via devm_ioremap_resource. The light restructuring better aligns crb and tis and makes it easier to see the that new changes make sense. The control area and its associated buffers do not always fall in the range of the iomem resource given by the ACPI object. This patch fixes the issue by mapping the buffers if this is the case. [jarkko.sakkinen@linux.intel.com: squashed update described in the last paragraph.] Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 ioread32 and readl are defined to read from PCI style memory, ie little endian and return the result in host order. On platforms where a swap is required ioread32/readl do the swap internally (eg see ppc). Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The TPM core has long assumed that every device has a driver attached, however the force path was attaching the TPM core outside of a driver context. This isn't generally reliable as the user could detatch the driver using sysfs or something, but commit b8b2c7d8 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally") forced the issue by leaving the driver pointer NULL if there is no probe. Rework the TPM setup to create a platform device with resources and then allow the driver core to naturally bind and probe it through the normal mechanisms. All this structure is needed anyhow to enable TPM for OF environments. Finally, since the entire flow is changing convert the init/exit to use the modern ifdef-less coding style when possible Reported-by:
"Wilck, Martin" <martin.wilck@ts.fujitsu.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 This does a request_resource under the covers which means tis holds a lock on the memory range it is using so other drivers cannot grab it. When doing probing it is important to ensure that other drivers are not using the same range before tis starts touching it. To do this flow the actual struct resource from the device right through to devm_ioremap_resource. This ensures all the proper resource meta-data is carried down. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 If the ACPI tables do not declare a memory resource for the TPM2 then do not just fall back to the x86 default base address. Also be stricter when checking the ancillary TPM2 ACPI data and error out if any of this data is wrong rather than blindly assuming TPM1. Fixes: 399235dc ("tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0") Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Instead of clearing the global interrupts flag when any device does not have an interrupt just pass -1 through tpm_info.irq. The only thing that asks for autoprobing is the force=1 path. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 include/acpi/actbl2.h is the proper place for these definitions and the needed TPM2 ones have been there since commit 413d4a6d ("ACPICA: Update TPM2 ACPI table") This also drops a couple of le32_to_cpu's for members of this table, the existing swapping was not done consistently, and the standard used by other Linux callers of acpi_get_table is unswapped. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 In my original patch sealing with policy was done with dynamically allocated buffer that I changed later into an array so the checks in tpm2-cmd.c became invalid. This patch fixes the issue. Fixes: 5beb0c43 ("keys, trusted: seal with a TPM2 authorization policy") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jerry Snitselaar authored
BugLink: http://bugs.launchpad.net/bugs/1398274 tpm_tis.c already gets actbl2.h via linux/acpi.h -> acpi/acpi.h -> acpi/actbl.h -> acpi/actbl2.h, so the direct include in tpm_tis.c is not needed. Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Acked-by:
-
Dasaratharaman Chandramouli authored
BugLink: http://bugs.launchpad.net/bugs/1461365 Enables "Intel(R) Xeon Phi(TM) Processor x200 Product Family" support, formerly code-named KNL. It is based on modified Intel Atom Silvermont microarchitecture. Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> [micah.barany@intel.com: adjusted values of residency and latency] Signed-off-by:
Micah Barany <micah.barany@intel.com> [hubert.chrzaniuk@intel.com: removed deprecated CPUIDLE_FLAG_TIME_VALID flag] Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
Pawel Karczewski <pawel.karczewski@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> (cherry picked from commit 281baf7a) Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1563485 While profiling the cxlflash_queuecommand() path under a heavy load it was found that number of retries to find cmd_room was fairly high. There are two problems with the current back-off: a) It starts with a udelay of 0 b) It backs-off linearly Tried several approaches (a higher multiple 10*n, 100*n, as well as n^2, 2^n) and found that the exponential back-off(2^n) approach had the least overall cost. Cost as being defined as overall time spent waiting. The fix is to change the linear back-off to an exponential back-off. This solution also takes care of the problem with the initial delay (starts with 1 usec). Signed-off-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
-
