lp:~kamalmostafa/ubuntu/+source/linux-aws/+git/bionic

Owned by Kamal Mostafa
Get this repository:
git clone https://git.launchpad.net/~kamalmostafa/ubuntu/+source/linux-aws/+git/bionic
Only Kamal Mostafa can upload to this repository. If you are Kamal Mostafa please log in for upload directions.

Branches

Name Last Modified Last Commit
aws-0xefa1 2020-09-23 14:52:04 UTC
RDMA/efa: Add EFA 0xefa1 PCI ID

Author: Gal Pressman
Author Date: 2020-07-22 14:03:12 UTC

RDMA/efa: Add EFA 0xefa1 PCI ID

BugLink: https://bugs.launchpad.net/bugs/1896791

Add support for 0xefa1 devices.

Link: https://lore.kernel.org/r/20200722140312.3651-5-galpress@amazon.com
Reviewed-by: Shadi Ammouri <sammouri@amazon.com>
Reviewed-by: Yossi Leybovich <sleybo@amazon.com>
Signed-off-by: Gal Pressman <galpress@amazon.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(backported from commit d4f9cb5c5b224dca3ff752c1bb854250bf114944)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

master 2020-09-21 18:17:05 UTC
UBUNTU: Ubuntu-aws-4.15.0-1084.88

Author: William Breathitt Gray
Author Date: 2020-09-21 18:17:05 UTC

UBUNTU: Ubuntu-aws-4.15.0-1084.88

Signed-off-by: William Breathitt Gray <william.gray@canonical.com>

lp1889282-aws-pvtime 2020-07-28 17:16:13 UTC
arm64: Retrieve stolen time as paravirtualized guest

Author: Steven Price
Author Date: 2019-10-21 15:28:23 UTC

arm64: Retrieve stolen time as paravirtualized guest

BugLink: https://bugs.launchpad.net/bugs/1889282

Enable paravirtualization features when running under a hypervisor
supporting the PV_TIME_ST hypercall.

For each (v)CPU, we ask the hypervisor for the location of a shared
page which the hypervisor will use to report stolen time to us. We set
pv_time_ops to the stolen time function which simply reads the stolen
value from the shared page for a VCPU. We guarantee single-copy
atomicity using READ_ONCE which means we can also read the stolen
time for another VCPU than the currently running one while it is
potentially being updated by the hypervisor.

Signed-off-by: Steven Price <steven.price@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit e0685fa228fdaf386f82ac0d64b2d6f3e0ddd588)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

aws-5.4-next 2020-07-14 05:25:27 UTC
UBUNTU: Ubuntu-aws-5.4-5.4.0-1020.20~18.04.2

Author: Khaled El Mously
Author Date: 2020-07-10 07:07:59 UTC

UBUNTU: Ubuntu-aws-5.4-5.4.0-1020.20~18.04.2

Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>

lp1859192/graviton-entropy 2020-01-10 16:29:48 UTC
efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness

Author: Dominik Brodowski
Author Date: 2019-10-29 17:37:52 UTC

efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness

BugLink: https://bugs.launchpad.net/bugs/1859192

Commit 428826f5358c ("fdt: add support for rng-seed") introduced
add_bootloader_randomness(), permitting randomness provided by the
bootloader or firmware to be credited as entropy. However, the fact
that the UEFI support code was already wired into the RNG subsystem
via a call to add_device_randomness() was overlooked, and so it was
not converted at the same time.

Note that this UEFI (v2.4 or newer) feature is currently only
implemented for EFI stub booting on ARM, and further note that
CONFIG_RANDOM_TRUST_BOOTLOADER must be enabled, and this should be
done only if there indeed is sufficient trust in the bootloader
_and_ its source of randomness.

[ ardb: update commit log ]

Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191029173755.27149-4-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 18b915ac6b0ac5ba7ded03156860f60a9f16df2b)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

