Michael Cyr [Fri, 26 Aug 2016 19:06:45 +0000 (14:06 -0500)]
UBUNTU: SAUCE: Return TCMU-generated sense data to fabric module
BugLink: http://bugs.launchpad.net/bugs/1615665
If an error status is passed to target_complete_cmd, then by default it
queues the command to target_complete_failure_work, which will generate
Logical Unit Communication Failure sense data, overwriting any sense data
already set in the command. This means that any sense data returned by
TCMU does not get returned to the fabric module.
This change implements a transport_complete function for target-user which
will set the SCF_TRANSPORT_TASK_SENSE flag if we have valid sense data,
which will cause target_complete_cmd to queue the command to
target_complete_ok_work instead of target_complete_failure_work.
Signed-off-by: Michael Cyr <mikecyr@linux.vnet.ibm.com> Reviewed-by: Andy Grover <agrover@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Chen Yu [Fri, 19 Aug 2016 17:25:57 +0000 (10:25 -0700)]
UBUNTU: SAUCE: PCI: Workaround to enable poweroff on Mac Pro 11
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: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: powerpc/pseries: Increase RMA size to 512MB.
BugLink: http://bugs.launchpad.net/bugs/1614309
When trying to boot large kernel and initrd images on large systems
(with hundreds of CPUs and Terabytes of memory), we sometimes run out
of memory for the flattened device tree (FDT).
Increase the memory allocated for the Real Mode Area (RMA) to 512MB to
allow more room for the FDT.
Ben Hutchings [Tue, 16 Aug 2016 16:27:00 +0000 (10:27 -0600)]
UBUNTU: SAUCE: security,perf: Allow further restriction of perf_event_open
https://lkml.org/lkml/2016/1/11/587
The GRKERNSEC_PERF_HARDEN feature extracted from grsecurity. Adds the
option to disable perf_event_open() entirely for unprivileged users.
This standalone version doesn't include making the variable read-only
(or renaming it).
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: Clear Linux: reduce e1000e boot time by tightening sleep ranges
The e1000e driver is a great user of the usleep_range() API,
and has any nice ranges that in principle help power management.
However the ranges that are used only during system startup are
very long (and can add easily 100 msec to the boot time) while
the power savings of such long ranges is irrelevant due to the
one-off, boot only, nature of these functions.
This patch shrinks some of the longest ranges to be shorter
(while still using a power friendly 1 msec range); this saves
100msec+ of boot time on my BDW NUCs
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Arjan van de Ven [Tue, 23 Jun 2015 06:26:52 +0000 (01:26 -0500)]
UBUNTU: SAUCE: Clear Linux: i8042: decrease debug message level to info
Author: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com> Signed-off-by: Jose Carlos Venegas Munoz <jos.c.venegas.munoz@intel.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 26 Oct 2012 16:36:24 +0000 (12:36 -0400)]
UBUNTU: SAUCE: UEFI: KEYS: Add a system blacklist keyring
This adds an additional keyring that is used to store certificates that
are blacklisted. This keyring is searched first when loading signed modules
and if the module's certificate is found, it will refuse to load. This is
useful in cases where third party certificates are used for module signing.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tim Gardner [Thu, 16 Jun 2016 06:41:35 +0000 (09:41 +0300)]
UBUNTU: SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
BugLink: http://bugs.launchpad.net/bugs/1593075
This is a better method for detecting the state of secure boot and
the MOKSBState override, as opposed to grepping status from the kernel log.
Both variables return 0 or 1. If secure_boot==0 then signed module
enforcement is not enabled. Likewise, if moksbstate_disabled==1 then
signed module enforcement is not enabled. The only conditions uder which
signed module enforcement is enabled is when secure_boot==1 and
moksbstate_disabled==0.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Tim Gardner [Mon, 18 Apr 2016 15:22:31 +0000 (09:22 -0600)]
UBUNTU: SAUCE: UEFI: Display MOKSBState when disabled
BugLink: http://bugs.launchpad.net/bugs/1571691
It would be much simpler if one could pass MOKSBState via a global variable,
but the the EFI bits appear to be managed and linked a bit differently then
a normal text section. Hence the shennanigans with boot_params.secure_boot.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Dave Young [Fri, 24 Jun 2016 13:34:14 +0000 (07:34 -0600)]
UBUNTU: SAUCE: UEFI: kexec/uefi: copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure boot
mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
In this state, the system is missing the protections provided by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub.
Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Thu, 3 Oct 2013 14:14:23 +0000 (10:14 -0400)]
UBUNTU: SAUCE: UEFI: MODSIGN: Support not importing certs from db
If a user tells shim to not use the certs/hashes in the UEFI db variable
for verification purposes, shim will set a UEFI variable called MokIgnoreDB.
Have the uefi import code look for this and not import things from the db
variable.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 26 Oct 2012 16:42:16 +0000 (12:42 -0400)]
UBUNTU: SAUCE: UEFI: MODSIGN: Import certificates from UEFI Secure Boot
Secure Boot stores a list of allowed certificates in the 'db' variable.
This imports those certificates into the system trusted keyring. This
allows for a third party signing certificate to be used in conjunction
with signed modules. By importing the public certificate into the 'db'
variable, a user can allow a module signed with that certificate to
load. The shim UEFI bootloader has a similar certificate list stored
in the 'MokListRT' variable. We import those as well.
In the opposite case, Secure Boot maintains a list of disallowed
certificates in the 'dbx' variable. We load those certificates into
the newly introduced system blacklist keyring and forbid any module
signed with those from loading.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dave Howells [Tue, 23 Oct 2012 13:36:28 +0000 (09:36 -0400)]
UBUNTU: SAUCE: UEFI: Add an EFI signature blob parser and key loader.
X.509 certificates are loaded into the specified keyring as asymmetric type
keys.
[labbott@fedoraproject.org: Drop KEY_ALLOC_TRUSTED] Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Fri, 20 Jun 2014 12:53:24 +0000 (08:53 -0400)]
UBUNTU: SAUCE: UEFI: hibernate: Disable in a signed modules environment
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it in
a secure modules environment.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Wed, 6 Feb 2013 00:25:05 +0000 (19:25 -0500)]
UBUNTU: SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode
A user can manually tell the shim boot loader to disable validation of
images it loads. When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set. Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Aug 2013 22:36:30 +0000 (18:36 -0400)]
UBUNTU: SAUCE: UEFI: Add option to automatically enforce module signatures when in Secure Boot mode
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Conflicts:
arch/x86/boot/compressed/eboot.c
Matthew Garrett [Fri, 8 Feb 2013 19:12:13 +0000 (11:12 -0800)]
UBUNTU: SAUCE: UEFI: x86: Restrict MSR access when module loading is restricted
Writing to MSRs should not be allowed if module loading is restricted,
since it could lead to execution of arbitrary code in kernel mode. Based
on a patch by Kees Cook.
Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Aug 2013 07:33:56 +0000 (03:33 -0400)]
UBUNTU: SAUCE: UEFI: kexec: Disable at runtime if the kernel enforces module loading restrictions
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Josh Boyer [Mon, 25 Jun 2012 23:57:30 +0000 (19:57 -0400)]
UBUNTU: SAUCE: UEFI: acpi: Ignore acpi_rsdp kernel parameter when module loading is restricted
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to circumvent any restrictions imposed on
loading modules. Disable it in that case.
Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 14:28:15 +0000 (09:28 -0500)]
UBUNTU: SAUCE: UEFI: Restrict /dev/mem and /dev/kmem when module loading is restricted
Allowing users to write to address space makes it possible for the kernel
to be subverted, avoiding module loading restrictions. Prevent this when
any restrictions have been imposed on loading modules.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 13:46:50 +0000 (08:46 -0500)]
UBUNTU: SAUCE: UEFI: asus-wmi: Restrict debugfs interface when module loading is restricted
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if any of
these features are enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Fri, 9 Mar 2012 13:39:37 +0000 (08:39 -0500)]
UBUNTU: SAUCE: UEFI: ACPI: Limit access to custom_method
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Matthew Garrett [Thu, 8 Mar 2012 15:35:59 +0000 (10:35 -0500)]
UBUNTU: SAUCE: UEFI: x86: Lock down IO port access when module security is enabled
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 [Thu, 8 Mar 2012 15:10:38 +0000 (10:10 -0500)]
UBUNTU: SAUCE: UEFI: PCI: Lock down BAR access when module security is enabled
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 <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Conflicts:
drivers/pci/syscall.c
Matthew Garrett [Fri, 9 Aug 2013 21:58:15 +0000 (17:58 -0400)]
UBUNTU: SAUCE: UEFI: Add secure_modules() call
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: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Steve Beattie [Tue, 10 May 2016 11:44:04 +0000 (12:44 +0100)]
UBUNTU: SAUCE: (no-up) disable -pie when gcc has it enabled by default
In Ubuntu 16.10, gcc's defaults have been set to build Position
Independent Executables (PIE) on amd64 and ppc64le (gcc was configured
this way for s390x in Ubuntu 16.04 LTS). This breaks the kernel build on
amd64. The following patch disables pie for x86 builds (though not yet
verified to work with gcc configured to build PIE by default i386 --
we're not planning to enable it for that architecture).
The intent is for this patch to go upstream after expanding it to
additional architectures where needed, but I wanted to ensure that
we could build 16.10 kernels first. I've successfully built kernels
and booted them with this patch applied using the 16.10 compiler.
Patch is against yakkety.git, but also applies with minor movement
(no fuzz) against current linus.git.
Signed-off-by: Steve Beattie <steve.beattie@canonical.com>
[apw@canonical.com: shifted up so works in arch/<arch/Makefile.] BugLink: http://bugs.launchpad.net/bugs/1574982 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario where kdump kenrel
after a crash can boot up on an non-zero boot cpu. The paca structure
allocation depends on value of nr_cpus and is indexed using logical cpu
ids. This definetly will be an issue if boot cpu id > nr_cpus
This patch modifies allocate_pacas() and smp_setup_cpu_maps() to
accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids.
This change would help to reduce the memory reservation requirement for
kdump on ppc64.
BugLink: http://bugs.launchpad.net/bugs/1558828
In case of ARCH_THUNDER, there is a need to allocate the GICv3 ITS table
which is bigger than the allowed max order. So we are forcing it only in
case of 4KB page size.
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> Signed-off-by: Robert Richter <rrichter@cavium.com>
[ dannf: Depend on ARM64_4K_PAGES instead of !ARM64_64K_PAGES now that
16K pages are available ] Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mehmet Kayaalp [Thu, 10 Mar 2016 21:22:13 +0000 (16:22 -0500)]
UBUNTU: SAUCE: (noup) KEYS: Support for inserting a certificate into x86 bzImage
BugLink: http://bugs.launchpad.net/bugs/1558553
The config option SYSTEM_EXTRA_CERTIFICATE reserves space in vmlinux file,
which is compressed to create the self-extracting bzImage. This patch adds the
capability of extracting the vmlinux, inserting the certificate, and
repackaging the result into a bzImage.
It only works if the resulting compressed vmlinux is smaller than the original.
Otherwise re-linking would be required. To make the reserved space allocate
actual space in bzImage, a null key is inserted into vmlinux before creating
the bzImage:
make vmlinux
scripts/insert-sys-cert -b vmlinux -c /dev/null
make bzImage
After null key insertion, the script populates the rest of the reserved space
with random bytes, which have poor compression. After receiving a bzImage that
is created this way, actual certificate can be inserted into the bzImage:
Seth Forshee [Tue, 19 Jan 2016 16:20:43 +0000 (10:20 -0600)]
UBUNTU: SAUCE: cred: Add clone_cred() interface
This interface returns a new set of credentials which is an exact
copy of another set. Also update prepare_kernel_cred() to use
this function instead of duplicating code.
Andy Whitcroft [Fri, 27 Nov 2015 17:38:30 +0000 (17:38 +0000)]
UBUNTU: SAUCE: (no-up) add compat_uts_machine= kernel command line override
We wish to use the arm64 buildds to build armhf binaries in 32bit chroots.
To make this work we need uname to return armv7l machine type. To achieve
this add a kernel command line override for the 32bit machine type.
Add compat_uts_machine=<type> to allow the LINUX32 personality to return
that type for uname.
Switch to a single tunnel for all mappings, this removes the limitations
on how many mappings each tunnel can handle, and therefore how many Fan
slices each local address may hold.
NOTE: This introduces a new kernel netlink interface which needs updated
iproute2 support.
BugLink: http://bugs.launchpad.net/bugs/1470091 Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Conflicts:
include/net/ip_tunnels.h
Tetsuo Handa [Sat, 29 Mar 2014 06:39:24 +0000 (15:39 +0900)]
UBUNTU: SAUCE: kthread: Do not leave kthread_create() immediately upon SIGKILL.
Commit 786235ee "kthread: make kthread_create() killable" changed to
leave kthread_create() as soon as receiving SIGKILL. But this change
caused boot failures if systemd-udevd worker process received SIGKILL
due to systemd's hardcoded 30 seconds timeout while loading fusion
driver using finit_module() [1].
Linux kernel people think that the systemd's hardcoded timeout is a
systemd bug. But systemd people think that loading of kernel module
needs more than 30 seconds is a kernel module's bug.
Although Linux kernel people are expecting fusion driver module not
to take more than 30 seconds, it will definitely not in time for
trusty kernel. Also, nobody can prove that fusion driver module is
the only case which is affected by commit 786235ee.
Therefore, this patch changes kthread_create() to wait for up to 10
seconds after receiving SIGKILL, unless chosen by the OOM killer,
in order to give the kthreadd a chance to complete the request.
The side effect of this patch is that current thread's response to
SIGKILL is delayed for a bit (likely less than a second, unlikely
10 seconds).
Andy Whitcroft [Wed, 16 Apr 2014 18:40:57 +0000 (19:40 +0100)]
UBUNTU: SAUCE: vt -- maintain bootloader screen mode and content until vt switch
Introduce a new VT mode KD_TRANSPARENT which endevours to leave the current
content of the framebuffer untouched. This allows the bootloader to insert
a graphical splash and have the kernel maintain it until the OS splash
can take over. When we finally switch away (either through programs like
plymouth or manually) the content is lost and the VT reverts to text mode.
BugLink: http://bugs.launchpad.net/bugs/1210848
On an ASUSTek G60JX laptop, the intel_ips driver spams the log with a warning message: "ME failed to update for more than 1s, likely hung". This ME doesn't support the feature, so requesting it be blacklisted for now.
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Nick Jenkins <tech.crew.jenkins@gmail.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() (for v3.7+)
BugLink: http://bugs.launchpad.net/bugs/462111
This patch uses TRACE_EVENT to add tracepoints for the open(),
exec() and uselib() syscalls so that ureadahead can cheaply trace
the boot sequence to determine what to read to speed up the next.
It's not upstream because it will need to be rebased onto the syscall
trace events whenever that gets merged, and is a stop-gap.
[apw@canonical.com: updated for v3.7 and later.]
[apw@canonical.com: updated for v3.19 and later.] BugLink: http://bugs.launchpad.net/bugs/1085766 Signed-off-by: Scott James Remnant <scott@ubuntu.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Conflicts:
fs/open.c
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Xiangliang Yu [Thu, 7 Mar 2013 14:29:16 +0000 (14:29 +0000)]
UBUNTU: SAUCE: (no-up) PCI: fix system hang issue of Marvell SATA host controller
BugLink: http://bugs.launchpad.net/bugs/1159863
Hassle someone if this patch hasn't been removed by 13.10.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1159863/comments/2
Fix system hang issue: if first accessed resource file of BAR0 ~
BAR4, system will hang after executing lspci command
Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Instead of SEMI_MT, present a full mt interface with simulated contact
positions for >=3 fingers. Enables e.g. multi-finger tap and drag for
old userspace applications which only count the contact positions.
Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1084192
Reverting this in the kernel as opposed to adding a sysctl
to the procps package guarentees that this regression will be
propagated to the Raring LTS kernel.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log