arm-erratum-1542419 2019-12-11 00:00:38 UTC
UBUNTU: aws: [Config] updateconfigs for ARM64_ERRATUM_1542419

Author: Kamal Mostafa
Author Date: 2019-12-06 18:13:47 UTC

UBUNTU: aws: [Config] updateconfigs for ARM64_ERRATUM_1542419

BugLink: https://bugs.launchpad.net/bugs/1855729

Signed-off-by: Kamal Mostafa <kamal@canonical.com>

arm-update-2 2019-12-06 20:17:31 UTC
TEST KERNEL 4.15.0-1057.59+neo

Author: Kamal Mostafa
Author Date: 2019-12-06 20:17:31 UTC

TEST KERNEL 4.15.0-1057.59+neo

arm-update-rebase 2019-11-14 22:14:42 UTC
arm64: Avoid flush_icache_range() in alternatives patching code

Author: Will Deacon
Author Date: 2018-06-22 08:31:15 UTC

arm64: Avoid flush_icache_range() in alternatives patching code

BugLink: https://bugs.launchpad.net/bugs/1850675

The implementation of flush_icache_range() includes instruction sequences
which are themselves patched at runtime, so it is not safe to call from
the patching framework.

This patch reworks the alternatives cache-flushing code so that it rolls
its own internal D-cache maintenance using DC CIVAC before invalidating
the entire I-cache after all alternatives have been applied at boot.
Modules don't cause any issues, since flush_icache_range() is safe to
call by the time they are loaded.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Rohit Khanna <rokhanna@nvidia.com>
Cc: Alexander Van Brunt <avanbrunt@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 429388682dc266e7a693f9c27e3aabd341d55343)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

arm-update 2019-10-30 17:43:22 UTC
arm64: Avoid flush_icache_range() in alternatives patching code

Author: Will Deacon
Author Date: 2018-06-22 08:31:15 UTC

arm64: Avoid flush_icache_range() in alternatives patching code

BugLink: https://bugs.launchpad.net/bugs/1850675

The implementation of flush_icache_range() includes instruction sequences
which are themselves patched at runtime, so it is not safe to call from
the patching framework.

This patch reworks the alternatives cache-flushing code so that it rolls
its own internal D-cache maintenance using DC CIVAC before invalidating
the entire I-cache after all alternatives have been applied at boot.
Modules don't cause any issues, since flush_icache_range() is safe to
call by the time they are loaded.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Rohit Khanna <rokhanna@nvidia.com>
Cc: Alexander Van Brunt <avanbrunt@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 429388682dc266e7a693f9c27e3aabd341d55343)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

efa-140-test 2019-09-16 16:44:44 UTC
TEST KERNEL

Author: Kamal Mostafa
Author Date: 2019-09-16 16:44:44 UTC

TEST KERNEL

efa-140 2019-09-16 16:15:30 UTC
UBUNTU: SAUCE: linux/efa: Bump driver version to 1.4.0

Author: Gal Pressman
Author Date: 2019-09-05 13:45:32 UTC

UBUNTU: SAUCE: linux/efa: Bump driver version to 1.4.0

BugLink: https://bugs.launchpad.net/bugs/1844166

Reviewed-by: Firas JahJah <firasj@amazon.com>
Reviewed-by: Yossi Leybovich <sleybo@amazon.com>
Signed-off-by: Gal Pressman <galpress@amazon.com>
Reference: https://github.com/amzn/amzn-drivers/tree/master/kernel/linux/efa
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

a1metal-part2 2019-08-23 21:19:38 UTC
TEST KERNEL 4.15.0-1047.49+a1metal2

Author: Kamal Mostafa
Author Date: 2019-08-23 21:19:38 UTC

TEST KERNEL 4.15.0-1047.49+a1metal2

graviton-lp1834962 2019-07-11 19:09:24 UTC
UBUNTU: SAUCE: [aws] arm64: acpi/pci: invoke _DSM whether to preserve firmwar...

Author: Frank van der Linden
Author Date: 2019-05-31 23:14:06 UTC

UBUNTU: SAUCE: [aws] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup

BugLink: https://bugs.launchpad.net/bugs/1834962

On arm64 ACPI systems, we unconditionally reconfigure the entire PCI
hierarchy at boot. This is a departure from what is customary on ACPI
systems, and may break assumptions in some places (e.g., EFIFB), that
the kernel will leave BARs of enabled PCI devices where they are.

Given that PCI already specifies a device specific ACPI method (_DSM)
for PCI root bridge nodes that tells us whether the firmware thinks
the configuration should be left alone, let's sidestep the entire
policy debate about whether the PCI configuration should be preserved
or not, and put it under the control of the firmware instead.

[not upstream, taken from https://patchwork.kernel.org/patch/9675707/]

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

hibernate-lp1831940c 2019-06-26 18:40:55 UTC
netlink: Don't shift on 64 for ngroups

Author: Dmitry Safonov
Author Date: 2018-08-05 00:35:53 UTC

netlink: Don't shift on 64 for ngroups

BugLink: https://bugs.launchpad.net/bugs/1831940

It's legal to have 64 groups for netlink_sock.

As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.

The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.

Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058)
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

hibernate-lp1831940 2019-06-18 19:00:57 UTC
netlink: Don't shift on 64 for ngroups

Author: Dmitry Safonov
Author Date: 2018-08-05 00:35:53 UTC

netlink: Don't shift on 64 for ngroups

BugLink: https://bugs.launchpad.net/bugs/1831940

It's legal to have 64 groups for netlink_sock.

As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.

The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.

Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

hibernate-master 2019-05-24 17:08:10 UTC
TEST KERNEL 4.15.0-1040.42+hibernate20150524

Author: Kamal Mostafa
Author Date: 2019-05-21 16:15:58 UTC

TEST KERNEL 4.15.0-1040.42+hibernate20150524

aws-hibernation-lp1804533 2018-11-21 22:04:39 UTC
UBUNTU: SAUCE [aws] PM / hibernate: update the resume offset on SNAPSHOT_SET_...

Author: Aleksei Besogonov
Author Date: 2017-10-27 17:59:18 UTC

UBUNTU: SAUCE [aws] PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA

BugLink: http://bugs.launchpad.net/bugs/1804533

The SNAPSHOT_SET_SWAP_AREA is supposed to be used to set the hibernation
offset on a running kernel to enable hibernating to a swap file.
However, it doesn't actually update the swsusp_resume_block variable. As
a result, the hibernation fails at the last step (after all the data is
written out) in the validation of the swap signature in
mark_swapfiles().

Before this patch, the command line processing was the only place where
swsusp_resume_block was set.

Signed-off-by: Aleksei Besogonov <cyberax@amazon.com>
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Anchal Agarwal <anchalag@amazon.com>
Reviewed-by: Munehisa Kamata <kamatam@amazon.com>
Reviewed-by: Eduardo Valentin <eduval@amazon.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

ena-1.5.0K 2018-06-01 17:06:13 UTC
net: ena: Eliminate duplicate barriers on weakly-ordered archs

Author: Sinan Kaya
Author Date: 2018-03-25 14:39:21 UTC

net: ena: Eliminate duplicate barriers on weakly-ordered archs

BugLink: http://bugs.launchpad.net/bugs/1774490

Code includes barrier() followed by writel(). writel() already has a
barrier on some architectures like arm64.

This ends up CPU observing two barriers back to back before executing the
register write.

Create a new wrapper function with relaxed write operator. Use the new
wrapper when a write is following a barrier().

Since code already has an explicit barrier call, changing writel() to
writel_relaxed() and adding mmiowb() for ordering protection.

Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6d2e1a8d5e25e5f4563f5ea24bcb5da1ae261b26)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>

118 of 18 results
This repository contains Public information 
Everyone can see this information.

Subscribers